I don't know enough about Spring's internals to really evaluate this but
here are a few questions.
The intent behind GBeans is that they are long running services - for
example, running for the lifetime of an application. Is that how Spring
would be using them or are you trying to
That's a somewhat different issue. The Tomcat mbeans are basically
completely unknown to geronimo. If we started the kernel with the
BasicGBeanRegistry rather than the JMXGBeanRegistry you'd never know
they were there.
If you wrapped the tomcat mbeans as gbeans, then you'd have a similar
On Feb 8, 2005, at 4:06 PM, Jules Gosnell wrote:
Jeff Genender wrote:
I think Jules has a point on this. What about the use of other open
source projects that manage their own private mbean lifecycles, such
as Tomcat?
and not forgetting Jetty :-), which also exposes internals to JMX in
this
David Jencks wrote:
That's a somewhat different issue. The Tomcat mbeans are basically
completely unknown to geronimo. If we started the kernel with the
BasicGBeanRegistry rather than the JMXGBeanRegistry you'd never know
they were there.
That's not to say that they are not needed though -
On Feb 8, 2005, at 1:56 PM, Jules Gosnell wrote:
Dain Sundstrom wrote:
I am definitely against this change. A fundamental assumption of the
current GBean code is it controls life-cycle,
in GBeanInstance without my patch:
the 'target' field is typed 'Object', not GBeanLifecycle.
doStart()
On Feb 8, 2005, at 4:06 PM, Jules Gosnell wrote:
Jeff Genender wrote:
I think Jules has a point on this. What about the use of other open
source projects that manage their own private mbean lifecycles, such
as Tomcat?
and not forgetting Jetty :-), which also exposes internals to JMX in
this
Jeremy Boynes wrote:
Jeff Genender wrote:
I think Jules has a point on this. What about the use of other open
source projects that manage thier own private mbean lifecycles, such
as Tomcat?
Well, the obvious question is how does that integrate with a Geronimo
kernel that is not based on JMX?
David Jencks wrote:
On Feb 8, 2005, at 4:06 PM, Jules Gosnell wrote:
Jeff Genender wrote:
I think Jules has a point on this. What about the use of other open
source projects that manage their own private mbean lifecycles, such
as Tomcat?
and not forgetting Jetty :-), which also exposes
On Wed, 09 Feb 2005 00:28:34 +, Jules Gosnell
[EMAIL PROTECTED] wrote:
David Jencks wrote:
That's a somewhat different issue. The Tomcat mbeans are basically
completely unknown to geronimo. If we started the kernel with the
BasicGBeanRegistry rather than the JMXGBeanRegistry you'd
David Jencks wrote:
I think you are confusing jmx and lifecycle management.
Jetty exposes some mbeans, but the mbean server AFAICT has nothing to
do with creating/destroying jetty components.
I never said it did - Jetty does this
In fact it looks to me as if the jetty mbeans are viewers that
On Feb 8, 2005, at 5:09 PM, Jules Gosnell wrote:
David Jencks wrote:
Fine, so how would you take an existing MBean instance and having
translated its interface into GBeanInfo/Data register it with the
kernel so that any tool attached to the kernel will see it ?
You don't. Your code can always
Jules Gosnell wrote:
fine - I now have code that can build a dynamic proxy and insert my POJO
into the kernel using that. One problem - I need cglib 2.0.2. We are
currently configured to run on 2.0 which does not have InterfaceMaker.
Should I start backporting InterfaceMaker to 2.0, or can we
Bruce Snyder wrote:
??? lost you here - are you saying rewrite Tomcat and Jetty because
they implement the standard J2EE management interface and Geronimo
doesn't ?
The statement above is absolutely correct!
No it isn't. Geronimo DOES implement the standard J2EE management
interface. It has to,
[EMAIL PROTECTED] wrote:
Author: dblevins
Date: Tue Feb 8 22:00:44 2005
New Revision: 153028
URL: http://svn.apache.org/viewcvs?view=revrev=153028
Log:
Added more required J2EE libraries
Added:
geronimo/trunk/specs/jaxrpc/
Why not use the one from Axis?
Jules Gosnell wrote:
snip for the sake of clarity on the following points/
To what extent is it necessary for Spring to register the actual POJOs
at runtime? How much can be built before hand and be packaged into a
Geronimo Configuration?
Good question I guess it comes down to the fact
Jules Gosnell wrote:
The intent behind GBeans is that they are long running services - for
example, running for the lifetime of an application. Is that how
Spring would be using them or are you trying to create/delete
instances frequently (say on each web request)?
long running services - the
Jeremy Boynes wrote:
Jules Gosnell wrote:
snip for the sake of clarity on the following points/
To what extent is it necessary for Spring to register the actual
POJOs at runtime? How much can be built before hand and be packaged
into a Geronimo Configuration?
Good question I guess it comes
Jeremy Boynes wrote:
Jules Gosnell wrote:
The intent behind GBeans is that they are long running services -
for example, running for the lifetime of an application. Is that how
Spring would be using them or are you trying to create/delete
instances frequently (say on each web request)?
long
On Tue, 08 Feb 2005 22:16:17 +, Rob Harrop [EMAIL PROTECTED] wrote:
I'm going to agree with Jules on this - adding another layer of proxies
in here is not a particularly good idea nor is it something we know will
even work. If Spring has already supplied a CGLIB proxy, then we cannot
proxy
Jeff,
why do we need to use the TomcatModuleBuilder(TMB)
in j2ee-deployer-plan.xml ? Are you actually able to
run apps on Tomcat using the current TMB?
TIA
Anita
--- Jeff Genender [EMAIL PROTECTED] wrote:
Anita,
I think this is now rectified for you.
First there was a bug in the
Jeremy,
I've been wondering whether I can do without upgrading cglib for the
whole of Geronimo, just doing it for the Spring module, since we use it
to build a standard 1.3 proxy. The problem is that this is done at
runtime, so I guess that the only version of cglib around will be the
one
Jules Gosnell wrote:
Jeremy,
I've been wondering whether I can do without upgrading cglib for the
whole of Geronimo, just doing it for the Spring module, since we use it
to build a standard 1.3 proxy. The problem is that this is done at
runtime, so I guess that the only version of cglib around
Thanks Jeremy - much appreciated
Jules
Jeremy Boynes wrote:
Jules Gosnell wrote:
Jeremy,
I've been wondering whether I can do without upgrading cglib for the
whole of Geronimo, just doing it for the Spring module, since we use
it to build a standard 1.3 proxy. The problem is that this is done at
Geir Magnusson Jr. wrote:
I just did an update, and it's not building :
[javac] Compiling 9 source files to
/Users/geir/dev/apache/geronimo/trunk/applications/magicGball/target/
classes
/Users/geir/dev/apache/geronimo/trunk/applications/magicGball/src/java/
anita kulshreshtha wrote:
Jeff,
why do we need to use the TomcatModuleBuilder(TMB)
in j2ee-deployer-plan.xml ?
Actually, I just left it in there because A) There is a Jetty Webbuilder
version in there, and also for the sake of consistency. I haven't tried
to remove it from the
After this mornings build fiasco I estimate that I personally have
spent between 5 and 10 hours dealing with the surprising behavior of
the geronimo build, i.e. don't build it all unless you remember an
obscure switch
I'l like to suggest two things:
1. The default top level build target
Fixed.
-dain
On Feb 9, 2005, at 9:38 AM, Jules Gosnell wrote:
Geir Magnusson Jr. wrote:
I just did an update, and it's not building :
[javac] Compiling 9 source files to
/Users/geir/dev/apache/geronimo/trunk/applications/magicGball/target/
classes
On Feb 9, 2005, at 1:38 PM, David Jencks wrote:
After this mornings build fiasco I estimate that I personally have
spent between 5 and 10 hours dealing with the surprising behavior of
the geronimo build, i.e. don't build it all unless you remember an
obscure switch
I'l like to suggest two
On Feb 9, 2005, at 10:38 AM, David Jencks wrote:
After this mornings build fiasco I estimate that I personally have
spent between 5 and 10 hours dealing with the surprising behavior of
the geronimo build, i.e. don't build it all unless you remember an
obscure switch
I'l like to suggest two
On Feb 9, 2005, at 3:02 PM, Dain Sundstrom wrote:
On Feb 9, 2005, at 11:59 AM, Geir Magnusson Jr wrote:
On Feb 9, 2005, at 1:38 PM, David Jencks wrote:
I'd like to volunteer some Gluecode resources
(non-Geronimo-committer!) to setup a simple CI-like system - it just
moronically does a clean
30 matches
Mail list logo
