-
1. Re: Registration is not done -> stop
dimitris Jan 18, 2005 3:19 AM (in response to greydeath)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. -
2. Re: Registration is not done -> stop
greydeath Jan 18, 2005 5:06 AM (in response to greydeath)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 -
3. Re: Registration is not done -> stop
greydeath Jan 18, 2005 5:39 AM (in response to greydeath)oh the forum drop something:
[jar-file]/[path]/fti-service.xml -
4. Re: Registration is not done -> stop
starksm64 Jan 19, 2005 3:57 AM (in response to greydeath)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.
-
5. Re: Registration is not done -> stop
greydeath Jan 19, 2005 4:00 AM (in response to greydeath)Exactly!
+1
Shall I add a bug entry? -
6. Re: Registration is not done -> stop
wonnekeysers Jan 19, 2005 4:14 AM (in response to greydeath)Or is it the same problem as this unresolved bug : http://jira.jboss.com/jira/browse/JBAS-1281 ?
-
7. Re: Registration is not done -> stop
starksm64 Jan 19, 2005 4:17 AM (in response to greydeath)Yes, add a bug, and no it has nothing to do with JBAS-1281
-
8. Re: Registration is not done -> stop
greydeath Jan 19, 2005 4:17 AM (in response to greydeath)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 -
9. Re: Registration is not done -> stop
dimitris Apr 27, 2006 7:48 AM (in response to greydeath)I'm looking into ways of solving this. The idea for a parent module won't solve all problems, I think.
For example consider:
deploy/test-service.xml
deploy/management/test-service.xml
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.
jboss.management.local:J2EEServer=Local,j2eeType=ServiceModule,name=iiop-service.xml url=file:/X:/cvs/jboss-public/jboss-4.0/build/output/jboss-4.0.4.GA/server/all/deploy/iiop-service.xml -
10. Re: Registration is not done -> stop
greydeath Apr 27, 2006 9:02 AM (in response to greydeath)It would solve the problem. Although it would expose information that should not be avialable via J2EE management, right?
-
11. Re: Registration is not done -> stop
dimitris Apr 27, 2006 9:30 AM (in response to greydeath)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? -
12. Re: Registration is not done -> stop
greydeath Apr 27, 2006 9:54 AM (in response to greydeath)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.