1 2 3 4 Previous Next 57 Replies Latest reply on Jun 9, 2010 10:51 AM by sguilhen Go to original post
      • 45. Re: Classcast exception while executing WSTrustClientTest
        anil.saldhana

        XML signatures are very sensitive to any changes in the xml. I am wondering if there is any kind of DOM/SAAJ/SOAP processing outside of Picketlink realm is messing up things.   Is there any kind of marshalling/unmarshalling done?  This can be one cause of problem.

         

        Ensure that you are using apache xml security rather than the xml security implementation in the JDK. You have to use the endorsed mechanism.

        • 46. Re: Classcast exception while executing WSTrustClientTest
          rashmirajappa

          Hi Anil,

           

          You were right that it XML validation is failing due to picketlink using sun jdk's xml security implementation

           

          I have attached the additional debug info where it is clear that the class being used is com.sun.org.apache.xml.internal.security part of JDK6. (I've verified using -verbose:class that xml sec jar is loaded from JDK/jre/lib/rt.jar)

           

          I verified that when we start JBOSS it modifys java.endorsed.dirs to <JBOSS_HOME>\lib\endorsed

          DEBUG [ServerInfo]     sun.boot.library.path: C:\Java\jdk1.6.0_01\jre\bin
          DEBUG [ServerInfo]     jboss.home.url: file:/E:/J2EEServers/jboss-5.1.0.GA/
          DEBUG [ServerInfo]     java.version: 1.6.0_01
          DEBUG [ServerInfo]     java.util.logging.manager: org.jboss.logmanager.LogManager
          DEBUG [ServerInfo]     user.timezone: Asia/Calcutta
          DEBUG [ServerInfo]     jboss.server.home.dir: E:\J2EEServers\jboss-5.1.0.GA\server\default
          DEBUG [ServerInfo]     jgroups.bind_addr: 127.0.0.1
          DEBUG [ServerInfo]     sun.arch.data.model: 32
          DEBUG [ServerInfo]     java.endorsed.dirs: E:\J2EEServers\jboss-5.1.0.GA\lib\endorsed

          Hence i have to place apache xmlsec in <JBOSS_HOME>\lib\endorsed
          I downloaded xml-security-bin-1_4_3.zip from apache repository

          xmlsec-1.4.3.jar has a dependency on commons-logging.jar
          If I place both these jars in <JBOSS_HOME>\lib\endorsed JBOSS does not start.

           

          2010-05-11 11:35:49,810 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) Error installing to Create: name=TransactionManager state=Configured
          java.lang.ExceptionInInitializerError
          at com.arjuna.ats.internal.arjuna.objectstore.ShadowingStore.<init>(ShadowingStore.java:839)
          at com.arjuna.ats.internal.arjuna.objectstore.ShadowNoFileLockStore.<init>(ShadowNoFileLockStore.java:155)
          at com.arjuna.ats.internal.arjuna.objectstore.HashedStore.<init>(HashedStore.java:268)
          at com.arjuna.ats.internal.arjuna.objectstore.HashedActionStore.<init>(HashedActionStore.java:172)
          at com.arjuna.ats.internal.arjuna.objectstore.HashedActionStore.<init>(HashedActionStore.java:167)
          at com.arjuna.ats.internal.arjuna.objectstore.HashedActionStore.create(HashedActionStore.java:100)
          at com.arjuna.ats.internal.arjuna.objectstore.HashedActionStoreSetup.createVoid(HashedActionStoreSetup.java:49)
          at com.arjuna.ats.internal.arjuna.gandiva.inventory.StaticInventory.createVoid(StaticInventory.java:76)
          at com.arjuna.ats.arjuna.gandiva.inventory.Inventory.createVoid(Inventory.java:84)
          at com.arjuna.ats.arjuna.objectstore.ObjectStore.<init>(ObjectStore.java:128)
          at com.arjuna.ats.arjuna.coordinator.TxControl.getStore(TxControl.java:249)
          at com.arjuna.ats.arjuna.recovery.ActionStatusService.<init>(ActionStatusService.java:71)
          at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
          at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
          at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
          at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
          at java.lang.Class.newInstance0(Class.java:355)
          at java.lang.Class.newInstance(Class.java:308)
          at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.start(TransactionStatusManager.java:140)
          at com.arjuna.ats.arjuna.recovery.TransactionStatusManager.<init>(TransactionStatusManager.java:71)
          at com.arjuna.ats.arjuna.coordinator.TxControl.createTransactionStatusManager(TxControl.java:286)
          at com.arjuna.ats.arjuna.coordinator.TxControl.<clinit>(TxControl.java:518)
          at com.arjuna.ats.jbossatx.jta.TransactionManagerService.create(TransactionManagerService.java:185)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
          at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
          at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
          at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
          at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
          at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
          at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
          at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
          at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
          at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
          at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
          at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
          at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
          at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
          at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
          at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
          at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
          at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
          at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
          at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
          at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
          at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
          at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
          at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
          at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
          at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
          at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
          at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
          at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
          at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
          at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
          at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
          at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
          at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
          at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
          at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
          at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
          at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
          at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
          at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
          at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
          at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
          at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
          at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
          at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
          at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
          at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
          at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
          at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
          at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
          at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
          at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
          at org.jboss.Main.boot(Main.java:221)
          at org.jboss.Main$1.run(Main.java:556)
          at java.lang.Thread.run(Thread.java:619)
          Caused by: com.arjuna.common.util.exceptions.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException) (Caused by org.apache.commons.logging.LogConfigurationException: java.lang.NullPointerException (Caused by java.lang.NullPointerException))
          at com.arjuna.common.internal.util.logging.jakarta.JakartaRelevelingLogFactory.getLog(JakartaRelevelingLogFactory.java:87)
          at com.arjuna.common.util.logging.LogFactory.getLogNoi18n(LogFactory.java:191)
          at com.arjuna.ats.arjuna.logging.tsLogger.<clinit>(tsLogger.java:58)

           

           

           

          Tried to fix this issue using two approaches system propert and commons-logging.properties.
          But the above problem persists.

           

          Pl let me know how i can make JBOSS use apache xmlsec while using JBOSS WS Metro?

           

          regards,

          Rashmi

          • 47. Re: Classcast exception while executing WSTrustClientTest
            rashmirajappa

            Jamere,

             

            Which webservices feature (JBOSS WS Native/CXF/Metro) have you configured with JBOSS 5.1.0 GA?

            I'm using Metro and on executing client I receive 'Is valid? false'

             

            regards,

            Rashmi

            • 48. Re: Classcast exception while executing WSTrustClientTest
              morrowjl

              I am using Native.

               

              picketLink.JPG

              • 49. Re: Classcast exception while executing WSTrustClientTest
                rashmirajappa

                Thanks that is the difference. I hope Stefan uses JBOSS WS Metro and tries to help me with a solution.

                Can you also pl paste a picture or attach the eclipse .classpath file?

                I configured a new instance of JBOSS with native but having trouble executing the client.

                 

                I read in one your posts you addressed me as he ... i'm a lady from India

                 

                Thanks & regards,

                Rashmi

                • 50. Re: Classcast exception while executing WSTrustClientTest
                  morrowjl

                  Sorry about that...

                   

                  Here is the classpath

                  • 51. Re: Classcast exception while executing WSTrustClientTest
                    sguilhen

                    Hi Rashmi,

                     

                    I'll try setting up JBossWS-Metro integration and see if I can reproduce the validation error there. I am working on an issue with the CXF integration and I'll take a look at your issue right after that.

                     

                    Cheers,

                    Stefan

                    • 52. Re: Classcast exception while executing WSTrustClientTest
                      raycardillo

                      Has anyone done this JBossWS-Metro testing yet?  I have experienced many of the problems mentioned in this thread while trying to experiment with PicketLink STS on system that has: JBoss AS 5.1 (JDK 6 build) with JBoss ESB 4.8 and JBossWS-Metro 3.2.2.  I believe the problems must be related to either the JDK 6 build or JBossWS-Metro because even the simplest WSTrustClientTest example does not work "out of the box" without hunting problems down (as others have documented previously in this thread).  The installation itself is sound, all is well, verified the installation, other services deploy and execute properly, etc.  Only problems at the moment are when working through the PicketLink experiments.

                       

                      In my present state, using the latest CR3 jars/wars available from the nexus site, I can obtain a token using an "Issue" request, but I cannot validate, cancel, or renew the token using their associated requests.  I have been studying the exception stack and the source code, and the problem is that the token element name and namespace is coming back as "null" and a SecurityTokenProvider cannot be found for "null:null".  I suspect this is related to StAX versus DOM manipulation of the message, etc, but I don't know the source code well enough to trace this down.  Tracing confirms that the token element is present, so something is going on with the message somewhere in one of the parsers or maybe in the JAXB bindings.  I have some experience diagnosing custom binding problems when xsd:any elements are involved in JAXB, but I would think that would be a universal problem if that were the cause (should not be unique to the JBossWS-Metro environment).

                       

                      For reference, I have tried both the CR3 release from nexus and the CR3.SNAPSHOT release that contains the WS-Trust namespace fix (PLFED-63).  In the latter version, I have to change my namespace reference in the requests, but I get the same error (token is null) once I do that.

                       

                      At any rate, if anyone ideas about where to look, or something else to try, I would greatly appreciate it, and I'm willing to help.

                      • 53. Re: Classcast exception while executing WSTrustClientTest
                        anil.saldhana

                        We have not done jbossws-metro testing yet.  You are free to choose the JBossWS-native stack where we have tested it.

                        • 54. Re: Classcast exception while executing WSTrustClientTest
                          raycardillo

                          Understood, but Stefan said that was being tested, and I am motivated to contribute in this regards because we need Metro for other purposes.  So aside from trying to see if these problems sounded familiar to anyone, I was also trying to find out if others have done anything in this area.

                           

                          I'm hoping that those interested in Metro support will be interested in participating in a new thread so we can share details about what works, what does not work, what progress has been made, etc.  So was hoping to hear from Stefan to learn more about what has been learned so far, and then see how other interested developers can help.

                          • 55. Re: Classcast exception while executing WSTrustClientTest
                            sguilhen

                            Hi Ray,

                             

                            I have unfortunatelly been busy with other issues and didn't have the time yet to look into the validation failure that is seen on metro integration. In the past we've had some issues with JAXB marshalling/unmarshalling processes messing with namespaces. Of course, any change to the XML document will result in a validation failure by the STS.

                             

                            As you said, it may have to do with Stax versus DOM so we have to find out exactly where the document is getting tempered. Is it right after the STS marshalls the response? Is it after the client code unmarshalls it? What if we just use JDK6 JAX-WS classes in the client side (that is, no JBossWS classes)?

                             

                            Either way, the STS has been tested with the Native stack but ideally we must be able to run it on top of CXF or Metro, have automated builds and tests on Hudson for all stacks, improve documentation, etc. Thus it is very important that you and other community members are willing to help by writting some code, reporting bugs, investigating issues, writting wiki articles that may help others deploy a particular configuration, etc. I've seen the discussion you started in the development forum and I want to ask you to post your findings there too. I will add my own considerations later this week.

                            • 56. Re: Classcast exception while executing WSTrustClientTest
                              sguilhen

                              Design discussion thread abou the Metro validation issue: https://community.jboss.org/thread/152427

                              • 57. Re: Classcast exception while executing WSTrustClientTest
                                sguilhen

                                Hi Rashmi,

                                 

                                I was owing you a reply about the JBossWS Metro integration. I've run some STS tests (JBAS 6.0.0.M3 and JBoss WS-Metro 3.3.1) here using Metro as the WS stack and the validation worked just fine. I used the STSClient API for both issuing and validating the security token. As Ray Cardillo stated in this thread (http://community.jboss.org/thread/152427?tstart=0), he was also having signature problems when using Metro stack and it turned out it was his client code messing with the assertion.

                                 

                                So you have to be absolutely sure your client app is not parsing the assertion somehow before you include it in the validation request. If the error persists, I would recommend using the STSClient API to send the WS-Trust requests.

                                 

                                Cheers,

                                Stefan

                                1 2 3 4 Previous Next