This is the JSR77 implementation that monitors deployment notifications of .ear, .war, .sar, .etc, and maintains its own "standard" view of MBeans.
The message is not something to worry about, it's coming from ServiceMBeanSupport baseclass. as if it tries to create on of those management mbeans, but it fails at some point.
Maybe if you follow the org.jboss.management.j2ee.* DEBUG messages in the log, you can figure out the offending MBean.
Thanks, I found it.
I have two service files in two different jar files that have the same name. thus:
2005-01-18 10:58:17,447 INFO [org.jboss.management.j2ee.ServiceModule] Registration is not done -> stop
2005-01-18 10:58:17,460 DEBUG [org.jboss.management.j2ee.ServiceModule] Could not create JSR-77 ServiceModule: fti-service.xml
javax.management.InstanceAlreadyExistsException: jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,name=fti-service.xml already registered.
IMHO the that should work though. Can we add the module name or even make the name more comprehensive like: //fti-service.xml
That would prevent these clashes
oh the forum drop something:
There should be a parent module name in the same way an ejb-jar in an ear has a parent name to define the scope.
Shall I add a bug entry?
Yes, add a bug, and no it has nothing to do with JBAS-1281
No, definitly not. That bug was reported by me. The problem there is that the cleanup for ResourceAdapters is not doing all it should.
This is an initialization problem.
Scott, if you have no objections I will enter a bug report
I'm looking into ways of solving this. The idea for a parent module won't solve all problems, I think.
For example consider:
You get the same problem, but there is certainly no notion of an enclosing parent module here.
For the way jboss works, the absolute deployment url is the ultimate id for a deployment, so my idea would be to add it in the name, e.g.
It would solve the problem. Although it would expose information that should not be avialable via J2EE management, right?
A vendor is free to add his own extensions to the jsr77 base stuff, and while I look more to it, I understand that knowing the actual deployment url is something useful.
The ugly part is to have this url in the objectname, although my guess is that most management tools will not show this.
On the other hand, what is another concrete way of solving this?
You are right of course. It is a solution and I have no idea on how else to do it either.
But as you said having the url as part of the identifier is ugly. and if it is the only thing that differs to items from different modules it is even uglier, because the url itself does not have a meaning.
I would still like to have the parent module in there, for just that reason. If I have the same service in two different modules, I would like to see that they come from different modules and not just figure that out by the url.