[Design the new POJO MicroContainer] - Added a deployment/deployer type notion
by scott.stark＠jboss.org
Deployer, DeploymentUnit, and DeploymentContext have been updated with a deployment type notion coming from the Deployer.
| /**
| * Get the deployment types associated with this deployment.
| * @return set of deployment type names deployers have identified
| * in this deployment.
| */
| public Set<String> getTypes();
|
Its up to the deployers to populate this set. Right now we don't make effective use of the Deployer.isRelevant(DeploymentUnit unit) method. If this was implemented to reflect when a deployer would process a deployment the MainDeployerImpl could manage the set. For now, the Abstract* deployers that have a specific type that is seen will add their Deployer.getType value to the set. The type property needs to be set in the deployer configuration for this to have meaning, or its initialization updated.
The standard known types are in a org.jboss.deployers.spi.deployer.StandardDeployerTypes interface:
| public interface StandardDeployerTypes
| {
| /** JavaEE enterprise application archive */
| public static final String EAR = "ear";
| /** JavaEE client application archive */
| public static final String CAR = "car";
| /** JavaEE ejb generic archive */
| public static final String EJB = "ejb";
| /** JavaEE ejb 2.1 and earlier archive */
| public static final String EJB2x = "ejb2x";
| /** JavaEE ejb 3x archive */
| public static final String EJB3x = "ejb3x";
| /** JavaEE JPA archive */
| public static final String JPA = "jpa";
| /** JavaEE resource adaptor archive */
| public static final String RAR = "rar";
| /** JBoss MC beans archive */
| public static final String MCBEANS = "beans";
| /** JBoss service archive */
| public static final String SAR = "sar";
| /** JBoss hibernate archive */
| public static final String HAR = "har";
| /** Spring archive */
| public static final String SPRING = "spring";
| /** An OSGi bundle */
| public static final String OSGI_BUNDLE = "osgi";
| /** The deployment type used if a deployer does not specify anything */
| public static final String UNSPECIFIED_TYPE = "unspecified";
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001615#4001615
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001615
19 years, 2 months
[Design of JCA on JBoss] - Re: Problems JCA JMS inflow issue and tx NotSupported
by timfox
"weston.price(a)jboss.com" wrote :
| Yes, this is simply a matter of running the testsuite against HEAD really where JBM is the default. Unfortunately, I haven't paid much attention to this as most of us are working on getting the TCK issues resolved and finalized.
|
Richard Achmatowicz is currently working on this. The end result is that both JBossMQ and JBM will run using the same set of integration tests.
anonymous wrote :
| Not really. There is a decent framework for testing both the JCA adapter and the container invoker. Again, I think this is simply a matter of dealing with JBM which up until recently I was aware had any issues. Since this is the first time I am hearing about this and 4.0.5 has been in the wild for a bit (at least enough time to accumulate a patch release), I am assuming that we are simply running into some scenarios with JCA/JBM that have not been accounted for at this point.
|
I had a good look in the test suite for MDB integration tests yesterday.
I started a thread on the dev list yesterday about this - have you seen it?
Scott pointed me in the direction of where the tests are. I had a look and it seemed to me the coverage was poor.
If there is a decent framework I guess I must have been looking in the wrong place. Can you point me in the right direction?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001503#4001503
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001503
19 years, 2 months
[Design of JCA on JBoss] - Re: Problems JCA JMS inflow issue and tx NotSupported
by weston.price＠jboss.com
The *easiest* thing to do would be to patch 4.0.5 and then make this patch available in the next cummulative patch release. The changes that made it in to 4.0.5 should simply be replaced with the new stuff. This will be the case with 4.2. Again, this is why I never wanted this backport to happen.
anonymous wrote :
| I'm not trying to attribute blame, just trying to work out what is going on, and find a solution. :)
|
Your altruism is quite refreshing.
anonymous wrote :
| If you are saying that the 4.0.5.GA code is a bodged backport and basically doesn't work, and there's no chance of getting it fixed, then we can tell our customers not to use that and stick with the JMSContainerInvoker until JB5.
|
That is not what I am saying. I am more that willing to address any issues you think might be occuring with JCA and JBM. Again, a patch release in our cummulative QA patch cycle is most likely the best approach.
anonymous wrote :
| (What about AS4.2 - I would have thought we would want the good HEAD version in that?)
|
Yes, the code in HEAD will be in 4.2.
anonymous wrote :
| For JBM1.2, we need to make sure that all these cases work, so I am going to improve the MDB integration tests and make sure they run with both the JMSContainerInvoker and JCA1.5 inflow.
|
Yes, this is simply a matter of running the testsuite against HEAD really where JBM is the default. Unfortunately, I haven't paid much attention to this as most of us are working on getting the TCK issues resolved and finalized.
anonymous wrote :
| Right now the MDB test coverage is scrappy (no blame) to say the least which is why issues like this and others are slipping through the net.
|
Not really. There is a decent framework for testing both the JCA adapter and the container invoker. Again, I think this is simply a matter of dealing with JBM which up until recently I was aware had any issues. Since this is the first time I am hearing about this and 4.0.5 has been in the wild for a bit (at least enough time to accumulate a patch release), I am assuming that we are simply running into some scenarios with JCA/JBM that have not been accounted for at this point.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001501#4001501
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001501
19 years, 2 months
[Design of JCA on JBoss] - Re: Problems JCA JMS inflow issue and tx NotSupported
by timfox
"weston.price(a)jboss.com" wrote :
| The spec is merely saying that if the client is using a transacted session, then the ack mode is AUTO_ACKNOWLEDGE which is just simply a convention in this case as has no overall effect.
I realise that if the session is transacted, then the ack mode is ignored, but that's not what the spec is saying. Here it is in full:
EJB 2 spec 15.4.8:
anonymous wrote :
| If bean managed transaction demarcation is used, the message receipt cannot be
| part of the bean-managed transaction, and, in this case, the receipt is acknowledged by the container. If
| bean managed transaction demarcation is used, the Bean Provider can indicate in the
| acknowedge-mode deployment descriptor element whether JMS AUTO_ACKNOWLEDGE semantics
| or DUPS_OK_ACKNOWLEDGE semantics should apply. If the acknowledge-mode deployment
| descriptor element is not specified, JMS AUTO_ACKNOWLEDGE semantics are assumed.
|
What the spec is saying, is that if you are using BMT then the message receipt will be acked using a local non transacted session, that is either AUTO_ACK or DUPS_OK, AND if the user omits to specify which ack mode in the deployment descriptor then it will use AUTO_ACK. This ack mode is *not* ignored, it used for the message receipt.
What I observe in practice, using JBM and the 4.0.5.GA JCA, is that if I specify the ackmode, then it all works fine (my trivial example), the message is received and acknowledged.
If I fail to specify the ack mode, I can see the JCA layer creating a *transacted* XA session, and trying to call commit on it.
Bottom line is JBM works with the JMSContainerInvoker but not with JCA inflow in 4.0.5, even for this most trivial example.
I'm not trying to attribute blame, just trying to work out what is going on, and find a solution. :)
This is either a problem in JBM or a problem with JCA. Right now I believe it is a bug in JCA because the JCA layer is trying to call commit on an XASession which seems clearly wrong to me. Although I am willing to accept there is a bug in JBM if you can come up with another explanation.
If you are saying that the 4.0.5.GA code is a bodged backport and basically doesn't work, and there's no chance of getting it fixed, then we can tell our customers not to use that and stick with the JMSContainerInvoker until JB5.
(What about AS4.2 - I would have thought we would want the good HEAD version in that?)
This isn't ideal but if that's the situation, then we have to live with that.
For JBM1.2, we need to make sure that all these cases work, so I am going to improve the MDB integration tests and make sure they run with both the JMSContainerInvoker and JCA1.5 inflow.
Right now the MDB test coverage is scrappy (no blame) to say the least which is why issues like this and others are slipping through the net.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001488#4001488
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001488
19 years, 2 months