Re: [jetty-dev] jmx with annotations

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

hm....

I can go that way as well, I whip it up that way and give it a spin

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx


On Thu, Aug 9, 2012 at 7:38 PM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>
> I like part B of option 2.
>
> Specifically I don't like:
>
> @ManagedObject(...
> @ManagedAttribute(...
> public class Foo
> {
>  ...
> }
>
> because as joakim says there is separation between the field and it's
> management meta data.
>
>
>
> But I also don't like:
>
> @ManagedObject(...
> public class Foo
> {
>
>    @ManagedAttribute(...
>    private int field;
>  ...
> }
>
> because hat field is private and should not be directly the target of
> management.
>
>
> So I only really like:
>
>
>
> @ManagedObject(...
> public class Foo
> {
>
>    @ManagedAttribute(...
>    public int getField();
>  ...
> }
>
> I think name="" should be optional, so that if it is not given, then name is
> taken from the getter.
>
> we should never need getter=, because it is the getter than we annotate.  We
> can have an optional setter= for non standard setters (or do we really need
> to support this?).
>
> cheers
>
>
>
>
>
> On 10 August 2012 07:52, Jesse McConnell <jesse@xxxxxxxxxxx> wrote:
>>
>> ok, I have tinkered enough with our jmx and converting off the mbean
>> properties files to annotations to like and love and hate a couple of
>> different options.
>>
>> so....which do people like most?
>>
>> @ManagedObject("this is a managed object")
>> @ManagedAttribute(name="threads", description="the threads on this
>> object") // with optionally ->  readonly="true/false",
>> managed="true/false", proxied="true/false",
>> getter="getNonStandardThreads", setter="setNonStandardThreads"
>> ..
>> ..
>> ..
>> public class Foo
>> {
>>
>>   @ManagedOperation("run foo") // with optionally ->
>> managed="true/false", proxied="true/false", impact="ACTION, etc etc"
>>   public void foo()
>>   {
>>
>>   }
>> }
>>
>>
>> OR!!!
>>
>>
>> @ManagedObject("this is a managed object")
>> public class Foo
>> {
>>
>>   @ManagedAttribute(name="threads", description="the threads on this
>> object") // with optionally ->  readonly="true/false",
>> managed="true/false", proxied="true/false",
>> getter="getNonStandardThreads", setter="setNonStandardThreads"
>>   private int _threads;
>>
>>
>>   @ManagedOperation("run foo") // with optionally ->
>> managed="true/false", proxied="true/false", impact="ACTION, etc etc"
>>   public void foo()
>>   {
>>
>>   }
>>
>>   which also supports this for attributes that don't correspond to
>> fields which exist in a number of places
>>
>>   @ManagedAttribute(name="threads", description="the threads on this
>> object") // with optionally ->  readonly="true/false",
>> managed="true/false", proxied="true/false",
>> getter="getNonStandardThreads", setter="setNonStandardThreads"
>>   public int getThreadCount()
>>   {
>>
>>   }
>> }
>>
>>
>> I like the first because it brings all the attributes into the same
>> place and you don't have them spread over the fields and methods of
>> the class...but then I was discussing it with joakim some and he
>> doesn't like that the could fall out of sync the same way the mbean
>> properties files do over time which I can see as well.  Currently I
>> have it written the second way...  If the second way is more desirable
>> I will clean it up to automatically take care of things like _ being
>> removed to find the getters and setters and things like that, to make
>> the default more tolerant of our code style and the like. :)
>>
>> Also, I have written some unit tests around the object mbean classes
>> now which I could also adapt into a testing framework for all of our
>> beans as well...which means I could wire in the jmx annotation
>> processing in unit tests in the build and fail it when things fall out
>> of sync which might address some of the concern with having them at
>> the Type (class) level.
>>
>> opinions?
>>
>> cheers,
>> jesse
>>
>> --
>> Jesse McConnell <jesse@xxxxxxxxxxx>
>> www.webtide.com – Developer advice, services and support from the
>> Jetty & CometD experts.
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>
>
>
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>