You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Aki Yoshida <el...@googlemail.com> on 2011/12/19 16:30:08 UTC
bus extensions association under multiple buses
There is a problem in the bus extension association under multiple
buses that may result in some concrete problem in some cases. I have a
possible fix for this problem but there is also a related question to
it. So, I would like to get your opinion about how we should proceed.
Concretely, the problem is that the association of the
InstrumentationManager extension to its bus is not correctly happening
when this extension is explicitly configured as a bean referencing to
a specific bus instance using its bus property parameter.
A particular use case of this occurs when one wants to use the
persistentBusId property of the instrumentation manager to specify the
jmx registration name for the bus instead of using the generated name
for the registration.
To support this registration name use case itself, we could probably
generate the registration name based partly on the bus name (ie. the
bus name along with some hash value and its bundle symbolic name if
available) instead of utilizing this persistedBusId mechanism. I think
I would have considered this approach if this persitentBusId didn't
exist. In this case, we would not have needed to configure the
instrumentation manager bean only to set the persistendBusId property.
But if we want to utilize the current persistentBusId mechanism,
namely to use this property value of the instrumentation manager
associated with the bus as the jmx registration name, it appears that
we need to make certain changes in the way how the extensions are
instantiated so that the bus-extension association is correctly done
and these buses are registered under the correct names.
The concrete changes that I think needed are:
1. remove the annotation at InstrumentationManagerIml's setBus so that
the invocation of this method can be controlled.
2. In org.apache.cxf.bus.extension.Extension's load method, invoke
the setBus method if the extension has no bus-argument constructor but
has the setBus method. This will ensure the implicit extension loading
by the default bus to work even after the removal of the annotation
above.
3. In InstrumentationManagerImpl's setBus method, verify if the bus
argument is already associated with another InstrumentationManagerImpl
instance. This will happen when this instrumentation bean is
explicitly configured as a bean in the described use case above. In
this case, update the association of the bus so that the bus is
associated with the explicitly configured instrumentation manager and
not the one that is implicitly loaded (so that this bus will be
registered under the persistentBusId name instead of the generated
registration name).
With these changes, I can see the buses, their endpoints, etc
registered under their persistent bus Id names.
But before taking any concrete action, I would like to ask you how we
should proceed.
- should we make this change so that the use of persistendBusId works
in multiple bus cases in 2.5.x? I think this change of invoking setBus
method at the extension instantiation itself makes sense independently
of the instrumentation manager's use case (as I see this as analogue
to the bus-argument constructor is used there if available).
- or is this approach incorrect or if there is another simpler
approach to get the association correctly made in such cases?
- and/or specific to this jmx registration issue, could we in the
future deprecate persistendBusId and generate the registration name
based partly on the bus name directly as suggested?
Thanks.
Regards, aki
Re: bus extensions association under multiple buses
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, December 20, 2011 5:58:23 PM Aki Yoshida wrote:
> Hi,
> While trying to write a few test cases, I just found out that the
> bus's id attribute seems to be already providing the same effect
> originally intended by the persistentBusId property.
>
> So, to assign the jmx registration name for each bus, we just need to
> set the id attribute for that bus.
>
> That means, for the container case, we don't need to configure the
> instrumentation manager bean at all, as its default setting will
> ensure the correct registration.
Yep. Actually, that's already the case in OSGi to some extent, but this will
also extend it out beyond OSGi. With 2.5.x, if an MBeanServer is found
either in the application context (Spring) or as an OSGi service (osgi, both
Blueprint and Spring), then the management is automatically enabled. For
example, if you deploy CXF into Karaf, Karaf pretty much always has an
MBeanServer registered as an OSGi service. Thus, CXF is always instrumented
there.
> For the standalone case, I can introduce bus properties
> "bus.jmx.enabled" etc to configure the instrumentation manager within
> the bus configuration. In this way, you don't need to refer to this
> instrumentation manager impl class in your configuration.
+1. Getting rid of references to "Impl" classes is great. :-)
Dan
>
> regards, aki
>
> 2011/12/20 Aki Yoshida <el...@googlemail.com>:
> > 2011/12/19 Daniel Kulp <dk...@apache.org>:
> >> Inline....
> >>
> >> On Monday, December 19, 2011 4:30:08 PM Aki Yoshida wrote:
> >>> There is a problem in the bus extension association under multiple
> >>> buses that may result in some concrete problem in some cases. I have
> >>> a
> >>> possible fix for this problem but there is also a related question
> >>> to
> >>> it. So, I would like to get your opinion about how we should
> >>> proceed.
> >>>
> >>> Concretely, the problem is that the association of the
> >>> InstrumentationManager extension to its bus is not correctly
> >>> happening
> >>> when this extension is explicitly configured as a bean referencing
> >>> to
> >>> a specific bus instance using its bus property parameter.
> >>>
> >>> A particular use case of this occurs when one wants to use the
> >>> persistentBusId property of the instrumentation manager to specify
> >>> the
> >>> jmx registration name for the bus instead of using the generated
> >>> name
> >>> for the registration.
> >>>
> >>> To support this registration name use case itself, we could probably
> >>> generate the registration name based partly on the bus name (ie. the
> >>> bus name along with some hash value and its bundle symbolic name if
> >>> available) instead of utilizing this persistedBusId mechanism. I
> >>> think
> >>> I would have considered this approach if this persitentBusId didn't
> >>> exist. In this case, we would not have needed to configure the
> >>> instrumentation manager bean only to set the persistendBusId
> >>> property.
> >>>
> >>> But if we want to utilize the current persistentBusId mechanism,
> >>> namely to use this property value of the instrumentation manager
> >>> associated with the bus as the jmx registration name, it appears
> >>> that
> >>> we need to make certain changes in the way how the extensions are
> >>> instantiated so that the bus-extension association is correctly done
> >>> and these buses are registered under the correct names.
> >>>
> >>> The concrete changes that I think needed are:
> >>>
> >>> 1. remove the annotation at InstrumentationManagerIml's setBus so
> >>> that
> >>> the invocation of this method can be controlled.
> >>
> >> +1
> >>
> >>> 2. In org.apache.cxf.bus.extension.Extension's load method, invoke
> >>> the setBus method if the extension has no bus-argument constructor
> >>> but
> >>> has the setBus method. This will ensure the implicit extension
> >>> loading
> >>> by the default bus to work even after the removal of the annotation
> >>> above.
> >>
> >> OK. But I'd likely just add a second Bus constructor to the
> >> InstrumentationManager that would get invoked. But it's still a good
> >> idea.>
> > I now think introducing the bus-argument constructor for InstManager
> > might be a safer approach than calling the setBus method. This does
> > not involve any change to Extension and hence is less invasive. In
> > this way, we can avoid this extra setBus call by just providing the
> > bus-argument constructor.
> >
> > Your simple "adding the bus constructor" approach has an additional
> > benefit of being able to distinguish between the two bus settings
> > cases in the method: the initial bus setting at the extension
> > construction (over the constructor) and a subsequent bus setting (over
> > setBus).
> >
> >>> 3. In InstrumentationManagerImpl's setBus method, verify if the bus
> >>> argument is already associated with another
> >>> InstrumentationManagerImpl
> >>> instance. This will happen when this instrumentation bean is
> >>> explicitly configured as a bean in the described use case above. In
> >>> this case, update the association of the bus so that the bus is
> >>> associated with the explicitly configured instrumentation manager
> >>> and
> >>> not the one that is implicitly loaded (so that this bus will be
> >>> registered under the persistentBusId name instead of the generated
> >>> registration name).
> >>
> >> I'm OK with that.
> >>
> >> HOWEVER......
> >>
> >> I would ALSO have it call something like:
> >>
> >> bus.getProperty("bus.jmx.persistentId")
> >> bus.getProperty("bus.jmx.url")
> >> etc...
> >> and anything else it may need. In that way, the entire management of
> >> the Bus can be configured in with just Bus properties without
> >> actually having to configure in an InstrumentationManagerImpl. Just
> >> some (hopefully documented) properties set on the bus would be
> >> enough.
> >
> > Yes. That sounds good. This will simplify the configuration.
> >
> >>> With these changes, I can see the buses, their endpoints, etc
> >>> registered under their persistent bus Id names.
> >>>
> >>> But before taking any concrete action, I would like to ask you how
> >>> we
> >>> should proceed.
> >>>
> >>> - should we make this change so that the use of persistendBusId
> >>> works
> >>> in multiple bus cases in 2.5.x? I think this change of invoking
> >>> setBus
> >>> method at the extension instantiation itself makes sense
> >>> independently
> >>> of the instrumentation manager's use case (as I see this as analogue
> >>> to the bus-argument constructor is used there if available).
> >>
> >> Yep.
> >
> > As the concern mentioned above, I think we should do this change
> > without the change to the Extension class.
> >
> >>> - or is this approach incorrect or if there is another simpler
> >>> approach to get the association correctly made in such cases?
> >>>
> >>> - and/or specific to this jmx registration issue, could we in the
> >>> future deprecate persistendBusId and generate the registration name
> >>> based partly on the bus name directly as suggested?
> >>
> >> Sure. Or a property. :-)
> >
> > Okay. Thanks for your advice, as always. :-)
> >
> > regards, aki
> >
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: bus extensions association under multiple buses
Posted by Aki Yoshida <el...@googlemail.com>.
Hi,
While trying to write a few test cases, I just found out that the
bus's id attribute seems to be already providing the same effect
originally intended by the persistentBusId property.
So, to assign the jmx registration name for each bus, we just need to
set the id attribute for that bus.
That means, for the container case, we don't need to configure the
instrumentation manager bean at all, as its default setting will
ensure the correct registration.
For the standalone case, I can introduce bus properties
"bus.jmx.enabled" etc to configure the instrumentation manager within
the bus configuration. In this way, you don't need to refer to this
instrumentation manager impl class in your configuration.
regards, aki
2011/12/20 Aki Yoshida <el...@googlemail.com>:
> 2011/12/19 Daniel Kulp <dk...@apache.org>:
>>
>> Inline....
>>
>> On Monday, December 19, 2011 4:30:08 PM Aki Yoshida wrote:
>>> There is a problem in the bus extension association under multiple
>>> buses that may result in some concrete problem in some cases. I have a
>>> possible fix for this problem but there is also a related question to
>>> it. So, I would like to get your opinion about how we should proceed.
>>>
>>> Concretely, the problem is that the association of the
>>> InstrumentationManager extension to its bus is not correctly happening
>>> when this extension is explicitly configured as a bean referencing to
>>> a specific bus instance using its bus property parameter.
>>>
>>> A particular use case of this occurs when one wants to use the
>>> persistentBusId property of the instrumentation manager to specify the
>>> jmx registration name for the bus instead of using the generated name
>>> for the registration.
>>>
>>> To support this registration name use case itself, we could probably
>>> generate the registration name based partly on the bus name (ie. the
>>> bus name along with some hash value and its bundle symbolic name if
>>> available) instead of utilizing this persistedBusId mechanism. I think
>>> I would have considered this approach if this persitentBusId didn't
>>> exist. In this case, we would not have needed to configure the
>>> instrumentation manager bean only to set the persistendBusId property.
>>>
>>> But if we want to utilize the current persistentBusId mechanism,
>>> namely to use this property value of the instrumentation manager
>>> associated with the bus as the jmx registration name, it appears that
>>> we need to make certain changes in the way how the extensions are
>>> instantiated so that the bus-extension association is correctly done
>>> and these buses are registered under the correct names.
>>>
>>> The concrete changes that I think needed are:
>>>
>>> 1. remove the annotation at InstrumentationManagerIml's setBus so that
>>> the invocation of this method can be controlled.
>>
>> +1
>>
>>> 2. In org.apache.cxf.bus.extension.Extension's load method, invoke
>>> the setBus method if the extension has no bus-argument constructor but
>>> has the setBus method. This will ensure the implicit extension loading
>>> by the default bus to work even after the removal of the annotation
>>> above.
>>
>> OK. But I'd likely just add a second Bus constructor to the
>> InstrumentationManager that would get invoked. But it's still a good idea.
>>
>
> I now think introducing the bus-argument constructor for InstManager
> might be a safer approach than calling the setBus method. This does
> not involve any change to Extension and hence is less invasive. In
> this way, we can avoid this extra setBus call by just providing the
> bus-argument constructor.
>
> Your simple "adding the bus constructor" approach has an additional
> benefit of being able to distinguish between the two bus settings
> cases in the method: the initial bus setting at the extension
> construction (over the constructor) and a subsequent bus setting (over
> setBus).
>
>>
>>> 3. In InstrumentationManagerImpl's setBus method, verify if the bus
>>> argument is already associated with another InstrumentationManagerImpl
>>> instance. This will happen when this instrumentation bean is
>>> explicitly configured as a bean in the described use case above. In
>>> this case, update the association of the bus so that the bus is
>>> associated with the explicitly configured instrumentation manager and
>>> not the one that is implicitly loaded (so that this bus will be
>>> registered under the persistentBusId name instead of the generated
>>> registration name).
>>
>> I'm OK with that.
>>
>> HOWEVER......
>>
>> I would ALSO have it call something like:
>>
>> bus.getProperty("bus.jmx.persistentId")
>> bus.getProperty("bus.jmx.url")
>> etc...
>> and anything else it may need. In that way, the entire management of the Bus
>> can be configured in with just Bus properties without actually having to
>> configure in an InstrumentationManagerImpl. Just some (hopefully documented)
>> properties set on the bus would be enough.
>>
>
> Yes. That sounds good. This will simplify the configuration.
>
>>
>>
>>
>>> With these changes, I can see the buses, their endpoints, etc
>>> registered under their persistent bus Id names.
>>>
>>> But before taking any concrete action, I would like to ask you how we
>>> should proceed.
>>>
>>> - should we make this change so that the use of persistendBusId works
>>> in multiple bus cases in 2.5.x? I think this change of invoking setBus
>>> method at the extension instantiation itself makes sense independently
>>> of the instrumentation manager's use case (as I see this as analogue
>>> to the bus-argument constructor is used there if available).
>>
>> Yep.
>
> As the concern mentioned above, I think we should do this change
> without the change to the Extension class.
>
>>
>>> - or is this approach incorrect or if there is another simpler
>>> approach to get the association correctly made in such cases?
>>>
>>> - and/or specific to this jmx registration issue, could we in the
>>> future deprecate persistendBusId and generate the registration name
>>> based partly on the bus name directly as suggested?
>>
>> Sure. Or a property. :-)
>
> Okay. Thanks for your advice, as always. :-)
>
> regards, aki
>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
Re: bus extensions association under multiple buses
Posted by Aki Yoshida <el...@googlemail.com>.
2011/12/19 Daniel Kulp <dk...@apache.org>:
>
> Inline....
>
> On Monday, December 19, 2011 4:30:08 PM Aki Yoshida wrote:
>> There is a problem in the bus extension association under multiple
>> buses that may result in some concrete problem in some cases. I have a
>> possible fix for this problem but there is also a related question to
>> it. So, I would like to get your opinion about how we should proceed.
>>
>> Concretely, the problem is that the association of the
>> InstrumentationManager extension to its bus is not correctly happening
>> when this extension is explicitly configured as a bean referencing to
>> a specific bus instance using its bus property parameter.
>>
>> A particular use case of this occurs when one wants to use the
>> persistentBusId property of the instrumentation manager to specify the
>> jmx registration name for the bus instead of using the generated name
>> for the registration.
>>
>> To support this registration name use case itself, we could probably
>> generate the registration name based partly on the bus name (ie. the
>> bus name along with some hash value and its bundle symbolic name if
>> available) instead of utilizing this persistedBusId mechanism. I think
>> I would have considered this approach if this persitentBusId didn't
>> exist. In this case, we would not have needed to configure the
>> instrumentation manager bean only to set the persistendBusId property.
>>
>> But if we want to utilize the current persistentBusId mechanism,
>> namely to use this property value of the instrumentation manager
>> associated with the bus as the jmx registration name, it appears that
>> we need to make certain changes in the way how the extensions are
>> instantiated so that the bus-extension association is correctly done
>> and these buses are registered under the correct names.
>>
>> The concrete changes that I think needed are:
>>
>> 1. remove the annotation at InstrumentationManagerIml's setBus so that
>> the invocation of this method can be controlled.
>
> +1
>
>> 2. In org.apache.cxf.bus.extension.Extension's load method, invoke
>> the setBus method if the extension has no bus-argument constructor but
>> has the setBus method. This will ensure the implicit extension loading
>> by the default bus to work even after the removal of the annotation
>> above.
>
> OK. But I'd likely just add a second Bus constructor to the
> InstrumentationManager that would get invoked. But it's still a good idea.
>
I now think introducing the bus-argument constructor for InstManager
might be a safer approach than calling the setBus method. This does
not involve any change to Extension and hence is less invasive. In
this way, we can avoid this extra setBus call by just providing the
bus-argument constructor.
Your simple "adding the bus constructor" approach has an additional
benefit of being able to distinguish between the two bus settings
cases in the method: the initial bus setting at the extension
construction (over the constructor) and a subsequent bus setting (over
setBus).
>
>> 3. In InstrumentationManagerImpl's setBus method, verify if the bus
>> argument is already associated with another InstrumentationManagerImpl
>> instance. This will happen when this instrumentation bean is
>> explicitly configured as a bean in the described use case above. In
>> this case, update the association of the bus so that the bus is
>> associated with the explicitly configured instrumentation manager and
>> not the one that is implicitly loaded (so that this bus will be
>> registered under the persistentBusId name instead of the generated
>> registration name).
>
> I'm OK with that.
>
> HOWEVER......
>
> I would ALSO have it call something like:
>
> bus.getProperty("bus.jmx.persistentId")
> bus.getProperty("bus.jmx.url")
> etc...
> and anything else it may need. In that way, the entire management of the Bus
> can be configured in with just Bus properties without actually having to
> configure in an InstrumentationManagerImpl. Just some (hopefully documented)
> properties set on the bus would be enough.
>
Yes. That sounds good. This will simplify the configuration.
>
>
>
>> With these changes, I can see the buses, their endpoints, etc
>> registered under their persistent bus Id names.
>>
>> But before taking any concrete action, I would like to ask you how we
>> should proceed.
>>
>> - should we make this change so that the use of persistendBusId works
>> in multiple bus cases in 2.5.x? I think this change of invoking setBus
>> method at the extension instantiation itself makes sense independently
>> of the instrumentation manager's use case (as I see this as analogue
>> to the bus-argument constructor is used there if available).
>
> Yep.
As the concern mentioned above, I think we should do this change
without the change to the Extension class.
>
>> - or is this approach incorrect or if there is another simpler
>> approach to get the association correctly made in such cases?
>>
>> - and/or specific to this jmx registration issue, could we in the
>> future deprecate persistendBusId and generate the registration name
>> based partly on the bus name directly as suggested?
>
> Sure. Or a property. :-)
Okay. Thanks for your advice, as always. :-)
regards, aki
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: bus extensions association under multiple buses
Posted by Daniel Kulp <dk...@apache.org>.
Inline....
On Monday, December 19, 2011 4:30:08 PM Aki Yoshida wrote:
> There is a problem in the bus extension association under multiple
> buses that may result in some concrete problem in some cases. I have a
> possible fix for this problem but there is also a related question to
> it. So, I would like to get your opinion about how we should proceed.
>
> Concretely, the problem is that the association of the
> InstrumentationManager extension to its bus is not correctly happening
> when this extension is explicitly configured as a bean referencing to
> a specific bus instance using its bus property parameter.
>
> A particular use case of this occurs when one wants to use the
> persistentBusId property of the instrumentation manager to specify the
> jmx registration name for the bus instead of using the generated name
> for the registration.
>
> To support this registration name use case itself, we could probably
> generate the registration name based partly on the bus name (ie. the
> bus name along with some hash value and its bundle symbolic name if
> available) instead of utilizing this persistedBusId mechanism. I think
> I would have considered this approach if this persitentBusId didn't
> exist. In this case, we would not have needed to configure the
> instrumentation manager bean only to set the persistendBusId property.
>
> But if we want to utilize the current persistentBusId mechanism,
> namely to use this property value of the instrumentation manager
> associated with the bus as the jmx registration name, it appears that
> we need to make certain changes in the way how the extensions are
> instantiated so that the bus-extension association is correctly done
> and these buses are registered under the correct names.
>
> The concrete changes that I think needed are:
>
> 1. remove the annotation at InstrumentationManagerIml's setBus so that
> the invocation of this method can be controlled.
+1
> 2. In org.apache.cxf.bus.extension.Extension's load method, invoke
> the setBus method if the extension has no bus-argument constructor but
> has the setBus method. This will ensure the implicit extension loading
> by the default bus to work even after the removal of the annotation
> above.
OK. But I'd likely just add a second Bus constructor to the
InstrumentationManager that would get invoked. But it's still a good idea.
> 3. In InstrumentationManagerImpl's setBus method, verify if the bus
> argument is already associated with another InstrumentationManagerImpl
> instance. This will happen when this instrumentation bean is
> explicitly configured as a bean in the described use case above. In
> this case, update the association of the bus so that the bus is
> associated with the explicitly configured instrumentation manager and
> not the one that is implicitly loaded (so that this bus will be
> registered under the persistentBusId name instead of the generated
> registration name).
I'm OK with that.
HOWEVER......
I would ALSO have it call something like:
bus.getProperty("bus.jmx.persistentId")
bus.getProperty("bus.jmx.url")
etc...
and anything else it may need. In that way, the entire management of the Bus
can be configured in with just Bus properties without actually having to
configure in an InstrumentationManagerImpl. Just some (hopefully documented)
properties set on the bus would be enough.
> With these changes, I can see the buses, their endpoints, etc
> registered under their persistent bus Id names.
>
> But before taking any concrete action, I would like to ask you how we
> should proceed.
>
> - should we make this change so that the use of persistendBusId works
> in multiple bus cases in 2.5.x? I think this change of invoking setBus
> method at the extension instantiation itself makes sense independently
> of the instrumentation manager's use case (as I see this as analogue
> to the bus-argument constructor is used there if available).
Yep.
> - or is this approach incorrect or if there is another simpler
> approach to get the association correctly made in such cases?
>
> - and/or specific to this jmx registration issue, could we in the
> future deprecate persistendBusId and generate the registration name
> based partly on the bus name directly as suggested?
Sure. Or a property. :-)
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com