1 2 Previous Next 27 Replies Latest reply: Feb 23, 2011 2:17 AM by Magesh Bojan RSS

Deployer update

Keith Babo Master

I pushed a fresh copy of the deployer work from the F2F into my core repository in the SWITCHYARD-38 branch.  This has been rebased against current upstream.  The core deployer interfaces and impl have been split off from CDI, with the CDI-based deployer in its own module now.

 

Tom C - can you pull it down and integrate your AS deployer work as a separate module inside the deploy directory?

 

Tom F - the current deploy API is still kinda yucky, but it's slimmed down from the last attempt, so that's something.  I have pushed an updated Bean and SOAP deployer to my components tomtomdeploy branch.  The only piece that''s missing is the creation of invocation proxies in the bean component activator.  Assuming the current API satisfies your needs, we can push the core and component pieces into upstream.

  • 1. Re: Deployer update
    Tom Cunningham Master

    Took a look at the SWITCHYARD-38 branch - it looks like the rebase against the current upstream broke things - it doesn't matter for the work I'm doing - I'll just comment things out for now and get my stuff working around it.

     

    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project deploy: Compilation failure: Compilation failure:
    [ERROR] /home/tcunning/src/switchyard/kbabo/core/deploy/base/src/main/java/org/switchyard/deploy/internal/Deployer.java:[38,44] cannot find symbol
    [ERROR] symbol  : class ExternalServiceModel
    [ERROR] location: package org.switchyard.config.model.composite
    [ERROR] /home/tcunning/src/switchyard/kbabo/core/deploy/base/src/main/java/org/switchyard/deploy/internal/Deployer.java:[39,44] cannot find symbol
    [ERROR] symbol  : class InternalServiceModel
    [ERROR] location: package org.switchyard.config.model.composite
    [ERROR] /home/tcunning/src/switchyard/kbabo/core/deploy/base/src/main/java/org/switchyard/deploy/internal/Deployer.java:[40,44] cannot find symbol
    [ERROR] symbol  : class ReferenceModel
    [ERROR] location: package org.switchyard.config.model.composite
    [ERROR] /home/tcunning/src/switchyard/kbabo/core/deploy/base/src/main/java/org/switchyard/deploy/internal/Deployer.java:[154,17] cannot find symbol
    [ERROR] symbol  : class InternalServiceModel
    [ERROR] location: class org.switchyard.deploy.internal.Deployer
    [ERROR] /home/tcunning/src/switchyard/kbabo/core/deploy/base/src/main/java/org/switchyard/deploy/internal/Deployer.java:[171,17] cannot find symbol
    [ERROR] symbol  : class ReferenceModel
    [ERROR] location: class org.switchyard.deploy.internal.Deployer
    [ERROR] /home/tcunning/src/switchyard/kbabo/core/deploy/base/src/main/java/org/switchyard/deploy/internal/Deployer.java:[184,13] cannot find symbol
    [ERROR] symbol  : class ExternalServiceModel
    [ERROR] location: class org.switchyard.deploy.internal.Deployer
    [ERROR] -> [Help 1]
    [ERROR] 
    
  • 2. Deployer update
    Keith Babo Master

    My bad.  I foolishly did not compile after the rebase ... whoops.  Nothing big, just some name changes.  Fixed the problem and pushed an update.  Thanks for catching it.

  • 3. Deployer update
    David Ward Master

    Keith, I looked here:

    https://github.com/kcbabo/core/blob/SWITCHYARD-38/deploy/base/src/main/java/org/switchyard/deploy/internal/Deployer.java

     

    , and line 89:

    switchyardConfig = (CompositeModel)new ModelResource().pull(switchyardConfig);

    is wrong.

     

    switchyard.xml now has a root element of <switchyard>, not <composite>.

     

    It should read:

    switchyardConfig = ((SwitchYardModel)new ModelResource().pull(switchyardConfig)).getComposite();

  • 4. Deployer update
    David Ward Master

    or rather:

    compositeModel = ...

     

  • 5. Deployer update
    Keith Babo Master

    Yeah, that's Tom's bit there.  :-)  You warned me about this yesterday and I forgot to change it.  Now that we are on the subject though ... is it really "wrong" to pull the config file into a child of the root module?  I agree with you that we will want to parse into the root SwitchYardModel inside Deployer, so take my question as mere curiosity on the possible uses of the config API.  As it stands now, the current code works, so I'm guessing this is a planned or accidental feature of the implementation.

  • 6. Deployer update
    David Ward Master

    The only reason I mentioned it is because I saw elsewhere in the code (where you were pulling it into an InputStream), that you were reading in a switchyard xml file.  Becase of this, your cast above would break.  If your xml file had a root of <composite>, it would work fine.

     

    That being said, there is nothing wrong with whoever is pulling the switchyard xml file to next access the CompositeModel, then pass that to other code: code that only cares about the CompositeModel.  Another example might be a gateway who only cares about a BindingModel, so it gets passed that.  My statement way-back-when when I said we should be passing around a SwitchYardModel instead of a CompositeModel was more of a suggestion for generic code where the requirements of the receiver are not specifically known.

  • 7. Deployer update
    David Ward Master

    As it stands now, the current code works, so I'm guessing this is a planned or accidental feature of the implementation.

     

    The only way the code above could work is if the switchyard.xml you're pulling in is old-school (ie: it has a root of <composite>), or maybe you haven't pulled updates into your local git repo for a while.

  • 8. Deployer update
    Keith Babo Master

    Crap. You're right on the money with the old switchyard.xml.  I was using the end-to-end example and I thought I had updated the config.

  • 9. Re: Deployer update
    Tom Fennelly Master

    OK... I've wired in the cdi client proxies now and have updated the unit tests to "deploy" the test services (see the JUnitCDIDeployer class).

     

    Located at...

    • git@github.com:tfennelly/jboss-switchyard-core.git kcbabo-SWITCHYARD-38
    • git@github.com:tfennelly/jboss-switchyard-components.git cdi-deployer-evolve-v5

     

    Main changes:

    1. Created an AbstractDeployer class, which both Deployer and JUnitCDIDeployer extend.
    2. I had to modify the Activator interface to add a method for getting the ServiceInterface for a service... Deployer and JUnitCDIDeployer use this when registering services.
    3. Added a createExchange(ExchangeContract) method to the Service interface.  I think we have another JIRA for this.  I wanted to get rid of the code level dependency on ServiceDomain(s) wherever I could.

     

    Notes:

    1. There are 2 copies of the JUnitCDIDeployer class (and some related classes) at the moment (in bean and soap component tests).  That should get fixed as part of the "test" component we're in the process of pulling together (see here).  However to fix it, we might need to move some of the bean comopnent classes (they depend) somewhere else (the CDI deployer perhaps?).
    2. The Activator interface... would it make sense to have Activator and ServiceActivator interfaces ?  ServiceActivator would extend Activator and add the new describe(QName) method I added as part of the new set of changes.  Activator could be used to implement activators that only activate reference or service binding components, while ServiceActivator could be used to implement activators that activate Service instances e.g. the SOAPActivator would just implement the Activator interface, while the BeanComponentActivator would implement the ServiceActivator interface.

     

    I probably forgot to mention something.

  • 10. Deployer update
    Keith Babo Master

    I just submitted a pull request based on Tom C's AS6 deployer work.  The good news is that it's working nicely on it's own.  When I added bean component to the mix, our JNDI handshake between the Deployer and Bean Activator got messed up.  I have reworked the ApplicationDescriptorSet implementation and posted a new version to the tomtomdeploy branch in my repository.  The resulting implementaiton appears to work in AS6* and actually improves the stability with CDI Deployer quite a bit.  Before, a redeploy would munge everything up with the CDI deployer, whereas now it seems to work pretty smoothly.

     

    * Unfortunately, CDI stuff is still not working quite right with AS6 deployer.  From stepping through in the debugger, it looks to me like the old problem of @Service beans not getting discovered in the CDI extension.  Tom F - since you have been through this a bunch of times before, I'll let you take a look and let me know what's what.  Let me know if you have any questions on how to reproduce.

  • 11. Deployer update
    Tom Fennelly Master

    I sorted out the commit squashing issues with the deployer changes I was making and have pushed them:

     

     

    Keith... I'll have a look at the CDI issues you are seeing.  I'll look at the mods you've made on that branch but can you also send me whatever you're using to test this + instructions... thanks.

  • 12. Re: Deployer update
    Keith Babo Master

    Instructions to reproduce AS6 deployer issue

     

    tfennelly:  while we are in here … I'll give you a quick rundown

    tfennelly:  all you have to do is build from upstream and you'll get an AS6 deployer zip in your deployer/build/target directory

    tfennelly:  unzip that into as6/server/default/deployers

    tfennelly:  then take the bean component and soap component from my tomtomdeploy branch

    tfennelly:  drop them in server/default/deploy

    tfennelly:  then deploy the app

     

    Update app attached.

  • 13. Re: Deployer update
    Keith Babo Master

    Missed some files in my last commit and push to tomtomdeploy.  To make things easier, I have pushed everything into a new branch SWITCHYARD-102 and rebased against the current upstream.  Use this branch if you are going to build and run a test following the instructions above.

     

    https://github.com/kcbabo/components/tree/SWITCHYARD-102

  • 14. Re: Deployer update
    Tom Fennelly Master

    Hmmm... perhaps there are more steps to the deployment, but what I'm seeing is that it's failing before the CDI Discovery every happens....

     

     

    Caused by: java.lang.NullPointerException
              at org.switchyard.deploy.internal.Deployment.init(Deployment.java:109) [:1.0-SNAPSHOT]
              at org.switchyard.deployment.SwitchYardDeployer.deploy(SwitchYardDeployer.java:49) [:1.0-SNAPSHOT]
              ... 42 more
    
    

     

     

    I hooked up a debugger and the issue in my case is that when the SwitchYardConfigParser attempts to create the config model, it gets null back from the call to (SwitchYardModel) new ModelResource().pull(is).  I stepped into that and the reason for the failure there is that it fails to discover the Marshaller for the "http://www.switchyard.org/config/model/switchyard/v1" namespace.

     

    Are there any other steps to deploying SwitchYard to AS6 that I am missing (I followed the ones above exactly)?

1 2 Previous Next