I see your point. BTW, 4 isn't so bad with custom syntax - it becomes just <jaxws:endpoint implementor="..."/>, but I think we probably shouldn't force users to write XML.
- Dan On 1/26/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > Good point. Using Spring to define the JMX interface definitely is > > > > easier > > > > > > and makes more sense. > > > > > > > > -----Original Message----- > > > > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, January 26, 2007 12:56 PM > > > > To: [email protected] > > > > 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 <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
