In message: <[EMAIL PROTECTED]>
Dalibor Topic <[EMAIL PROTECTED]> writes:
>Hi Alexander,
>
>T. Alexander Popiel wrote:
>
>> I have not found any documented way of replacing the parser version.
>> Mangling bootclasspath to do it isn't documented, either... but follows
>> from first principles.
>
>See docs for org.xml.sax.helpers.XMLReaderFactory. citing the docs:
>"This method uses the value of the system property "org.xml.sax.driver"
>as the full name of a Java class and tries to instantiate that class as
>a SAX2 XMLReader."
The problem is not the name of the class, but rather the jar that the
class is taken from. The name is the same in both places.
>> Given that the code which is having trouble is being run inside both
>> jboss and weblogic, we don't have particularly good control of the
>> classloader (unless we do a whole bunch of platform-specific dinking
>> for each one).
>
>I'm not quite sure I get that. Can't you use your own class loader to
>load the main class, and have it delegate to the proper jar for the
>classes whose names start with 'org.xml' or 'org.apache' or whatever the
>xerces prefix is? Lookup docs for Thread.setContextClassLoader , it
>could help there.
My understanding (which could be flawed, since I'm not the one
who was set to exaustively investigate this) is that the J2EE
container has its own classloader which it creates and uses to
instantiate the session beans that we're using. By the time
that the session beans are fully instantiated (and we'd be able
to create our own classloaders), the SAX stuff has already been
loaded.
Alternately, if we wrap the platform-dependent J2EE container
initialization with our own classloader, it seems to interfere
with the container making its own classloaders... so in addition
to adjusting the SAX source, we have to mimic the behaviour of
the classloaders for each of the containers.
As I say, this is just my possibly flawed understanding... but
the general idea of using a J2EE container in the first place
is to shield yourself from such mundane details as classloaders...
so when the VM or the container get it wrong, you're basically
screwed.
- Alex
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
