I noticed that, thank you ;-)
I won't get into doing this for one or two weeks.
(If someone cannot wait, he can still capture the JIRA.)
Bernd
On 10/2/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I already created https://issues.apache.org/jira/browse/JAMES-645 and
assigned it to you ;-)
Th
I already created https://issues.apache.org/jira/browse/JAMES-645 and
assigned it to you ;-)
This would be really helpful trying to debug "leak" issues reported by
Noel. And the future include a lot of tools that needs DNS for their
checks lookups so this feature would be a great tool to help
> Can you layout the differences for those of us who haven't
> spent as much time looking at this as you?
Sure. But how long do you think I've been looking at it ? (rhetorical)
;)
> From what you are saying, if a monitor has a metric that
> isn't filled in by a service, it sits empty. And if
Steve Short wrote:
> > I thought, from Chapter 8 of the JMX (JSR 77) specification
> > that SNMP is supported directly by JMX.
> There's a difference between JMX and JSR 77. JMX is the basic
> management API and is covered by JSR 3.
> JSR 77 is for management of the J2EE platform. It does includ
Noel,
> I thought, from Chapter 8 of the JMX (JSR 77) specification
> that SNMP is supported directly by JMX.
There's a difference between JMX and JSR 77. JMX is the basic
management API and is covered by JSR 3. It does not include any remote
access capability at all, it does allow for remote a
Steve,
I don't know JMX well enough yet, but your proposal seems good. The only
thing I would like for you to clarify comes from:
> Eventually we could provide several implementations of the
> service one for JMX, one for SNMP.
I thought, from Chapter 8 of the JMX (JSR 77) specification that SN
on and
> reporting would alleviate this somewhat. There's also the
> issue of how and when to create group entries such as
> "Protocols" that don't have a direct implementation point in
> James - this could be done automatically at register() time
>
- Original Message -
From: Steve Short <[EMAIL PROTECTED]>
Sent: Dec 5, 9:26 AM
>
> The only decent usable LGPL one I've found is Joesnmp, which is
> currently part of the Opennms project but is in the process of becoming
> an independent project at Sourceforge.
A previous company I wo
Steve Short wrote:
As far as JMX is concerned the root kernel is already MBean
enabled and is an active event generator (reflecting changes
to kernel state).
What still needs to be done is the exposure (via the kernel)
of the subsidiary applicance mbeans - but more internal event
structure
Alex Karasulu wrote:
Yes this is the next critical step. I think everyone at
Avalon would be in favor of this since it has surprisingly
become the basis for IoC in the J2EE container world.
Yes, I'm all for it as Noel says! Once the repo release is
complete is suspect this is the next priorit
Noel J. Bergman wrote:
Stephen J. McConnell wrote:
Right now I'm in the process of pulling together the next release of
Merlin. The main *feature* of the new release will be a much cleaning
embedding strategy based on a bunch of improvements from Alex (Apache
Directory Project).
If
> > My suggestion would be to use JNDI for this purpose, and to have a JNDI
> > context containing the metrics.
> I would have thought you would have used something like
> javax.management.NotificationBroadcasterSupport
The J2EE Management Specification (aka JSR 77) uses events for management.
Bu
o you say Steve?
Alex
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 05, 2003 1:53 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; James Developers List
> Subject: RE: Monitoring
>
> Stephen J. McConnell wrote
> As far as JMX is concerned the root kernel is already MBean
> enabled and is an active event generator (reflecting changes
> to kernel state).
> What still needs to be done is the exposure (via the kernel)
> of the subsidiary applicance mbeans - but more internal event
> structure is needed
Stephen J. McConnell wrote:
> Right now I'm in the process of pulling together the next release of
> Merlin. The main *feature* of the new release will be a much cleaning
> embedding strategy based on a bunch of improvements from Alex (Apache
> Directory Project).
> If you or other have thoughts
> Sent: Friday, December 05, 2003 10:13 AM
> To: James Developers List
> Subject: RE: Monitoring
>
>
> > The Monitor service would be exposed via JMX (automatically
> thanks to
> > Phoenix and hopefully Merlin).
>
> > The monitor service configuration would
Noel J. Bergman wrote:
The Monitor service would be exposed via JMX (automatically
thanks to Phoenix and hopefully Merlin).
The monitor service configuration would allow declaration of
groups and act as a factory for other components that wish
to be monitored.
My suggestion would be
Steve Short wrote:
I can do it using JMX calls but if Stephen
McConnell is reading - please treat this as a feature request for
Merlin's JMX implemtation.
I'm reading ;-)
Right now I'm in the process of pulling together the next release of
Merlin. The main *feature* of the new release will be
> The Monitor service would be exposed via JMX (automatically
> thanks to Phoenix and hopefully Merlin).
> The monitor service configuration would allow declaration of
> groups and act as a factory for other components that wish
> to be monitored.
My suggestion would be to use JNDI for this purpo
Firstly to answer Serge's question: I've looked around for Java SNMP
libraries and the most fully developed ones are commercial (obviously)
or GPL. The only decent usable LGPL one I've found is Joesnmp, which is
currently part of the Opennms project but is in the process of becoming
an independe
Steve Short wrote:
I've been taking a look at what it would take to add some monitoring to
James.
I'm very interested in SNMP w/Java in general, but not particularly
James. Do you have a library in mind to use it? I remember finding one
or two poorly-maintained projects, and I think LGPL as wel
> I've been taking a look at what it would take to add some monitoring to
> James.
> So does it seem to the members of this list like a good idea to base
> James monitoring on these basic structures?
Without doing more than scanning the rfc it looks like a good idea.
Perhaps you could save
James does have rudimentary JMX support at the moment, thanks to Avalon.
What James really needs is instrumentation points (or whatever) in the
code so whatever monitoring framework we use we can get useful data out.
However I think the implementing some of the RFC 2789 structures would
be a good i
23 matches
Mail list logo
