cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: bus extensions association under multiple buses
Date Tue, 20 Dec 2011 18:49:43 GMT
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 <elakito@googlemail.com>:
> > 2011/12/19 Daniel Kulp <dkulp@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

Mime
View raw message