Pyisuh,
Thanks for investigating this, it looks promising! I had only a quick look
due to the current beta 19 focus.
IMO, the JMX management should be a optional. Its use should be enabled via
the API and implemented as a pluggable extension
(com.noelios.restlet.ext.jmx). If you look at the latest beta 19 snapshot,
you'll see the following properties:
Container
+ logService : access log for all virtual hosts (disabled by default)
+ statusService : status page setting (enabled by default)
Application
+ logService : access log for the application (enabled by default)
+ statusService : status page setting (enabled by default)
+ connectorService : optional and required connectors
+ localService : extension name to media type mapping, etc.
All the service classes are extending a new org.restlet.util.Service class.
It would be very easy to add a "managementService" property to Container
that users could call in order to enable or disable the JMX service or
configure it in a portable way (not specific to NRE).
The pluggability of the JMX service into the NRE's core could be done using
the same mechanism as the pluggable connectors (using a property file at a
known location for introspection). We could use a helper class (like for
connectors) based on your option 3 ("Delegating Container").
With this approach I think we would have the maximum flexibility. Those who
don't need JMX would still use a light NRE core JAR. Those needing JMX would
just add the JMX extension JAR to their classpath. Those needing to provide
a custom implementation would plug their own extension JAR.
As for the JDK level, the current base line is Java 5. Java 1.4 support is
only provided as a convenience backport using the retroweaver feature. IMO,
we should first aim at Java 5 for JMX support, then see if it's reasonably
easy to make it work in a Java 1.4 environment. The pluggability of the JMX
extension could help in this case, especially if we can't support it in Java
1.4.
Best regards,
Jerome
> -----Message d'origine-----
> De : Piyush Purang [mailto:[EMAIL PROTECTED]
> Envoyé : dimanche 22 octobre 2006 14:42
> À : [email protected]
> Objet : Re: Restlets and JMX
>
> One thing common to all the following approaches is to define common
> baseline Management interfaces to the managed resources. In the
> following discussion I take Container as an example but it applies to
> all other managed resources as well.
>
> 1. Tight integration: The moment someone creates a
> Container it is
> automatically registered with the configured MBeanServer(s). For this
> Container will have to implement the Management interface and then it
> registers itself as part of its initialization process.
>
> 2. Subclassing Container: Provide a Container
> implementation that
> subclasses Container and implements the container management
> interface. Users have to make a choice: managed container or not. If
> yes then they use this Subclass.
>
> 3. Delegating Container: Provide an implementation that takes a
> delegatee Container object and decorates it with the management
> interface. Users can use the normal container or a subclass and then
> wrap it with the management interface decorator.
>
> 4. Completely transparent: Using dynamic proxy/byte code
> intervention
> woodoo to make everything else inconsequential.
>
> Then we have to discuss configurational-issues, 1.4 and 1.5 issue etc
> (supportng JMX on 1.4 platform will require additional setup).
>
> Attached are some examples to highlight the different approaches
> (except for the 4th point noted above). In the comments there
> are some
> important todos highlighted.
>
> I like the ManangementService way of doing things the best.
>
> The jar file can be used with the latest snapshot and
> requires atleast
> an http connector. I use the jetty 6. Java 1.5 is essential. Don't
> forget to set the VM parameter "-Dcom.sun.management.jmxremote"
>
> Once started you can use jconsole and look at the MBeans tab to play
> around with the registered Mbeans. (On a windows machine you need
> atleast your temporary folder on NTFS for jconsole to detect your
> management enabled VM. That is one of the reasons why I had to go to
> linux to test a bit. All my windows partitions are FAT32.)
>
> Caution: starting, stopping and starting a container throws an
> exception that issue is subject of another email.
>
> Cheers
> Piyush
>
> P.S: I haven't dug into how tomcat achieves this ... maybe I
> should do that :)
>
>
>
