|> Well, I believe the real fix is to make the EJB-loader use the "non |> Java2" class-loading style as well, i.e. force people to bundle in JAR's |> that the app is going to use. That is the ultimate way to get things |> portable, and to be able to allow different running apps use different |> versions of, say, JAXP. | | |I have to say that I reluctantly agree. Now that the non-compliant |loader cat is out of the bag, we have no choice but to force users |to be disciplined about their bundling of jars. For consistency this
RH Scoped classloader to the rescue. I still need to fix the jung stuff for the ordering and overwritting but we are there. |should apply the the EJB container as well as teh servlet container |(again assuming the J2EE spec does agree with the 2.3 servlet spec). | | |However, I would like to suggest a change in the language. We should |try to force the users to NOT include jars that they can reasonably |expect the container will provide. You don't force your users jack, you give them a simple and consistent behavior as we are trying with RH and then it works and when it doesnt they know why. UI design at its simplest. |JAXP is a key example, as I think it was the driver for the change |in the specification. Users wanted richer XML parsing for their |web applications than was provided by their containers. Hence they |now have the ability to write an application that is dependant on |a specific JAXP version and/or provider by bundling the jars for |them. But now almost all container provide recent versions |of JAXP with good parser implementations, so applications that |include jaxp.jar and xerces.jar are probably fixing a problem that |no longer exists! | |So our language should encourage users to NOT include their own |versions of jars unless absolutely necessary for a particular |deployment. Somewhere is should be clearly stated that the BYO |implementation approach is bad because: Relax, when teh code is out and we see how it behaves then we can put forth recommendations of usage. Right now the UI recommendations are based on monolythic cl approaches. Give me time. | + Firstly and foremost, it is just bad OO design. You should be | dependant on the interfaces not the implementations. Sure it | allows you to get around short term deployment issues, but it is | a much better approach to try to get your container to provide | the APIs and implementations that you need. | | + Including your own jars does create confusion and problems in | calling "local" interfaces that actually cross classloader boundaries. | The new priority inversion of classloader increases the chances | of cross loader calls being made. | | + There is a significant cost in terms of memory and serialization. | | + Applications that provide their own implementations of common | libraries cannot receive the benefits of updating the container. | If new versions are deployed by a container that fix bugs or | improve performance, these are not used by applications that | have included their own jars. | | + The logical extension of shipping your own jaxp.jar in order | to be portable is to ship your own swing, your own jboss and | eventually your own JVM, OS and hardware :-) | |Thus I think the documentation should not be written so that |developers think "I better include jaxp.jar xerces.jar as it is |better to be safe than sorry". | |Rather they should be encouraged to not include these jars, in |the knowledge that IF a problem does occur with a particular |container AND they can't update that container, only then should |they can fix that deployment by including specific versions of the |jars they need. | |Finally users should be given the confidence that their containers |of choice are open and being actively maintained, thus new APIs and |implementations should rapidly become available in the containers. | |regards my own eyes are rolling when I read the points. You are still carrying knowledge of the container to the user as developer. Bad UI design. Better than including CL dependencies in XML but still kind of silly. THIS IS PACKAGING KNOWLEDGE, i.e. it is worth about 0.00002c marcf | | |-- |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
