I was going to post this in a comment to my
last UCL rant, but I ended up deciding the topic was big enough
for its own entry.
Yes, the option exists to use a separate UCL for your components,
which does move one closer to the "standard" way of doing things. But
when you do this you really aren't making the classloader any less
broken, you are just narrowing the scope in which the broken behaviour
lives. (by "broken" I mean "doesn't work in an intuitive, predictable
manner")
You can treat this as a very obscure and poorly documented
deployment issue. But why? I can't imagine anyone who actually
deploys JBoss in a production system would want the UCL classloader.
It's a great convenience for hacking together toy applications, but I
don't know anyone writing production code that wants their classes to
leak across the boundaries. Do you? What does the UCL solve except
to make it easier to be sloppy in distributing your J2EE components?
Laziness is usually promoted as a virtue to which good programmers
should aspire, but the UCL goes beyond lazy to sloppy. Breaking down
the classloader walls you expect to be there is like forgetting about
the public/private/protected access levels. Actually, it's not like
simply forgetting them, it would be like your IDE going in doing code
assist to help you find and use the private members your hacked
environment gives you access to without even telling you you are doing
anything out of the ordinary. Of course the code you are running that
accesses the private members can only be run in the "broken" JVM. But
if they were concerned about portability they would just develop
portable applications, right?
If you think I'm exaggerating, try looking at the EAR files and
WAR files produced by JBoss developers. The developers aren't forced
to consider the visibility of their class files and just throw
together applications that sort of work. I can't tell you how I
cringe when I see sites that depend on the deployment order of files
(PrefixDeploymentSorter, anyone?) or that mysteriously stop working
when the developer hot deploys one of the components. It's not enough
to change the deployment descriptors to deploy to another app server.
You have to completely repackage the entire thing to make sure all the
components see what they expect to see. What a pain.
Having said all this, let me once again say that I am a huge fan
of JBoss. I use JBoss every day and can't count the number of systems
I've helped migrate to JBoss from other app servers. Using JBoss, for
the most part, is a pleasure in comparison to the competition. But,
I'm not afraid to say when I think something smells bad, and that UCL
sure is stinking up the room.
Previous Topic
