|But that is exactly the problem with the non-compliant |class loader as specified by the 2.3 servlet spec.
agreed, |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. it is dumb, but then it is not Craig, it is the spec! wow, time to reset on SUN, the king is crazy, |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. Depends on how you use CL. |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. the system classpath one is always going to throw off the appserver. Overriding the class with the requirement of the scope declaration (which is then in effect used as versioning) is the way to do this. The logic behind this is really a UI one. 1-provide consistent behavior of the CL and classpath. too many developers default to adding stuff in the classpath when it doesn't work. Not good, dangerous. Used 90% of the time though. 2- provide, but hide, advanced tools such as the scope to allow developers to include several versions of the same class in one VM, USED RARELY. It is simple UI logic, UI being the ease of deployment for the developer in this case. |Unfortunatley the default behaviour should be what the |specification says and the 2.3 servlet spec definitely |requires the non java2 compliant class loader. Then it rules out the delegation (which is the simplest, and frankly it is a silly requirement) then the only solution is the native sharing of CL in RH due to integration. Interestingly enough, the spec KILLS the clone integration and forces "monolythic" stacks as the only optimized integration. DON'T LET KIDS WRITE SPECS THEY ARE GOING TO POOPOO THEIR PAMPERS. Interestingly enough it goes against their clone push, they probably don't even see the problem :) |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 am saying they arent, but it is a minor point really. |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??? sure :) but the problem applies to everyone. We want to be able to integrate stacks and you need that visibility on the classes across stacks. Not just the system cl which is the dumb problem but even the packaging across ears and who sees what. Really the simplest is the RH cl that will still be compliant with scope declaration but will buy us the rest. I really think this is the bullet solution. marcf | |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 | | | | |-- |Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 |Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631 |http://www.mortbay.com AU Phone: +61-(0)2 98107029 | | |------------------------ 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/1_Y1qC/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
