cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: bus extensions association under multiple buses
Date Mon, 19 Dec 2011 20:05:52 GMT


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.


> 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.


I would ALSO have it call something like:

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).


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

View raw message