You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Juan Carlos Murillo <mu...@inet.co.cr> on 2005/06/16 17:56:01 UTC
Proposal for Web Admin Console
Hello all,
My name is Juan Murillo. I run a web development and integration
company out of Costa Rica.
I would like to contribute to the Web Admin Console project that was
proposed by Ann for her Summer of Code proposal, I myself would not be
working under the SOC project.
I have posted some ideas on how this could be done and your comments as
to the viability of these ideas or additions to them would be most
welcome:
http://wiki.apache.org/james/WebAdminConsole#preview
--
Juan Carlos Murillo <mu...@inet.co.cr>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Juan Carlos Murillo <mu...@inet.co.cr>.
On Thu, 2005-06-23 at 16:37 -0600, Juan Carlos Murillo wrote:
> currently signed up on
> the Web Admin Console are I, Ann and Joe.
Sorry I think i might have gotten the list wrong, i think Nguyen was the
one who expressed interest.
Also a question about the HttpAdaptor for those who might know the
answer. I cannot get it to reply to me when running James under
j2sdk-1.4.2_08 or jre1.5.0_02. It runs fine under j2sdk-1.4.2_02.
All i get is a blank page, which looks to me like an xslt problem, any
clues? Is it working ok on your systems?
--
Juan Carlos Murillo <mu...@inet.co.cr>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Juan Carlos Murillo <mu...@inet.co.cr>.
I must say that is one approach I had never heard of, sounds very
interesting. However we were hoping to keep complexity and need to ramp
up to a minimum on the web side of things. Probably JSP and Servlets
only, basic HTML and CSS. I was thinking since its an admin console and
most forms are very small we can do away with client side validation and
just do SSV. However your help is very welcome, currently signed up on
the Web Admin Console are I, Ann and Joe. So any contribution on your
side is greatly appreciated.
>
> Regarding the communication interface between James and Web Admin, I
> suggest to also think about the possibility of using XML-RPC (RMI and
> SOAP have been mentioned). XML-RPC offers the openness of SOAP and is
> even easier to work with. BTW: Apache XML-RPC is based on an early
> version of Helma.
>
> [3] http://ws.apache.org/xmlrpc/
Regarding the implementation of a communiction interface for James
management we have the following restrictions:
1- We will use JMX: The JMX implementation in James currently is MX4J
http://www.mx4j.org/ MX4J exposes several comm interfaces
(HTTP-XSTL,HTTP-XML,HTTP-Hessian/Burlap, HTTP-SOAP,RMI-JRMP and
RMI-IIOP)
If we implement any other protocol than the ones offered by MX4J we will
have to do double work as we will need to implement one of the above
also.
I was leaning towards SOAP, but it appears SOAP has external
dependencies not fulfilled by default MX4J and it might not be supported
by the version we use.
After poking around a bit more I found that by changing the
ProcessorName property in the HttpAdaptor MBean from
'Http:name=XSLTProcessor' to 'Http:name=DefaultProcessor' you can get
the HTTP Adaptor to recieve and reply in plain XML.
This is very good for our purposes as we can implement basic
authentication and SSL for security, and have a basic XML parser do the
marshalling and unmarshalling or requests for us.
So, things are looking even simpler than before.
--
Juan Carlos Murillo <mu...@inet.co.cr>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Chris Zumbrunn <ch...@zumbrunn.com>.
On Jun 17, 2005, at 10:19 AM, Stefano Bagnara wrote:
> On Jun 17, 2005, at 1:11 AM, Juan Carlos Murillo wrote:
>
>> Embed Tomcat - portability should not be an issue as any web
>> application
>> written under the J2EE specificiation should deploy to any J2EE
>> compliant container. Tomcat however is by far the leader in
>> popularity.
>> Also a plus is the fact that its also an Apache project. I think
>> embedding it would be great as it totally removes the need for the
>> user
>> to do anything. I currently have a James configured so that you can
>> start tomcat and deploy the web app with the same run script used to
>> start James. So no work whatsoever for the user. The script output
>> would tell the user 'go to this url to access the management console:
>> xxxx'.
>
> I know in past there was an Avalon<->Jetty adapter.
>
> I don't know how easy would be to create an adapter to run Tomcat
> inside
> Avalon but it would not be so difficult to update the old
> avalon<->jetty
> adapter.
>
> Jetty is a slim servlet container. Probably the licensing doesn't
> allow to
> redistribute it with james.
Hi everybody,
I'm starting to use James as the mail component for OpenMocha [1] (a
web app server framework for javascript developers) and will need to
manage James from Helma [2] applications. So, this project would come
at the right time for me. Wherever there are synergies I'll be glad to
contribute what I can. Helma offers a Rhino based scripting environment
and embeds the Jetty web server.
Helma cleanly separates application logic from design using "skins".
Providing an easy way to customize the appearance beyond CSS could also
be a good idea for James Web Admin. I would certainly encourage you to
take a look at Helma. Should you decide to build James Web Admin using
Helma, I would be happy to help with the Helma side of things.
[1] http://openmocha.org/
[2] http://helma.org/
Regarding the communication interface between James and Web Admin, I
suggest to also think about the possibility of using XML-RPC (RMI and
SOAP have been mentioned). XML-RPC offers the openness of SOAP and is
even easier to work with. BTW: Apache XML-RPC is based on an early
version of Helma.
[3] http://ws.apache.org/xmlrpc/
Anyway, I'll be following this thread with great interest. I will
implement some kind of Helma based way of managing James and will
hopefully be able to contribute to the James Web Admin project in some
way.
Chris
chris@czv.com +41 329 41 41 41
Chris Zumbrunn Ventures - http://www.czv.com/
Internet Application Technology - Reduced to the Maximum
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Juan Carlos Murillo <mu...@inet.co.cr>.
Meant to include this link but hit Ctrl+Enter by mistake:
http://wiki.apache.org/james/WebAdminConsole#preview
What is the preference for exposing JMX to management interfaces, RMI or
SOAP?
On Fri, 2005-06-17 at 11:10 -0600, Juan Carlos Murillo wrote:
> How does this sound:
>
> 1- We build the web management console.
> 2- We offer it as a war download
> 3- We offer it as a war/servlet container bundle
> 4- We offer it as a James/war/servlet container bundle
>
> This targets three different user types:
>
> (2) Would target savvy user with multiple James that have centralized
> J2EE appserver for general app management
> (3) Would target users that decide to run James and web app on separate
> servers
> (4) Would target SOHO users that don't want to deal with the pain of
> installation/configuration.
>
> I agree with Noel's breakdown below. We can do parallel development on
> all these tiers and be finished faster. I have updated the proposal to
> reflect it as to what pertains to the web admin console itself:
> > >
> > > What we're look at probably lays out as:
> > >
> > > - JMX support w/MBeans embedded in each managed process
> > > - Admin service (model)
> > > - Admin webapp in a web container of the user's choice
> > > - Admin script interface (uses BSF)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Juan Carlos Murillo <mu...@inet.co.cr>.
How does this sound:
1- We build the web management console.
2- We offer it as a war download
3- We offer it as a war/servlet container bundle
4- We offer it as a James/war/servlet container bundle
This targets three different user types:
(2) Would target savvy user with multiple James that have centralized
J2EE appserver for general app management
(3) Would target users that decide to run James and web app on separate
servers
(4) Would target SOHO users that don't want to deal with the pain of
installation/configuration.
I agree with Noel's breakdown below. We can do parallel development on
all these tiers and be finished faster. I have updated the proposal to
reflect it as to what pertains to the web admin console itself:
> >
> > What we're look at probably lays out as:
> >
> > - JMX support w/MBeans embedded in each managed process
> > - Admin service (model)
> > - Admin webapp in a web container of the user's choice
> > - Admin script interface (uses BSF)
> >
> > where the webapp and script interface are just clients of the admin service.
> > For Anne's purposes, since she has a defined timeframe and task, as long as
> > she talks to JMX, we're probably fine, and later refactoring can handle
> > remaining issues.
> >
> > --- Noel
> >
--
Juan Carlos Murillo <mu...@inet.co.cr>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Anne S <hy...@gmail.com>.
Oy, oy, oy people! Let's not forget that I haven't been accepted yet!
No code has been laid down as of yet, so we can discuss this to our
heart's content. (Although, maybe somebody could slip a kind word to
the Apache people deciding on SOC projects about this project, that
would be much appreciated ;-) )
I'm perfectly comfortable speaking to JMX if need be, but as Jason
noted, security is a big issue. I'll explore the docs for JMX and see
what can be done.
And no, as Noel pointed out, the webapp should NOT be the final word
on the management of James. Somebody may prefer to write another
management app in the future for some reason, or integrate James
support into an existing package. Giving future developers an API
would be a terrific springboard for them. Opening up a servlet
container for each process is definitely a waste of memory.
As for the Tomcat embedded vs. Jetty, a quick look at the docs for
both shows that embedded Tomcat is a 2.8 MB download, while Jetty's
homepage claims to be able to provide a fully functioning server in a
350 KB jar file. Can anybody explain the big difference in size, and
if it's important for our uses?
On 6/17/05, Noel J. Bergman <no...@devtech.com> wrote:
> Juan Carlos Murillo wrote:
>
> > I understood that Avalon was in the process of being replaced by Spring
> > as the Container.
>
> I would sooner use the Geronimo microkernel than Spring.
>
> > > However, I don't believe that we want to embed a web container with
> JAMES.
> > > Rather, I feel that we want to enhance our primitive JMX support, and
> have
> > > administration tools use that interface.
>
> > I understand the issues for not wanting to embed the servlet container
>
> Actually, I am not sure that everyone yet fully grasps all of the issues.
> JAMES is currently a single process, but once we have multiple managed
> processes: SMTP handler(s), POP3 handler(s), pipeline processor(s), etc., we
> need JMX support embedded in each managed process. For a standalone JAMES,
> we could look at embedding the web container in the JAMES process, but that
> won't be scalable. We don't want to embed a web container and admin webapp
> in each managed process, nor would that provide a satisfactory UI, nor
> should a webapp be the only management interface.
>
> What we're look at probably lays out as:
>
> - JMX support w/MBeans embedded in each managed process
> - Admin service (model)
> - Admin webapp in a web container of the user's choice
> - Admin script interface (uses BSF)
>
> where the webapp and script interface are just clients of the admin service.
> For Anne's purposes, since she has a defined timeframe and task, as long as
> she talks to JMX, we're probably fine, and later refactoring can handle
> remaining issues.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Nguyen Trong Hung <tn...@mail.usyd.edu.au>.
Juan Carlos Murillo wrote:
>>Stefano Bagnara wrote:
>>
>>
>>
>>>I know in past there was an Avalon<->Jetty adapter.
>>>
>>>
>
>I understood that Avalon was in the process of being replaced by Spring
>as the Container. So ideally new developments could start this process
>of detachment by not using Avalon to run.
>
>
>
>>>Jetty is a slim servlet container. Probably the licensing
>>>doesn't allow to redistribute it with james.
>>>
>>>
>
>Tomcat-embedded is a minimal footprint distribution of Tomcat for uses
>such as the one proposed here. I hear Jetty is very good also however.
>
>
>
>>Jetty (http://jetty.mortbay.org/jetty/) is under the Apache License.
>>
>>However, I don't believe that we want to embed a web container with JAMES.
>>Rather, I feel that we want to enhance our primitive JMX support, and have
>>administration tools use that interface.
>>
>>
>
>I understand the issues for not wanting to embed the servlet container,
>it adds a dependency, it increases the size of the download etc. I was
>hoping however that making this a 'no configuration/ no installation'
>turnkey solution would greatly increase the adoption rate of James. One
>of the biggest complaints against Java systems as of today is the huge
>complexity involved in deployment of new systems. Picture this:
>
>Scenario 1
>1- Download, extract and run James
>
>Scenario 2
>1- Download, extract and run James
>2- Download Tomcat
>3- Install Tomcat
>4- Configure security and other on Tomcat
>5- Download James admin console
>6- Configure James console
>7- Deploy James admin console
>
>
>It is definetly not a life or death choice, but I was hoping to make
>life easy for the end user. I also think we should try to do all
>in-house as opposed to having a separate sourceforge bundling project as
>proposed by Ann.
>
>
>
I also find the webconsole admin interesting.
I have some thoughts here:
as the web console is not likely going to the main distribution of
James, we can always make a james version with embedded
servlet container (Tomcat here). The embedded Tomcat version is around
3MB which seems to be an acceptable size for downloading.
The primary concern should go to the web app as webapp design is good,
we can always make it to an embedded tomcat version or let the mail admin
install by themselves.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Proposal for Web Admin Console
Posted by "Noel J. Bergman" <no...@devtech.com>.
Noel J. Bergman wrote:
> For Anne's purposes, since she has a defined timeframe and task ...
Sheesh, and I know better ... for those who don't and just for correctness
of pronous, Anne is a nickname, and the owner is male.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Proposal for Web Admin Console
Posted by "Noel J. Bergman" <no...@devtech.com>.
Juan Carlos Murillo wrote:
> I understood that Avalon was in the process of being replaced by Spring
> as the Container.
I would sooner use the Geronimo microkernel than Spring.
> > However, I don't believe that we want to embed a web container with
JAMES.
> > Rather, I feel that we want to enhance our primitive JMX support, and
have
> > administration tools use that interface.
> I understand the issues for not wanting to embed the servlet container
Actually, I am not sure that everyone yet fully grasps all of the issues.
JAMES is currently a single process, but once we have multiple managed
processes: SMTP handler(s), POP3 handler(s), pipeline processor(s), etc., we
need JMX support embedded in each managed process. For a standalone JAMES,
we could look at embedding the web container in the JAMES process, but that
won't be scalable. We don't want to embed a web container and admin webapp
in each managed process, nor would that provide a satisfactory UI, nor
should a webapp be the only management interface.
What we're look at probably lays out as:
- JMX support w/MBeans embedded in each managed process
- Admin service (model)
- Admin webapp in a web container of the user's choice
- Admin script interface (uses BSF)
where the webapp and script interface are just clients of the admin service.
For Anne's purposes, since she has a defined timeframe and task, as long as
she talks to JMX, we're probably fine, and later refactoring can handle
remaining issues.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Proposal for Web Admin Console
Posted by Juan Carlos Murillo <mu...@inet.co.cr>.
> Stefano Bagnara wrote:
>
> > I know in past there was an Avalon<->Jetty adapter.
I understood that Avalon was in the process of being replaced by Spring
as the Container. So ideally new developments could start this process
of detachment by not using Avalon to run.
>
> > Jetty is a slim servlet container. Probably the licensing
> > doesn't allow to redistribute it with james.
Tomcat-embedded is a minimal footprint distribution of Tomcat for uses
such as the one proposed here. I hear Jetty is very good also however.
>
> Jetty (http://jetty.mortbay.org/jetty/) is under the Apache License.
>
> However, I don't believe that we want to embed a web container with JAMES.
> Rather, I feel that we want to enhance our primitive JMX support, and have
> administration tools use that interface.
I understand the issues for not wanting to embed the servlet container,
it adds a dependency, it increases the size of the download etc. I was
hoping however that making this a 'no configuration/ no installation'
turnkey solution would greatly increase the adoption rate of James. One
of the biggest complaints against Java systems as of today is the huge
complexity involved in deployment of new systems. Picture this:
Scenario 1
1- Download, extract and run James
Scenario 2
1- Download, extract and run James
2- Download Tomcat
3- Install Tomcat
4- Configure security and other on Tomcat
5- Download James admin console
6- Configure James console
7- Deploy James admin console
It is definetly not a life or death choice, but I was hoping to make
life easy for the end user. I also think we should try to do all
in-house as opposed to having a separate sourceforge bundling project as
proposed by Ann.
--
Juan Carlos Murillo <mu...@inet.co.cr>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Stefano Bagnara <ap...@bago.org>.
> > Jetty is a slim servlet container. Probably the licensing doesn't
> > allow to redistribute it with james.
>
> Jetty (http://jetty.mortbay.org/jetty/) is under the Apache License.
>
> However, I don't believe that we want to embed a web
> container with JAMES.
> Rather, I feel that we want to enhance our primitive JMX
> support, and have administration tools use that interface.
I agree that the communication should be done over JMX.
BTW it would be easier for the common user to have a prepackaged jetty in
the james/phoenix install.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Proposal for Web Admin Console
Posted by Jason Webb <jw...@inovem.com>.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 17 June 2005 14:58
> To: James Developers List
> Subject: RE: Proposal for Web Admin Console
>
> Stefano Bagnara wrote:
>
> > I know in past there was an Avalon<->Jetty adapter.
>
> > Jetty is a slim servlet container. Probably the licensing
> > doesn't allow to redistribute it with james.
>
> Jetty (http://jetty.mortbay.org/jetty/) is under the Apache License.
>
> However, I don't believe that we want to embed a web container with JAMES.
> Rather, I feel that we want to enhance our primitive JMX support, and have
> administration tools use that interface.
>
> To see the existing JMX support, to a source build and then look under the
> build/ directory for *.mxinfo, which will describe the JMX interfaces
> available. Those, and the corresponding MBeans, were generated using the
> Phoenix XDoclet Ant task.
I've looked at the JMX support before and there was one show-stopping issue:
no security on the JMX invocations. We need to make sure that at least only
"root" can access the JMX services.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Proposal for Web Admin Console
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> I know in past there was an Avalon<->Jetty adapter.
> Jetty is a slim servlet container. Probably the licensing
> doesn't allow to redistribute it with james.
Jetty (http://jetty.mortbay.org/jetty/) is under the Apache License.
However, I don't believe that we want to embed a web container with JAMES.
Rather, I feel that we want to enhance our primitive JMX support, and have
administration tools use that interface.
To see the existing JMX support, to a source build and then look under the
build/ directory for *.mxinfo, which will describe the JMX interfaces
available. Those, and the corresponding MBeans, were generated using the
Phoenix XDoclet Ant task.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Stefano Bagnara <ap...@bago.org>.
> Embed Tomcat - portability should not be an issue as any web
> application written under the J2EE specificiation should
> deploy to any J2EE compliant container. Tomcat however is by
> far the leader in popularity.
> Also a plus is the fact that its also an Apache project. I
> think embedding it would be great as it totally removes the
> need for the user to do anything. I currently have a James
> configured so that you can start tomcat and deploy the web
> app with the same run script used to start James. So no work
> whatsoever for the user. The script output would tell the
> user 'go to this url to access the management console:
> xxxx'.
I know in past there was an Avalon<->Jetty adapter.
I don't know how easy would be to create an adapter to run Tomcat inside
Avalon but it would not be so difficult to update the old avalon<->jetty
adapter.
Jetty is a slim servlet container. Probably the licensing doesn't allow to
redistribute it with james.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Proposal for Web Admin Console
Posted by Juan Carlos Murillo <mu...@inet.co.cr>.
Hi Ann,
Thanks for your reply, here are my thoughts:
Embed Tomcat - portability should not be an issue as any web application
written under the J2EE specificiation should deploy to any J2EE
compliant container. Tomcat however is by far the leader in popularity.
Also a plus is the fact that its also an Apache project. I think
embedding it would be great as it totally removes the need for the user
to do anything. I currently have a James configured so that you can
start tomcat and deploy the web app with the same run script used to
start James. So no work whatsoever for the user. The script output
would tell the user 'go to this url to access the management console:
xxxx'.
As you say, we force no one, the web app will be in the package, it can
be extracted and used elsewhere in a different container and the tomcat
server shutdown. On the Tomcat stability, i must say Tomcat is very
stable and we would be running it on its own VM so it will
not impact James in any way even if it totally crashes and dies. I
would prefer to do it all in James, but that is up to the commiters to
decide. My preference would therefore be the simple, stable, small
footprint, independent VM, no configuration Tomcat + our app.
Communication - I agree with you on the config.xml. I am not sure the
web app talking to the telnet port is such a great idea. Maybe we can
use JMX or RMI for that kind of communication.
Framework: I am with you. This app will not be changing all the time
and adding a specific framework will just add a learning curve to the
app. We could stick with Servlets for flow control and JSP for
presentation.
Layout: I like your idea of watching what is normally expected of admin
consoles on other mail servers. I also like the idea about the mail
truck but James has a logo and that part might be difficult to change,
we also need to keep our 'enterprise' looks about us :)
Clustering: Not my cup of tea either. Lets leave that for when we are
done with the easy stuff. Maybe someone else can help us with it.
Data Base: I say we keep the admin up a straight interface to the James
server. Tomcat can handle security (user/pass) and all the rest of our
data is from James itself. As for transient data for wizards and other
immediate stuff, we can use in memory session objects to store that.
Juan
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org