more details on the deployment problems on SAP WAS (Netweaver)

> Groovy code (Java code, if you want) on the fly within the context  
> of Orbeon web application.
> The conclusion so far is that none of the classes  defined in WEB-INF
> \lib\private\xerces-xercesImpl-2_9_orbeon_20070711.jar is visible to  
> the class loader. The problem is not specific to XML parsers (as I  
> thought initially) but to any.
>
> For instance, even a simple class like  
> orbeon.apache.xerces.util.XMLErrorCode (defined in the same jar)  
> loaded via Class.forName gives the following stack trace:
>
> com
> .sap
> .engine
> .frame.core.load.ReferencedLoader.loadClass(ReferencedLoader.java:382)
> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> java.lang.Class.forName0(Native Method)
> java.lang.Class.forName(Class.java:141),
>
> On OC4J, the same test code would print the expected class loader  
> hierarchy (root, app, web app - test is the name of the EAR).
>
> trying to load orbeon.apache.xerces.util.XMLErrorCode
> successfully loaded. Class loader hierarchy is:
>   test.web.ops:0.0.0
>   test.root:0.0.0
>   default.root:0.0.0
>
>
> xerces-xercesImpl-2_9_orbeon_20070711.jar is referenced in the Class-
> Path entry of WEB-INF\lib\orbeon.jar\META-INF\MANIFEST.MF
>
> I can't say yet if Netweaver has a problem following such references  
> (I'd expect such a bug would have been caught in a J2EE  
> certification test, but cannot be sure). or there is something else.
>
> Questions
> - why is that jar packaged as it is if it contains orbeon.* classes?  
> There is only one non-orbeon* class inside xerces-
> xercesImpl-2_9_orbeon_20070711.jar:  
> org.w3c.dom.html.HTMLDOMImplementation

>> I added a small servlet to Orbeon that allows me to pass and execute
>> Groovy code (Java code, if you want) on the fly within the context
>> of Orbeon web application.
>> The conclusion so far is that none of the classes  defined in WEB-INF
>> \lib\private\xerces-xercesImpl-2_9_orbeon_20070711.jar is visible to
>> the class loader. The problem is not specific to XML parsers (as I
>> thought initially) but to any.
>>
>> For instance, even a simple class like
>> orbeon.apache.xerces.util.XMLErrorCode (defined in the same jar)
>> loaded via Class.forName gives the following stack trace:
>>
>> com
>> .sap
>> .engine
>> .frame.core.load.ReferencedLoader.loadClass(ReferencedLoader.java:382)
>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
>> java.lang.Class.forName0(Native Method)
>> java.lang.Class.forName(Class.java:141),
>>
>> On OC4J, the same test code would print the expected class loader
>> hierarchy (root, app, web app - test is the name of the EAR).
>>
>> trying to load orbeon.apache.xerces.util.XMLErrorCode
>> successfully loaded. Class loader hierarchy is:
>>   test.web.ops:0.0.0
>>   test.root:0.0.0
>>   default.root:0.0.0
>>
>>
>> xerces-xercesImpl-2_9_orbeon_20070711.jar is referenced in the Class-
>> Path entry of WEB-INF\lib\orbeon.jar\META-INF\MANIFEST.MF
>>
>> I can't say yet if Netweaver has a problem following such references
>> (I'd expect such a bug would have been caught in a J2EE
>> certification test, but cannot be sure). or there is something else.
>>
>> Questions
>> - why is that jar packaged as it is if it contains orbeon.* classes?
>> There is only one non-orbeon* class inside xerces-
>> xercesImpl-2_9_orbeon_20070711.jar:
>> org.w3c.dom.html.HTMLDOMImplementation
>
> I don't quite understand the question: the JAR contains orbeon.*
> classes, right?
>
>> - is this clas (HTMLDOMImplementation) still needed? Just asking in
>> case it happens to be an obsolete thing
>
> Absolutely no idea! ;-) Certainly, Orbeon Forms doesn't use it
> directly, but I don't know if it may be used indirectly.
>
> I feel for your hair though. What can I say, J2EE class loading is
> broken from the start, and actual implementations are even more broken
> it seems.
>
> -Erik
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/

