cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject bus extensions association under multiple buses
Date Mon, 19 Dec 2011 15:30:08 GMT
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

Mime
View raw message