7:28 p.m.
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(a)lists.jboss.org
[mailto:jboss-development-
bounces(a)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(a)lists.jboss.org
[mailto:jboss-development-
> bounces(a)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(a)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(a)lists.jboss.org
> >> [mailto:jboss-development- bounces(a)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(a)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(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
8:24 p.m.
New subject: [JBoss-dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBossAS5.0.0 Beta
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(a)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(a)lists.jboss.org
[mailto:jboss-development-
bounces(a)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(a)lists.jboss.org
[mailto:jboss-development-
> bounces(a)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(a)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(a)lists.jboss.org
> >> [mailto:jboss-development- bounces(a)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(a)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(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-development
> >
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
7:40 a.m.
New subject: [JBoss-dev]InstanceAlreadyExistsExceptionafterundeployandrepeateddeployinJBossAS5.0.0 Beta
Please don't use html e-mails.
On Thu, 2006-08-17 at 20:24 -0500, Jaroslaw Kijanowski wrote:
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.
There is no choice other than cancelling the whole deployment if there
is a duplicate. That is unless you install a dummy context,
e.g. "jboss.mq.destination:name=testTopic,service=Topic-**DUPLCIATE1**"
to hold the error message against so you can
continue and try to deploy any others.
In fact, this behaviour is better than it used to be 4.0.x
Now, only an xml parsing failure or a duplicate ObjectName
causes it to fail without the context going under control
of the Microcontainer.
This means much better summaries of errors can be produced.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxx
7170
days inactive
7175
days old
jboss-development@lists.jboss.org
2 comments
3 participants
participants (3)
-
Adrian Brock -
Jaroslaw Kijanowski -
Jason T. Greene