river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: com.sun.jini.reggie.Registrar
Date Mon, 29 Oct 2012 18:33:41 GMT
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.reedy@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 <gregg@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.creswell@gmail.com>
> wrote:
> >>
> >>> Sounds more like a job for JMX to me....
> >>>
> >>> On 29 October 2012 00:06, Gregg Wonderly <gregg@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 <simon@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 <simon@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.
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message