Comments on: ClassLoaders in JEE 5 Specifications http://www.bearaway.org/wp/2005/11/25/classloaders-in-jee-5-specifications/ Just another rant Sat, 22 May 2010 15:41:26 +0000 hourly 1 http://wordpress.org/?v=3.0 By: stephane http://www.bearaway.org/wp/2005/11/25/classloaders-in-jee-5-specifications/comment-page-1/#comment-297 stephane Tue, 29 Nov 2005 20:05:09 +0000 http://www.bearaway.org/wp/?p=21#comment-297 Thanks for your feedback Scott. I agree that scope wise this is a non trivial problem. But one should also not forget that there is at least the need for a minimal standard on which people can rely to deploy confidentely on any application server. As of today, there is none and it is a big issue. An application can be deployed and 'work' accidentally. I also don't think that it is tied to JSR-277 which is a bit of another issue. In the Java EE case we must simply be strict about a the existence of (at least) a default behavior which is as of now NO such big deal to implement..as it already exists. Every application server available on the market is certainly is able to do it now. Some will break their default behavior, but it's up to them to provide a painless migration step. For Java EE and JSR-277, there is something that is an interesting use case. I have seen several times at customers the WEB-INF/lib of WARs serving as a dumping ground for every jar. You could then find in it 3 different versions of a the same jar. The jar picked up, thus mostly depends on the app. server, JDK and filesystem. Thanks for your feedback Scott. I agree that scope wise this is a non trivial problem. But one should also not forget that there is at least the need for a minimal standard on which people can rely to deploy confidentely on any application server. As of today, there is none and it is a big issue. An application can be deployed and ‘work’ accidentally.

I also don’t think that it is tied to JSR-277 which is a bit of another issue. In the Java EE case we must simply be strict about a the existence of (at least) a default behavior which is as of now NO such big deal to implement..as it already exists. Every application server available on the market is certainly is able to do it now. Some will break their default behavior, but it’s up to them to provide a painless migration step.

For Java EE and JSR-277, there is something that is an interesting use case. I have seen several times at customers the WEB-INF/lib of WARs serving as a dumping ground for every jar. You could then find in it 3 different versions of a the same jar. The jar picked up, thus mostly depends on the app. server, JDK and filesystem.

]]> By: Scott M Stark http://www.bearaway.org/wp/2005/11/25/classloaders-in-jee-5-specifications/comment-page-1/#comment-296 Scott M Stark Tue, 29 Nov 2005 19:19:47 +0000 http://www.bearaway.org/wp/?p=21#comment-296 I agree that the class loading model in Java EE 5 is problematic, but this is because there has been no consideration for how class loading should work in a multi-user/multi-application server environment. With components that allow call by reference semantics and containers that allow for customization of container component call level pathways(interceptors, valves, aspects), its a non-trivial problem. This is an issue that should be raised in the context of the JSR-277 (a jdk7 timeframe spec) as well as Java EE 6. I agree that the class loading model in Java EE 5 is problematic, but this is because there has been no consideration for how class loading should work in a multi-user/multi-application server environment. With components that allow call by reference semantics and containers that allow for customization of container component call level pathways(interceptors, valves, aspects), its a non-trivial problem. This is an issue that should be raised in the context of the JSR-277 (a jdk7 timeframe spec) as well as Java EE 6.

]]> By: Rajesh Patel http://www.bearaway.org/wp/2005/11/25/classloaders-in-jee-5-specifications/comment-page-1/#comment-295 Rajesh Patel Tue, 29 Nov 2005 15:48:11 +0000 http://www.bearaway.org/wp/?p=21#comment-295 Did more reading, JBoss is not using the FLAT model anymore: http://jira.jboss.com/jira/browse/JBAS-1691 Did more reading, JBoss is not using the FLAT model anymore:
http://jira.jboss.com/jira/browse/JBAS-1691

]]> By: Rajesh Patel http://www.bearaway.org/wp/2005/11/25/classloaders-in-jee-5-specifications/comment-page-1/#comment-294 Rajesh Patel Tue, 29 Nov 2005 15:38:34 +0000 http://www.bearaway.org/wp/?p=21#comment-294 BTW, Websphere defaults to parent first classloading, which is just as bad as the unified classloader. BTW, Websphere defaults to parent first classloading, which is just
as bad as the unified classloader.

]]> By: Rajesh Patel http://www.bearaway.org/wp/2005/11/25/classloaders-in-jee-5-specifications/comment-page-1/#comment-293 Rajesh Patel Tue, 29 Nov 2005 15:37:06 +0000 http://www.bearaway.org/wp/?p=21#comment-293 Amen brother, I too tire of the different default implementations of classloaders. I find that the concept of classloader hiearchies is enough to blow most developers minds. Then you throw in the differing default implementations and you have mass confusion. I can't just say "put all your jars in the WEB-INF/lib directory for you application". Amen brother,
I too tire of the different default implementations of classloaders.
I find that the concept of classloader hiearchies is enough to
blow most developers minds. Then you throw in the differing
default implementations and you have mass confusion. I can’t
just say “put all your jars in the WEB-INF/lib directory for you application”.

]]> By: stephane http://www.bearaway.org/wp/2005/11/25/classloaders-in-jee-5-specifications/comment-page-1/#comment-20 stephane Fri, 25 Nov 2005 13:06:26 +0000 http://www.bearaway.org/wp/?p=21#comment-20 Steve, any app server is free to offer added value stuff, but what is important is that the specification can at least specify a standard expected behavior in this area to avoid all sort of custom interpretation. I think JEE developers/administrator pay a hard price in production otherwise. If it's not standard, behavior is also bound to change any time (like JBoss does with the isolation mechanism) and creates more havoc when upgrading. I'm also afraid to not to really get the JMX mechanism you are thinking about. Steve, any app server is free to offer added value stuff, but what is important is that the specification can at least specify a standard expected behavior in this area to avoid all sort of custom interpretation. I think JEE developers/administrator pay a hard price in production otherwise. If it’s not standard, behavior is also bound to change any time (like JBoss does with the isolation mechanism) and creates more havoc when upgrading.

I’m also afraid to not to really get the JMX mechanism you are thinking about.

]]> By: Steve Loughran http://www.bearaway.org/wp/2005/11/25/classloaders-in-jee-5-specifications/comment-page-1/#comment-19 Steve Loughran Fri, 25 Nov 2005 12:30:48 +0000 http://www.bearaway.org/wp/?p=21#comment-19 You have to remember that those appserver people want to offer added value stuff, because that is how they differentiate their server/lock in users. Maybe the provisioning of those features should be different, for example you could ask a JMX manager for an MBean of a specific interface, and you'd get back that particular (remote?) interface. No classpath injection, just interfaces at build time and proxies you get at runtime by asking for specific versions. -steve You have to remember that those appserver people want to offer added value stuff, because that is how they differentiate their server/lock in users.

Maybe the provisioning of those features should be different, for example you could ask a JMX manager for an MBean of a specific interface, and you’d get back that particular (remote?) interface. No classpath injection, just interfaces at build time and proxies you get at runtime by asking for specific versions.

-steve

]]>