That is correct. The packaging required to run under a 2.2 servlet container is inconsistent with that required to run under a 2.3 container due to the change in the web container class loader behavior. I see this with Tomcat 3.2.3 vs Tomcat 4.0. Really, the only time this shows up is for JSP pages trying to access EJBs. Due to a problem/feature of the 2.2 version of jasper this required duplicate classes to be placed into the war. This is no longer required in the 2.3 spec version, and in fact now causes a problem.
The whole optimized call thing is going to change along with the class loader architecture. It is also unnecessary due to the introduction of local interfaces. ----- Original Message ----- From: "Greg Wilkins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Rickard Öberg" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, November 21, 2001 2:58 AM Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott - Optimised intra-container calls & ClassLoaders > Julian Gosnell wrote: > > > Your just putting the onus on the Application > > programmer to work around shortcomings in the Server - > > I think..... > > > But that is exactly the problem with the non-compliant > class loader as specified by the 2.3 servlet spec. > > Because it advocates a "application developer knows better" > approach, then the application developer get's total control > over non-system classes - so they have to set it up right, > else it does not work. > > If they want to share class instances between the servlet > container and the EJB container, then they MUST prevent > the servlet context from seeing those classes, else > it will load it's own copy of them. > > There is absolutely no programatic way to distinguish > between a webapp that has included a class on purpose to > override an "old" version in the container, or due to > an unknowing programmer being overzealous with their > classpath. > > > > Perhaps someone will make a pronouncement on HOW > > JBoss/Jetty SHOULD behave here. Then we can figure out > > how to achieve this behaviour. > > > Unfortunatley the default behaviour should be what the > specification says and the 2.3 servlet spec definitely > requires the non java2 compliant class loader. > > Somebody should check the full J2EE specification to > see exactly what it specifies, as there is no guarantee > that the specs are compatible in this regards. > > I'm in two minds about providing the compliant loader > options - while I think it is the simple and correct > way to go, it may just complicate things to propogate > a non standard mode. Maybe EJB developers are just going > to have to be a lot more careful with their classpaths > now??? > > And this includes the developers of the JBoss web integration > test suite. Their should not be classes in the webapp > context that are also available via the EJB container or > system class loader. > > Regards > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
