J2EE deployment woes
J2EE on the whole is a rather good thing. For the first time, there is a standard covering this kind of stuff. A lovely unified umbrella on how to write applications that are not tied to any particular vendor. Arguably, there has been some measure of success in this. It is possible (after a few bucketloads of blood, sweat, and tears) to come up with an .ear file that deploys on a bunch of appservers.
Now, there is an overall componentisation aspect to J2EE. The idea being that one builds apps out of a number of components. These components are, on a higher level, things like ejb modules, client modules, and web modules. Drilling down, we have ejb components within an ejb module, servlets/filters/pages within a web module, and whatever you want in a client module. All good and well, there’s no fundamental flaw with that approach.
In practice though, it all goes rather pear shaped. Given this component architecture, it’d be quite reasonable to expect to plug in components in to j2ee apps. So, I am baffled by how difficult it is to do so. Picture the following scenario. You use app X, which comes from some vendor. They supply you with an ear. Now, you want to deploy another webapp within that ear. To do so, you have to modify application.xml. If they send you an upgraded ear, your changes are swatted away. The same problem happens if you want to add any sort of extra module locally, or in fact, any component at all. Want to add an extra filter? Sorry, you’ll have to constantly deal with merging new versions in.
Even the potential for doing this kind of thing was removed from the J2EE 1.4 spec. I really don’t understand the logic behind deliberately crippling a component architecture this way.
Of course, much of the blame lies on the expert groups too. They generally consist of a bunch of complete morons who get off on pimping their own implementation (the ‘I wrote a servlet/jsp book so I should ge to inflict my academic childish implementation onto the rest of the world’ brigade). The formal spec process is nothing more than an official marketing channel for their own featureset and/or incompetencies. Almost every single JSR at some point has something along the lines of ‘well it’s too hard for us to implement that, so lets not put it in the spec’ spewing out of some vendor or the other. End users be damned, it’s all about making these specs trivial to implement for any monkey (witness Tomcat, local entities, filters applied once per request, etc). Many of these things came about through vendors whining sufficiently about their own stupid code.
The whole idea of separating the deployer and assembler concerns is a good one, Sun should have just carried the idea forward a bit more and considered the use case of ear/module-as-deliverable more thoroughly.
July 20th, 2003 at 6:21 am
I’d hope you talk about the configuration aspect as well. The thing is it’s overly complicated to configure a J2EE application because there is no standard. An EAR should never be opened to change some setting, so you must deliver an external way to set properties. Adding a database is too much a pain for 2 or 3 external strings, and today there is no standard mechanism to fetch a file “linked” to an EAR on the different app servers.
July 20th, 2003 at 8:27 am
The expert groups carry their own doom, certainly. I think the problem is that morons are the ones most likely to want to invest a lot of time in an expert group; my own participation in an expert group worked out that way. When I was working on one, I was happy to put in the work until it turned into a “who can offer the most features” group, at which point I, as a lone coder, simply couldn’t compete and became largely silent. Many of the participants have since written books about the product, which I find serious issues with.
July 20th, 2003 at 7:28 pm
JBoss supports exploded deployment of EARs (and other deployment packages). This is very convenient as it saves you from the unpack - change - package work, all you need to do is go and touch the deployment descriptor in the META-INF directory. After a change your EAR will be automatically redeployed.
Mikki