--- Jeff Genender [EMAIL PROTECTED] wrote:
Anita Kulshreshtha wrote:
I see Monitoring Console as a tool, a standard J2EE
Application,
that has been packaged for a convenient installation in Geronimo.
It
talks to a geronimo specific agent to discover and monitor a
geronimo
On Dec 10, 2007, at 7:18 AM, Jeff Genender wrote:
Anita Kulshreshtha wrote:
I see Monitoring Console as a tool, a standard J2EE Application,
that has been packaged for a convenient installation in Geronimo. It
talks to a geronimo specific agent to discover and monitor a geronimo
--- Matt Hogstrom [EMAIL PROTECTED] wrote:
On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:
2. If yes, then where should we move it to? Should it be in
server/
trunk/plugins or should the monitoring plugin be a subproject.
I was thinking of plugins..
I'm not sure it
I'm with Matt on this. Since it is not perfect to everybody's
satisfaction, let us move it to the /plugins tree (at least for now).
Sandbox is definitely not the place for it.
Erik, contrary to your belief, the /plugins tree does not contain only
those plugins that work independent of G. It
On Dec 10, 2007, at 8:25 AM, Anita Kulshreshtha wrote:
I see Monitoring Console as a tool, a standard J2EE Application,
that has been packaged for a convenient installation in Geronimo. It
talks to a geronimo specific agent to discover and monitor a geronimo
instance running elsewhere. I
Matt Hogstrom wrote:
I think the correct decision would be what do
the users want in terms of it being an integral part of what they do
they would prefer to not go and install it but have it as part of the
base install. I'd be ok with either approach. Most AppServers that I
know of do
Anita Kulshreshtha wrote:
I see Monitoring Console as a tool, a standard J2EE Application,
that has been packaged for a convenient installation in Geronimo. It
talks to a geronimo specific agent to discover and monitor a geronimo
instance running elsewhere. I do not see it as an
On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:
--- Kevan Miller [EMAIL PROTECTED] wrote:
On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:
--- Viet Nguyen [EMAIL PROTECTED] wrote:
On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
Eric,
--- Kevan Miller [EMAIL PROTECTED] wrote:
On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:
--- Viet Nguyen [EMAIL PROTECTED] wrote:
On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
Eric,
.
Perhaps I
We definitely need such an adapter interface. This will allow us to
not corrupt the target instance, e.g. a minimal server, by installing
openejb.
Thanks
Anita
--- Jeff Genender [EMAIL PROTECTED] wrote:
So I think we are kind of caught in a catch 22 here...
The issue is, the server is
On Dec 6, 2007, at 12:45 PM, Viet Nguyen wrote:
There are goods and bads to both sides to this. If we strictly follow
JSR 77, which means we will use MEJB and are forced to have OpenEJB as
a pre-req, we won't have to worry if our architecture is good or not
(I hope this is right), because
On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:
2. If yes, then where should we move it to? Should it be in server/
trunk/plugins or should the monitoring plugin be a subproject.
I was thinking of plugins..
I'm not sure it really matters where the code goes in the interim.
Kevan Miller wrote:
OK. That's good information. But, IMO, that doesn't necessarily mean
we shouldn't move the monitoring plugin out of sandbox. It might mean
that we aren't ready to *release* the monitoring plugin. I don't think
we're having a *release* discussion -- at least we shouldn't
On Dec 6, 2007 5:43 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
Don't I get 24 hours to respond :)
Yes, you *did* ;-) It passed.
Seriously, I'm in favor releasing what we've got so far as that's the
best way to get people (end users and us) engaged in the development
process of the
--- Viet Nguyen [EMAIL PROTECTED] wrote:
On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
Eric,
For this discussion I will use MC for monitoring console (aka
client), and agent for mrc-server. It is possible to use 3 G
instances
(I used this method until
I am still unsure of why having the monitoring plugin in trunk is such
a bad thing. It is in no way a perfect solution, but once it's in
trunk we can engage users and other devs to better it. I do not see
any dominating issues that should keep this plugin outside of trunk.
Should we vote for this?
On Dec 5, 2007, at 11:43 PM, Anita Kulshreshtha wrote:
Anita, can you please technically show why this is not ready or
should
not be released? Can you explain/show where the graphs are wrong?
This
may help move things along.
Jeff
Don't I get 24 hours to respond :)
We've got lot's of
On Dec 6, 2007, at 12:01 PM, Viet Nguyen wrote:
I am still unsure of why having the monitoring plugin in trunk is such
a bad thing. It is in no way a perfect solution, but once it's in
trunk we can engage users and other devs to better it. I do not see
any dominating issues that should keep
On Dec 6, 2007, at 1:27 AM, Viet Nguyen wrote:
On Dec 5, 2007 9:23 PM, Kevan Miller [EMAIL PROTECTED] wrote:
On Dec 5, 2007, at 9:07 PM, David Jencks wrote:
On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
Viet,
Thanks for working on the monitoring console. A lot still remains
to
Yes, with the current implementation we have, OpenEJB is a
prerequisite. JMX is a good solution too, but I wanted to follow the
JSR 77 spec, which tells us to communicate with the server through the
usage of MEJB, which is why OpenEJB is needed in this case.
--Viet
Isn't the JSR 77 spec JMX based?
Jeff
Viet Nguyen wrote:
Yes, with the current implementation we have, OpenEJB is a
prerequisite. JMX is a good solution too, but I wanted to follow the
JSR 77 spec, which tells us to communicate with the server through the
usage of MEJB, which is why OpenEJB
Never mind...yes looks like MEJB is a requirement.
Jeff
Jeff Genender wrote:
Isn't the JSR 77 spec JMX based?
Jeff
Viet Nguyen wrote:
Yes, with the current implementation we have, OpenEJB is a
prerequisite. JMX is a good solution too, but I wanted to follow the
JSR 77 spec, which tells
So I think we are kind of caught in a catch 22 here...
The issue is, the server is pluggable for the most part. People may/may
not want EJB, but definitely want the management capabilities.
Whats your thought on an adapter interface that provides for full JSR-77
compatibility, thus requiring
On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:
--- Viet Nguyen [EMAIL PROTECTED] wrote:
On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED]
wrote:
Eric,
For this discussion I will use MC for monitoring console (aka
client), and agent for mrc-server. It is possible to use
Whats your thought on an adapter interface that provides for full JSR-77
compatibility, thus requiring EJB, or a switch that allows for pure JMX
remoting? This would allow for compliance or be able to leverage the
management without EJB if so desired.
Thoughts?
There are goods and bads to
I certainly believe it deserves a spot in trunk...this is an enhancement
to what we don't have before. That's progress...and its pretty darn
cool too ;-)
I definitely don't want my ideas to hold up its movement...just food for
thought for down the road.
Jeff
Viet Nguyen wrote:
Whats your
On Dec 6, 2007, at 10:06 AM, Paul McMahan wrote:
On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote:
1. Are we ready to move monitoring plugin out of sandbox?
+1
2. If yes, then where should we move it to? Should it be in server/
trunk/plugins or should the monitoring plugin be a
On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote:
1. Are we ready to move monitoring plugin out of sandbox?
+1
2. If yes, then where should we move it to? Should it be in server/
trunk/plugins or should the monitoring plugin be a subproject.
I would vote for server/trunk/plugins, if for no
Hi All,
There has been a lot of work done on the monitoring plugin lately. I
think it is now time to move it from sandbox into trunk, in time for
the 2.1 release. I am unsure
of the timeline for 2.1, but I feel as though the monitoring plugin
should be moved to trunk around this time, so that the
+1
Jacek
On Dec 5, 2007 10:36 PM, Viet Nguyen [EMAIL PROTECTED] wrote:
Hi All,
There has been a lot of work done on the monitoring plugin lately. I
think it is now time to move it from sandbox into trunk, in time for
the 2.1 release. I am unsure
of the timeline for 2.1, but I feel as
+1
I am definitely in favor of this, and would also like to see this make
it to trunk before the 2.1 branch occurs.
It would be great if we could get a few extra pairs of eyes to take a
look at things and make sure it's all peachy.
Thanks,
Erik B. Craig
[EMAIL PROTECTED]
Viet Nguyen wrote:
Anita,
You mentioned that the collecting agent running within the same jvm
(I.E. under a Geronimo instance being monitored as a plugin) is an
issue due to resource consumption... however I am unsure what a good
alternative approach would be? Are you suggesting we have a separate
instance
Viet,
Thanks for working on the monitoring console. A lot still remains to
be done. There are architectural issues which need to be addressed:
Currently the agent (aka mrc-server) needs to reside in same jvm as
the server being monitored. It consumes significant DB resources.
The
On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
Viet,
Thanks for working on the monitoring console. A lot still
remains to
be done. There are architectural issues which need to be addressed:
Currently the agent (aka mrc-server) needs to reside in same
jvm as
the server being
David Jencks wrote:
On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
Viet,
Thanks for working on the monitoring console. A lot still remains to
be done. There are architectural issues which need to be addressed:
Currently the agent (aka mrc-server) needs to reside in same
On Dec 5, 2007, at 9:07 PM, David Jencks wrote:
On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
Viet,
Thanks for working on the monitoring console. A lot still remains
to
be done. There are architectural issues which need to be addressed:
Currently the agent (aka mrc-server)
Eric,
For this discussion I will use MC for monitoring console (aka
client), and agent for mrc-server. It is possible to use 3 G instances
(I used this method until GERONIMO-3660). G1 with MC on remote or local
m/c, G2 with agent on local m/c, and G3 the instance to be monitored.
This is the
Anita, can you please technically show why this is not ready or
should
not be released? Can you explain/show where the graphs are wrong?
This
may help move things along.
Jeff
Don't I get 24 hours to respond :)
Thanks
Anita
On Dec 5, 2007 9:23 PM, Kevan Miller [EMAIL PROTECTED] wrote:
On Dec 5, 2007, at 9:07 PM, David Jencks wrote:
On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
Viet,
Thanks for working on the monitoring console. A lot still remains
to
be done. There are architectural issues
On Dec 5, 2007 11:36 PM, Anita Kulshreshtha [EMAIL PROTECTED] wrote:
Eric,
For this discussion I will use MC for monitoring console (aka
client), and agent for mrc-server. It is possible to use 3 G instances
(I used this method until GERONIMO-3660). G1 with MC on remote or local
m/c, G2
40 matches
Mail list logo