>>> Questions
>>> - why is that jar packaged as it is if it contains orbeon.* classes?
>>> There is only one non-orbeon* class inside xerces-
>>> xercesImpl-2_9_orbeon_20070711.jar:
>>> org.w3c.dom.html.HTMLDOMImplementation
>>
>> I don't quite understand the question: the JAR contains orbeon.*
>> classes, right?
>
>
> I was asking why instead of simply putting xerces-
> xercesImpl-2_9_orbeon_20070711.jar into WEB-INF\lib, the current  
> packaging has it in WEB-INF\lib\private and referenced via the  
> orbeon.jar's MANIFEST.MF. The classes in xerces-
> xercesImpl-2_9_orbeon_20070711.jar are in an orbeon.* subpackage and  
> thus not conflicting with some standard libraries.
>
> In fact, I modified orbeon.war here and moved those 2 jars from  
> private into web-inf\lib and the deployment on SAP WAS appears to  
> work (more testing will be done on Monday).
>
>
> ----- Original Message ----- From: "Erik Bruchez"  
> <[hidden email]>
> To: <[hidden email]>
> Sent: Friday, March 14, 2008 4:21 PM
> Subject: [ops-users] Re: more details on the deployment problems on  
> SAP WAS (Netweaver)
>
>
>>> I added a small servlet to Orbeon that allows me to pass and execute
>>> Groovy code (Java code, if you want) on the fly within the context
>>> of Orbeon web application.
>>> The conclusion so far is that none of the classes  defined in WEB-
>>> INF
>>> \lib\private\xerces-xercesImpl-2_9_orbeon_20070711.jar is visible to
>>> the class loader. The problem is not specific to XML parsers (as I
>>> thought initially) but to any.
>>>
>>> For instance, even a simple class like
>>> orbeon.apache.xerces.util.XMLErrorCode (defined in the same jar)
>>> loaded via Class.forName gives the following stack trace:
>>>
>>> com
>>> .sap
>>> .engine
>>> .frame.core.load.ReferencedLoader.loadClass(ReferencedLoader.java:
>>> 382)
>>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
>>> java.lang.Class.forName0(Native Method)
>>> java.lang.Class.forName(Class.java:141),
>>>
>>> On OC4J, the same test code would print the expected class loader
>>> hierarchy (root, app, web app - test is the name of the EAR).
>>>
>>> trying to load orbeon.apache.xerces.util.XMLErrorCode
>>> successfully loaded. Class loader hierarchy is:
>>>  test.web.ops:0.0.0
>>>  test.root:0.0.0
>>>  default.root:0.0.0
>>>
>>>
>>> xerces-xercesImpl-2_9_orbeon_20070711.jar is referenced in the  
>>> Class-
>>> Path entry of WEB-INF\lib\orbeon.jar\META-INF\MANIFEST.MF
>>>
>>> I can't say yet if Netweaver has a problem following such references
>>> (I'd expect such a bug would have been caught in a J2EE
>>> certification test, but cannot be sure). or there is something else.
>>>
>>> Questions
>>> - why is that jar packaged as it is if it contains orbeon.* classes?
>>> There is only one non-orbeon* class inside xerces-
>>> xercesImpl-2_9_orbeon_20070711.jar:
>>> org.w3c.dom.html.HTMLDOMImplementation
>>
>> I don't quite understand the question: the JAR contains orbeon.*
>> classes, right?
>>
>>> - is this clas (HTMLDOMImplementation) still needed? Just asking in
>>> case it happens to be an obsolete thing
>>
>> Absolutely no idea! ;-) Certainly, Orbeon Forms doesn't use it
>> directly, but I don't know if it may be used indirectly.
>>
>> I feel for your hair though. What can I say, J2EE class loading is
>> broken from the start, and actual implementations are even more  
>> broken
>> it seems.
>>
>> -Erik
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws

