binding.jca/inboundInteraction/endpointClass: the name of concrete Endpoint class

binding.jca/inboundInteraction/transacted: boolean value that indicates the delivery should be transacted or not.

Key classes of JCA component

Related Repository: components

org.switchyard.component.jca.deploy.InboundHandler: This is the SwitchYard ServiceHandler and also implements JCA MessageEndpointFactory. This performs JCA Endpoint activation and set up the Endpoint proxy to pass to the ResourceAdapter.

org.switchyard.component.jca.EndpointProxy: JCA Endpoint proxy implementation. This class sets up the common facilities like transaction, concurrency control, and ClassLoader for actual Endpoint implementation.

org.switchyard.component.jca.endpoint.JMSEndpoint: A concrete implementation of JCA Endpoint for JMS messaging. We need to set the binding.jca/inboundInteraction/endpointClass configuration parameter as the name of this class to use.

Injecting ResourceAdapterRepository from AS7 service

Related Repository: core, release

I have added the addResourceDependency() method on org.switchyard.deploy.Component and inject ResourceAdapterRepository into JCAComponent via SwitchYardComponentService.

I'd appreciate if you let me know anything you have noticed. I will add testcases and maybe a quickstart until then.

Sorry it took so long. There's a lot to digest here and I'm afraid I've only scratched the surface. This looks like a great start though, so I'll share the feedback I have and we can go from there.

- The changes to core and release to inject the RA repository are perfect for now, since they are small and do exactly what you need. I will probably want to develop a more generic mechanism for this, where a component module can be injected with various bits as needed. For AS7 runtime, this would specified in our subsystem definition in standalone.xml. No need to worry about this now though.

- Looks like you've borrowed a good deal of code from JBoss ESB on the actual JCA inbound implementation, which is good. That implementation is rock solid, so there's no reason to change much - just move it forward and adapt it to our component/activator APIs.

- The test cases and quickstart will help a lot in reviewing this at the next level. It would be good to have a JMS JCA example (this can be the quickstart) and a more general example which likely could be used in unit tests in the component repository. I believe that IronJacamar has pretty solid unit test and standalone support. This is important to make sure we honor the various bits of the JCA inflow contract and will also help validate that other (i.e. non JMS) adapters will work.

- Looks like there is some CCI stuff in there right now, which I assume you will use for the oubound (reference binding) support?

- The config model is present, but I did not see a schema. Do you think we can use the JCA binding spec directly or should we use our own schema definition?

- Looks like you've borrowed a good deal of code from JBoss ESB on the actual JCA inbound implementation, which is good. That implementation is rock solid, so there's no reason to change much - just move it forward and adapt it to our component/activator APIs.

Yep, EndpointProxy is a most important infrastructure that is originally come from JBossESB's

- The test cases and quickstart will help a lot in reviewing this at the next level. It would be good to have a JMS JCA example (this can be the quickstart) and a more general example which likely could be used in unit tests in the component repository. I believe that IronJacamar has pretty solid unit test and standalone support. This is important to make sure we honor the various bits of the JCA inflow contract and will also help validate that other (i.e. non JMS) adapters will work.

Yeah, I'm thinking just now is to cook up the JCAMixIn using Embedded IronJacamar! It will support some basic unit tests.

- Looks like there is some CCI stuff in there right now, which I assume you will use for the oubound (reference binding) support?

ah, nope, it's just a sample Endpoint for Message inflow in the case of using CCI interface. JCA spec defines the CCI message listener as the default interface, however I guess the CCI Endpoint should be specialized to the specific ResourceAdapter(and EIS over the adapter), so just provide a sample. well, CCI MessageListener actually support InOut sequence while JMS MessageListener just support InOnly.

- The config model is present, but I did not see a schema. Do you think we can use the JCA binding spec directly or should we use our own schema definition?

I think we can use SCA JCA binding schema directly, since the elements I've added is allowed by that schema. I will confirm it in the tests.

JCAMixIn uses IronJacamar embedded for the ResourceAdapter container, and the IronJacamar needs naming service which supports javax.naming.Reference binding. MockNamingContext doesn't support this and looks not so easy to add that feature, so I have simply brought the JBossAS naming service component into our SwitchYardTestKit.

Configuration Schema

Currently the binding.jca schema is almost same as SCA JCA Binding, and has some unnecessary element/attribute in its Schema. For example, /binding.jca/inboundConnection/resourceAdapter/@type must be specified, but we don't need it because the ResourceAdapter MUST implement javax.resource.spi.ResourceAdapter and that's all, so we don't really need to know the ResourceAdapter's concrete class type. We may need to remove those unnecessary element/attribute to avoid user confusion.

Ignore this comment. ConnectorServices.RA_REPOSITORY_SERVICE could be cooked up easily using String literal.

JBoss AS7 has a API change in ConnectorServices between 7.1.0 and 7.1.1 - which is referenced from SwitchYardSubsystemAdd, and my branch needs 7.1.1 for both of standalone and OpenShift. I wish the AS7 version in OpenShift will get up to date before we merge this.