"wolfc" wrote : "adrian(a)jboss.org" 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4032893#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...