> |> - the client has to be written in Java
> |
> |Yes, but I'd prefer a servlet oriented one instad of a Swing one.
>
> same here... I will try the taglib approach to simplify it :)
IMO an HTML interface is maybe good to look what is going on on the
App. Server but not good to maintain and control an App. Server.
Have a look at the Netscape IPlanet Admin. Console (HTML) against
Java Web Server Admin. Console (Applet, which was not very well
implemented but it works).
As I already said there must be a reason why both BEA and IBM
uses an application instead of a Web interface for its administration
console.
> |> The server implementation of JBoss could look like:
> |> - either JMX MBeans or EJBs implements the server-side
> administration
> |> - are registered at the JNDI server
> |> - delivers the service interfaces to the client and map the
> |request to the
> |> server-side components
> |> - I would suggest RMI as a transport protocol
> |
> |So, like what we have now with the RMI connector then?
>
> yes only we wouldn't have to support the code of the connector...
To get or set an attribute or invoke a method JMX uses a number of
calls to od it which slows down the performance. I think we can go
around this on a pure Java based solution and still keep some of
the features of JMX.
> |> Why not JMX ?:
> |> - I aggree with Marc that JMX is good when the client is
> not written in
> |> Java but ugly when it is
> |
> |JMX syntax can be hidden with things like the
> org.jboss.util.MBeanProxy
> |though.
>
> ohh nice... thanks
I hadn't time to have a look at it but I was proposing a out of the
JBoss JVM solution and I think this won't work.
Hava fun - Andy
