-
1. Re: Implicit container dependencies
starksm64 Mar 28, 2007 12:30 PM (in response to starksm64)To ease this compatibility issue, and address a long outstanding issue with not being able to specify deployment module level dependencies (mdb.jar depends on test-destinations-service.xml), I think a feature of the structure parse should be to order the DeploymentContexts. This would be a superset of the old Russian doll ordering. One should be able to declare the directed graph of DeploymentContexts such that a BFS traversal from the deployment root runs the deployment through the deployers in the declared order.
-
2. Re: Implicit container dependencies
weston.price Mar 28, 2007 12:30 PM (in response to starksm64)Technically we should be integrating destinations, connection factories etc via the AdminObject facility of JCA and establishing the dependencies in this manner. At the very least, we need to consider reworking some of this. By all rights, the JmsLookupProvider should dissapear as it is JBoss specific and prohibts using the JCA/JMS adapter in other app server environments.
-
3. Re: Implicit container dependencies
starksm64 Mar 28, 2007 12:35 PM (in response to starksm64)How does this apply to an mdb accessing a remote destination though?
-
4. Re: Implicit container dependencies
weston.price Mar 28, 2007 12:47 PM (in response to starksm64)Feasibly those admin objects that are hosted remotely should be bound into our local JNDI tree with a proxy/wrapper for the remote admin object.
The generic jms project is a good example of this integration approach.
Note, this is effectively what the JmsJNDIProvider does today, or at least it can do. What we do in the case of a remote destination is bind to JNDI tree of the remote resource directly, or we force some sort of bridge layer (ie the WASMQ integration stuff on the Wiki).
While this works, it effectively removes any dependency control we might have until the actual point of activation where we attempt the lookup on the destination. -
5. Re: Implicit container dependencies
bill.burke Mar 28, 2007 12:52 PM (in response to starksm64)The problem with implicit dependencies is that MDB's, traditionally, will create the topic/queue by default if it does not already exist.
Please add the nested first deployment ordering.
BTW, I don't understand why the ordering matters. It works like this right?for (Deployer deployer : deployers) { for (Deployments deployment: deployments) deployer.process(deployment) }
Why doesn't the Queue/Topic get deployed before the MDB anyways? -
6. Re: Implicit container dependencies
weston.price Mar 28, 2007 12:52 PM (in response to starksm64)In other words, the JmsJNDIProvider effectively provides 'AdminObject' like behavior today. This is currently how we do JMS provider integration. These facilities should be moved to the JCA/JMS adapter to be more in line with the JCA specfication.
-
7. Re: Implicit container dependencies
starksm64 Mar 28, 2007 12:53 PM (in response to starksm64)This seems to be effectively pushing the mechanism for configuring the mc component providing the admin object to the jca layer. That's fine and makes sense. So if given an admin object (type, name) pair, there is a stable jca component containers can declare a dependency on, we are good. The details will fall to the admin object deployment.
-
8. Re: Implicit container dependencies
anil.saldhana Mar 28, 2007 12:58 PM (in response to starksm64)Also JCA integration will bring in that added value of potential security extensions like JSR-196.
-
9. Re: Implicit container dependencies
starksm64 Mar 28, 2007 1:04 PM (in response to starksm64)"bill.burke@jboss.com" wrote:
The problem with implicit dependencies is that MDB's, traditionally, will create the topic/queue by default if it does not already exist.
Please add the nested first deployment ordering.
BTW, I don't understand why the ordering matters. It works like this right?for (Deployer deployer : deployers) { for (Deployments deployment: deployments) deployer.process(deployment) }
Why doesn't the Queue/Topic get deployed before the MDB anyways?
There is no ordering of the DeploymentContexts currently. When a DeploymentContext is added to the MainDeployer its children are simply added to the set to process. This should be part of the structural information. We could default to Russian doll and allow for complete specification as well, including cross top-level deployment ordering. -
10. Re: Implicit container dependencies
adrian.brock Mar 28, 2007 1:05 PM (in response to starksm64)"weston.price@jboss.com" wrote:
Feasibly those admin objects that are hosted remotely should be bound into our local JNDI tree with a proxy/wrapper for the remote admin object.
An admin object is just a way to create the object in local jndi rather than
doing a remote jndi request.
There's an outstanding feature request to be able to define admin objects
in jboss.xml
1) So everything is together
2) You could create the admin object in java:comp just for that ejb -
11. Re: Implicit container dependencies
adrian.brock Mar 28, 2007 1:07 PM (in response to starksm64)"bill.burke@jboss.com" wrote:
The problem with implicit dependencies is that MDB's, traditionally, will create the topic/queue by default if it does not already exist.
This has been turned off in JBoss5 (at least for EJB2).
1) The code was not (is not) portable
2) Just because remote access to jndi (either another member of the cluster
or a thirdparty jms provider) is flakey, you don't want it to create a queue
3) It obscures the most common problem, which is that you mistyped the jndi name -
12. Re: Implicit container dependencies
adrian.brock Mar 28, 2007 1:12 PM (in response to starksm64)I don't really understand why this is causing the test to fail?
The MDB is designed to recover from the missing jndi name
and keep trying to startup every 10 seconds until the binding becomes available?
I suspect the test is a bit impatient :-) -
13. Re: Implicit container dependencies
weston.price Mar 28, 2007 1:18 PM (in response to starksm64)Just to clarify this is EJB3 or EJB2?
This might be my bug/feature:-)
I added a reconnect attempt state variable to the JMSActivation that halts reconnect attempts after a given threshhold has been exceeded. -
14. Re: Implicit container dependencies
starksm64 Mar 28, 2007 1:21 PM (in response to starksm64)"weston.price@jboss.com" wrote:
Just to clarify this is EJB3 or EJB2?
This might be my bug/feature:-)
I added a reconnect attempt state variable to the JMSActivation that halts reconnect attempts after a given threshhold has been exceeded.
The tests I'm looking at are ejb2, but it should be using the same logic as ejb3 under jboss5. Certainly there are still legacy issues that need to be updated, the JMSContainerInvoker being one of them.