cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <>
Subject Re: bus extensions association under multiple buses
Date Mon, 19 Dec 2011 23:09:50 GMT
2011/12/19 Daniel Kulp <>:
> 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

>> 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
> -
> Talend Community Coder -

View raw message