Roberto Lo Giacco wrote:
>
> Ok, stopping the debate once for all, ok guys?
+1
> Here I was meaning the tool could be as portable to be an added value to the
> framework, not just a graphical interface for our configs, but an easy way
> to access framework resources and to configure/start/stop them in the
> easyest way we can thing: just a click.
+1. But this makes things a lot more complicated! :-)
> More: I think James is in use and we haven't a GUI :) James is a very
> interesting approach to mail servicing and I think this is THE POWER, but we
> can add value to it: a good set of mail servlets to startup, integration
> with other systems (through Avalon I think), total control of the service
> (through XML files), easy of use (through GUI tools), remote administration
> (through a monitored client/server aplication), expandibility (through a
> good API), etc...
> So I agree with Stefano: GUI should be builded upon a good XML conf. What I
> was saying, again, is we can have other solutions to make XML file
> understandable to EVERYONE: just do it understandable to who really wants to
> put his hands into it.
Do not worry... even trying hard as we are trying there's no way to make
confs "too simple"! :-)
Tree configuration are pretty new and progammability trought conf is
totally new so anyone approching Avalon (both from a GUI or from vi)
will have lots of things to learn before becaming an expert!
>
> > The view I have in my mind about that tool is a client/server application
> > with a well know (reconfigurable for security) port where the Avalon is
> > listening for connections (simply TCP/IP authentication required based
> upon
> > addresses, domains, login, and even secret key).
>
> Tecnology proposal for the tool: again I really know I'm not inventing
> something, but I'm just asking to some of the JServ authors if the approach
> is correct.
IMHO Avalon should implement an interface I called "Container" to allow
Main.java to access Avalon's children's configurations, start and stop
them etc.
Something like
public Enumeration getChildrenNames();
public Service getChildService(String name);
....
This way you can write a protocol handler to connect your specific
client application or an http oriented tool or whatever else you may
think about.
And for example an EJB server working on top of Avalon will implement
this interface too to make beans configuratoins and lifecycle accessible
from the same tool used for Avalon. This IMO is POWER! :-)
Fede
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
