Deploy Shib2 IdP in Glassfish 3
Farrukh Najmi
farrukh at wellfleetsoftware.com
Wed Jun 19 11:36:48 EDT 2013
On 06/18/2013 01:26 PM, Cantor, Scott wrote:
> On 6/18/13 1:19 PM, "Farrukh Najmi" <farrukh at wellfleetsoftware.com> wrote:
>> Having read the archives I understand that there are some issues in
>> deploying Shib2 IdP in Glassfish 3 container.
> The IdP is very minimal in use of Java server features and is standards
> compliant, so if there are issues, they fall into a couple of areas:
>
> - container bugs
> - the back channel thing
>
Scott,
Here is my experience so far...
* With no special preparations I tried deploying the idp.war using
asadmin tool of Glassfish 3 with following:
~/glassfish3/bin/asadmin deploy --force=true --contextroot idp
--precompilejsp=false --verify=false --upload=false
/home/najmi/shibboleth/shibboleth-identityprovider-2.4.0/installation/war/idp.war
* Deployment of idp.war failed with error:
Cannot find class [org.apache.xerces.util.SecurityManager] for bean
with name 'shibboleth.XercesSecurityManager' defined in URL
[file:/home/najmi/shibboleth/shibboleth-identityprovider-2.4.0/installation//conf/internal.xml];
nested exception is java.lang.ClassNotFoundException:
org.apache.xerces.util.SecurityManager
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:5389)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at
com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2019)
at
com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669)
at
com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at
org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
* Upon inspection deployment failure was due to the following missing
xerces runtime dependencies in the IdP project.
edu.internet2.middleware:shibboleth-identityprovider:jar:trunk
...
+- org.apache.xerces:xercesImpl:jar:2.9.1:runtime
The org.opensaml.xml.parse.BasicParserPool class is configured to
use above class in internal.xml spring config. As an aside, I wonder
whether the explicit xerces dependency is necessary or whether use
of standard JAXP API would suffice.
* So I added xercesImpl-2.10.0.jar using following command:
cp
/home/najmi/shibboleth/shibboleth-identityprovider-2.4.0/endorsed/xercesImpl-2.10.0.jar
/home/najmi/glassfish3/glassfish/domains/domain1/lib
* Now GF startup failed with the error:
SEVERE: Exception while deploying the app
[spring-security-samples-ldap-2.0.3]
SEVERE: org/w3c/dom/ElementTraversal
java.lang.NoClassDefFoundError: org/w3c/dom/ElementTraversal
at org.apache.xerces.dom.DeferredDocumentImpl.getNodeObject(Unknown
Source)
at
org.apache.xerces.dom.DeferredDocumentImpl.synchronizeChildren(Unknown
Source)
at org.apache.xerces.dom.CoreDocumentImpl.getDocumentElement(Unknown
Source)
at
org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDOMSource.execute(MbeansDescriptorsDOMSource.java:122)
at
org.apache.tomcat.util.modeler.modules.MbeansDescriptorsDOMSource.loadDescriptors(MbeansDescriptorsDOMSource.java:110)
at org.apache.tomcat.util.modeler.Registry.load(Registry.java:761)
at
org.apache.tomcat.util.modeler.Registry.loadDescriptors(Registry.java:874)
at
org.apache.tomcat.util.modeler.Registry.loadDescriptors(Registry.java:853)
at
org.apache.tomcat.util.modeler.Registry.findDescriptor(Registry.java:928)
at
org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java:639)
at
org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java:983)
at
org.apache.tomcat.util.modeler.Registry.registerComponent(Registry.java:801)
at
org.apache.catalina.connector.Connector.initialize(Connector.java:1316)
at
com.sun.enterprise.web.connector.coyote.PECoyoteConnector.initialize(PECoyoteConnector.java:705)
at com.sun.enterprise.web.WebConnector.initialize(WebConnector.java:76)
at org.apache.catalina.startup.Embedded.start(Embedded.java:934)
at
com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:604)
at
com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at
com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at
com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at
com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at
org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:93)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:956)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:666)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
at
com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at
com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at
com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at
com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at
com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:253)
at
com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at
com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
* Using the following bash shell command I found that this class is
defined in
/home/najmi/shibboleth/shibboleth-identityprovider-2.4.0/endorsed/xml-apis-2.10.0.jar
for i in
/home/najmi/shibboleth/shibboleth-identityprovider-2.4.0/endorsed/*.jar;
do jar -tvf "$i" | grep -Hsi org.w3c.dom.ElementTraversal && echo
$i; done
* So I added xml-apis-2.10.0.jar with command:
cp
/home/najmi/shibboleth/shibboleth-identityprovider-2.4.0/endorsed/xml-apis-2.10.0.jar
/home/najmi/glassfish3/glassfish/domains/domain1/lib
Now GF startup failed with the error:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: javax.xml.stream.FactoryConfigurationError: Provider
com.ctc.wstx.stax.WstxInputFactory not found
at javax.xml.stream.XMLInputFactory.newInstance(Unknown Source)
at org.jvnet.hk2.config.ConfigParser.<clinit>(ConfigParser.java:244)
at
com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateConfig(AbstractModulesRegistryImpl.java:174)
at
com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createHabitat(AbstractModulesRegistryImpl.java:158)
at com.sun.enterprise.module.bootstrap.Main.createHabitat(Main.java:459)
at org.jvnet.hk2.osgiadapter.HK2Main.createHabitat(HK2Main.java:96)
at
com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:89)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
* I found a workaround in the following resource:
http://metro.1045641.n5.nabble.com/Xerces-Xalan-not-playing-nice-with-Glassfish-Metro-td1061800.html
The workaround was to edit the
/home/najmi/glassfish3/glassfish/domains/domain1/lib/xercesImpl-2.10.0.jar
file to rename the folder /META-INF/service to /META-ING/servicessaved
I did the rename using Archive Manager in Ubuntu Linux so I did not
have to extract and repackage the jar, though any other means
including extracting the jar renaming in filesystem and recreating
the jar is fine.
Above makes sure that the classes of this jar are not used as
plugins by JAXP layer and do not confuse the ClassLoader.
* I then redeployed the idp using the asadmin command:
~/glassfish3/bin/asadmin deploy --force=true --contextroot idp
--precompilejsp=false --verify=false --upload=false
/home/najmi/shibboleth/shibboleth-identityprovider-2.4.0/installation/war/idp.war
This time deployment went fine (no errors).
What I have gathered so far is that direct use of xerces classes in
opensaml (and possibly IdP) is not a good fit with Glassfish which
expects that JAXP implementation provided by the JDK to be used. The
kludge / workaround I list above seems to work though I need to test
this further. The open question is whether Shib projects can and should
consider removing the explicit dependency on xerces and instead rely on
standard JAXP API.
I will plug away at this some more and keep this thread updated. Please
let me know if you see me going in the weeds. Thanks very much for your
help.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130619/cb701426/attachment-0001.html
More information about the users
mailing list