>I see. Good question. This was done years ago, probably to solve a
> class loading issue with one of the containers!
>
> But maybe at this point it is more of a problem than a solution
> (although the other containers seem to deal with this correctly).
>
> -Erik
>
> On Mar 14, 2008, at 2:06 PM, Jean Luc wrote:
>
>>>> Questions
>>>> - why is that jar packaged as it is if it contains orbeon.* classes?
>>>> There is only one non-orbeon* class inside xerces-
>>>> xercesImpl-2_9_orbeon_20070711.jar:
>>>> org.w3c.dom.html.HTMLDOMImplementation
>>>
>>> I don't quite understand the question: the JAR contains orbeon.*
>>> classes, right?
>>
>>
>> I was asking why instead of simply putting xerces-
>> xercesImpl-2_9_orbeon_20070711.jar into WEB-INF\lib, the current
>> packaging has it in WEB-INF\lib\private and referenced via the
>> orbeon.jar's MANIFEST.MF. The classes in xerces-
>> xercesImpl-2_9_orbeon_20070711.jar are in an orbeon.* subpackage and
>> thus not conflicting with some standard libraries.
>>
>> In fact, I modified orbeon.war here and moved those 2 jars from
>> private into web-inf\lib and the deployment on SAP WAS appears to
>> work (more testing will be done on Monday).
>>
>>
>> ----- Original Message ----- From: "Erik Bruchez"
>> <[hidden email]>
>> To: <[hidden email]>
>> Sent: Friday, March 14, 2008 4:21 PM
>> Subject: [ops-users] Re: more details on the deployment problems on
>> SAP WAS (Netweaver)
>>
>>
>>>> I added a small servlet to Orbeon that allows me to pass and execute
>>>> Groovy code (Java code, if you want) on the fly within the context
>>>> of Orbeon web application.
>>>> The conclusion so far is that none of the classes  defined in WEB-
>>>> INF
>>>> \lib\private\xerces-xercesImpl-2_9_orbeon_20070711.jar is visible to
>>>> the class loader. The problem is not specific to XML parsers (as I
>>>> thought initially) but to any.
>>>>
>>>> For instance, even a simple class like
>>>> orbeon.apache.xerces.util.XMLErrorCode (defined in the same jar)
>>>> loaded via Class.forName gives the following stack trace:
>>>>
>>>> com
>>>> .sap
>>>> .engine
>>>> .frame.core.load.ReferencedLoader.loadClass(ReferencedLoader.java:
>>>> 382)
>>>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
>>>> java.lang.Class.forName0(Native Method)
>>>> java.lang.Class.forName(Class.java:141),
>>>>
>>>> On OC4J, the same test code would print the expected class loader
>>>> hierarchy (root, app, web app - test is the name of the EAR).
>>>>
>>>> trying to load orbeon.apache.xerces.util.XMLErrorCode
>>>> successfully loaded. Class loader hierarchy is:
>>>>  test.web.ops:0.0.0
>>>>  test.root:0.0.0
>>>>  default.root:0.0.0
>>>>
>>>>
>>>> xerces-xercesImpl-2_9_orbeon_20070711.jar is referenced in the
>>>> Class-
>>>> Path entry of WEB-INF\lib\orbeon.jar\META-INF\MANIFEST.MF
>>>>
>>>> I can't say yet if Netweaver has a problem following such references
>>>> (I'd expect such a bug would have been caught in a J2EE
>>>> certification test, but cannot be sure). or there is something else.
>>>>
>>>> Questions
>>>> - why is that jar packaged as it is if it contains orbeon.* classes?
>>>> There is only one non-orbeon* class inside xerces-
>>>> xercesImpl-2_9_orbeon_20070711.jar:
>>>> org.w3c.dom.html.HTMLDOMImplementation
>>>
>>> I don't quite understand the question: the JAR contains orbeon.*
>>> classes, right?
>>>
>>>> - is this clas (HTMLDOMImplementation) still needed? Just asking in
>>>> case it happens to be an obsolete thing
>>>
>>> Absolutely no idea! ;-) Certainly, Orbeon Forms doesn't use it
>>> directly, but I don't know if it may be used indirectly.
>>>
>>> I feel for your hair though. What can I say, J2EE class loading is
>>> broken from the start, and actual implementations are even more
>>> broken
>>> it seems.
>>>
>>> -Erik
>>>
>>> --
>>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>>> http://www.orbeon.com/
>>
>>
>> --
>> You receive this message as a subscriber of the [hidden email]
>> mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>

