Hi Kevin,
Kevin Jones wrote:
>
> > I'm using Xalan 2 in my framework and I've had the same problem with
> > pretty much all the containers that I've tried playing with. With Orion,
> > substituting xalan.jar and xerces.jar in the Orion directory did the
> > trick for me in 1.4.*.
>
> This is an ugly hack though :-) If another app using the same server and
> relies on Xalan-1 functionality, they're screwed.
I know, I know, and it also breaks our "application atomicity" as it is
not enough to pack our applications in .ear files, we also have to make
sure Xalan 2 is manually installed in the container :(. But we jumped to
JAPX as soon as it implemented the TRaX API to finally become
independent of the XSLT processor and as all our applications use the
same XML/XSLT framework, based in JAXP and TRaX... We've run into some
troubles with some external applications but in this case, I'd rather
have another orion instance with another classpath than downgrading my
whole framework to become parser-dependent again. I hope JSDK2.3 allows
us to get rid of this "ugliness"
>
> > with Resin and I never tried with Tomcat.
>
> Tomcat 4 fixes this (mostly)
Mostly? That sounds scary! ;) (Warning! Warning! that was meant to be a
joke ;) )
> > The problem seems to be
> > something like "the first XML library to be used is the one to be used
> > for everything" and as all the containers have nowadays XML
> > configuration files and use an XML parser as soon as they start up, then
> > the XML library that is used is the one that the container uses,
>
> Yes, sort of. The problem is that the same classloader used by your web-app
> can also 'see' the global 'classpath ' set by Orion, and, as classloaders
> delegate, when the web-app CL tries to use an XML parser, or Xalan or
> something that is shared then the 'global' one gets used first.
I see. I guess that's the reason why the 2.3 spec says talks about
application classpath "taking precedence" over the global one.
> > hence
> > the need to put your desired library in the global CLASSPATH. This can
> > lead to problems that can't be solved, if the container and your
> > application can only use incompatible versions of a parser. As somebody
> > mentioned,
>
> That was me
>
> > I think JSDK 2.3 tries to solve this, specifically,
> > Point SRV.9.7.2 Web Application Classloader (Page 63 JSDK2.3 PFD2)
> > states:
> > "...
> > It is recommended, however, that the application classloader be
> > implemented so that classes and resources packaged within the WAR are
> > loaded in preference to classes and resources residing in container-wide
> > library JARs.
> > "
>
> Yes, we put this in because of these sorts of problems.
Oh, so you are one of them ;). You can bet everybody will appreciate it
if you can specify things so this issue is solved. From my experience,
this is number one source of problems when using todays containers (not
talking about code bugs or similar problems).
Now that we are at it. Have you thought about improving security so the
mappings are a bit more dynamic and that user-role mapping is not
container-dependent? These are the reasons that lead us to develop our
own library but I would have lived happier if I needn't have to do it.
Thanks for your comments,
D.
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
> Kevin Jones
> DevelopMentor
> www.develop.com
