Dynamic MBeans can keep it well disconnected from existing classes.  But to 
some degree, there could be some changes needed to provide the correct 
instrumentation interfaces.

Gregg Wonderly 


On Oct 29, 2012, at 1:46 PM, Dennis Reedy <dennis.re...@gmail.com> wrote:

> Regardless how you connect, the rub is creating MBeans for "legacy" services 
> (reggie, outrigger, etc ...), getting them registered, have them represent 
> reasonable monitored properties. Looking at Dynamic MBeans may be the way to 
> go here. I cant remember where all this was left back in the day. 
> 
> On Oct 29, 2012, at 233PM, Dan Creswell wrote:
> 
>> That's another option...I'm comfortable with any and all...
>> 
>> I haven't thought it all the way through but I'm wondering about all those
>> service admin interfaces we have lying around and whether or not they can
>> be made easily JMX friendly in all cases. If it can't be easily done,
>> ServiceUI might be a useful fallback (and Gregg seems to like the
>> self-contained'ness, on some occasions, me too).
>> 
>> In my usual style, I'm tempted to "let a thousand flowers bloom" and see
>> what works for whom rather than single out one approach at this point.
>> 
>> Overall, I'm just thinking that making River play nicer with a predominant
>> monitoring standard for "Java-houses" can only be a good thing. One less
>> barrier to entry...
>> 
>> On 29 October 2012 18:21, Dennis Reedy <dennis.re...@gmail.com> wrote:
>> 
>>> Just curious, but are you planning to use the JSR 160 attributes? You
>>> would also need to start a JMX connector server for the JVM. With Rio,
>>> services that run in their own JVMs get advertised with the following:
>>> 
>>> net.jini.lookup.entry.jmx.JMXProtocolType
>>> net.jini.lookup.entry.jmx.JMXProperty
>>> 
>>> The latter has the JMX connector service URL (of course you'd need MBeans
>>> added as well). Using a standard client that discovers services that has
>>> these attributes can be used to attach jconsole (or visualvm) to the remote
>>> service(s). No custom service ui is required, you just need to discover
>>> these attributes.
>>> 
>>> HTH
>>> 
>>> Dennis
>>> 
>>> On Oct 29, 2012, at 159PM, Dan Creswell wrote:
>>> 
>>>> And a ServiceUI that could do some JMX-based prodding of a service?
>>>> 
>>>> On 29 October 2012 16:09, Gregg Wonderly <gr...@wonderly.org> wrote:
>>>> 
>>>>> I think that JMX could be used there.  The bigger issue, is that from
>>> some
>>>>> perspectives, having a JMX monitoring system already in place, makes it
>>>>> more easy to do it with JMX.  From the other perspective, having a
>>> standard
>>>>> "Management/tuning/observing" ServiceUI roll makes it possible to
>>> trivially
>>>>> integrate lots of different things into a single desktop experience.  If
>>>>> you have to solve the problem with JMX connectors "through the network",
>>>>> then Jini should be doable as well.  Internally, we could suggest that
>>> JMX
>>>>> be used, but then provide a connector which is not remote, but proxied
>>> to,
>>>>> by a standard Jini service interface.
>>>>> 
>>>>> Gregg
>>>>> 
>>>>> On Oct 29, 2012, at 3:12 AM, Dan Creswell <dan.cresw...@gmail.com>
>>> wrote:
>>>>> 
>>>>>> Sounds more like a job for JMX to me....
>>>>>> 
>>>>>> On 29 October 2012 00:06, Gregg Wonderly <gr...@wonderly.org> wrote:
>>>>>> 
>>>>>>> Well, perhaps some package private extensions could be put in place
>>>>> which
>>>>>>> could have "protected" access proxy methods which could allow you to
>>> get
>>>>>>> access?  I've always wanted to more formally and fully instrument
>>>>> discovery
>>>>>>> in particular.  I seem to always end up patching in lots of
>>>>> new/different
>>>>>>> debugging each time I end up with some odd network situation at my
>>>>>>> customers' sites.  It seems that there are almost always some firewall
>>>>>>> issues or something.  I'd like to see a serviceUI on reggie which
>>> would
>>>>>>> allow you to see all the registered notification listeners as well as
>>>>> the
>>>>>>> connections for each as well as failing notifications due to socket
>>>>> connect
>>>>>>> errors and what the related errors are for example.
>>>>>>> 
>>>>>>> Gregg Wonderly
>>>>>>> 
>>>>>>> On Oct 28, 2012, at 7:58 AM, Simon IJskes - QCG <si...@qcg.nl> wrote:
>>>>>>> 
>>>>>>>> On 27-10-12 19:08, Gregg Wonderly wrote:
>>>>>>>>> What is your motivation to ask this question?
>>>>>>>>> 
>>>>>>>>> Gregg
>>>>>>>>> 
>>>>>>>>> On Oct 24, 2012, at 7:08 AM, Simon IJskes - QCG <si...@qcg.nl>
>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Does anybody have a problem with making
>>> com.sun.jini.reggie.Registrar
>>>>>>> public?
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I wanted to build a monitor/prototype for some experimentation,
>>> around
>>>>>>> Registrar.notify(), and noticed i couldnt because of the package
>>> private
>>>>>>> access.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
> 

Reply via email to