You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Vikram Goyal <te...@craftbits.com> on 2003/08/19 13:55:13 UTC
Servlet and JSP engine
Hello all,
I have been following the list with quite fascination since it began. The
volume of traffic has been quite overwhelming to say the least.
I noticed early on that a conscious decision has been made to avoid
developing a servlet and JSP engine and rather rely on embedding either
Tomcat or Jetty. Is this correct?
If this is the case, is there a rationale decision for this? If we are
developing everything from scratch, then why not the servlet and JSP engine
as well? It makes more sense than embedding other implementations.
Regards,
Vikram Goyal
Re: Servlet and JSP engine
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Vikram,
The aim is to get up off the ground quickly, however the beauty of Open
Source and the aim of the Geronimo project would not be to preclude the
use of other web containers, but to encourage you to go out, build your
own and contribute it.
Geronimo services will be pluggable and interchangeable. I'm sure
another webcontainer would be welcome. It's simply that it is not on our
critical path, because we already have two.
Jules
Daniel Hofstetter wrote:
>Hi Vikram
>
>
>
>>I noticed early on that a conscious decision has been made to avoid
>>developing a servlet and JSP engine and rather rely on embedding either
>>Tomcat or Jetty. Is this correct?
>>
>>
>
>Afaik: yes.
>
>
>
>>If this is the case, is there a rationale decision for this? If we are
>>developing everything from scratch, then why not the servlet and JSP
>>engine
>>as well? It makes more sense than embedding other implementations.
>>
>>
>
>To create an appserver from scratch means not to reinvent everything :) (see
>FAQ: "What other projects will Geronimo reuse?")
>
>I think to develop another servlet/JSP engine isn't worth the effort because
>there exist with Tomcat/Jetty already good products. It makes more sense to
>concentrate the forces on a good integration of these components and, if
>necessary, to enhance them.
>
>Bye,
>Daniel
>
>
>
--
/*************************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
* http://www.coredevelopers.net
*************************************/
Re: Servlet and JSP engine
Posted by Daniel Hofstetter <da...@gmx.ch>.
Hi Vikram
> I noticed early on that a conscious decision has been made to avoid
> developing a servlet and JSP engine and rather rely on embedding either
> Tomcat or Jetty. Is this correct?
Afaik: yes.
> If this is the case, is there a rationale decision for this? If we are
> developing everything from scratch, then why not the servlet and JSP
> engine
> as well? It makes more sense than embedding other implementations.
To create an appserver from scratch means not to reinvent everything :) (see
FAQ: "What other projects will Geronimo reuse?")
I think to develop another servlet/JSP engine isn't worth the effort because
there exist with Tomcat/Jetty already good products. It makes more sense to
concentrate the forces on a good integration of these components and, if
necessary, to enhance them.
Bye,
Daniel
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
Re: Servlet and JSP engine
Posted by Vikram Goyal <te...@craftbits.com>.
>
> The approach that I wish to take - is to firstly define geronimos own view
of
> what are web containers, connectors and applications and to capture that
in
> the AbstractWebContainer layer. This will be focused on what geronimo
needs
> as a complete J2EE engine and will not pander to any particular
implementation.
>
> Then if the jetty/tomcat implementations of this are not suitable
> robust, modular and efficient - we can consider a geronimo native
> implementation. I may even consider donating Jetty to apache to assist
> with this - but I think this is WAY too early to think about such things.
Excellent !! This is perhaps the best way to do this, although I still think
that the underlaying implementation should be from scratch. It is not Jetty
that we need to improve or fix but have geronimo be based on a clean,
separate and independent implementation.
>
> But I take your point - use of external implementations should not be
> allowed to be an excuse for not having a top class, seamlessly integrated
> J2EE compliant web tier withing geronimo.
Thanks. I am not trying to criticize the choices made, but simply trying to
understand them.
I would love to help you out with this implementation. Let me know where and
how to begin.
Regards,
Vikram
>
> regards
>
>
>
>
Re: Servlet and JSP engine
Posted by Greg Wilkins <gr...@mortbay.com>.
Vikram Goyal wrote:
> Besides, there are several complexities with the plugging in other servlet
> containers. I am not sure how many of you have ever tried to integrate
> Tomcat with Apache or tried to embed Tomcat as part of an application. The
> embedding makes the control pass on to another applications space, in which
> we have no control or say. Ideally that should be the case, after all that
> is what OO is all about. However, an integrated engine, developed within the
> confines of the complete J2EE engine has a better likelihood of being
> robust, modular and performing better.
Which is why I am proposing using Jetty as the first implementation.
Jetty's bread and butter is integrating into other applications/platforms.
As the lead developer of Jetty, if there is something that prevents it
from being embedded in Geronimo is a robust, modular and efficient way,
then that is a fault in Jetty and I will fix it.
Note that I believe that under the hood - tomcat is also flexible and
embedable and should be able to equally integrated. It is just that this
has not been tomcats main focus and any required changes will be of less
priority for them. But I'm sure it will get done.
The approach that I wish to take - is to firstly define geronimos own view of
what are web containers, connectors and applications and to capture that in
the AbstractWebContainer layer. This will be focused on what geronimo needs
as a complete J2EE engine and will not pander to any particular implementation.
Then if the jetty/tomcat implementations of this are not suitable
robust, modular and efficient - we can consider a geronimo native
implementation. I may even consider donating Jetty to apache to assist
with this - but I think this is WAY too early to think about such things.
But I take your point - use of external implementations should not be
allowed to be an excuse for not having a top class, seamlessly integrated
J2EE compliant web tier withing geronimo.
regards
Re: Servlet and JSP engine
Posted by James Strachan <ja...@yahoo.co.uk>.
On Wednesday, August 20, 2003, at 08:31 am, Vikram Goyal wrote:
> Hi Greg and others,
>
> My understanding is that the initial idea of Geronimo was to develop a
> world
> class J2EE compatible container, separate from the exisitng Apache
> projects,
> with two main goals:
> a.. integration of various existing and new code bases into a J2EE
> stack,
> with those codebases existing both inside and outside of the project
> b.. certification of the J2EE stack
> An easy interpretation of these goals (specifically the first one) is
> that
> if an existing technology supports the components of the stack then it
> should be integrated without having to develop is from scratch. This
> leads
> me to believe that the sole aim of this project is to bring together
> technologies rather than provide implementations, which I believe
> should
> really have been the aim.
Not quite. There is plenty of software we can reuse to make the J2EE
stack - however there's still lots of new stuff we need to do and lots
of integration code required.
> A <b>complete</b> J2EE certified server and a fully modular J2EE stack
> would
> be incomplete without an implementation of the servlet engine.
Sure.
> Even if an
> existing servlet engine can be plugged in behind the scenes it is
> breaking
> the notion of a complete J2EE certified server.
Why? Why can't a J2EE server be modular and support pluggable service
providers. There are various Servlet container implementations to
choose from, various JMS providers etc.
> If the end user can take the
> servlet engine out (presumably, after all the servlet engine is
> modular and
> pluggable), the J2EE certified server is NOT a J2EE server.
I don't follow your logic. Being modular is good. Being able to just
use a servlet container outside of Geroniom if thats what you want is a
good thing. However Geronimo will always have a servlet container
inside it, unless a user really wants to disable it in their specific
deployment configuration.
Services drop into Geronimo, so a user could create a Geornimo
distribution which only includes web services + JTA + JMS. However the
certified distribution of Geronimo will have the entire J2EE stack.
> I am not sure
> what you would call it, a Web services engine?, an EJB container?
J2EE server?
> Besides, there are several complexities with the plugging in other
> servlet
> containers. I am not sure how many of you have ever tried to integrate
> Tomcat with Apache or tried to embed Tomcat as part of an application.
The folks around here are well aware of Tomcat & Jetty and integrating
them into JBoss
> The
> embedding makes the control pass on to another applications space, in
> which
> we have no control or say. Ideally that should be the case, after all
> that
> is what OO is all about. However, an integrated engine, developed
> within the
> confines of the complete J2EE engine has a better likelihood of being
> robust, modular and performing better.
Thats pretty much what we're doing. Its just we don't need to write a
servlet engine from scratch - we can just reuse the existing ones.
There's plenty of other stuff for us to do :)
James
-------
http://radio.weblogs.com/0112098/
Re: Servlet and JSP engine
Posted by Vikram Goyal <te...@craftbits.com>.
Hi Greg and others,
My understanding is that the initial idea of Geronimo was to develop a world
class J2EE compatible container, separate from the exisitng Apache projects,
with two main goals:
a.. integration of various existing and new code bases into a J2EE stack,
with those codebases existing both inside and outside of the project
b.. certification of the J2EE stack
An easy interpretation of these goals (specifically the first one) is that
if an existing technology supports the components of the stack then it
should be integrated without having to develop is from scratch. This leads
me to believe that the sole aim of this project is to bring together
technologies rather than provide implementations, which I believe should
really have been the aim. If for example, we had an open source ASF licensed
EJB stack, we would have been left with providing an integrator to that
rather than building it from scratch, which we are doing now.
A little more understanding of the complexity of J2EE is required to fully
appreciate these goals. I think the scope specified in the project
documentation is closer to the truth than the goals:
a.. a complete J2EE certified server which is fully ASF/BSD licensed and
backed by a healthy open source community.
a.. to create a fully modular J2EE stack so that the Apache community can
use whichever parts of the J2EE stack they require separate from the J2EE
server project.
A <b>complete</b> J2EE certified server and a fully modular J2EE stack would
be incomplete without an implementation of the servlet engine. Even if an
existing servlet engine can be plugged in behind the scenes it is breaking
the notion of a complete J2EE certified server. If the end user can take the
servlet engine out (presumably, after all the servlet engine is modular and
pluggable), the J2EE certified server is NOT a J2EE server. I am not sure
what you would call it, a Web services engine?, an EJB container?
Besides, there are several complexities with the plugging in other servlet
containers. I am not sure how many of you have ever tried to integrate
Tomcat with Apache or tried to embed Tomcat as part of an application. The
embedding makes the control pass on to another applications space, in which
we have no control or say. Ideally that should be the case, after all that
is what OO is all about. However, an integrated engine, developed within the
confines of the complete J2EE engine has a better likelihood of being
robust, modular and performing better.
Regards,
Vikram
>
>
> Vikram,
>
> have a look at
> http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/WebContainer
>
> where I have described the approach that we are taking.
>
> The actual implementation of the web container will be tomcat and/or
> jetty - but I would like geronimo to wrap those implementations
> sufficiently so that you cannot tell which. Thus for 99% of
configuration
> and management, it will be geronimo that you are dealing with.
>
> The Abstract Web container classes have been created, but are a
> little empty at the moment... we have been waiting for the
component/container
> model to stabalize. Hopefully there will be some more progress this week.
>
> cheers
>
>
> Vikram Goyal wrote:
> > Hello all,
> >
> > I have been following the list with quite fascination since it began.
The
> > volume of traffic has been quite overwhelming to say the least.
> >
> > I noticed early on that a conscious decision has been made to avoid
> > developing a servlet and JSP engine and rather rely on embedding either
> > Tomcat or Jetty. Is this correct?
> >
> > If this is the case, is there a rationale decision for this? If we are
> > developing everything from scratch, then why not the servlet and JSP
engine
> > as well? It makes more sense than embedding other implementations.
> >
> > Regards,
> > Vikram Goyal
> >
> >
>
>
>
> --
> /**************************
> * Greg Wilkins
> * Partner
> * Core Developers Network
> **************************/
>
>
>
>
>
Re: Servlet and JSP engine
Posted by Greg Wilkins <gr...@coredevelopers.net>.
Vikram,
have a look at
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/WebContainer
where I have described the approach that we are taking.
The actual implementation of the web container will be tomcat and/or
jetty - but I would like geronimo to wrap those implementations
sufficiently so that you cannot tell which. Thus for 99% of configuration
and management, it will be geronimo that you are dealing with.
The Abstract Web container classes have been created, but are a
little empty at the moment... we have been waiting for the component/container
model to stabalize. Hopefully there will be some more progress this week.
cheers
Vikram Goyal wrote:
> Hello all,
>
> I have been following the list with quite fascination since it began. The
> volume of traffic has been quite overwhelming to say the least.
>
> I noticed early on that a conscious decision has been made to avoid
> developing a servlet and JSP engine and rather rely on embedding either
> Tomcat or Jetty. Is this correct?
>
> If this is the case, is there a rationale decision for this? If we are
> developing everything from scratch, then why not the servlet and JSP engine
> as well? It makes more sense than embedding other implementations.
>
> Regards,
> Vikram Goyal
>
>
--
/**************************
* Greg Wilkins
* Partner
* Core Developers Network
**************************/
[OT] RE: Servlet and JSP engine
Posted by Tim Anderson <tm...@netspace.net.au>.
The main point for not using the name "Geronimo"
is that is that a name which has cultural signficance.
While you may view this as a tribute to Geronimo,
or native Americans in general, or think its just
a really cool name, there will be others who see it
as a cynical marketing exercise.
The same goes for any name with cultural or religious
significance.
-Tim
> -----Original Message-----
> From: Ned G [mailto:nedgham@optushome.com.au]
> Sent: Wednesday, 20 August 2003 1:00 PM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: Servlet and JSP engine
>
>
> I have been reading many email with concern to the name "geronimo" and how
> it could offend some if not all native Americans
> tribes. What I would like to say that its a name that is been put on a
> product that carries pride, hard work and freedom
> I cant see why it would or could offend native Americans when
> they should be
> proud to have a product named after them.
> I can understand if its been used in an offensive way.
>
> -----Original Message-----
> From: Ned G [mailto:nedgham@optushome.com.au]
> Sent: Wednesday, 20 August 2003 3:52 AM
> To: geronimo-dev@incubator.apache.org
> Subject: RE: Servlet and JSP engine
>
>
RE: Servlet and JSP engine
Posted by Ned G <ne...@optushome.com.au>.
I have been reading many email with concern to the name "geronimo" and how
it could offend some if not all native Americans
tribes. What I would like to say that its a name that is been put on a
product that carries pride, hard work and freedom
I cant see why it would or could offend native Americans when they should be
proud to have a product named after them.
I can understand if its been used in an offensive way.
-----Original Message-----
From: Ned G [mailto:nedgham@optushome.com.au]
Sent: Wednesday, 20 August 2003 3:52 AM
To: geronimo-dev@incubator.apache.org
Subject: RE: Servlet and JSP engine
I couldnt agree more
-----Original Message-----
From: Vikram Goyal [mailto:tech@craftbits.com]
Sent: Tuesday, 19 August 2003 9:55 PM
To: geronimo-dev@incubator.apache.org
Subject: Servlet and JSP engine
Hello all,
I have been following the list with quite fascination since it began. The
volume of traffic has been quite overwhelming to say the least.
I noticed early on that a conscious decision has been made to avoid
developing a servlet and JSP engine and rather rely on embedding either
Tomcat or Jetty. Is this correct?
If this is the case, is there a rationale decision for this? If we are
developing everything from scratch, then why not the servlet and JSP engine
as well? It makes more sense than embedding other implementations.
Regards,
Vikram Goyal
RE: Servlet and JSP engine
Posted by Ned G <ne...@optushome.com.au>.
I couldnt agree more
-----Original Message-----
From: Vikram Goyal [mailto:tech@craftbits.com]
Sent: Tuesday, 19 August 2003 9:55 PM
To: geronimo-dev@incubator.apache.org
Subject: Servlet and JSP engine
Hello all,
I have been following the list with quite fascination since it began. The
volume of traffic has been quite overwhelming to say the least.
I noticed early on that a conscious decision has been made to avoid
developing a servlet and JSP engine and rather rely on embedding either
Tomcat or Jetty. Is this correct?
If this is the case, is there a rationale decision for this? If we are
developing everything from scratch, then why not the servlet and JSP engine
as well? It makes more sense than embedding other implementations.
Regards,
Vikram Goyal
Re: Servlet and JSP engine
Posted by James Strachan <ja...@yahoo.co.uk>.
On Tuesday, August 19, 2003, at 12:55 pm, Vikram Goyal wrote:
> Hello all,
>
> I have been following the list with quite fascination since it began.
> The
> volume of traffic has been quite overwhelming to say the least.
>
> I noticed early on that a conscious decision has been made to avoid
> developing a servlet and JSP engine and rather rely on embedding either
> Tomcat or Jetty. Is this correct?
Yes. The web container module is already in CVS - though I've
personally not tried it yet.
> If this is the case, is there a rationale decision for this? If we are
> developing everything from scratch, then why not the servlet and JSP
> engine
> as well? It makes more sense than embedding other implementations.
We're not developing everything from scratch. We're reusing any good
existing open source, which is suitably licensed, to create a full J2EE
stack. So for sure Tomcat / Jetty will be the Servlet engines.
James
-------
http://radio.weblogs.com/0112098/
RE: Servlet and JSP engine
Posted by Danny Angus <da...@apache.org>.
Vikram,
You say:
> If we are
> developing everything from scratch, then why not the servlet and
> JSP engine
> as well? It makes more sense than embedding other implementations.
I wonder if you'd like to say why you think so, as this is by no means
obvious to me..
d.