You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Pasi Salminen <pa...@profitsoftware.com> on 2003/08/12 12:47:14 UTC
Re: [services] getting service developers started - the initial
component model
Hi,
All that sounds reasonable and I fully agree with you. However, as the
project is still in early stages I'd like to emphasize the fact that J2EE
developers may want to deploy their own MBeans (doing things like flushing
a cache) also at runtime. This possibility is without doubt been forgetten
while WebLogic Server was coded. Even BEA WLS developers cannot supply one
with any reasonable ways to deploy your own standard MBeans which do not
have anything to do with WLS itself. And even if you can do it registering
those beans is next to impossible. You have to supply administrative user
and its password to WLS before you can register your own beans (due to
security issues). WebSphere handles this in much nicer way. One can embed
was.policy file into your application and the policy file contains grants
to do things. I know this is kind of future (and partly even security)
issue but I feel it's so important that I wanted speak it out now. It's
been a major show-stopper for deploying our own MBeans with application
servers and I've been doing tons of work due to this in order to make it
reasonable to deploy the same MBeans (part of our framework) to WLS and
WebSphere.
Another thing which is really annoying in app servers is the fact that you
can't ask the name of the current J2EE application. That would help a lot
while creating a unique ObjectName for MBean which is instantiated and
registered at runtime (for example when the cache instance is registered by
the CacheManager or the bean itself). I just wonder why there's no API to
ask the name of the application in J2EE.?!?! I know that it's not J2EE
specified thing but it would be nice to be able to ask it without tons of
code (as I had to do in WebSphere).
Regards,
Paci
jastrachan@mac.com wrote:
> I'm sure we could all debate the perfect container framework and
> compare and contrast the intricacies of the various flavours of Avalon
> containers, PicoContainer, JMX & Java Beans until the cows come home.
> However what is really important right now is we start writing
> lightweight, pluggable services ASAP to start filling in the J2EE stack
> for Geronimo.
>
> Up to now the Geronimo codebase has assumed a JMX micro kernel,
> following in the footsteps of JBoss, Tomcat 5 and Jetty. I'm sure this
> can be improved with time though this strategy has been proved to work.
> Before we get bogged down in months of upfront design for what the
> perfect container should be - I'd like us to be able to make good
> progress integrating the various services - of which there are many.
> Then we have some real use cases that can help us as we refactor the
> Geronimo container.
>
> What I'd like to do as an initial step is choose a default component
> model for service developers to follow as they write Geronimo services.
> For some time most of the main services in Geronimo are going to be
> fairly course grained (web container, Axis, JMS provider, JTA etc). In
> addition at the time of writing Geronimo can deploy MBeans.
>
> So initially I think the component model should be JMX MBeans. These
> are simple, lightweight components that have no compile time
> dependencies on anything. The MBeans themselves should follow the
> Inversion of Control pattern - i.e. the container instantiates &
> configures the MBean. In addition we should try follow the MBean
> interface pattern such that we can do efficient interception easily
> with dynamic proxies - also note that MBeans do not need to use JMX at
> all - any container mechanism can be used to configure & wire together
> the components.
>
> Already today Geronimo can handle MBeans. It must always be able to
> handle MBeans. Indeed whatever Geronimo's container framework becomes
> it should be easily cable of working with the plethora of J2EE MBeans
> that are out there. (MBeans are essential to J2EE).
>
> So in summary
>
> * lets start writing J2EE services as MBeans that we can plug into
> Geronimo today.
>
> * in parallel to this activity folks can help improve & innovate inside
> the Geronimo kernel - without adversely affecting the progress of the
> component authors - we can all work in parallel
>
> * those Avalon fans could package up one or more Avalon containers as
> MBeans then any Avalon components could be easily deployed inside an
> actual Avalon container inside Geronimo. Ditto for PicoContainer too.
> i.e. this strategy allows for a diversity of containers to be deployed.
>
> * once all the required deployment options are available (EAR, WAR,
> SAR) and the ClassLoader stuff is working along with the interceptor
> stack; folks can then refactor the container using some real J2EE
> services to improve the manageability & codebase - based on real
> refactoring of working code rather than too much up front design.
> Indeed we can take a TDD approach to refactoring the container. So
> rather than guessing what a J2EE container should look now, we can
> refactor as we get there to improve it.
>
> * we should make great progress, getting J2EE coverage fairly soon -
> yet we won't really be tied to JMX at all - the MBeans could be used in
> any container implementation.
>
> * if in the future we come up with some other component model to be
> supported, it should be trivially easy to plugin MBeans anyway, or a
> simple refactor to support them
>
> Thoughts?
>
> James
> -------
> http://radio.weblogs.com/0112098/
__________________________________________________________________________
This message and its attachments have been found clean from known viruses
with three different antivirus programs.
__________________________________________________________________________
RE: [services] getting service developers started - the initial component model
Posted by James deGraft-Johnson <jd...@digaman.com>.
I agree in principle, though I don't see how if the kernel framework is
based on MBeans, it will be easier to support MBeans created by J2EE
application developers.
Anyway, an approach to the kernel framework loosely based on MBeans has been
outlined in another thread, so I think we can worry about supporting JSR077
during design of the appropriate service.
James deGraft-Johnson
Software Engineer - IT
Verizon Information Services
Tel: (240) 456-7018
Fax: (240) 456-7072
Mobile: (240) 475-1444 <jd...@verizon-uc.com>
-----Original Message-----
From: Jan Bartel [mailto:janb@mortbay.com]
Sent: Tuesday, August 12, 2003 8:33 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: [services] getting service developers started - the initial
component model
I would have thought that we'd want to support JSR077 management for
J2EE from the outset. JSR077 describes lifecycles, events and
performance statistics for all J2EE components (everthing from ejbs,
datasources, jca through to web containers and servlets) that can be
modelled by mbeans.
It would be by far the simplest if geronimo's services were directly
based JSR077 mbeans, because:
1. we need to support JSR077 anyway
2. the simplest way to support it is directly, without extra layers of
adaption code
3. there's nothing in the service lifecycle that cannot be encompassed
by JSR077 mbeans
Jan
Alex Blewitt wrote:
>> My understanding of the JMX/MBeans idea from SUN is so that it is
>> possible
>> to create MBeans (Management Beans) as part of a J2EE application to
>> support
>> administration, management and monitoring of the J2EE application.
>> This is a
>> very powerful idea, which ideally will be supported by Geronimo.
>
>
> Absolutely. I have always been for there being a JMX /interface/ to
> Geronimo, but not as an /implementation/ of the kernel.
>
>> The use of a JMX/MBeans model for Kernel framework shouldn't
>> jeopardize the
>> above. In fact I assumed that the discussion of the MBeans as a service
>> component model was actually MBeans-like, i.e. basing the component
>> model on
>> the MBeans design. (We can structure the Geronimo kernel like JMX without
>> actually making the kernel a JMX implementation, so as to incorporate
>> into
>> the kernel the ability for J2EE application developers to create and
>> install
>> actual MBeans.) Because of the above, this is what makes sense for this
>> approach.
>
>
> I think there should be a distinction between the kernel and a JMX/MBean
> container -- they're not necessarily the same. Granted, that it may be
> desirable for MBeans to be incorporated in at a later stage, but by
> starting off with the doctrine 'everything is an MBean' then it's very
> difficult to be innovative and come up with ideas outside of the JMX spec.
>
> For example:
>
> public abstract Service {
> public abstract String getName();
> public abstract void start();
> public abstract void stop();
> public MBean getMBeanInterface() {
> return new ServiceMBeanInterfaceAdapter(this);
> }
> }
>
> public ServiceMBean implements GenericMBean {
> private Service instance;
> public ServiceMBean(Service instance) {
> this.instance = instance;
> }
> public void start() { instance.start(); }
> public void stop() { instance.stop(); }
> }
>
> That way, you can create subcomponents of Service that are entirely
> independent of JMX, whilst still providing a JMX interface to the same.
> Indeed, subclasses can provide their own specific JMXBean
> implementations if the default is not desirable.
>
> Additionally, if there is a move from using MBeans to another component
> architecture, then this will allow the same representation to be used.
>
> Alex.
Re: [services] getting service developers started - the initial
component model
Posted by Jan Bartel <ja...@mortbay.com>.
I would have thought that we'd want to support JSR077 management for
J2EE from the outset. JSR077 describes lifecycles, events and
performance statistics for all J2EE components (everthing from ejbs,
datasources, jca through to web containers and servlets) that can be
modelled by mbeans.
It would be by far the simplest if geronimo's services were directly
based JSR077 mbeans, because:
1. we need to support JSR077 anyway
2. the simplest way to support it is directly, without extra layers of
adaption code
3. there's nothing in the service lifecycle that cannot be encompassed
by JSR077 mbeans
Jan
Alex Blewitt wrote:
>> My understanding of the JMX/MBeans idea from SUN is so that it is
>> possible
>> to create MBeans (Management Beans) as part of a J2EE application to
>> support
>> administration, management and monitoring of the J2EE application.
>> This is a
>> very powerful idea, which ideally will be supported by Geronimo.
>
>
> Absolutely. I have always been for there being a JMX /interface/ to
> Geronimo, but not as an /implementation/ of the kernel.
>
>> The use of a JMX/MBeans model for Kernel framework shouldn't
>> jeopardize the
>> above. In fact I assumed that the discussion of the MBeans as a service
>> component model was actually MBeans-like, i.e. basing the component
>> model on
>> the MBeans design. (We can structure the Geronimo kernel like JMX without
>> actually making the kernel a JMX implementation, so as to incorporate
>> into
>> the kernel the ability for J2EE application developers to create and
>> install
>> actual MBeans.) Because of the above, this is what makes sense for this
>> approach.
>
>
> I think there should be a distinction between the kernel and a JMX/MBean
> container -- they're not necessarily the same. Granted, that it may be
> desirable for MBeans to be incorporated in at a later stage, but by
> starting off with the doctrine 'everything is an MBean' then it's very
> difficult to be innovative and come up with ideas outside of the JMX spec.
>
> For example:
>
> public abstract Service {
> public abstract String getName();
> public abstract void start();
> public abstract void stop();
> public MBean getMBeanInterface() {
> return new ServiceMBeanInterfaceAdapter(this);
> }
> }
>
> public ServiceMBean implements GenericMBean {
> private Service instance;
> public ServiceMBean(Service instance) {
> this.instance = instance;
> }
> public void start() { instance.start(); }
> public void stop() { instance.stop(); }
> }
>
> That way, you can create subcomponents of Service that are entirely
> independent of JMX, whilst still providing a JMX interface to the same.
> Indeed, subclasses can provide their own specific JMXBean
> implementations if the default is not desirable.
>
> Additionally, if there is a move from using MBeans to another component
> architecture, then this will allow the same representation to be used.
>
> Alex.
Re: [services] getting service developers started - the initial component model
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 12, 2003, at 12:51 pm, James deGraft-Johnson wrote:
> I agree with this.
>
> By structuring the kernel architecture like JMX/MBeans we will
> simplify the
> design task, have less changes (refactoring) to make to existing
> kernel,
> which is based on JMX/MBeans. However it is important not to tie the
> design
> tightly to JMX/MBeans, (or implement the kernel strictly as
> JMX/MBeans) as
> pointed out). Note that JMX/MBeans is meant to be a feature (management
> extension) of the J2EE container not an architecture for design of the
> J2EE
> kernel. By not tightly coupling kernel architecture to JMX/MBeans we
> can
> incorporate design ideas from outside JMX/MBeans and also allow the
> component to be changed later.
Agreed.
we have
components <-> container <-> JMX
The container in the middle could be based on JMX or could be based on
some other model and just adapt to JMX. But thats the containers job to
figure that out.
For all the services & component developers we should adopt the
standard MBean programming model as the first convention for
developers. In the future we may have other options for component
authors to follow (e.g. Pico components or Avalon components etc).
However for now following the MBean convention is a no brainer since
its already being used & supported.
If developers of a service wish to use some new wizzy abstraction API
or to write Pico components or to use some Avalon container or whatever
- then we can just deploy the container inside Geronimo via MBeans. So
we could have..
avalon component -> avalon container -> avalon MBean -> geronimo -> JMX
James
-------
http://radio.weblogs.com/0112098/
RE: [services] getting service developers started - the initial component model
Posted by James deGraft-Johnson <jd...@digaman.com>.
I agree with this.
By structuring the kernel architecture like JMX/MBeans we will simplify the
design task, have less changes (refactoring) to make to existing kernel,
which is based on JMX/MBeans. However it is important not to tie the design
tightly to JMX/MBeans, (or implement the kernel strictly as JMX/MBeans) as
pointed out). Note that JMX/MBeans is meant to be a feature (management
extension) of the J2EE container not an architecture for design of the J2EE
kernel. By not tightly coupling kernel architecture to JMX/MBeans we can
incorporate design ideas from outside JMX/MBeans and also allow the
component to be changed later.
James deGraft-Johnson
Software Engineer - IT
Verizon Information Services
Tel: (240) 456-7018
Fax: (240) 456-7072
Mobile: (240) 475-1444 <jd...@verizon-uc.com>
-----Original Message-----
From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
Sent: Tuesday, August 12, 2003 7:35 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: [services] getting service developers started - the initial
component model
> My understanding of the JMX/MBeans idea from SUN is so that it is
> possible
> to create MBeans (Management Beans) as part of a J2EE application to
> support
> administration, management and monitoring of the J2EE application.
> This is a
> very powerful idea, which ideally will be supported by Geronimo.
Absolutely. I have always been for there being a JMX /interface/ to
Geronimo, but not as an /implementation/ of the kernel.
> The use of a JMX/MBeans model for Kernel framework shouldn't
> jeopardize the
> above. In fact I assumed that the discussion of the MBeans as a service
> component model was actually MBeans-like, i.e. basing the component
> model on
> the MBeans design. (We can structure the Geronimo kernel like JMX
> without
> actually making the kernel a JMX implementation, so as to incorporate
> into
> the kernel the ability for J2EE application developers to create and
> install
> actual MBeans.) Because of the above, this is what makes sense for this
> approach.
I think there should be a distinction between the kernel and a
JMX/MBean container -- they're not necessarily the same. Granted, that
it may be desirable for MBeans to be incorporated in at a later stage,
but by starting off with the doctrine 'everything is an MBean' then
it's very difficult to be innovative and come up with ideas outside of
the JMX spec.
For example:
public abstract Service {
public abstract String getName();
public abstract void start();
public abstract void stop();
public MBean getMBeanInterface() {
return new ServiceMBeanInterfaceAdapter(this);
}
}
public ServiceMBean implements GenericMBean {
private Service instance;
public ServiceMBean(Service instance) {
this.instance = instance;
}
public void start() { instance.start(); }
public void stop() { instance.stop(); }
}
That way, you can create subcomponents of Service that are entirely
independent of JMX, whilst still providing a JMX interface to the same.
Indeed, subclasses can provide their own specific JMXBean
implementations if the default is not desirable.
Additionally, if there is a move from using MBeans to another component
architecture, then this will allow the same representation to be used.
Alex.
Re: [services] getting service developers started - the initial component model
Posted by Alex Blewitt <Al...@ioshq.com>.
> My understanding of the JMX/MBeans idea from SUN is so that it is
> possible
> to create MBeans (Management Beans) as part of a J2EE application to
> support
> administration, management and monitoring of the J2EE application.
> This is a
> very powerful idea, which ideally will be supported by Geronimo.
Absolutely. I have always been for there being a JMX /interface/ to
Geronimo, but not as an /implementation/ of the kernel.
> The use of a JMX/MBeans model for Kernel framework shouldn't
> jeopardize the
> above. In fact I assumed that the discussion of the MBeans as a service
> component model was actually MBeans-like, i.e. basing the component
> model on
> the MBeans design. (We can structure the Geronimo kernel like JMX
> without
> actually making the kernel a JMX implementation, so as to incorporate
> into
> the kernel the ability for J2EE application developers to create and
> install
> actual MBeans.) Because of the above, this is what makes sense for this
> approach.
I think there should be a distinction between the kernel and a
JMX/MBean container -- they're not necessarily the same. Granted, that
it may be desirable for MBeans to be incorporated in at a later stage,
but by starting off with the doctrine 'everything is an MBean' then
it's very difficult to be innovative and come up with ideas outside of
the JMX spec.
For example:
public abstract Service {
public abstract String getName();
public abstract void start();
public abstract void stop();
public MBean getMBeanInterface() {
return new ServiceMBeanInterfaceAdapter(this);
}
}
public ServiceMBean implements GenericMBean {
private Service instance;
public ServiceMBean(Service instance) {
this.instance = instance;
}
public void start() { instance.start(); }
public void stop() { instance.stop(); }
}
That way, you can create subcomponents of Service that are entirely
independent of JMX, whilst still providing a JMX interface to the same.
Indeed, subclasses can provide their own specific JMXBean
implementations if the default is not desirable.
Additionally, if there is a move from using MBeans to another component
architecture, then this will allow the same representation to be used.
Alex.
RE: [services] getting service developers started - the initial component model
Posted by James deGraft-Johnson <jd...@digaman.com>.
My understanding of the JMX/MBeans idea from SUN is so that it is possible
to create MBeans (Management Beans) as part of a J2EE application to support
administration, management and monitoring of the J2EE application. This is a
very powerful idea, which ideally will be supported by Geronimo.
The use of a JMX/MBeans model for Kernel framework shouldn't jeopardize the
above. In fact I assumed that the discussion of the MBeans as a service
component model was actually MBeans-like, i.e. basing the component model on
the MBeans design. (We can structure the Geronimo kernel like JMX without
actually making the kernel a JMX implementation, so as to incorporate into
the kernel the ability for J2EE application developers to create and install
actual MBeans.) Because of the above, this is what makes sense for this
approach.
James deGraft-Johnson
Software Engineer - IT
Verizon Information Services
Tel: (240) 456-7018
Fax: (240) 456-7072
Mobile: (240) 475-1444 <jd...@verizon-uc.com>
-----Original Message-----
From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
Sent: Tuesday, August 12, 2003 6:57 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: [services] getting service developers started - the initial
component model
> All that sounds reasonable and I fully agree with you. However, as the
> project is still in early stages I'd like to emphasize the fact that
> J2EE
> developers may want to deploy their own MBeans (doing things like
> flushing
> a cache) also at runtime. This possibility is without doubt been
> forgetten
> while WebLogic Server was coded. Even BEA WLS developers cannot supply
> one
> with any reasonable ways to deploy your own standard MBeans which do
> not
> have anything to do with WLS itself.
AFAIK the J2EE spec doesn't say anything about being able to put your
own MBean into a server. However, an MBean container for just this
purpose sounds like an excellent idea.
Note that I don't believe the server itself needs to be an MBean
container (in much the same way that the whole isn't a web container or
ejb container) but it seems reasonable to assume that at some future
point the J2EE spec may create the concept of an MBean container.
> Alex.
Re: [services] getting service developers started - the initial
component model
Posted by Pasi Salminen <pa...@profitsoftware.com>.
We have a framework built on top of J2EE services where we are coding application
level services like this:
public interface PropertyService
{
public String getProperty( String propertyName,String defaultValue );
}
public class PropertyServiceImpl
extends AbstractService
implements PropertyService
{
public String getProperty( ... ) { }
}
and the lookup is then like this:
PropertyService ps = ( PropertyService ) Services.getService(
PropertyService.class.getName( ) );
which means that the interface is used to lookup the implementation. Here's the XML
configuration (which is used to configure Services class)
<services>
<service id="com.profitsoftware.appfw.propertyservice.PropertyService">
<class-name>com.profitsoftware.appfw.propertyservice.PropertyServiceImpl</class-name>
</service>
...
</services>
So, if somebody wants to replace service implementation (which is used through the
framework by other components), they just change the implementation class in the
XML configuration file. Works nicely. Here nobody is managing other components but
they are using each other by looking up the service and using it through a well
defined interface.
Regards,
Paci
Berin Loritsch wrote:
> Jeremy Boynes wrote:
>
> >>The danger with using too much JMX is that when components start
> >>talking to each other using JMX, then it's very difficult to undo at a
> >>later stage.
> >>
> >
> >
> > Difference between components managing each other (for which JMX may be
> > good), and invoking each other (for which an alternative may be better).
> >
> > We need to keep this difference in mind.
> >
> > We also need to be careful about coupling of implementations and making sure
> > we keep invocations detached (to allow for redeployment). JMX enforces this,
> > any other framework needs to support it as well.
>
> Coding to interfaces does a good job of managing these things. As long as
> your code *never* does a cast to the interface like this:
>
> ((MyImpl)service).doSomethingNotInInterface();
>
> That is REALLY BAD. You will never be able to have loose coupling, or insert
> interceptors properly with that approach. When the interface covers the entire
> contract, components can use each other and even be completely replaced with
> something new and still function.
>
> The MAJOR RED FLAG I saw is the notion of components _managing_ each other.
> It is the Container's job to manage components. Period. No component should
> manage another component unless it in turn is a container for the managed
> component. For example:
>
> BAD
> ---
>
> +--------------+
> ..| Container |..
> . +------+-------+ .
> . | .
> v +------+-------+ v
> +----+---+ +--------+
> | Comp 1 |.....>| Comp 2 |
> +--------+ +--------+
>
> (the dotted line is management)
>
> GOOD/ACCEPTIBLE
> ---------------
>
> +--------------+
> | Container |
> +------+-------+
> . |
> . +----+---+
> .>| Comp 1 |..
> +----+---+ .
> | .
> +----+---+ .
> | Comp 2 |<.
> +--------+
>
> In other words, a heirarchy of components is much easier to work with, develop,
> and debug than any component usurping the container's job and cause
> unpredictable results. Not to mention it complicates the security mechanisms
> much more than necessary.
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
__________________________________________________________________________
This message and its attachments have been found clean from known viruses
with three different antivirus programs.
__________________________________________________________________________
Re: [services] getting service developers started - the initial
component model
Posted by Berin Loritsch <bl...@apache.org>.
Jeremy Boynes wrote:
>>The danger with using too much JMX is that when components start
>>talking to each other using JMX, then it's very difficult to undo at a
>>later stage.
>>
>
>
> Difference between components managing each other (for which JMX may be
> good), and invoking each other (for which an alternative may be better).
>
> We need to keep this difference in mind.
>
> We also need to be careful about coupling of implementations and making sure
> we keep invocations detached (to allow for redeployment). JMX enforces this,
> any other framework needs to support it as well.
Coding to interfaces does a good job of managing these things. As long as
your code *never* does a cast to the interface like this:
((MyImpl)service).doSomethingNotInInterface();
That is REALLY BAD. You will never be able to have loose coupling, or insert
interceptors properly with that approach. When the interface covers the entire
contract, components can use each other and even be completely replaced with
something new and still function.
The MAJOR RED FLAG I saw is the notion of components _managing_ each other.
It is the Container's job to manage components. Period. No component should
manage another component unless it in turn is a container for the managed
component. For example:
BAD
---
+--------------+
..| Container |..
. +------+-------+ .
. | .
v +------+-------+ v
+----+---+ +--------+
| Comp 1 |.....>| Comp 2 |
+--------+ +--------+
(the dotted line is management)
GOOD/ACCEPTIBLE
---------------
+--------------+
| Container |
+------+-------+
. |
. +----+---+
.>| Comp 1 |..
+----+---+ .
| .
+----+---+ .
| Comp 2 |<.
+--------+
In other words, a heirarchy of components is much easier to work with, develop,
and debug than any component usurping the container's job and cause
unpredictable results. Not to mention it complicates the security mechanisms
much more than necessary.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
RE: [services] getting service developers started - the initial component model
Posted by Jeremy Boynes <je...@coredevelopers.net>.
> The danger with using too much JMX is that when components start
> talking to each other using JMX, then it's very difficult to undo at a
> later stage.
>
Difference between components managing each other (for which JMX may be
good), and invoking each other (for which an alternative may be better).
We need to keep this difference in mind.
We also need to be careful about coupling of implementations and making sure
we keep invocations detached (to allow for redeployment). JMX enforces this,
any other framework needs to support it as well.
--
Jeremy
Re: [services] getting service developers started - the initial component model
Posted by Alex Blewitt <Al...@ioshq.com>.
>> AFAIK the J2EE spec doesn't say anything about being able to put your
>> own MBean into a server. However, an MBean container for just this
>> purpose sounds like an excellent idea.
>
> There are rumors of a user loadable JMX services JSR forming.
Cunning. However, I think that the ApacheJ2EE server should eventually
use a micro-kernel, of which one of the containers is a MBean
container, rather than necessarily the ApacheJ2EE server being an MBean
container.
>> Note that I don't believe the server itself needs to be an MBean
>> container (in much the same way that the whole isn't a web container
>> or ejb container) but it seems reasonable to assume that at some
>> future point the J2EE spec may create the concept of an MBean
>> container.
>
> I agree that the standard component model (the component model is not
> the server) does not have to be JMX, but it seems like an extreme
> waste of effort to create a shadow JMX object for every component in
> the server, when we can just have them be JMX components.
There's no reason they can't be both, but generate the JMX interfaces
automatically and/or dynamically rather than having to have the user
code them.
The danger with using too much JMX is that when components start
talking to each other using JMX, then it's very difficult to undo at a
later stage.
Alex.
Re: [services] getting service developers started - the initial component model
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Tuesday, August 12, 2003, at 05:57 AM, Alex Blewitt wrote:
>> All that sounds reasonable and I fully agree with you. However, as the
>> project is still in early stages I'd like to emphasize the fact that
>> J2EE
>> developers may want to deploy their own MBeans (doing things like
>> flushing
>> a cache) also at runtime. This possibility is without doubt been
>> forgetten
>> while WebLogic Server was coded. Even BEA WLS developers cannot
>> supply one
>> with any reasonable ways to deploy your own standard MBeans which do
>> not
>> have anything to do with WLS itself.
>
> AFAIK the J2EE spec doesn't say anything about being able to put your
> own MBean into a server. However, an MBean container for just this
> purpose sounds like an excellent idea.
There are rumors of a user loadable JMX services JSR forming.
> Note that I don't believe the server itself needs to be an MBean
> container (in much the same way that the whole isn't a web container
> or ejb container) but it seems reasonable to assume that at some
> future point the J2EE spec may create the concept of an MBean
> container.
I agree that the standard component model (the component model is not
the server) does not have to be JMX, but it seems like an extreme waste
of effort to create a shadow JMX object for every component in the
server, when we can just have them be JMX components.
-dain
/*************************
* Dain Sundstrom
* Partner
* Core Developers Network
*************************/
Re: [services] getting service developers started - the initial component model
Posted by Alex Blewitt <Al...@ioshq.com>.
> All that sounds reasonable and I fully agree with you. However, as the
> project is still in early stages I'd like to emphasize the fact that
> J2EE
> developers may want to deploy their own MBeans (doing things like
> flushing
> a cache) also at runtime. This possibility is without doubt been
> forgetten
> while WebLogic Server was coded. Even BEA WLS developers cannot supply
> one
> with any reasonable ways to deploy your own standard MBeans which do
> not
> have anything to do with WLS itself.
AFAIK the J2EE spec doesn't say anything about being able to put your
own MBean into a server. However, an MBean container for just this
purpose sounds like an excellent idea.
Note that I don't believe the server itself needs to be an MBean
container (in much the same way that the whole isn't a web container or
ejb container) but it seems reasonable to assume that at some future
point the J2EE spec may create the concept of an MBean container.
> Alex.