1 2 Previous Next 27 Replies Latest reply: Feb 23, 2011 2:17 AM by Magesh Bojan Go to original post RSS
  • 15. Re: Deployer update
    Tom Fennelly Master

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

  • 16. Deployer update
    Keith Babo Master

    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
    Tom Fennelly Master

    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
    Tom Fennelly Master

    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
    Keith Babo Master

    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
    Tom Fennelly Master

    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
    Tom Fennelly Master

    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
    Keith Babo Master

    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
    Keith Babo Master

    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
    Tom Fennelly Master

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

  • 25. Re: Deployer update
    Keith Babo Master

    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
    Keith Babo Master

    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
    Magesh Bojan Master

    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