Hi Robert,

I have asked too about this because I also use XML and not the same version. I
use
xmltr2. My problem is that the parser is leaving whitespace between elements
where no whitespace can be according to the DTD. This breaks my code because
apparently I'm using the one built into the application server and it leaves
TEXT elements
between my elements. My workaround is to make sure my XML has no whitespace
between
elements.

In a previous post from Ken Saks on the J2EE team, he said in response to my
questions about
initial context:
from me
>> And then since components are loaded by seperate classloaders so they can
be
>> loaded and unloaded then what is the classloading scheme for the what I'm
calling
>> the "global" context or is there only one context?

from Ken
>It can be risky to make assumptions about the underlying classloading
>scheme used by an application server.  As a component developer the
>key is to obey the programming restrictions defined in the J2EE specs( e.g.
Runtime
>Environment chapter of EJB spec).   For example, the use of read/write static
data
>members in EJB components is discouraged.

Certainly, some restrictions and assumptions have to put in the J2EE spec.
What
if you want to use your own implementation as your point illustrates? What do
you
do?

My thought is that this is a very tough problem since the classloading scheme
is so
pervasive in the Java Platform. Sure the application server programmer can
provide their
own classloading scheme but usually there is a parent classloader and the
classloader must
look for classes somewhere when it has exhausted the local jar(s) for the WAR,

EJB Jar, or EAR. My understanding is that the classloaders differ to the
parent for
loading because it normally makes sense but in this case it seems it needs to
look
from local to global.

Some clarification would be very helpful,
Eric :-)

Robert Krüger wrote:

> Hi,
>
> I'm still not sure I understand how classloaders are used in orion and
> would like to ask a few things. before tonight I always thought that a
> class that's loaded via the orion.jar classpath has priority over the class
> with the same name loaded from a jar that's specified in a library-path
> element in server.xml (i.e. it's not being loaded at all). that means if I
> do not want to risk interfering with the server I cannot choose my own
> version of xalan, xerces to use in my applications. I just stumbled over a
> case where this obviously behaves differently (the version from the library
> path is taken). Is this version then also used for orion's internal
> parsing, meaning that I risk having strange side effects?
>
> Is it possible to safely use my own versions of libs that also shipping
> with orion (like xalan, xerces etc.?) in my application code?
>
> thanks for any clarification.
>
> robert
>
> p.s.:a short note on the classloader setup in orion would be a good thing
> to include in the docs as it frequently affects the developer, judging by
> the number of postings on this list that are somehow related to classloader
> issues. I know either magnus or karl once sent a mail to the list
> explaining the basic setup but I cannot find it anymore.
>
> (-) Robert Krüger
> (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
> (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
> (-) Tel: 06151 665401, Fax: 06151 665373
> (-) [EMAIL PROTECTED], www.signal7.de


Reply via email to