[weston.price]

Ok, then that elminates the reconnect thing as the JMSContainerInvoker does not have this *feature* in it :-)

[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 :-)

The test is not in fact failing. I'm just commenting on all of the noise in the log resulting from the dependency issue. However, I need to validate that test is not producing a false positive and that things are ultimately getting wired up correctly. One test that certainly seems invalid is the durable subscriber test as its using a user that has no valid subscription, so how that is passing is beyond me.

[wolfc]

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

I want this functionality. The feature is that if you're running EJB3 with JBoss Messaging, EJB3 will create a queue for you if needed.

1. We only do it when running JBoss Messaging, so it's not ment to be portable.

2. We don't stuff anything in JNDI, we ask JBoss Messaging for a queue.

It's similar to JBCTS-541, only there j2ee-mods is asking for a queue. I don't see a problem in that. Either admin, j2ee-mods or EJB3 deployer is creating a queue.

BTW. I want to get JBCTS-541 out of the way. Shall I create a new DestinationManager which hooks into ServerPeer?

[starksm64]

I added http://jira.jboss.com/jira/browse/JBMICROCONT-168 to introduce an spi for allowing DeploymentContext level ordering within a given MainDeployer.process execution. This would be a superset of the Russian doll, deployment scanner notions of the past.

[starksm64]

"wolfc" wrote:

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

I want this functionality. The feature is that if you're running EJB3 with JBoss Messaging, EJB3 will create a queue for you if needed.

1. We only do it when running JBoss Messaging, so it's not ment to be portable.

2. We don't stuff anything in JNDI, we ask JBoss Messaging for a queue.

It's similar to JBCTS-541, only there j2ee-mods is asking for a queue. I don't see a problem in that. Either admin, j2ee-mods or EJB3 deployer is creating a queue.

BTW. I want to get JBCTS-541 out of the way. Shall I create a new DestinationManager which hooks into ServerPeer?

Yes, update the existing cts porting layer to work. There is an example org.jboss.test.jbossmessaging.JBossMessagingAdmin implementation in the testsuite that I noted on the issue.

Whether or not the ejb container creates destinations has to be a manageable, metadata driven policy. This is ultimately overridable by the managment layer/policy service as whether or not a given environment allows for dynamic creation of destinations is an admin policy decision. It has nothing to do with whether ejb3 and jbm exist in the same environment.

In terms of ease of use for testing, embedded, you should be able to setup the metadata defaults to allow for this. That should be a trivial configuration of the externalized policy.

[wolfc]

http://jira.jboss.com/jira/browse/EJBTHREE-932

[adrian.brock]

This thread is really getting off topic. :-)

EJB3 should be doing anything with JBoss Messaging.
If anything should be doing this, it is the resource adapter.

e.g. there should be an activation spec property called "createDestination"

The resource adapter could then be updated to use the admin class,
or my preference would be something like this:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033100#4033100

which should really be in the JMS spec.

This approach maps to other inbound adapters like AMPQ
which does define a portable management api.

[adrian.brock]

In general we should be trying to simplify the platform.
We should be letting each area get on with what it does best.

EJB3 is not an integration api, JCA is.

The JBoss EJB3 implementation is still doing far too much integration work itself
which is continually a problem both in terms of not reusing code that is known
to work, but also in terms of the portablity as these integration details change.

In some cases, constraints are being imposed on other projects
where EJB3 is using api that was never intended for external use.

Webservices has the exact same problem which is why I was complain about
them breaking the build all the time.

It should be the AS (or in future "JBoss Embedded") that defines a
portable integration api for EJB3/Webservices
to hook into not EJB3/Webservices each doing their own "broken" integrations
with every other project including the AS itself.

[bill.burke]

Quit ranting. EJB3 is an integration project. Its not our fault that the things we interface with don't have any SPIs!!!

What exact integration work is EJB3 doing besides providing its own MEP and queue/topic creation(which we removed in head)? What exact constraints are you talking about that EJB3 places on other projects? What code is forked? Are you still living in 2006?

[adrian.brock]

I'm "ranting" at Carlo wanting to do JBoss Messaging integration in the EJB3 project.
The JIRA task he just raised.

I still don't see a "ActivationFactory" interface defined in either the appserver
or JBoss Embeded for EJB3 to inject that can be implemented as
1) An invocation on the JMX bus in JBoss4
2) A facade on the RAR metadata repository in JBoss5
3) Whatever mechanism other environments have for this integration.

I'll be able to sleep a lot easier when this (and many other properly defined and stable
integration points) exists and EJB3 uses it. :-)

[adrian.brock]

What code is forked?

I didn't mention forked code?

Are you still living in 2006?

I will admit that I stopped looking at the EJB3 code a while ago, but that was mainly
because trying to get anything done about what I see as the problems
wasn't getting anywhere, so it was a waste of energy.

I just left you guys to come to the correct conclusions yourselves
as you realize what the problems are and how unsupportable a component
doing its own integration with n platforms for m different versions
(n * m == large number) is.

EJBTHREE-932 tells me you haven't got there yet. :-)

[wolfc]

I'll be able to sleep a lot easier when this (and many other properly defined and stable integration points) exists and EJB3 uses it. :-)

The integration point in EJB3 is JMSDestinationFactory. 4 supplies a DestinationManagerJMSDestinationFactory, 5 has a ServerPeerJMSDestinationFactory. It isn't how it should be yet, so any criticism is appreciated.

n * m is currently 2, and that's about the max we can handle, so I've already dropped support for AS 4.0.5. I need have the separate EJB3 binary plugin asap to solve the n*m problem.

[weston.price]

JCA should be providing all of this. IF you need something in terms of integration points (ie temp destinations etc) file a JIRA.