-
2. Re: EJB3 JCA/JMS Integration
starksm64 Dec 12, 2005 8:27 AM (in response to adrian.brock)An additional aspect is the management features that are supported. We have had questions about whether the existing type of jmx management ops on the container invoker are supported, e.g. MBean name jboss.j2ee.binding=message-driven-bean,jndiName=local/MyMDB@16200546,plugin=invoker,service=EJB) and elect to startDelivery(), stopDelivery(), setMaxMessages(int) and adjust the MDB pool size.
-
4. Re: EJB3 JCA/JMS Integration
adrian.brock Dec 12, 2005 3:36 PM (in response to adrian.brock)http://jira.jboss.com/jira/browse/EJBTHREE-373
I'm not sure I understand this?
Only the connection that created the temporary queue is allowed to receive from it.
I think this is really a JBossMQ "bug" since SpyConnectionConsumer
doesn't have acheckTemporary(destination);
check?/** * Check a tempoary destination * * @param destination the destination */ void checkTemporary(Destination destination) throws JMSException { if (destination instanceof TemporaryQueue || destination instanceof TemporaryTopic) { synchronized (temps) { if (temps.contains(destination) == false) throw new JMSException("Cannot create a consumer for a temporary destination from a different session. " + destination); } } }
-
5. Re: EJB3 JCA/JMS Integration
starksm64 Dec 12, 2005 3:57 PM (in response to adrian.brock)So let's ditch the ASF stuff in favor of jca inflow abstraction, including as the default MDB 2.1 container in 4.x. Is this something that should be a critical task for 4.0.4?
-
6. Re: EJB3 JCA/JMS Integration
adrian.brock Dec 12, 2005 4:08 PM (in response to adrian.brock)Even if we ditch the ASF, the JMS inbound RAR still currently uses
the ConnectionConsumer. :-)
Because that is the way legacy JMS expects an XA aware message listener to be
written.
If it is critical, we need to find somebody to work on testing it. Tim who is assigned
is too busy on other things.
And then there are issues of EJB3 using different activation-config-property properties
to the rar.
But with the exception of the non-portable resource-adapter indentification,
that can mostly be solved by having duplicate properties mapping to same underlying
property. -
7. Re: EJB3 JCA/JMS Integration
adrian.brock Dec 12, 2005 4:13 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
I think this is really a JBossMQ "bug" since SpyConnectionConsumer
doesn't have a
Bug report:
http://jira.jboss.com/jira/browse/JBAS-2552 -
8. Re: EJB3 JCA/JMS Integration
starksm64 Dec 12, 2005 5:18 PM (in response to adrian.brock)So let's explore this as a valid abstraction to cleanup the current ejb3 integration, have Thomas comment on if this can be used for aynch webservice invocation and if its a valid patch for the 4.0.4 timeframe I'll find a resource to stress test it.
Should I start with the pojo jca prototype as the interface abstractions? -
9. Re: EJB3 JCA/JMS Integration
kabirkhan Dec 12, 2005 5:33 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
http://jira.jboss.com/jira/browse/EJBTHREE-373
I'm not sure I understand this?
Only the connection that created the temporary queue is allowed to receive from it.
Please ignore, I misinterpreted the behaviour. The client was sending on the correct destination, but bean was creating a temporary queue on which no messages were received (since the client was sending somewhere else) -
10. Re: EJB3 JCA/JMS Integration
adrian.brock Dec 12, 2005 5:48 PM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
Should I start with the pojo jca prototype as the interface abstractions?
I think we are mixing levels of abstraction :-)
There are really two different problems.
JMS:
1) Properly testing jms rar inbound, in particular tweaking all the parameters
and testing failure conditions. This will allow removal of the JMSContainerInvoker
and make ASF "redundant". But that are still issues relating to old configurations.
JCA Inbound in general
1) Defining an abstraction for the MessageEndpointFactory. Currently this uses
org.jboss.proxy (i.e. org.jboss.invocation) when it should be using aop like the
prototype in pojo jca.
2) The MessageEndpointFactory still needs a mechanism to delegate
container.getClassLoader() and container.isDeliveryTransacted(Method)
to the target container (EJB2.1, EJB3, JMX, POJO)
This is an unsolved problem in the POJO JCA prototype
as is the whole notion of an org.jboss.proxy replacement in AOP.
I currently use a prototype ProxyAdvisor although Kabir is supposed to have
done some work on (or replaced?) the AOP instance advisors recently.
I don't mind supporting two different MessageEndpoint(Factory|Interceptor)s
for org.jboss.proxy (EJB2.1 and XMBean)
and org.jboss.aop.Invocation (EJB3.0 and POJO)
as long as the other machinary is consistent.
It is pointless maintaining three or four different versions of this code.
With different mechanisms to plug the container to the ConnectionConsumer/SessionPool
and different activation-config-properties ;-) -
11. Re: EJB3 JCA/JMS Integration
adrian.brock Dec 12, 2005 5:52 PM (in response to adrian.brock)In case you are trying to follow this and you don't know how this works.
At deployment:
container -> rar -> activateEndpoint(MessageEndpointFactory)
At runtime
rar -> MessageEndpointFactory -> createEndpoint, etc.
message -> rar -> messageEndpoint -> container/target
The messageEndpoint is really a proxy with a MessageEndpointInterceptor
handling the JCA1.5 semantics that crosscut the message/listener implementation.
There are extra methods such as
isDeliveryTransacted - does the rar need to enlist its XAResource?
beforeDelivery/afterDelivery - allows the rar to do work with the target's classloader/ENC context before/after doing "onMessage" -
12. Re: EJB3 JCA/JMS Integration
bill.burke Dec 12, 2005 6:11 PM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
So let's ditch the ASF stuff in favor of jca inflow abstraction, including as the default MDB 2.1 container in 4.x. Is this something that should be a critical task for 4.0.4?
ignorant question, doesn't HA-JMS depend on ASF? Or can we write a JCA adapter around ASF? -
13. Re: EJB3 JCA/JMS Integration
adrian.brock Dec 12, 2005 6:16 PM (in response to adrian.brock)So what I would like to see is:
1) AbstractMessageEndpointFactory and AbstractMessageEndpointInterceptor
that do all the main behaviour.
2) Some Container plugin for the isDeliveryTransacted() query
transaction manager injection (if this can't be done at the abstract level)
and before/afterDelivery context establishment
3) ProxyMessageEndpointFactory/Interceptor using org.jboss.invocation (org.jboss.proxy)
4) AOPMessageEndpointFactory/Interceptor using org.jboss.aop.Invocation (instance advisor)
Then all EJB3 needs to do is is provide the ContainerPlugin and use the AOP proxy.
POJO will provide a different ContainerPlugin with the same AOP proxy.
EJB2.1 with provide another ContainerPlugin with the org.jboss.proxy
XMBean (if we want to do this) will use its own ContainerPlugin and org.jboss.proxy -
14. Re: EJB3 JCA/JMS Integration
adrian.brock Dec 12, 2005 6:22 PM (in response to adrian.brock)Something like:
public class EJB3InflowContainerAdapter { public boolean isDeliveryTransacted(Method method) {} public void beforeDelivery(Method method) {} public void afterDelivery(Method method) {} }
At deployment:ContainerAdapter adapter = new EJB3ContainerAdapter(this); MessageEndpointFactory mef = new AOPMessageEndpointFactory(adapter); jca.endpointActivation(rarName, mef, activationSpec);