[JBoss-dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBossAS5.0.0 Beta

Thu Aug 17 21:24:09 EDT 2006

Adrian's fix works great! Over 700 errors disappeared in the testsuite.
But what happens when a common service, like topic/testTopic is bound to jndi at the startup of the server (or someone else bounded it after the startup), and someone else tries to bind it again? AS answers with an Exception.
Example:
Starting the server:
08:44:55,671 INFO  [C] Bound to JNDI name: queue/C
08:44:55,687 INFO  [D] Bound to JNDI name: queue/D
08:44:55,703 INFO  [ex] Bound to JNDI name: queue/ex
08:44:55,750 INFO  [B] Bound to JNDI name: queue/B
08:44:55,765 INFO  [A] Bound to JNDI name: queue/A
08:44:55,765 INFO  [testQueue] Bound to JNDI name: queue/testQueue
08:44:55,781 INFO  [securedTopic] Bound to JNDI name: topic/securedTopic
08:44:55,781 INFO  [testTopic] Bound to JNDI name: topic/testTopic
08:44:55,781 INFO  [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
08:44:55,781 INFO  [DLQ] Bound to JNDI name: queue/DLQ
08:44:55,781 INFO  [UILServerILService] JBossMQ UIL service available at : /0.0.0.0:8093
08:44:56,093 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
08:44:56,109 INFO  [WebMetaData] WebMetaData:importJBossWebXml: maxActiveSessions = -1
08:44:56,125 INFO  [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
08:44:56,703 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080
08:44:56,781 INFO  [ChannelSocket] JK: ajp13 listening on /0.0.0.0:8009
08:44:56,796 INFO  [JkMain] Jk running ID=0 time=0/46  config=null
08:44:56,843 INFO  [Server] JBoss (MX MicroKernel) [5.0.0.Beta (build: CVSTag=HEAD date=200608071122)] Started in 38s:984ms
***********************
Now starting a testsuite test (org.jboss.test.cts.test.BmpUnitTestCase):
***********************
08:45:14,875 ERROR [MainDeployer] Could not create deployment: file:/D:/jboss-svn4/jboss-head/build/output/jboss-5.0.0.Beta/server/all/tmp/deploy/tmp30918cts.jar-contents/test-destinations-full-service.xml
org.jboss.deployment.DeploymentException: Error during install; - nested throwable: (java.lang.IllegalStateException: jboss.mq.destination:name=testTopic,service=Topic is already installed.)
        at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException (DeploymentException.java:53)
        at org.jboss.system.ServiceController.install(ServiceController.java:259)
***************************
The test ends with an error because it can't bind "ejbcts", because an Exception cancels the whole deployment instead of printing out an info, that "testTopic" is already bound.
Same issue in JBoss404GA.
Wouldn't it be nicer to print on stdout an info, that the resource is already registered? The deployment would continue, "ejbcts" would bind, the test (and some others) wouldn't fail.

________________________________

From: jboss-development-bounces at lists.jboss.org on behalf of Jason T. Greene
Sent: Thu 2006-08-17 19:28
To: JBoss.org development list
Subject: RE: [JBoss-dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBossAS5.0.0 Beta

Actually looking at it in more depth, it can't be done without some kind
of post cleanup which would be overkill. So nevermind :)

-Jason

> -----Original Message-----
> From: jboss-development-bounces at lists.jboss.org
[mailto:jboss-development-
> bounces at lists.jboss.org] On Behalf Of Jason T. Greene
> Sent: Thursday, August 17, 2006 7:22 PM
> To: JBoss.org development list
> Subject: RE: [JBoss-
>
dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBossA
S
> 5.0.0 Beta
>
> > 2) Jason, are you proposing that if Controller unregisters an MBean
it
> > didn't register, it should complain a bit (i.e. log a WARN or
> > something)?
>
> Yes, because in theory we would be able to drop the unregister code
from
> controller once people are given enough time to fix their code.
>
> > -----Original Message-----
> > From: jboss-development-bounces at lists.jboss.org
> [mailto:jboss-development-
> > bounces at lists.jboss.org] On Behalf Of Brian Stansberry
> > Sent: Thursday, August 17, 2006 2:42 PM
> > To: JBoss.org development list
> > Subject: RE: [JBoss-
> >
>
dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBoss
> AS
> > 5.0.0 Beta
> >
> > I think my 'Mom' analogy was a bad idea, as I'm losing track of the
> real
> > meaning of the conversation :) My post was that way too.
> >
> > 1) Having the new implementation clean up after people is good.  I
> > didn't mean to imply it wasn't.
> > 2) Jason, are you proposing that if Controller unregisters an MBean
it
> > didn't register, it should complain a bit (i.e. log a WARN or
> > something)?
> > 3) IMHO having EjbModule call registerMBean and then not clean up
> after
> > itself is bad.  Does anyone who is more familiar with EJB 2
> deployments
> > see any reason not to call unregisterMBean() in
> > EjbModule.destroyService()? (Harder alternative is figure out how to
> get
> > rid of the registerMBean call in createService()).
> >
> > I'll shut up now; probably this is something that will be sorted as
> part
> > of updating the deployers. My concern was getting the HA-JNDI unit
> test
> > working, which Adrian kindly did :)
> >
> > jboss-development-bounces at lists.jboss.org wrote:
> > > Right, so why don't we complain if they don't clean up after
> > > themselves, and then clean up for them? Just like Mom does.
> > >
> > >> -----Original Message-----
> > >> From: jboss-development-bounces at lists.jboss.org
> > >> [mailto:jboss-development- bounces at lists.jboss.org] On Behalf Of
> > >> Brian Stansberry
> > >> Sent: Wednesday, August 16, 2006 11:20 AM
> > >> To: JBoss.org development list
> > >> Subject: RE: [JBoss-
> > >> dev]InstanceAlreadyExistsExceptionafterundeployandrepeated
deployin
> > >> JBoss AS 5.0.0 Beta
> > >>
> > >> jboss-development-bounces at lists.jboss.org wrote:
> > >>> On Wed, 2006-08-16 at 15:49 +0200, Adrian Brock wrote:
> > >>>> Also, this change causes "problems" for web deployments (looks
> like
> > >>>> they being unregistered from the MBeanServer rather than being
> > >>>> removed from the ServiceController?):
> > >>>>
> > >>>
> > >>> Yep. And I've fixed this as well.
> > >>
> > >> So, before ServiceController.remove() was cleaning up after
people,
> > >> and now the new implementation is again.  And you just fixed an
> > >> issue where it would complain if people had already cleaned up
> after
> > >> themselves :)
> > >>
> > >> If need be my mom used to clean up after me, but she also trained
> me
> > >> to clean up after myself (well, kinda). So, seems like if
> > >> EjbModule.createService() is going to call registerMBean(),
> > >> EjbModule.destroyService() should call unregisterMBean().
> > >>
> > >> Brian Stansberry
> > >> Lead, AS Clustering
> > >> JBoss, a division of Red Hat
> > >> Ph: 510-396-3864
> > >> skype: bstansberry
> > >>
> > >> _______________________________________________
> > >> jboss-development mailing list
> > >> jboss-development at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/jboss-development
> > >
> > > _______________________________________________
> > > jboss-development mailing list
> > > jboss-development at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> >
> >
> > Brian Stansberry
> > Lead, AS Clustering
> > JBoss, a division of Red Hat
> > Ph: 510-396-3864
> > skype: bstansberry
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development

_______________________________________________
jboss-development mailing list
jboss-development at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 11799 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jboss-development/attachments/20060817/c4a45e25/attachment.bin 