> I looked in http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf, what they  
> say "If the classes in a JAR file depend on classes in another JAR  
> file, the first JAR file should reference the second JAR file using  
> the Class-Path mechanism. A notable exception to this rule is JAR  
> files located in the WEB-INF/lib directory of a web application. All  
> such JAR files are included in the class path of the web  
> application at runtime; explicit references to them using the Class-
> Path mechanism are not needed"
>
> Based on that I'd expect the classes in private\ to be loaded; but I  
> won't be surprised to hear subdirectories are not supported.
>
> I agree with you, at this point the complication with the  
> subdirectory is more of a problem. If it's not required, you may  
> want to add this to the clean-up to-do list.
>
> Thanks,
> JL
>
> ----- Original Message -----
> From: "Erik Bruchez" <[hidden email]>
> To: <[hidden email]>
> Sent: Friday, March 14, 2008 7:09 PM
> Subject: [ops-users] Re: Re: Re: more details on the deployment  
> problems on SAP WAS (Netweaver)
>
>
>> I see. Good question. This was done years ago, probably to solve a
>> class loading issue with one of the containers!
>>
>> But maybe at this point it is more of a problem than a solution
>> (although the other containers seem to deal with this correctly).
>>
>> -Erik
>>
>> On Mar 14, 2008, at 2:06 PM, Jean Luc wrote:
>>
>>>>> Questions
>>>>> - why is that jar packaged as it is if it contains orbeon.*  
>>>>> classes?
>>>>> There is only one non-orbeon* class inside xerces-
>>>>> xercesImpl-2_9_orbeon_20070711.jar:
>>>>> org.w3c.dom.html.HTMLDOMImplementation
>>>>
>>>> I don't quite understand the question: the JAR contains orbeon.*
>>>> classes, right?
>>>
>>>
>>> I was asking why instead of simply putting xerces-
>>> xercesImpl-2_9_orbeon_20070711.jar into WEB-INF\lib, the current
>>> packaging has it in WEB-INF\lib\private and referenced via the
>>> orbeon.jar's MANIFEST.MF. The classes in xerces-
>>> xercesImpl-2_9_orbeon_20070711.jar are in an orbeon.* subpackage and
>>> thus not conflicting with some standard libraries.
>>>
>>> In fact, I modified orbeon.war here and moved those 2 jars from
>>> private into web-inf\lib and the deployment on SAP WAS appears to
>>> work (more testing will be done on Monday).
>>>
>>>
>>> ----- Original Message ----- From: "Erik Bruchez"
>>> <[hidden email]>
>>> To: <[hidden email]>
>>> Sent: Friday, March 14, 2008 4:21 PM
>>> Subject: [ops-users] Re: more details on the deployment problems on
>>> SAP WAS (Netweaver)
>>>
>>>
>>>>> I added a small servlet to Orbeon that allows me to pass and  
>>>>> execute
>>>>> Groovy code (Java code, if you want) on the fly within the context
>>>>> of Orbeon web application.
>>>>> The conclusion so far is that none of the classes  defined in WEB-
>>>>> INF
>>>>> \lib\private\xerces-xercesImpl-2_9_orbeon_20070711.jar is  
>>>>> visible to
>>>>> the class loader. The problem is not specific to XML parsers (as I
>>>>> thought initially) but to any.
>>>>>
>>>>> For instance, even a simple class like
>>>>> orbeon.apache.xerces.util.XMLErrorCode (defined in the same jar)
>>>>> loaded via Class.forName gives the following stack trace:
>>>>>
>>>>> com
>>>>> .sap
>>>>> .engine
>>>>> .frame.core.load.ReferencedLoader.loadClass(ReferencedLoader.java:
>>>>> 382)
>>>>> java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
>>>>> java.lang.Class.forName0(Native Method)
>>>>> java.lang.Class.forName(Class.java:141),
>>>>>
>>>>> On OC4J, the same test code would print the expected class loader
>>>>> hierarchy (root, app, web app - test is the name of the EAR).
>>>>>
>>>>> trying to load orbeon.apache.xerces.util.XMLErrorCode
>>>>> successfully loaded. Class loader hierarchy is:
>>>>> test.web.ops:0.0.0
>>>>> test.root:0.0.0
>>>>> default.root:0.0.0
>>>>>
>>>>>
>>>>> xerces-xercesImpl-2_9_orbeon_20070711.jar is referenced in the
>>>>> Class-
>>>>> Path entry of WEB-INF\lib\orbeon.jar\META-INF\MANIFEST.MF
>>>>>
>>>>> I can't say yet if Netweaver has a problem following such  
>>>>> references
>>>>> (I'd expect such a bug would have been caught in a J2EE
>>>>> certification test, but cannot be sure). or there is something  
>>>>> else.
>>>>>
>>>>> Questions
>>>>> - why is that jar packaged as it is if it contains orbeon.*  
>>>>> classes?
>>>>> There is only one non-orbeon* class inside xerces-
>>>>> xercesImpl-2_9_orbeon_20070711.jar:
>>>>> org.w3c.dom.html.HTMLDOMImplementation
>>>>
>>>> I don't quite understand the question: the JAR contains orbeon.*
>>>> classes, right?
>>>>
>>>>> - is this clas (HTMLDOMImplementation) still needed? Just asking  
>>>>> in
>>>>> case it happens to be an obsolete thing
>>>>
>>>> Absolutely no idea! ;-) Certainly, Orbeon Forms doesn't use it
>>>> directly, but I don't know if it may be used indirectly.
>>>>
>>>> I feel for your hair though. What can I say, J2EE class loading is
>>>> broken from the start, and actual implementations are even more
>>>> broken
>>>> it seems.
>>>>
>>>> -Erik
>>>>
>>>> --
>>>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>>>> http://www.orbeon.com/
>>>
>>>
>>> --
>>> You receive this message as a subscriber of the [hidden email]
>>> mailing list.
>>> To unsubscribe: mailto:[hidden email]
>>> For general help: mailto:[hidden email]?subject=help
>>> OW2 mailing lists service home page: http://www.ow2.org/wws
>>
>> --
>> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
>> http://www.orbeon.com/
>>
>>
>
>
> --------------------------------------------------------------------------------
>
>
>>
>> --
>> You receive this message as a subscriber of the [hidden email]  
>> mailing list.
>> To unsubscribe: mailto:[hidden email]
>> For general help: mailto:[hidden email]?subject=help
>> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>
> --
> You receive this message as a subscriber of the [hidden email]  
> mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws