jca integration
by Bill Burke
Ok, did 1st stage of JCA Gateway. I'll commit that tomorrow morning.
Still need to do schema change to add jca elements.
Here's what a JCA endpoint looks like:
public class MyEndpointBean implements InflowGateway, MessageListener
{
private ServiceInvoker service;
public void setServiceInvoker(ServiceInvoker invoker)
{
this.service = invoker;
}
public void onMessage(Message message)
{
try
{
// convert the message ...
service.postMessage(esbMessage);
}
catch (Exception e)
{
throw new RuntimeException(e);
}
}
}
The InflowGateway interface has one method: setServiceInvoker(). The
ServiceInvoker allows you to post ESB messages to the target service's
EPR. The ServiceInvoker is created by the ESB container and passed to
the endpoint bean in the initialization phase. The endpoint bean is a
singleton. I did it this way for a couple of reasons:
* I wanted to reduce the amount of artifacts people needed to write.
The endpoint bean needs to receive inbound messages as well as be able
to transform the message into an ESB message and push it along. This
means I didn't want to have a specific Transformer class like the other
gateways have.
* I made the endpoint bean a singleton to be consistent with the action
framework model. If the user wants per instance and/or instance
pooling, they should use an MDB or the Spring bullshit equivalent.
Next steps?
Schema changes to add JCA elements. Here's what I was thinking:
<providers>
<jca-bus busid="JMS-Inflow-Bus"
adapter="jms-ra.rar"
endpointClass="org.test.MyEndpointBean"
messagingType="javax.jms.MessageListener"
jcaBridge="org.jboss.gateway.jca.JBoss42ActivationBridge">
<activation-config>
<activation-config-property>
<activation-config-property-name>
destinationType
</activation-config-property-name>
<activation-config-property-value>
javax.jms.Queue
</activation-config-property-value>
</activation-config-property>
...
</activation-config>
</jca-bus>
</providers>
<services>
<service category="HelloWorld_ActionESB"
name="SimpleListener"
description="Hello World">
<listeners>
<jca-gateway busid="JMS-Inflow-Bus" ...>
... same thing as jca-inflow-bus ...
</jca-gateway>
The messageType is optional. If it is not specified, the ESB container
will guess what it is. The jcaBridge is optional. This class is an SPI
for plugging in the JCA code into other app servers. Only JBoss is
supported now obviously.
The <activation-config> syntax was stolen from EJB. Should we simplify
it? Or leave it consistent with EJB?
The <jca-gateway> syntax is allowed to override/augment any <jca-bus>
configuration.
Since raw JCA would be inbound only, again, I don't think it makes sense
to require a bus definition in the schema. There really isn't much
re-use to gain.
--
Bill Burke
JBoss, a division of Red Hat Inc.
16 years, 11 months
- 5
- 33
properites file problem
by Bill Burke
I'm getting this error. Anybody have any hints?
12:52:49,359 FATAL [ModulePropertyManager] ModulePropertyManager failed
12:52:49,359 ERROR [JmsServerSession] Unexpected error delivering
message delegator->JBossMessage[0]:PERSISTENT
org.jboss.soa.esb.FatalError:
com.arjuna.common.util.exceptions.LoadPropertiesException: Failed to
instantiate plugin: j
ava.lang.NullPointerException
at
org.jboss.soa.esb.common.ModulePropertyManager.initialise(ModulePropertyManager.java:160)
at
org.jboss.soa.esb.common.ModulePropertyManager.getPropertyManager(ModulePropertyManager.java:115)
at
org.jboss.soa.esb.couriers.filter.FilterManager.<init>(FilterManager.java:107)
at
org.jboss.soa.esb.couriers.filter.FilterManager.getInstance(FilterManager.java:54)
at
org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:164)
Caused by: com.arjuna.common.util.exceptions.LoadPropertiesException:
Failed to instantiate plugin: java.lang.NullPointe
rException
at
com.arjuna.common.internal.util.propertyservice.PropertyManagerImpl.load(PropertyManagerImpl.java:367)
at
org.jboss.soa.esb.common.ModulePropertyManager.initialise(ModulePropertyManager.java:153)
... 33 more
--
Bill Burke
JBoss, a division of Red Hat Inc.
16 years, 11 months
- 1
- 0
remove bus/provider requirement
by Bill Burke
I would like to remove the bus/provider requirement that
listeners/gateways have.
The move is basically around cutting the amount of syntax sugar that is
required when writing a gateway or a listener. My bet is that in a
majority of cases, the provider/bus syntax/metadata is not reusable.
Why require the extra metadata?
This is even more so when plugging in JCA since JCA in/out is configured
separately, or in the case of JMS, might not even have an outbound
configuration.
Bill
--
Bill Burke
JBoss, a division of Red Hat Inc.
16 years, 12 months
- 6
- 13