Rickard Öberg wrote:
> Julian Gosnell wrote:
>
>>Are you saying that we should simply support both -
>>but not a third strategy which somehow supports
>>sandboxing AND optimised intra-container calls ?
>
> 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
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.
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:
+ 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
--
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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
