New problem deploying MDB in latest code

[panz]

I'm looking at the latest code, and i can't deploy a trivial MDB. It deploys fine in 2.4.0BETA.

I get the following in the log:

[ContainerFactory] Deploying TestModule
[JMSContainerInvoker] destination not found: queue/testModuleQueue reason: javax.naming.NameNotFoundException: testModuleQueue not bound
[JMSContainerInvoker] creating a new temporary destination: queue/testModuleQueue
[QueueManager] Initializing
[JBossMQService] Could not create the destination:
javax.management.MBeanException: Exception thrown in operation init
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1644)
at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
at org.jboss.mq.server.JBossMQService.createQueue(JBossMQService.java:56)

and the following on the console:

[QueueManager] Initialization failed
javax.jms.JMSException: This destination already exists !
at org.jboss.mq.server.JMSServer.addDestination(JMSServer.java:474)
at org.jboss.mq.server.QueueManager.initService(QueueManager.java:70)
at org.jboss.util.ServiceMBeanSupport.init(ServiceMBeanSupport.java:84)

Queue is defined in jboss.jcml:




So the server appears to be saying
- You're deploying an MDB on a nonexistent queue, so i'll create a temporary one [is it checking for testModuleQueue instead of queue/testModuleQueue?]
- I can't create a temporary queue with that name because one exists after all!

If i take the queue definition out of jboss.jcml, the bean deploys successfully (on a temporary queue -- i wonder what the implications of that are?)

[pra]

Is this the latest 2.4.x tree or is it the HEAD branche?

//Peter

[panz]

Yeah, i just did a co without a tag.

I'm confused about what is the latest 2.4.x tag to be getting. The cvs doc talks about how successive builds are numbered, but it doesn't say where we are right now. Should i be getting Rel_2_4_1_1 (the only 2.4 i see looking at a random file)?

[pra]

What I have learned is this. If you have checked out a branche (or the head trunc) you will allways (with cvs update -d) get the latest changes in that branch.

The tags is to make it possible to get a specific version of a branch. But generally, the 2.4.0 branch is not the same as the 2.4.0 release, but contains the latest bug fixed and such, and at some time it will be released as 2.4.1.

//Peter

[panz]

Yes, it's sticky, but the question is what do you do from scratch (no code checked out so far).

If i do a co jboss-all with no preexisting jboss-all dir and with no -r (so i guess it gets the head), i get the bug mentioned above.

What exactly do developers do when they want to checkout the code from scratch? I just tried
cvs co -f -r -R Branch_2_4 jboss-all
but it won't build. I guess I'll try Rel_2_4_1_1 next.

[hchirino]

Heres is the break down:

cvs co jboss-all --> gets you the active dev JBoss (RH)
cvs co -r Branch_2_4 jboss --> gets you the active stable 2.4 branch (this will not get you the the soruces of an official release)\
cvs co -r Rel_2_4_1_1 jboss gets you the sources of the latest stable release.

Notice that the Jboss 2.5.x dev is done on 'jboss-all' while the 2.4.x dev is done on 'jboss'

Regards,
Hiram

[panz]

Great. I guess the jboss-all vs jboss thing was confusing me. I can build both the 2.5 HEAD revision and the latest 2.4 branch now.

Getting back to the original question, both these builds are giving me the same problem. I do not have the problem with 2.4.0.

I create a queue in jboss.jcml like this:



I then deploy a trivial MDB on it (using auto-deploy directory before starting the server). My jboss.xml looks like this:

<enterprise-beans>
<message-driven>
<ejb-name>TestModule</ejb-name>
<configuration-name>Standard Message Driven Bean</configuration-name>
<destination-jndi-name>queue/testModuleQueue</destination-jndi-name>
...

Deployment fails with the error messages in the original post. It seems the server:
- looks for the testModuleQueue
- misses it somehow
- tries to create a temp queue with the same name for the bean deployment
- fails because there really is a queue deployed with that name already

If i do not create the queue in jboss.jcml, the server creates a temp queue and deploys the bean on it successfully. But i don't want my bean on a temp queue!

New info since the original post: If i autodeploy the same bean again (without restarting jboss), i get a new exception:

[J2eeDeployer] exception while searching deployment:
java.io.FileNotFoundException: S:\jboss-2.4\jboss\dist\tmp\deploy\Default\my.ear\deployment.cfg (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(Unknown Source)
at java.io.FileInputStream.(Unknown Source)
at org.jboss.deployment.InstallerFactory.loadConfig(InstallerFactory.java:264)
at org.jboss.deployment.InstallerFactory.findDeployment(InstallerFactory.java:198)

But i also see:
[Container factory] Deployed application: file:/S:/jboss-2.4/jboss/dist/tmp/deploy/Default/my.ear/
[J2EE Deployer Default] J2EE application: file:/S:/jboss-2.4/jboss/dist/deploy/my.ear is deployed.

No destroy message. So the bean does deploy the second time. It also appears to be receiving messages.

Any further redeployments give the same result.

[pra]

This is so strange, since both mdb test and the JMS examples works fine in 2.4.x and 2.5.x.

I think the best way to check this is that you send your mdb in a jar directly to me so I can check it: mailto:[e-mail]

//Peter

[panz]

I believe i've nailed down the problem, to the point where i can avoid it and i know why you're not seeing it.

I was defining my queues by placing the mbeans at the bottom of jboss.jcml, where it says "put your custom mbeans here." This gave the errors posted above.

When i moved the queue definitions up to where the jboss test queues are defined, everything worked again.

So the problem is apparently that jboss
1) checks for existence of the mdb deployment queue
2) creates a temp one if it's not found

and step 1) is returning a false negative, depending on where in your jboss.jcml your queue is defined. Weird.

I haven't actually looked at the jboss code yet, so i don't know what would cause that. The xml stuff inbetween is mostly mbeans for connection factories.

I suspect that if you move your queue definitions to the bottom of jboss.jcml, your test cases will fail. Let me know.

[pra]

It is hard to belive this (but never, say never). The only cirkumstance this would actually happen is when you have copyed your bean to deploy and does a restart of JBoss, since the deployment process is done/defined earlier in jboss.jcml (before your destination was defined)

//Peter

[panz]

Well, i guess that's actually the typical case for me, since my build.xml deploys beans to the auto-deploy directory.

Of course the jboss.jcml file warned me that mbean order is important, so i should have known better.

I'd be surprised if i'm the first to waste time on this problem though. Perhaps we should have a "put your queue/topic defs here" comment in jcml, to save folks like me from themselves. :) It was the "put your custom mbeans here" comment at the bottom that led me astray in the first place.

At any rate, thanks for your help.

[pra]

You are quite right, but bear with us. Destinations being defined in jboss.jcml is quite new. Earlier they where defined in a separate file.

But hey, just wait on the 3.0 Rabit Hole. Stuff commited last night will make it possible to sort of hot deploy also your destinations. Jiha.

JBoss is going wild now.

//Peter

[hchirino]

I can't get over how cool the hot deploy is!!!