Starting with SUSE Linux Enterprise Server 10, Novell delivers Apache Geronimo as J2EE Application Server. JBoss got dropped from the distribution, but Novell committed themselves to continue support for JBoss.
Allegedly, license issues caused Novell to switch application servers, but I don't get that argument since JBoss as well as its companion products are LGPL licensed. I can't imagine a problem arising from that.
I think it's more of a competition thing with Red Hat, but that's okay. Competition is good for customers.
Update, 2006-07-20: According to Computer Business Review, it's not about the application server's licensing but about that of third party components. Novell's director of marketing for Linux and open platform solutions, Justin Steinman, explained:
As part of the SUSE Linux Enterprise development process, we evaluate the licensing for each package that we ship in our distribution. While packages like JBoss are distributed under the LGPL license, there are many components which are proprietary technologies from third parties," he stated.
"We found several components in JBoss4 that fit this profile. We checked with JBoss and the two areas in question, the SRP security extensions and the application client, ship under licenses that have questionable redistribution rights for Novell," he added.
Everytime I discover that I just made quite a blunder, there comes that hot feeling rushing fast from my stomach up to my head. But I guess that's only a fraction of how that poor bloke at Plusnet must have felt when he realised that the storage system he just reconfigured (sending all data to nirvana in the process) wasn't the backup system but actually the productive one
That's a situation where I would consider taking that katana sword off the wall...
These days, everyone and his dog are getting their own Web 2.0 service online. And finally, there's hardware to base your Poopr or Sneezr or whatchamacallit on: "Thumper", the harddisk-munching and O'Reilly-approved Web 2.0 server from Sun!
Seriously, folks, what's so "Web 2.0" about this X4500, as its official name is? Sure, it's impressive, with its high performance storage capacity of up to 24TB in a single case. But "Web 2.0 server", that's cheesy unless it does social networking with other servers, tags my network cables automatically and offers an AJAX management web interface. :-)
But, since it has some interesting features, I'm trying to get my hands on one for some tests. And I'm sure that Ralf will publish a review afterwards.
I just replaced my ever growing blogroll list by a Grazr panel.
It's been a busy week -- much to do at the company and CAJ meetings on the Monday, Tuesday and Wednesday evenings. That's why I had no time to do some blogging (among other things). But heeere comes the weekend!
Yesterday evening was occupied as well: I went to Stuttgart for a meeting of the local Java User Group. Its JBoss SIG(Special Interest Group) had organized a talk about JBoss Cache held by Bela Ban, project lead for JGroups and JBoss Cache
Bela gave an interesting overview of how to replicate data across a cluster of application server instances using JBoss Cache in its two incarnations, the Tree Cache and the POJO Cache. The Tree Cache divides cachable data into hierarchical nodes with attributes that can be replicated indivually, thus preventing the replication of huge data sets. The POJO Cache ensures that every change of an object gets replicated once the object has been registered in the distributed cache.
Cache instances can be connected to a distributed tree much like a HTTP cache hierarchy can be built with Squid. At what time the replication of changes actually gets done depends on if the changes are made in a transaction context. If not, replication happens immediately. Inside a transaction, replication occurs not until the transaction is commited.
Cache distribution can be extended by cache persistence where cache data is written to a filesystem or database. This provides the possibility of "swapping" data on a cache host or even between cache hosts.
Locking is crucial point in distributed data storage and JBoss offers two opposite strategies, optimistic and pessimistic locking.
When Bela showed a diagram depicting that JBoss HTTP Sessions are based on JBoss Cache as well, I first concluded that this facilitated using a simple load balancer distributing HTTP requests randomly between JBoss instances. JBoss Cache should make sure that every instance can handle every current HTTP session, after all. But Bela pointed out that HTTP session should be sticky to one host each because the cache data isn't evenly distributed but gravitates to where it's used the most.
It was an interesting talk supplemented by a small live demonstration. Bela certainly knows what he's talking about. It seems to me that JBoss Cache is a well thought-out solution to distributed data storage.
Since Bela held this talk already as a keynote at TheServerSide Java Symposium Europe, his slides (in PDF) are available for download on the conference website.
This SIG meeting was an evening well spent and I was even given a JBoss backpack for taking part in suggesting presentation topics for future meetings. Meetings some of which I'll attend, I'm sure.