cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Neward" <...@tedneward.com>
Subject RE: Managing (JMX) Configuration/Policy Beans
Date Mon, 29 Jan 2007 01:18:30 GMT
Oh, God, PLEASE don't shove Spring down my throat. I have a hard enough time
with Spring folks as it is. :-)

+1 on making the bits manageable without Spring. (God forbid if I were to
actually want this stuff inside an EJB 3 container, for example....)

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: Daniel Kulp [mailto:daniel.kulp@iona.com]
> Sent: Friday, January 26, 2007 12:40 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Managing (JMX) Configuration/Policy Beans
> 
> On Friday 26 January 2007 15:08, Dan Diephouse wrote:
> > If the impl has the @ManagedResource annotation for Spring, isn't it
> > probably also going to be managed by Spring? In which case its kind of a
> > non-issue.
> 
> I think your missing the point.
> 
> My use case:
> Basically, I'm a JAX-WS developer.   I'm writing a JAX-WS endpoint, but
> I'd
> like to have parts of it "managable" in the JMX console and wired in with
> the
> rest of the stuff in CXF that is managed.   (example, my endpoint may hang
> off the specific named bus or similar in the hierarchical/tree view)
> Nowhere does spring come into play.
> 
> 
> There are basically a couple solutions:
> 1) We just provide a handle to the JMX server we are using and they would
> need
> to handle all the JMX stuff themselves.   I'd definitely prefer making
> this
> easier.
> 
> 2) Keep the annotations we have and tell the user they can use those.
> Make
> Endpoint.publish smart enough to recognize those and auto-register them.
> 
> 3) Get rid of ours and defer to the Spring annotations, but still make it
> easy
> to register.
> 
> 4) Get rid of ours and require the user to completely learn spring and
> write
> spring bean xml files to get their object registered.    Or use the other
> Spring API's to create/publish their objects.    I'm against this.   I'm a
> JAX-WS developer.   I shouldn't have Spring shoved down my throat for
> this.
> 
> 5) Others?......
> 
> 
> 
> Basically, the question is, how will we be instrumenting objects that are
> NOT
> managed by spring?
> 
> Dan
> 
> 
> 
> 
> >
> > On 1/26/07, Daniel Kulp <daniel.kulp@iona.com> wrote:
> > > On Friday 26 January 2007 14:00, Dan Diephouse wrote:
> > > > If we go this route, do we still need the annotations in cxf-common?
> > > > The only references to them that I see are on the work manager.
> Anyone
> > > > know about this code?
> > >
> > > Well, if I'm instrumenting some endpoint code or something, I'd MUCH
> > > rather
> > > use JDK5 annotations than a spring bean file.   However, since spring
> > > provides some annotations, I'd say just use those and ditch ours.
> The
> > > only "trick" will be to get non spring-defined objects wired into the
> > > spring
> > > JMX server.   Example, if I call:
> > >
> > > Endpoint.publish(url, impl);
> > > and the impl has the spring ManagedResource annotations on it, should
> our
> > > runtime automatically register it, or should we provide a "hook" (like
> > > bus.get(ManagementServer.class).register(name, impl)) for users to be
> > > able to
> > > add objects?
> > >
> > > Dan
> > >
> > > > - Dan
> > > >
> > > > On 1/26/07, Soltysik, Seumas <Seumas.Soltysik@iona.com> wrote:
> > > > > Good point. Using Spring to define the JMX interface definitely is
> > >
> > > easier
> > >
> > > > > and makes more sense.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > > > Sent: Friday, January 26, 2007 12:56 PM
> > > > > To: cxf-dev@incubator.apache.org
> > > > > Subject: Re: Managing (JMX) Configuration/Policy Beans
> > > > >
> > > > >
> > > > > Is this information we really want to keep in our schemas? Spring
> > > > > provides an approach where you can control the MBean interface
> > > > > through the MBeanInfoAssembler
> > > > > interface. There are multiple implementations including one where
> we
> > >
> > > can
> > >
> > > > > just specify what methods should be exposed as attributes in the
> > > > > spring.xml:
> > > > >
> > > > >
> http://static.springframework.org/spring/docs/2.0.x/reference/jmx.htm
> > > > >l
> > >
> > >
> http://static.springframework.org/spring/docs/2.0.x/reference/jmx.html#jm
> > >
> > > > >x-interface
> > > > >
> > > > > - Dan
> > > > >
> > > > > On 1/26/07, Soltysik, Seumas <Seumas.Soltysik@iona.com> wrote:
> > > > > > It seems like it would be a good idea to be able to modify
> certain
> > > > >
> > > > > runtime
> > > > >
> > > > > > attributes associated with the config/policy Spring Beans via
> JMX.
> > > > > > Since only certain attributes make sense to modify at runtime,
> only
> > > > > > these
> > > > >
> > > > > certain
> > > > >
> > > > > > attributes should be exposed via an MBean. Could we integrate
> the
> > > > > > information regarding which attributes should be exposed by
> > >
> > > annotating
> > >
> > > > > the
> > > > >
> > > > > > existing schemas for the policies and then modifying the JAXB
> code
> > > > >
> > > > > generator
> > > > >
> > > > > > to add JMX annotations to the appropriate getter/setter methods?
> > >
> > > This
> > >
> > > > > way we
> > > > >
> > > > > > can ensure that only certain appropriate values can be changed
> via
> > >
> > > JMX.
> > >
> > > > > --
> > > > > Dan Diephouse
> > > > > Envoi Solutions
> > > > > http://envoisolutions.com | http://netzooid.com/blog
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727    C: 508-380-7194
> > > daniel.kulp@iona.com
> 
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194
> daniel.kulp@iona.com
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.12/653 - Release Date: 1/26/2007
> 11:11 AM
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.12/655 - Release Date: 1/28/2007
1:12 PM
 


Mime
View raw message