You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Szabo Peter <Pe...@START.de> on 2002/01/16 10:35:00 UTC
.jar access problem
Hello All,
I've run into a serious problem...
I developed a converter from a proprietary structure to XML
and back using Xerces 1.4.4 which works fine, no problem
at all.
Now a project would like to reuse my component. They use
BEA Web Logic Enterprise as a surrounding runtime environment.
Now the problem is:
BEA WLE has a built-in jar file containing the same packages
and classes as Xerces but they are (of course) much older than
Xerces 1.4.4. And The BEA runtime has this library hardcoded
in its ClassPath at the very beginning, there is no way to
put xerces.jar in front of it. So under BEA WLE all modul
use the BEA WLE version of org.w3c.dom.* and so on which cause
syntax error (method not found) on some interfaces, I guess
Xerces introduced some more useful stuff since BEA fixed his
library. (And I guess/hope Xerces 1.4.4 is more bug free and
performant than an old stuff)
I have two idea how to workaround this problem:
1. hack the BEA jar file, deleting all XML stuff from it, then
everything will use the Xerces 1.4.4 including BEA WLE itself.
But this is against some licensing and varranty policies.
2. hack Xerces 1.4.4: Eg. add one more package name level to each
class in the jar, so developers will use XPackage.org.w3c.dom.*
which cannot be found anywhere else. (And all internal Xerces
reference should be replaced like this as well...)
This will have to be done by a script to be able to use the latest
stable version of Xerces-J...
(One more info:
WLE seems to be not really supproted by BEA anymore, so I don't
hope to get updates of their XML library. Only some bugfixes are
expected.)
Any idea, hint, whatever on this subject?
Best Regards,
Peter Szabo
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: .jar access problem
Posted by John Keyes <jo...@yahoo.com>.
Sorry it should have read JDK/jre/lib/ext or you can specify
the extension directories using -Djava.ext.dirs=<path> to
the interpreter.
-John K
John Keyes wrote:
> Have you tried placing Xerces 1.4.4 jar in the bootclasspath?
>
> -Xbootclasspath:<directories and zip/jar files separated by ;>
> set search path for bootstrap classes and resources
> -Xbootclasspath/a:<directories and zip/jar files separated by ;>
> append to end of bootstrap class path
> -Xbootclasspath/p:<directories and zip/jar files separated by ;>
> prepend in front of bootstrap class path
>
> Or you could place it in the JDK/lib/ext directory.
>
> The order in which classes are loaded are:
> bootclasspath, extension directory then classpath.
>
> See java documentation[1] for more information.
> -John K
>
> [1] win 32 - http://java.sun.com/j2se/1.3/docs/tooldocs/win32/java.html
> solaris - http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html
> linux - http://java.sun.com/j2se/1.3/docs/tooldocs/linux/java.html
>
> Szabo Peter wrote:
>
>> Hello All,
>>
>> I've run into a serious problem...
>>
>> I developed a converter from a proprietary structure to XML and back
>> using Xerces 1.4.4 which works fine, no problem
>> at all.
>>
>> Now a project would like to reuse my component. They use
>> BEA Web Logic Enterprise as a surrounding runtime environment.
>>
>> Now the problem is:
>> BEA WLE has a built-in jar file containing the same packages
>> and classes as Xerces but they are (of course) much older than
>> Xerces 1.4.4. And The BEA runtime has this library hardcoded
>> in its ClassPath at the very beginning, there is no way to
>> put xerces.jar in front of it. So under BEA WLE all modul use the BEA
>> WLE version of org.w3c.dom.* and so on which cause
>> syntax error (method not found) on some interfaces, I guess
>> Xerces introduced some more useful stuff since BEA fixed his
>> library. (And I guess/hope Xerces 1.4.4 is more bug free and
>> performant than an old stuff)
>>
>> I have two idea how to workaround this problem:
>> 1. hack the BEA jar file, deleting all XML stuff from it, then
>> everything will use the Xerces 1.4.4 including BEA WLE itself.
>> But this is against some licensing and varranty policies.
>> 2. hack Xerces 1.4.4: Eg. add one more package name level to each
>> class in the jar, so developers will use XPackage.org.w3c.dom.*
>> which cannot be found anywhere else. (And all internal Xerces
>> reference should be replaced like this as well...)
>> This will have to be done by a script to be able to use the latest
>> stable version of Xerces-J...
>> (One more info:
>> WLE seems to be not really supproted by BEA anymore, so I don't hope
>> to get updates of their XML library. Only some bugfixes are
>> expected.)
>>
>> Any idea, hint, whatever on this subject?
>>
>> Best Regards,
>> Peter Szabo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: .jar access problem
Posted by John Keyes <jo...@yahoo.com>.
Have you tried placing Xerces 1.4.4 jar in the bootclasspath?
-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
Or you could place it in the JDK/lib/ext directory.
The order in which classes are loaded are:
bootclasspath, extension directory then classpath.
See java documentation[1] for more information.
-John K
[1] win 32 - http://java.sun.com/j2se/1.3/docs/tooldocs/win32/java.html
solaris - http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html
linux - http://java.sun.com/j2se/1.3/docs/tooldocs/linux/java.html
Szabo Peter wrote:
> Hello All,
>
> I've run into a serious problem...
>
> I developed a converter from a proprietary structure to XML
> and back using Xerces 1.4.4 which works fine, no problem
> at all.
>
> Now a project would like to reuse my component. They use
> BEA Web Logic Enterprise as a surrounding runtime environment.
>
> Now the problem is:
> BEA WLE has a built-in jar file containing the same packages
> and classes as Xerces but they are (of course) much older than
> Xerces 1.4.4. And The BEA runtime has this library hardcoded
> in its ClassPath at the very beginning, there is no way to
> put xerces.jar in front of it. So under BEA WLE all modul
> use the BEA WLE version of org.w3c.dom.* and so on which cause
> syntax error (method not found) on some interfaces, I guess
> Xerces introduced some more useful stuff since BEA fixed his
> library. (And I guess/hope Xerces 1.4.4 is more bug free and
> performant than an old stuff)
>
> I have two idea how to workaround this problem:
> 1. hack the BEA jar file, deleting all XML stuff from it, then
> everything will use the Xerces 1.4.4 including BEA WLE itself.
> But this is against some licensing and varranty policies.
> 2. hack Xerces 1.4.4: Eg. add one more package name level to each
> class in the jar, so developers will use XPackage.org.w3c.dom.*
> which cannot be found anywhere else. (And all internal Xerces
> reference should be replaced like this as well...)
> This will have to be done by a script to be able to use the latest
> stable version of Xerces-J...
> (One more info:
> WLE seems to be not really supproted by BEA anymore, so I don't
> hope to get updates of their XML library. Only some bugfixes are
> expected.)
>
> Any idea, hint, whatever on this subject?
>
> Best Regards,
> Peter Szabo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org