Björn,

XmlBeans definitely doesn't use its own classloader, but the
explanation is probably that it uses the wrong classloader, i.e. the
Web app classloader (loading classes from WEB-INF/classes and
WEB-INF/lib). I guess that the XmlBeans JAR is deployed in WEB-INF/lib
and that your module contains the JARs with the generated code. I'm
not an expert of XmlBeans, but I assume that it uses the context
classloader. Axis2 may be configured to set the context classloader
when invoking a service, but there is probably no such feature for
modules. The solution would then be to set the context classloader
explicitly before invoking XmlBeans (or the code that relies on it).
See the Javadoc of java.lang.Thread for more information about how to
set the context classloader.

Regards,

Andreas

2009/6/26 Björn Hagemeier <b.hageme...@fz-juelich.de>:
> Dear Andreas,
>
> when removing all _my_ jars from the WEB-INF/lib folder (I assume you
> didn't mean removing all, as many of them are there from the plain axis2
> war deployment), I still get the same behavior.
>
> I have debugged a little by adding "-verbose" to my JAVA_OPTS environment,
> so it would show each class when it is loaded and from where. My guess is
> that XmlBeans has some class loading issues. The JAR files which I had to
> copy to the WEB-INF/lib directory were actually also available in
> <tomcat-root>/temp/axis2-tmp-3137206636581348232.tmp/. Classes were also
> picked up from there, but not for certain purposes, e.g. XmlBeans.
>
> The stack trace I get when doing as you asked (except I needed to install
> rampart and thus copy its libraries over to WEB-INF/lib) is this:
> ==================================================
> 2009-06-26 10:48:08,046 [http-8080-4] ERROR
> eu.smartlm.security.aa.handlers.UVOSAuthenticationHandler  - Something wrong
> in eu.smartlm.security.aa.handlers.UVOSAuthenticationHandler
> pl.edu.icm.unicore.uvos.wsapi.xmlbeans.UnsupportedSAMLException: Unknown
> type of attribute value received, value <xml-fragment
> urnx1:scope="/UNICORE/UUDB/SMARTLM-FZJ"
> xsi:type="urnx1:ScopedStringAttributeValueType"
> xmlns:urnx0="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML"
> xmlns:urnx1="urn:vo:SAML:2.0:attribute:ext"
> xmlns:urn="urn:oasis:names:tc:SAML:2.0:assertion"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>FZJ</xml-fragment>
>        at
> pl.edu.icm.unicore.uvos.wsapi.xmlbeans.SAMLXMLBeansMapper.mapAttrValue2APIAttr(SAMLXMLBeansMapper.java:128)
>        at
> pl.edu.icm.unicore.uvos.wsapi.xmlbeans.SAMLXMLBeansMapper.map2APIAttributes(SAMLXMLBeansMapper.java:65)
>        at
> pl.edu.icm.unicore.uvos.wsclient.samlapi.SAMLVOQueryClient.getAttributesGeneric(SAMLVOQueryClient.java:305)
>        at
> pl.edu.icm.unicore.uvos.wsclient.samlapi.SAMLVOQueryClient.getAttributes(SAMLVOQueryClient.java:120)
>        at
> eu.smartlm.security.aa.handlers.UVOSAuthenticationHandler.invoke(UVOSAuthenticationHandler.java:120)
>        at org.apache.axis2.engine.Phase.invoke(Phase.java:318)
>        at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
>        at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
>        at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
>        at
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>        at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>        at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>        at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>        at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>        at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>        at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>        at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
>        at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
>        at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>        at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
>        at java.lang.Thread.run(Thread.java:595)
> ==================================================
>
> I think XmlBeans uses its own classloaders and may thus not be able to pick
> up Classes from any path.
>
>
> Best regards,
> Björn
>
> On 23.06.2009 17:19, Andreas Veithen wrote :
>>
>> Björn,
>>
>> Can you post the exception (including stack trace) you get when you
>> deploy just the MAR (i.e. when you remove _all_ your JARs from
>> WEB-INF/lib)?
>>
>> Andreas
>>
>> 2009/6/23 Björn Hagemeier <b.hageme...@fz-juelich.de>:
>>>
>>> Dear Andreas,
>>>
>>> there are a whole bunch of JARs in my MAR (about 44). To give you an
>>> example, here are two prominent examples, which I know don't get picked
>>> up
>>> from the MAR:
>>>
>>> ==================================================
>>> -rw-r--r--  2.0 unx   873863 b- defN 19-May-09 16:29
>>> lib/SAMLtypes-1.1.jar
>>> -rw-r--r--  2.0 unx    96323 b- defN 29-May-09 12:20 lib/samly2-1.2.1.jar
>>> ==================================================
>>>
>>> SAMLtypes are Java bindings of XML types created by XmlBeans, samly2 is
>>> library handling SAML documents and possibly also containing XmlBeans
>>> generated Java bindings.
>>> These two are in the MAR, but don't get picked up, so I had to copy them
>>> into WEB-INF/lib as well. If they are there, everything is fine. This
>>> behavior can be seen for other JARs, too. It will always occur at
>>> runtime,
>>> when the actual authentication & authorization is done. For example, when
>>> I
>>> remove SAMLtypes from the WEB-INF/lib folder and then try and do
>>> authentication through my handlers, I get the following:
>>>
>>> ==================================================
>>> java.lang.NoClassDefFoundError:
>>> xmlbeans/org/oasis/saml2/assertion/NameIDType$Factory
>>>       at eu.unicore.samly2.elements.NameID.<init>(NameID.java:27)
>>>       at
>>>
>>> pl.edu.icm.unicore.uvos.wsclient.samlapi.SAMLVOClient.<init>(SAMLVOClient.java:50)
>>>       at
>>>
>>> pl.edu.icm.unicore.uvos.wsclient.samlapi.SAMLVOQueryClient.<init>(SAMLVOQueryClient.java:64)
>>>       at
>>>
>>> eu.smartlm.security.aa.handlers.UVOSAuthenticationHandler.invoke(UVOSAuthenticationHandler.java:116)
>>>       at org.apache.axis2.engine.Phase.invoke(Phase.java:317)
>>>       at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:264)
>>>       at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:163)
>>>       at
>>>
>>> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
>>>       at
>>> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:133)
>>>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
>>>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>>>       at
>>>
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>>       at
>>>
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>>       at
>>>
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>>>       at
>>>
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>>>       at
>>>
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>>       at
>>>
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>>>       at
>>>
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>>       at
>>>
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
>>>       at
>>>
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
>>>       at
>>>
>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
>>>       at
>>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>>>       at java.lang.Thread.run(Thread.java:595)
>>> ==================================================
>>>
>>> Does this information help?
>>>
>>>
>>> Best regards,
>>> Björn
>>>
>>> On 23.06.2009 14:13, Andreas Veithen wrote :
>>>>
>>>> Björn,
>>>>
>>>> Can you please give us some more details about which JARs are not
>>>> picked up and how your code uses the classes in these JARs?
>>>>
>>>> Andreas
>>>>
>>>> On Tue, Jun 23, 2009 at 13:59, Björn
>>>> Hagemeier<b.hageme...@fz-juelich.de>
>>>> wrote:
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I'm using the axis2-mar-maven-plugin to build an AA module, which
>>>>> contains a
>>>>> number of dependencies. I need to configure the plugin with
>>>>>
>>>>> <includeDependencies>true</includeDependencies>
>>>>>
>>>>> to get all the dependencies in. However, I also need to copy some of
>>>>> the
>>>>> dependencies manually to axis2/WEB-INF/lib, as not all of them seem to
>>>>> be
>>>>> picked up from the .mar file (although they are contained in it). Could
>>>>> someone please explain why some JARs do get picked up from the module
>>>>> and
>>>>> some have to be available in the lib folder. I would like all
>>>>> dependencies
>>>>> to get picked up from the module archive itself, so I can provide a
>>>>> self-contained file that doesn't rely on certain JARs to be available,
>>>>> which
>>>>> are not existing in an ordinary Axis2 deployment.
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Björn
>>>>> --
>>>>> Dipl.-Inform. Björn Hagemeier
>>>>> Juelich Supercomputing Centre
>>>>> Institute for Advanced Simulation
>>>>>
>>>>> Phone: +49 2461 61 1584
>>>>> Fax  : +49 2461 61 6656
>>>>> Email: b.hageme...@fz-juelich.de
>>>>> Skype: bhagemeier
>>>>> WWW  : http://www.fz-juelich.de/jsc
>>>>>
>>>>> JSC is the coordinator of the
>>>>> John von Neumann Institute for Computing
>>>>> and member of the
>>>>> Gauss Centre for Supercomputing
>>>>>
>>>>>
>>>>> Forschungszentrum Jülich GmbH
>>>>> 52425 Jülich
>>>>>
>>>>> Sitz der Gesellschaft: Jülich
>>>>> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
>>>>> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
>>>>> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
>>>>> Dr. Ulrich Krafft (stellv. Vorsitzender); Dr. Sebastian M. Schmidt
>>>>>
>>>
>>> --
>>> Dipl.-Inform. Björn Hagemeier
>>> Juelich Supercomputing Centre
>>> Institute for Advanced Simulation
>>>
>>> Phone: +49 2461 61 1584
>>> Fax  : +49 2461 61 6656
>>> Email: b.hageme...@fz-juelich.de
>>> Skype: bhagemeier
>>> WWW  : http://www.fz-juelich.de/jsc
>>>
>>> JSC is the coordinator of the
>>> John von Neumann Institute for Computing
>>> and member of the
>>> Gauss Centre for Supercomputing
>>>
>>>
>>> Forschungszentrum Jülich GmbH
>>> 52425 Jülich
>>>
>>> Sitz der Gesellschaft: Jülich
>>> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
>>> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
>>> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
>>> Dr. Ulrich Krafft (stellv. Vorsitzender); Dr. Sebastian M. Schmidt
>>>
>>
>
>
> --
> Dipl.-Inform. Björn Hagemeier
> Juelich Supercomputing Centre
> Institute for Advanced Simulation
>
> Phone: +49 2461 61 1584
> Fax  : +49 2461 61 6656
> Email: b.hageme...@fz-juelich.de
> Skype: bhagemeier
> WWW  : http://www.fz-juelich.de/jsc
>
> JSC is the coordinator of the
> John von Neumann Institute for Computing
> and member of the
> Gauss Centre for Supercomputing
>
>
> Forschungszentrum Jülich GmbH
> 52425 Jülich
>
> Sitz der Gesellschaft: Jülich
> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
> Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
> Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
> Dr. Ulrich Krafft (stellv. Vorsitzender); Dr. Sebastian M. Schmidt
>
>

Reply via email to