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.
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]
Keith, I looked here:
, and line 89:
switchyardConfig = (CompositeModel)new ModelResource().pull(switchyardConfig);
switchyard.xml now has a root element of <switchyard>, not <composite>.
It should read:
switchyardConfig = ((SwitchYardModel)new ModelResource().pull(switchyardConfig)).getComposite();
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.
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.
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.
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).
- firstname.lastname@example.org:tfennelly/jboss-switchyard-core.git kcbabo-SWITCHYARD-38
- email@example.com:tfennelly/jboss-switchyard-components.git cdi-deployer-evolve-v5
- Created an AbstractDeployer class, which both Deployer and JUnitCDIDeployer extend.
- 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.
- 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.
- 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?).
- 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.
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.
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.
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.
TestDeployApp.jar 9.6 K
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.
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)?