| |Your just putting the onus on the Application |programmer to work around shortcomings in the Server - |I think.....
Like I said, dumb backwards thinking, I am in fact doubtful that Craig would do such a thing, Rickard you sure about this? |Perhaps someone will make a pronouncement on HOW |JBoss/Jetty SHOULD behave here. Then we can figure out |how to achieve this behaviour. Done, look I am almost done with teh rewrite of the proxies (having fun at this stage), then I want to look at deployment and packaging, we need to unify the way it works, it will be important for all functional aspect of the sub-containers, eg EJB/web services and their clustering. We are running smack into the packaging madness and how it ties to ClassLoaders. We DO HAVE THE SILVER BULLET, we have had it for a year, I just need to sit down and make it simpler. We will get there. marcf | | --- Rickard Öberg <[EMAIL PROTECTED]> wrote: > |Julian Gosnell wrote: |> |> > 2. Non-compliant - only requests for system |> classes |> > are passed upwards. |> |> |> FWIW, Tomcat4 does the same thing, which means that |> you have to bundle |> in jaxp.jar in your webapp, or you're going to get |> strange class-cast |> exceptions and class-not-found exceptions. The |> solution is to bundle all |> libraries with your app. | |If you do that with Jetty in stand-alone, compliant |mode - you will simply find you are using the JAXP |that Jetty loaded to parse it's own XML configuration |files. | |If you do it with Jetty in embedded, non-compliant |mode - you will find isAssignableFrom() fails. | |So Jetty, at the very leat, needs to know whether it |is embedded or not, and it may be more complex than |that - I thought I would bring in the big guns at this |point ! | |Jules | | Jetty |> |> > This strategy resolves the problems listed against |> (1) |> > but causes the isAssignableFrom() test mentioned |> above |> > to fail. What appears to happen is that JBoss |> passes |> > ClassLoader A to the EJB container which loads |> class X |> > then on to Jetty which creates it's WebApp |> > ClassLoader, B, as a child of A, then asks B to |> load |> > class X. B does not delegate to A, but loads class |> A |> > for a second time. |> |> |> So you need to put all classes in the EAR scope |> instead of in the webapp |> scope to make things work. Right? |> |> |> /Rickard |> |> |> |> -- |> Rickard Öberg |> | |__________________________________________________ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | |------------------------ 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/XwUZwC/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
