|-----Original Message-----
|From: Scott M Stark [mailto:[EMAIL PROTECTED]]
|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.
|
Right ok, then let's integrate with Jetty and leave everybody else behind,
buhbye!
|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.
that I don't agree see my previous mails
marcf
|
|----- 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
|>
|
|
|
|------------------------ Yahoo! Groups Sponsor ---------------------~-->
|Universal Inkjet Refill Kit $29.95
|Refill any ink cartridge for less!
|Includes black and color ink.
|http://us.click.yahoo.com/bAmslD/MkNDAA/ySSFAA/CefplB/TM
|---------------------------------------------------------------------~->
|
|For the latest information about Jetty, please see http://jetty.mortbay.
|
|Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
|
|
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
