11:58 p.m.
This probably needs to be fixed in the ServiceControllerContext in AS
code? We can do a simple wrapper around ObjectName name representation,
where equality is not dependent on the properties order. I can look at
that, np. ------------------- >> The order of properties in a depends
string should not matter. There are getCanonicalKeyPropertyListString()
and getCanonicalName() ObjectName methods that return the props in a
sorted order, but should not be needed for depends. Must be a change in
the depends lookup that is going to a string form which is not the
canonical format. Carlo de Wolf wrote:
> After breaking my head for two days why dependencies aren't
working
> anymore, Ales kindly pointed out to me that my properties are in the
> wrong order. It turns out this is a global problem.
>
> If I deploy this:
> <?xml version="1.0" encoding="UTF-8"?>
> <server>
> <mbean code="org.jboss.mq.server.jmx.Topic"
> name="jboss.mq.destination:service=Topic,name=myTestTopic">
> <attribute
name="JNDIName">topic/myTestTopic</attribute>
> <depends
optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
> </mbean>
> </server>
>
> I get this in jmx-console:
> jboss.mq.destination
> * name=myTestTopic,service=Topic
>
> Note the reversal of the properties. I'm digging down into this, but
> maybe this will ring a bell to someone.
>
> Carlo
12:18 a.m.
New subject: ObjectName property order
ObjectNames already are property order independent because they use the
canonical name for comparison. We should not need a wrapper around it.
There has to be use of a non-canonical string somewhere to cause this
problem.
Ales Justin wrote:
This probably needs to be fixed in the ServiceControllerContext in
AS
code? We can do a simple wrapper around ObjectName name representation,
where equality is not dependent on the properties order. I can look at
that, np.
3:31 p.m.
New subject: ObjectName property order
The problem is caused by the integration between the MC and JMX.
MC uses Strings for its names so it won't understand reordering of
properties if you reference/inject a JMX ObjectName.
For this reason, I took the decision that when you create a
ServiceControllerContext it takes the canonical name
and registers that in the MC.
It does the same for all references to ObjectNames, e.g.
dependencies and everywhere else in the api.
There is no reason why the example you post shouldn't be working.
The <depends/> should be converted into with mc depdency with the
canonical name.
If you can reproduce the problem, add a test to the system-jmx project
in the appserver.
Just saying "IT DOES NOT WORK" and posting a random xml snippet doesn't
really help me in reproducing the problem.
On Wed, 2007-01-31 at 23:58 +0100, Ales Justin wrote:
This probably needs to be fixed in the ServiceControllerContext in AS
code? We can do a simple wrapper around ObjectName name representation,
where equality is not dependent on the properties order. I can look at
that, np. ------------------- >> The order of properties in a depends
string should not matter. There are getCanonicalKeyPropertyListString()
and getCanonicalName() ObjectName methods that return the props in a
sorted order, but should not be needed for depends. Must be a change in
the depends lookup that is going to a string form which is not the
canonical format. Carlo de Wolf wrote:
> > After breaking my head for two days why dependencies aren't working
> > anymore, Ales kindly pointed out to me that my properties are in the
> > wrong order. It turns out this is a global problem.
> >
> > If I deploy this:
> > <?xml version="1.0" encoding="UTF-8"?>
> > <server>
> > <mbean code="org.jboss.mq.server.jmx.Topic"
> > name="jboss.mq.destination:service=Topic,name=myTestTopic">
> > <attribute
name="JNDIName">topic/myTestTopic</attribute>
> > <depends
optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
> > </mbean>
> > </server>
> >
> > I get this in jmx-console:
> > jboss.mq.destination
> > * name=myTestTopic,service=Topic
> >
> > Note the reversal of the properties. I'm digging down into this, but
> > maybe this will ring a bell to someone.
> >
> > Carlo
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
5:07 p.m.
New subject: ObjectName property order
The "problem" is easily reproducable, just deploy the xml I specified
and observe jmx-console. It's not showing the serialized name. :-)
But I agree with you that we should use the canonical name instead of
the serialized name. It's just that it broke stuff in EJB 3, because of
the assumption was that the name you register, you can ~depend~
upon. :-)
Maybe you should change the API so only ObjectName can be used to
install beans, instead of String? That would alleviate the problem once
and for all.
I've added your comment to EJBTHREE-859, so to understand the cause
which initiated the change.
Carlo
On Thu, 2007-02-01 at 15:31 +0100, Adrian wrote:
The problem is caused by the integration between the MC and JMX.
MC uses Strings for its names so it won't understand reordering of
properties if you reference/inject a JMX ObjectName.
For this reason, I took the decision that when you create a
ServiceControllerContext it takes the canonical name
and registers that in the MC.
It does the same for all references to ObjectNames, e.g.
dependencies and everywhere else in the api.
There is no reason why the example you post shouldn't be working.
The <depends/> should be converted into with mc depdency with the
canonical name.
If you can reproduce the problem, add a test to the system-jmx project
in the appserver.
Just saying "IT DOES NOT WORK" and posting a random xml snippet doesn't
really help me in reproducing the problem.
On Wed, 2007-01-31 at 23:58 +0100, Ales Justin wrote:
> This probably needs to be fixed in the ServiceControllerContext in AS
> code? We can do a simple wrapper around ObjectName name representation,
> where equality is not dependent on the properties order. I can look at
> that, np. ------------------- >> The order of properties in a depends
> string should not matter. There are getCanonicalKeyPropertyListString()
> and getCanonicalName() ObjectName methods that return the props in a
> sorted order, but should not be needed for depends. Must be a change in
> the depends lookup that is going to a string form which is not the
> canonical format. Carlo de Wolf wrote:
>
> > > After breaking my head for two days why dependencies aren't working
> > > anymore, Ales kindly pointed out to me that my properties are in the
> > > wrong order. It turns out this is a global problem.
> > >
> > > If I deploy this:
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <server>
> > > <mbean code="org.jboss.mq.server.jmx.Topic"
> > >
name="jboss.mq.destination:service=Topic,name=myTestTopic">
> > > <attribute
name="JNDIName">topic/myTestTopic</attribute>
> > > <depends
optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
> > > </mbean>
> > > </server>
> > >
> > > I get this in jmx-console:
> > > jboss.mq.destination
> > > * name=myTestTopic,service=Topic
> > >
> > > Note the reversal of the properties. I'm digging down into this, but
> > > maybe this will ring a bell to someone.
> > >
> > > Carlo
> >
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
5:26 p.m.
New subject: ObjectName property order
Why don't you just fix it like the ServiceMetaData does
when it doesn't know whether it is dealing with a bean name
or ObjectName?
String dependency = ...
try
{
ObjectName on = new ObjectName(dependency);
dependency = on.getCanonicalName();
}
catch (MalformedObjectName ignored)
{
// Not an object name
}
On Thu, 2007-02-01 at 17:07 +0100, Carlo de Wolf wrote:
The "problem" is easily reproducable, just deploy the xml I
specified
and observe jmx-console. It's not showing the serialized name. :-)
But I agree with you that we should use the canonical name instead of
the serialized name. It's just that it broke stuff in EJB 3, because of
the assumption was that the name you register, you can ~depend~
upon. :-)
Maybe you should change the API so only ObjectName can be used to
install beans, instead of String? That would alleviate the problem once
and for all.
I've added your comment to EJBTHREE-859, so to understand the cause
which initiated the change.
Carlo
On Thu, 2007-02-01 at 15:31 +0100, Adrian wrote:
> The problem is caused by the integration between the MC and JMX.
>
> MC uses Strings for its names so it won't understand reordering of
> properties if you reference/inject a JMX ObjectName.
>
> For this reason, I took the decision that when you create a
> ServiceControllerContext it takes the canonical name
> and registers that in the MC.
>
> It does the same for all references to ObjectNames, e.g.
> dependencies and everywhere else in the api.
>
> There is no reason why the example you post shouldn't be working.
> The <depends/> should be converted into with mc depdency with the
> canonical name.
>
> If you can reproduce the problem, add a test to the system-jmx project
> in the appserver.
>
> Just saying "IT DOES NOT WORK" and posting a random xml snippet
doesn't
> really help me in reproducing the problem.
>
> On Wed, 2007-01-31 at 23:58 +0100, Ales Justin wrote:
> > This probably needs to be fixed in the ServiceControllerContext in AS
> > code? We can do a simple wrapper around ObjectName name representation,
> > where equality is not dependent on the properties order. I can look at
> > that, np. ------------------- >> The order of properties in a depends
> > string should not matter. There are getCanonicalKeyPropertyListString()
> > and getCanonicalName() ObjectName methods that return the props in a
> > sorted order, but should not be needed for depends. Must be a change in
> > the depends lookup that is going to a string form which is not the
> > canonical format. Carlo de Wolf wrote:
> >
> > > > After breaking my head for two days why dependencies aren't
working
> > > > anymore, Ales kindly pointed out to me that my properties are in the
> > > > wrong order. It turns out this is a global problem.
> > > >
> > > > If I deploy this:
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > <server>
> > > > <mbean code="org.jboss.mq.server.jmx.Topic"
> > > >
name="jboss.mq.destination:service=Topic,name=myTestTopic">
> > > > <attribute
name="JNDIName">topic/myTestTopic</attribute>
> > > > <depends
optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
> > > > </mbean>
> > > > </server>
> > > >
> > > > I get this in jmx-console:
> > > > jboss.mq.destination
> > > > * name=myTestTopic,service=Topic
> > > >
> > > > Note the reversal of the properties. I'm digging down into this,
but
> > > > maybe this will ring a bell to someone.
> > > >
> > > > Carlo
> > >
> > _______________________________________________
> > 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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
6287
days inactive
6288
days old
jboss-development@lists.jboss.org
4 comments
4 participants
participants (4)
-
Adrian -
Ales Justin -
Carlo de Wolf -
Scott M Stark