1 2 Previous Next 27 Replies Latest reply on Feb 23, 2011 2:17 AM by mageshbk Go to original post
      • 15. Re: Deployer update
        tfennelly

        I just noticed something strange in my debugger... I might have a dirty AS6... ignore last post untill further notice

        • 16. Deployer update
          kcbabo

          One thing that was not completely obvious in my previous post is that the attachment is actually a jar of the project directory.  So you will need to unjar and "mvn install" to create a deployable app.

          • 17. Re: Deployer update
            tfennelly

            OK.. sorry about the last post... I did have a dirty AS6.

             

            From what I can see we have a deployment ordering issue.  The AS6 deployer is getting in before the CDI bean discovery is happening.  I think that would explain what Keith is seeing.

             

            As a test, I stubbed out the SwitchYardDeployer class and just had it print a sysout.  I also added sysouts to the CDI bean discover class.  This is what I see (ran it a few times) ...

             

             

            20:37:25,954 INFO  [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS [6.0.0.Final "Neo"] Started in 26s:75ms
            20:38:06,242 INFO  [STDOUT] ***** AS6 Deployer!!!!
            20:38:06,313 INFO  [STDOUT] ***** Before CDI Discovery!!!!
            20:38:06,399 INFO  [STDOUT] ***** CDI ProcessBean javax.transaction.UserTransaction
            20:38:06,400 INFO  [STDOUT] ***** CDI ProcessBean javax.enterprise.inject.spi.InjectionPoint
            20:38:06,401 INFO  [STDOUT] ***** CDI ProcessBean org.jboss.weld.context.http.HttpRequestContext
            
            etc....
            
            

             

            Note that the AS6 deployer is before the CDI bean discovery.

             

            So am I doing something wrong or did I miss something in the setup, or is there a deployment ordering issue?

            • 18. Re: Deployer update
              tfennelly

              Forgot to mention... it is discovering the @Service beans....

               

               

              20:38:06,409 INFO  [STDOUT] ***** CDI ProcessBean org.switchyard.example.deployable.SimpleServiceBean
              
              • 19. Deployer update
                kcbabo

                Just tested this again with upstream master for core and the SWITCHYARD-102 branch in my components repository and here's what I get:

                 

                Caused by: java.lang.RuntimeException: Unknown Service name 'SimpleService'.

                    at org.switchyard.component.bean.deploy.BeanComponentActivator.init(BeanComponentActivator.java:66) [:1.0-SNAPSHOT]

                    at org.switchyard.deploy.internal.Deployment.deployServices(Deployment.java:166) [:1.0-SNAPSHOT]

                    at org.switchyard.deploy.internal.Deployment.init(Deployment.java:114) [:1.0-SNAPSHOT]

                    at org.switchyard.deployment.SwitchYardDeployer.deploy(SwitchYardDeployer.java:49) [:1.0-SNAPSHOT]

                    ... 42 more

                 

                cheers,

                keith

                • 20. Re: Deployer update
                  tfennelly

                  Keith Babo wrote:

                   

                  Just tested this again with upstream master for core and the SWITCHYARD-102 branch in my components repository and here's what I get:

                   

                  Caused by: java.lang.RuntimeException: Unknown Service name 'SimpleService'.

                      at org.switchyard.component.bean.deploy.BeanComponentActivator.init(BeanComponentActivator.java:66) [:1.0-SNAPSHOT]

                      at org.switchyard.deploy.internal.Deployment.deployServices(Deployment.java:166) [:1.0-SNAPSHOT]

                      at org.switchyard.deploy.internal.Deployment.init(Deployment.java:114) [:1.0-SNAPSHOT]

                      at org.switchyard.deployment.SwitchYardDeployer.deploy(SwitchYardDeployer.java:49) [:1.0-SNAPSHOT]

                      ... 42 more

                   

                  cheers,

                  keith

                   

                  That would be because the bean discovery has not kicked in yet i.e. the beans have not yet been discovered.

                   

                  Can we make our deployer dependent on the weld deployer?  Hopefully that would switch the ordering.  I'll try that in the morning.

                  • 21. Re: Deployer update
                    tfennelly

                    Sorry for popping in and out... I go away and then come back again after thinking of something else to try

                     

                    So... the TCCL when the SwitchYardDeployer is called is not hte same as that of the deployment, but... you can get it from the getClassLoader() method on the VFSDeploymentUnit that's passed to SwitchYardDeployer.deploy().  I checked and they are the same, which makes sense.

                    • 22. Deployer update
                      kcbabo

                      I could have sworn that I walked through this in the debugger and the beans were not getting discovered even when the SY deployer kicked in after the bean discovery.  Just ran it again and I'm obviously mistaken, because moving the SY deployer to DeploymentStages.INSTALLED works.  After that, I ran into an issue with CDI barfing during the descriptor lookup.  That was due to the TCCL not getting set.  Used the DeploymentUnit hook you pointed out above and it works like a charm!

                       

                      I will commit the change to get the AS6 SY deployer to behave correctly.  Not sure my changes to use BeanManager are necessary now.  Guess it depends on whether you like the BeanManager or ClassLoader route better. :-)  Either way, we should spend some time post M1 to review how this is done.  Looking at the Weld AS6 integration, it looks like Kabir did a lot of that work.  We should sync up with him to see if he has some alternatives.

                      • 23. Deployer update
                        kcbabo

                        Quick update.  I have updated the Deployer to kick off in the REAL stage, which I'm pretty sure is when the relevant Weld deployer is kicked off and our extension observer methods get called.  I also added a BeanMetaData implementation to allow us to (a) set dependencies correctly within the REAL stage and (b) get create/start/stop/destroy lifecycle support from AS.  Will clean it up and issue a pull request tomorrow AM.

                        • 24. Deployer update
                          tfennelly

                          Ah cool... I was about to jump into this again but you've it sorted out... thanks Keith!!

                          • 25. Re: Deployer update
                            kcbabo

                            The saga continues.  The was a race condition or random ordering with the deployer configuration where sometimes we would get in front of Bean discovery and other times after it.  After lots of digging through the Weld MC integration code, I believe the following dependency will work:

                             

                             

                                    bmdBuilder.addDependency(deploymentUnit.getName() + "_WeldBootstrapBean");

                             

                            I will package this up in a bit and commit.  Ugh.

                            • 26. Re: Deployer update
                              kcbabo

                              Best I can tell everything is sorted with the CDI and AS6 deployer now.  I can deploy/undeploy/redeploy in both environments with no issues.  One kinda bizarre thing is that both environments puke when starting the AS with the app already in the deploy directory.  Haven't had time to dig further on that bit.

                               

                              BTW, I'm no longer using my tomtomdeploy branch in the components repository.  If you have an up-to-date upstream master and pull the following changes then it should work just fine for you:

                               

                              https://github.com/jboss-switchyard/components/pull/51

                              https://github.com/jboss-switchyard/core/pull/85

                               

                              NOTE: the SOAP config's namespace changed at some point, which means that the current SOAP gateway has a marshaller that is not compatible with the last example app I attached.  I have attached a new one to this post (unjar and build).

                              • 27. Re: Deployer update
                                mageshbk

                                Yet another updated deployable app project. Updated the artifact ids and the SOAP config's namespace.

                                 

                                Sweet surprise to see CXF's Endpoint Server implementation kick in 1,000 cool!

                                 

                                [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] Creating Service {http://test.ws/}SimpleWebService from class org.switchyard.component.soap.BaseWebService
                                [org.apache.cxf.endpoint.ServerImpl] Setting the server's publish address to be http://localhost:18001/SimpleWebService
                                [org.switchyard.component.soap.InboundHandler] WebService published at http://localhost:18001/SimpleWebService
                                

                                 

                                However the Endpoint is not listed here http://localhost:8080/jbossws/services, though.

                                1 2 Previous Next