Implementation class is located in a EAP's module

[anikulin]

Hi guys

I tried to define a SwitchYard Service Bean whose interface and implementation are located in an EAP module. I defined it like this:

   <component xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="TickDAO">
            <implementation.bean xmlns="urn:switchyard-component-bean:config:1.1" class="nu.magick.masterKonnector.dao.TickDAOBean"/>
            <service name="TickDAO">
                <interface.java interface="nu.magick.masterKonnector.dao.TickDAO"/>
            </service>
        </component>

MANIFEST.MF file has a nu.magick.masterKonnector dependency, but when I try to deploy this app I get the following error:

ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."backTestKonnector.jar".SwitchYardService: org.jboss.msc.service.StartException in service jboss.deployment.unit."backTestKonnector.jar".SwitchYardService: org.switchyard.SwitchYardException: SWITCHYARD030412: Unknown Service name '{ck:BackTestKonnector:0.0.1-SNAPSHOT}TickDAO'.
  at org.switchyard.as7.extension.services.SwitchYardService.start(SwitchYardService.java:80)
  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
Caused by: org.switchyard.SwitchYardException: SWITCHYARD030412: Unknown Service name '{ck:BackTestKonnector:0.0.1-SNAPSHOT}TickDAO'.
  at org.switchyard.component.bean.deploy.BeanComponentActivator.activateService(BeanComponentActivator.java:90)
  at org.switchyard.deploy.internal.Deployment.deployImplementations(Deployment.java:546)
  at org.switchyard.deploy.internal.Deployment.start(Deployment.java:144)
  at org.switchyard.as7.extension.deployment.SwitchYardDeployment.start(SwitchYardDeployment.java:101)
  at org.switchyard.as7.extension.services.SwitchYardService.start(SwitchYardService.java:73)
  ... 5 more

If I move TickDAOBean class into the app (but TickDAO interface is still in a EAP's module), the app is successfully deployed and works fine.

Can you help me please to solve this issue?

Thanks, Anton

[igarashitm]

Did you add beans.xml into your jboss module jar?

[igarashitm]

Found related ticket in AS7 JIRA (which has been already fixed in EAP6.1 i.e. FSW6.0) https://issues.jboss.org/browse/AS7-4567

[anikulin]

Thanks for your help, Tomohisa.

Yes, the jboss module jar has beans.xml file. I deployed it to EAP 6.1, so i think this issue should have been fixed there.

Maybe there is smth specific in module.xml file that I should do?

[jorgemoralespou_2]

Hi,

I think you need to add a Tag to the module.xml to instruct the AS to export also the META-INF. I do not recall the tag, but had you search in this forum for athread from me regarding CDI alternatives you'll see exact tag.

Sorry but writing from my mobile, so not handy to search for U.

Cheers,

[anikulin]

Thanks, Jorge

After adding a "meta-inf" tag into MANIFEST.MF file I succeeded to inject a CDI bean located in a EAP's module using @Inject annotation. But if I try to define it as a SY bean component in switchyard.xml I still have the same error.

Is it possible to define a SY bean with an implementation located in an EAP's module or should I use RemoteInvoker for this purpose?

Thanks, Anton

[igarashitm]

Hi Anton,

After I thought about it a bit more, now I think it's not possible. (Please suggest a solution if anyone knows!)

SwitchYard Bean service is not a plain CDI bean, it should be visible for our CDI Extension (SwitchYardCDIServiceDiscovery). The extension is only available inside of each SwitchYard application, so the CDI Discovery event must happen in SwitchYard deployment scope. If you have the CDI bean outside of SwitchYard application, then its discovery event would happen outside of SwitchYard deployment.

Is there any reason why you don't just copy the bean implementation into SwitchYard application? If you want to expose that JBoss module as a external and indivisual SwitchYard application, then promote that service with SCA binding and use RemoteInvoker (or use SCA Reference binding if it's also SwitchYard application) to connect would be the right solution IMO (you don't even need to make it as a JBoss module in that case, just deploy the SwitchYard application).

hth,

Tomo

[anikulin]

Thanks a lot, Tomo. Your help is really appreciated.

Yes, if it's not possible I'll use SCA binding.

Thanks, Anton

[igarashitm]

Maybe I was wrong. When I took a look at internal behavior with the debugger, CDI beans in the JBoss module are recognized by Weld if "meta-inf" is added to the manifest Dependencies, and it looks like the discovery happens in SwitchYard app deployment sequence, however all of them are not available via BeanManager (Not only SY Bean Service). Possibly something wrong with our BeanManager setup. Need to dig into more...

[igarashitm]

OK, I got a conclusion for this topic.

This is actually possible, once you add appropriate dependencies to the module.xml for the module which contains Bean service implementation, then it can be used in the other SwitchYard application. Collecting appropriate dependencies is a bit tough work, since Weld CDI engine sometimes silently ignores the CDI Bean which has unsatisfied dependencies. You can't find it even in the DEBUG log. The point is to add "org.switchyard.component.bean" dependency so our CDI Extension is registered appropriately.

However, after I talked with Keith about this, now I think exposing Bean implementation to the AS module is not a good idea. From design POV, the service implementation detail should be packaged together. Plus @Service bean is a special class for SwitchYard application, and we don't expect it to be used through such a extended class loading. We don't guarantee it always works.

As I already mentioned, if you just want to expose it as a independent SwitchYard service and invoke it from outside, then promoting the service with SCA binding is your option. This is totally different model from referencing a implementation class from outside (i.e. AS module). There is application boundary between provider and consumer on SCA invocation, while it just means an extended class loading in a single application in AS module case. Yes, the SCA invocation cost is relatively high since it's performed over HTTP, but that's a trade-off you need to accept to keep the service independent.

If you're still interested in how this can be done, please take a look at this example:

switchyard-issues/bean-module at bean-module · igarashitm/switchyard-issues · GitHub

But as I said also in the Readme, this is an antipattern. We strongly recommend to package your service implementation detail together.

Keith, I guess you can explain those in a better way, please rephrase them for us

hth,

Tomo

[jorgemoralespou_2]

Hi,

Just to correct one statement:

" Yes, the SCA invocation cost is relatively high since it's performed over HTTP, but that's a trade-off you need to accept to keep the service independent."

This is only true if your SCA invocation is defined as clustered,  otherwise there is no additional cost add it is a java call.

[igarashitm]

Ah I forgot the invokeLocal optimization again. Thanks for the correction, Jorge.

[anikulin]

Thanks a lot, Tomo and Jorge. Your help is greatly appreciated.