You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Jonathan Pierce <Jo...@seagram.com> on 1999/10/29 00:42:09 UTC
Re[2]: TomCat Feature Requests
James,
Thanks for the quick and really useful reply. I wasn't aware of the servlet jar
support since I hadn't yet read the 2.2 spec and I built the webserver with my
own tools.
I tested the jar file in the lib directory support and it worked well.
I'm glad to hear that loading servlets from URLs is also supported. I probably
should have read more of the documentation before sending my post to the list.
I agree that we should continue the discussion about the dynamic reloading of
servlets. Perhaps we can use the same implementation that JavaServer uses. If
not, I can share my implementation. By putting all servlet classes into a
servlets jar file, the engine can reload the servlet if the jar file date
changes which would occur if any of its classes changed. This might be a problem
though if two servlets share the same library classes in different jar files
since other jar files with the same classes may not have changed.
As far as the admin tool is concerned, I think it might be better to make this
an optional component to keep the installation and configuration as simple as
possible. I don't think people mind editing the XML file.
-Jonathan
____________________Reply Separator____________________
Subject: Re: TomCat Feature Requests
Author: general@jakarta.apache.org
Date: 10/28/99 1:44 PM
hi jonathan -
firstly this is a great topic to continue on
the tomcat-dev aliase.
regarding the servlet loader it is intended to
meet the minimal requirements as specified by
the servlet 2.2 spec
(http://java.sun.com/products/servlet/2.2), namely
web application classes are loaded from WEB-INF/classes
and web application libraries are loaded from
WEB-INF/lib/*jar. i think this meets some of your
requirements.
as to class reloading this is a much requested feature
which would be nice to address. there are a variety
of approaches which have been discussed on this and
other aliases. we should continue the discussion and
see as to how best to proceed.
as to the loading servlets from a url, per servlet 2.2
and tomcat's interpretation there of, it is possible
to specify a web appliation document base via an http
url today. the entire web application can be archived
in a war (web application archive) file and distributed
from a centralized location.
as to the nt and iis issues, good points i hope someone
can address.
lastly, i've been floating the idea for a bit to
kick off a tomcat admin project. to that end i believe
there are about 5 or so folks that are interested in
proceeding and a couple of other folks who offer opinions
from time to time. based on your stated objectives i
have a feeling you'd be interested in seeing a more
sophisticated administration tool for tomcat.
hope this helps,
- james
Jonathan Pierce wrote:
>
> Everyone,
>
> I just downloaded and built the Jakarta TomCat webserver with my Development
> environment (CodeWarrior) and tried it out. It seems to work well.
>
> I have a few features that I'd like to see added to the distribution to make
the
> standalone version of TomCat more useable for deployment.
>
> I've written an implementation for many of these features in my own web
server,
> but have not yet tried to incorporate them into the TomCat sources. Many of
> these features also exist in Sun's JavaWebServer product.
>
> Please let me know whether any of these features are being discussed. I can
> assist with the implementation if needed. I'm sure I'm not the only one who
> wants to deploy TomCat, not just use it for development.
>
> 1. Please extend the Servlet Loader to support loading servlets from jar
files.
> The jar file name can be the name of the servlet without its package, so
servlet
> Package1.Servlet1 would load from file Servlet1.jar
>
> 2. Please extend the Servlet Loader to dynamically reload servlets if they
have
> changed. This can be done if the jar file date is newer that when the servlet
> was loaded. This would allow developers to rebuild the servlet without having
to
> restart the servlet engine.
>
> 3. Please extend the Servlet Loader to support loading servlets from a URL.
> This would allow the same servlet to be deployed on multiple machines to
> distribute processing without the need to redistribute it manually.
>
> 4. Please include in the distribution a procedure for installing the servlet
> engine as a service on Windows NT. This can be done using the instsrv.exe and
> the SrvAny.exe from the Windows NT resource kit. This would allow the servlet
> engine to be restarted automatically when the machine is rebooted. This should
> be implemented so that stopping the NT service will shutdown the TomCat
> webserver.
>
> 5. Please consider adding support for Internet Information Server on Windows
NT
> using an ISAPI extension that forwards requests from port 80 to the TomCat
> servlet engine. This is done by the JRun product.
>
> -Jonathan Pierce
> Java Consultant / Web Developer
> Seagram Co. Ltd.
> E-mail: jonathan_pierce@Seagram.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: building problem w 19991029042334
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Luc Saint-Elie wrote:
> D:\Telechargement\Java\jakarta\jakarta-tomcat\src\share\org\apache\tomcat\se
> rvic
> e\Ajp11ConnectionHandler.java:234: Can't make static reference to method
> int con
> vert2Int(byte[]) in class org.apache.tomcat.util.HexUtils.
> len=HexUtils.convert2Int(hex);
> ^
> 1 error
>
I patched this one last night. Please try a newer snapshot.
Craig McClanahan
building problem w 19991029042334
Posted by Luc Saint-Elie <ls...@imaginet.fr>.
Hello,
context
Machine P200/NT4SP4
JDK 1.2.2
Building using :ANT
releases :
jakarta-tomcat_19991029042334_tar.gz
jakarta-tools_19991029042507_tar.gz
//============================
Executing Target: main
Compiling 265 source files to
D:\Telechargement\Java\jakarta\build\tomcat\classe
s
D:\Telechargement\Java\jakarta\jakarta-tomcat\src\share\org\apache\tomcat\se
rvic
e\Ajp11ConnectionHandler.java:234: Can't make static reference to method
int con
vert2Int(byte[]) in class org.apache.tomcat.util.HexUtils.
len=HexUtils.convert2Int(hex);
^
1 error
//=============================
Re: TomCat Feature Requests
Posted by James Todd <ja...@eng.sun.com>.
typo fix.
- james
James Todd wrote:
>
> [cc'ing tomcat-dev]
>
> Jonathan Pierce wrote:
> >
> > I'm glad to hear that loading servlets from URLs is also supported. I probably
> > should have read more of the documentation before sending my post to the list.
>
> nada problem. i have a feeling other folks have or will
> have similiar questions.
>
> i should've been a bit more explicit about loading servlets
> via url as i'm not sure my explation is exactly what your
> looking for ... but i think it is. here goes:
>
> if you specify a docbase as "http://foo.bar/bop"
> the hosting server effectively will become a
> proxy server forwarding the requests to the
> specified uri
>
> - on the other hand -
>
> if you specify a fully qualified war (web application
> archive) docbase [note: check out jdk 1.2.x JarURLConnection]
> you can effectively pull web applications from across
> the web hosted in a centralized location which inturn
> will get expanded (as a configuration flag) internally.
> such a war docbase looks like:
>
> war:http://foo.bar/bop.war
should be:
war:http://foo.bar!/bop.war
>
> note: from the above you can probably get
> a feeling as to why i would like to see
> an admin tool ... as there are more features
> under the covers that are just dying to be
> exploited.
>
> local (ie file protocol) war docbases look like:
>
> bop.war
> war:file:///bop.war
>
> > changes which would occur if any of its classes changed. This might be a problem
> > though if two servlets share the same library classes in different jar files
> > since other jar files with the same classes may not have changed.
>
> there are problems a plenty ... that doesn't mean we shouldn't
> do it though ... it just means we should probably compare notes
> and tread lightly with respect to class loaders.
>
> >
> > As far as the admin tool is concerned, I think it might be better to make this
> > an optional component to keep the installation and configuration as simple as
> > possible. I don't think people mind editing the XML file.
>
> yep ... that is the the lowest common denominator. that
> said, the hooks to stop/start/add web apps is all there
> in tomcat hence my thoughts quite awhile back as to why
> not build up an admin tool (command line, ui) to start
> taking advantage of the these features.
>
> hope this helps,
>
> - james
>
> >
> > hi jonathan -
> >
> > firstly this is a great topic to continue on
> > the tomcat-dev aliase.
> >
> > regarding the servlet loader it is intended to
> > meet the minimal requirements as specified by
> > the servlet 2.2 spec
> > (http://java.sun.com/products/servlet/2.2), namely
> > web application classes are loaded from WEB-INF/classes
> > and web application libraries are loaded from
> > WEB-INF/lib/*jar. i think this meets some of your
> > requirements.
> >
> > as to class reloading this is a much requested feature
> > which would be nice to address. there are a variety
> > of approaches which have been discussed on this and
> > other aliases. we should continue the discussion and
> > see as to how best to proceed.
> >
> > as to the loading servlets from a url, per servlet 2.2
> > and tomcat's interpretation there of, it is possible
> > to specify a web appliation document base via an http
> > url today. the entire web application can be archived
> > in a war (web application archive) file and distributed
> > from a centralized location.
> >
> > as to the nt and iis issues, good points i hope someone
> > can address.
> >
> > lastly, i've been floating the idea for a bit to
> > kick off a tomcat admin project. to that end i believe
> > there are about 5 or so folks that are interested in
> > proceeding and a couple of other folks who offer opinions
> > from time to time. based on your stated objectives i
> > have a feeling you'd be interested in seeing a more
> > sophisticated administration tool for tomcat.
> >
> > hope this helps,
> >
> > - james
> >
> > Jonathan Pierce wrote:
> > >
> > > Everyone,
> > >
> > > I just downloaded and built the Jakarta TomCat webserver with my Development
> > > environment (CodeWarrior) and tried it out. It seems to work well.
> > >
> > > I have a few features that I'd like to see added to the distribution to make
> > the
> > > standalone version of TomCat more useable for deployment.
> > >
> > > I've written an implementation for many of these features in my own web
> > server,
> > > but have not yet tried to incorporate them into the TomCat sources. Many of
> > > these features also exist in Sun's JavaWebServer product.
> > >
> > > Please let me know whether any of these features are being discussed. I can
> > > assist with the implementation if needed. I'm sure I'm not the only one who
> > > wants to deploy TomCat, not just use it for development.
> > >
> > > 1. Please extend the Servlet Loader to support loading servlets from jar
> > files.
> > > The jar file name can be the name of the servlet without its package, so
> > servlet
> > > Package1.Servlet1 would load from file Servlet1.jar
> > >
> > > 2. Please extend the Servlet Loader to dynamically reload servlets if they
> > have
> > > changed. This can be done if the jar file date is newer that when the servlet
> > > was loaded. This would allow developers to rebuild the servlet without having
> > to
> > > restart the servlet engine.
> > >
> > > 3. Please extend the Servlet Loader to support loading servlets from a URL.
> > > This would allow the same servlet to be deployed on multiple machines to
> > > distribute processing without the need to redistribute it manually.
> > >
> > > 4. Please include in the distribution a procedure for installing the servlet
> > > engine as a service on Windows NT. This can be done using the instsrv.exe and
> > > the SrvAny.exe from the Windows NT resource kit. This would allow the servlet
> > > engine to be restarted automatically when the machine is rebooted. This should
> > > be implemented so that stopping the NT service will shutdown the TomCat
> > > webserver.
> > >
> > > 5. Please consider adding support for Internet Information Server on Windows
> > NT
> > > using an ISAPI extension that forwards requests from port 80 to the TomCat
> > > servlet engine. This is done by the JRun product.
> > >
> > > -Jonathan Pierce
> > > Java Consultant / Web Developer
> > > Seagram Co. Ltd.
> > > E-mail: jonathan_pierce@Seagram.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TomCat Feature Requests
Posted by James Todd <ja...@eng.sun.com>.
typo fix.
- james
James Todd wrote:
>
> [cc'ing tomcat-dev]
>
> Jonathan Pierce wrote:
> >
> > I'm glad to hear that loading servlets from URLs is also supported. I probably
> > should have read more of the documentation before sending my post to the list.
>
> nada problem. i have a feeling other folks have or will
> have similiar questions.
>
> i should've been a bit more explicit about loading servlets
> via url as i'm not sure my explation is exactly what your
> looking for ... but i think it is. here goes:
>
> if you specify a docbase as "http://foo.bar/bop"
> the hosting server effectively will become a
> proxy server forwarding the requests to the
> specified uri
>
> - on the other hand -
>
> if you specify a fully qualified war (web application
> archive) docbase [note: check out jdk 1.2.x JarURLConnection]
> you can effectively pull web applications from across
> the web hosted in a centralized location which inturn
> will get expanded (as a configuration flag) internally.
> such a war docbase looks like:
>
> war:http://foo.bar/bop.war
should be:
war:http://foo.bar!/bop.war
>
> note: from the above you can probably get
> a feeling as to why i would like to see
> an admin tool ... as there are more features
> under the covers that are just dying to be
> exploited.
>
> local (ie file protocol) war docbases look like:
>
> bop.war
> war:file:///bop.war
>
> > changes which would occur if any of its classes changed. This might be a problem
> > though if two servlets share the same library classes in different jar files
> > since other jar files with the same classes may not have changed.
>
> there are problems a plenty ... that doesn't mean we shouldn't
> do it though ... it just means we should probably compare notes
> and tread lightly with respect to class loaders.
>
> >
> > As far as the admin tool is concerned, I think it might be better to make this
> > an optional component to keep the installation and configuration as simple as
> > possible. I don't think people mind editing the XML file.
>
> yep ... that is the the lowest common denominator. that
> said, the hooks to stop/start/add web apps is all there
> in tomcat hence my thoughts quite awhile back as to why
> not build up an admin tool (command line, ui) to start
> taking advantage of the these features.
>
> hope this helps,
>
> - james
>
> >
> > hi jonathan -
> >
> > firstly this is a great topic to continue on
> > the tomcat-dev aliase.
> >
> > regarding the servlet loader it is intended to
> > meet the minimal requirements as specified by
> > the servlet 2.2 spec
> > (http://java.sun.com/products/servlet/2.2), namely
> > web application classes are loaded from WEB-INF/classes
> > and web application libraries are loaded from
> > WEB-INF/lib/*jar. i think this meets some of your
> > requirements.
> >
> > as to class reloading this is a much requested feature
> > which would be nice to address. there are a variety
> > of approaches which have been discussed on this and
> > other aliases. we should continue the discussion and
> > see as to how best to proceed.
> >
> > as to the loading servlets from a url, per servlet 2.2
> > and tomcat's interpretation there of, it is possible
> > to specify a web appliation document base via an http
> > url today. the entire web application can be archived
> > in a war (web application archive) file and distributed
> > from a centralized location.
> >
> > as to the nt and iis issues, good points i hope someone
> > can address.
> >
> > lastly, i've been floating the idea for a bit to
> > kick off a tomcat admin project. to that end i believe
> > there are about 5 or so folks that are interested in
> > proceeding and a couple of other folks who offer opinions
> > from time to time. based on your stated objectives i
> > have a feeling you'd be interested in seeing a more
> > sophisticated administration tool for tomcat.
> >
> > hope this helps,
> >
> > - james
> >
> > Jonathan Pierce wrote:
> > >
> > > Everyone,
> > >
> > > I just downloaded and built the Jakarta TomCat webserver with my Development
> > > environment (CodeWarrior) and tried it out. It seems to work well.
> > >
> > > I have a few features that I'd like to see added to the distribution to make
> > the
> > > standalone version of TomCat more useable for deployment.
> > >
> > > I've written an implementation for many of these features in my own web
> > server,
> > > but have not yet tried to incorporate them into the TomCat sources. Many of
> > > these features also exist in Sun's JavaWebServer product.
> > >
> > > Please let me know whether any of these features are being discussed. I can
> > > assist with the implementation if needed. I'm sure I'm not the only one who
> > > wants to deploy TomCat, not just use it for development.
> > >
> > > 1. Please extend the Servlet Loader to support loading servlets from jar
> > files.
> > > The jar file name can be the name of the servlet without its package, so
> > servlet
> > > Package1.Servlet1 would load from file Servlet1.jar
> > >
> > > 2. Please extend the Servlet Loader to dynamically reload servlets if they
> > have
> > > changed. This can be done if the jar file date is newer that when the servlet
> > > was loaded. This would allow developers to rebuild the servlet without having
> > to
> > > restart the servlet engine.
> > >
> > > 3. Please extend the Servlet Loader to support loading servlets from a URL.
> > > This would allow the same servlet to be deployed on multiple machines to
> > > distribute processing without the need to redistribute it manually.
> > >
> > > 4. Please include in the distribution a procedure for installing the servlet
> > > engine as a service on Windows NT. This can be done using the instsrv.exe and
> > > the SrvAny.exe from the Windows NT resource kit. This would allow the servlet
> > > engine to be restarted automatically when the machine is rebooted. This should
> > > be implemented so that stopping the NT service will shutdown the TomCat
> > > webserver.
> > >
> > > 5. Please consider adding support for Internet Information Server on Windows
> > NT
> > > using an ISAPI extension that forwards requests from port 80 to the TomCat
> > > servlet engine. This is done by the JRun product.
> > >
> > > -Jonathan Pierce
> > > Java Consultant / Web Developer
> > > Seagram Co. Ltd.
> > > E-mail: jonathan_pierce@Seagram.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TomCat Feature Requests
Posted by James Todd <ja...@eng.sun.com>.
[cc'ing tomcat-dev]
Jonathan Pierce wrote:
>
> I'm glad to hear that loading servlets from URLs is also supported. I probably
> should have read more of the documentation before sending my post to the list.
nada problem. i have a feeling other folks have or will
have similiar questions.
i should've been a bit more explicit about loading servlets
via url as i'm not sure my explation is exactly what your
looking for ... but i think it is. here goes:
if you specify a docbase as "http://foo.bar/bop"
the hosting server effectively will become a
proxy server forwarding the requests to the
specified uri
- on the other hand -
if you specify a fully qualified war (web application
archive) docbase [note: check out jdk 1.2.x JarURLConnection]
you can effectively pull web applications from across
the web hosted in a centralized location which inturn
will get expanded (as a configuration flag) internally.
such a war docbase looks like:
war:http://foo.bar/bop.war
note: from the above you can probably get
a feeling as to why i would like to see
an admin tool ... as there are more features
under the covers that are just dying to be
exploited.
local (ie file protocol) war docbases look like:
bop.war
war:file:///bop.war
> changes which would occur if any of its classes changed. This might be a problem
> though if two servlets share the same library classes in different jar files
> since other jar files with the same classes may not have changed.
there are problems a plenty ... that doesn't mean we shouldn't
do it though ... it just means we should probably compare notes
and tread lightly with respect to class loaders.
>
> As far as the admin tool is concerned, I think it might be better to make this
> an optional component to keep the installation and configuration as simple as
> possible. I don't think people mind editing the XML file.
yep ... that is the the lowest common denominator. that
said, the hooks to stop/start/add web apps is all there
in tomcat hence my thoughts quite awhile back as to why
not build up an admin tool (command line, ui) to start
taking advantage of the these features.
hope this helps,
- james
>
> hi jonathan -
>
> firstly this is a great topic to continue on
> the tomcat-dev aliase.
>
> regarding the servlet loader it is intended to
> meet the minimal requirements as specified by
> the servlet 2.2 spec
> (http://java.sun.com/products/servlet/2.2), namely
> web application classes are loaded from WEB-INF/classes
> and web application libraries are loaded from
> WEB-INF/lib/*jar. i think this meets some of your
> requirements.
>
> as to class reloading this is a much requested feature
> which would be nice to address. there are a variety
> of approaches which have been discussed on this and
> other aliases. we should continue the discussion and
> see as to how best to proceed.
>
> as to the loading servlets from a url, per servlet 2.2
> and tomcat's interpretation there of, it is possible
> to specify a web appliation document base via an http
> url today. the entire web application can be archived
> in a war (web application archive) file and distributed
> from a centralized location.
>
> as to the nt and iis issues, good points i hope someone
> can address.
>
> lastly, i've been floating the idea for a bit to
> kick off a tomcat admin project. to that end i believe
> there are about 5 or so folks that are interested in
> proceeding and a couple of other folks who offer opinions
> from time to time. based on your stated objectives i
> have a feeling you'd be interested in seeing a more
> sophisticated administration tool for tomcat.
>
> hope this helps,
>
> - james
>
> Jonathan Pierce wrote:
> >
> > Everyone,
> >
> > I just downloaded and built the Jakarta TomCat webserver with my Development
> > environment (CodeWarrior) and tried it out. It seems to work well.
> >
> > I have a few features that I'd like to see added to the distribution to make
> the
> > standalone version of TomCat more useable for deployment.
> >
> > I've written an implementation for many of these features in my own web
> server,
> > but have not yet tried to incorporate them into the TomCat sources. Many of
> > these features also exist in Sun's JavaWebServer product.
> >
> > Please let me know whether any of these features are being discussed. I can
> > assist with the implementation if needed. I'm sure I'm not the only one who
> > wants to deploy TomCat, not just use it for development.
> >
> > 1. Please extend the Servlet Loader to support loading servlets from jar
> files.
> > The jar file name can be the name of the servlet without its package, so
> servlet
> > Package1.Servlet1 would load from file Servlet1.jar
> >
> > 2. Please extend the Servlet Loader to dynamically reload servlets if they
> have
> > changed. This can be done if the jar file date is newer that when the servlet
> > was loaded. This would allow developers to rebuild the servlet without having
> to
> > restart the servlet engine.
> >
> > 3. Please extend the Servlet Loader to support loading servlets from a URL.
> > This would allow the same servlet to be deployed on multiple machines to
> > distribute processing without the need to redistribute it manually.
> >
> > 4. Please include in the distribution a procedure for installing the servlet
> > engine as a service on Windows NT. This can be done using the instsrv.exe and
> > the SrvAny.exe from the Windows NT resource kit. This would allow the servlet
> > engine to be restarted automatically when the machine is rebooted. This should
> > be implemented so that stopping the NT service will shutdown the TomCat
> > webserver.
> >
> > 5. Please consider adding support for Internet Information Server on Windows
> NT
> > using an ISAPI extension that forwards requests from port 80 to the TomCat
> > servlet engine. This is done by the JRun product.
> >
> > -Jonathan Pierce
> > Java Consultant / Web Developer
> > Seagram Co. Ltd.
> > E-mail: jonathan_pierce@Seagram.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
Re: Re[2]: TomCat Feature Requests
Posted by Glenn Vanderburg <gv...@delphis.com>.
Jonathan_Pierce@seagram.com (Jonathan Pierce) writes:
>
> I agree that we should continue the discussion about the dynamic reloading of
> servlets. Perhaps we can use the same implementation that JavaServer uses. If
> not, I can share my implementation.
Here's a problem I ran into with the JavaServer implementation. I'm
describing it so we (er ... you; I can't guarantee I'll have the time
to actively contribute to Jakarta in the near term) can avoid it.
There's also a chance you can all tell me I was doing something
silly. :-)
I was developing an application where servlets did the initial
processing, retrieving or storing necessary data. Then the request
was forwarded to a JSP that used the data to generate the HTML.
The servlet communicated with the JSP using a bean (the canonical
model for such communication, so far as I can tell).
Since I was developing, I put the servlet in the "servlets" directory,
so that it would be loaded anew each time. That worked well. Except ...
The JSP was compiled into classes that resided elsewhere, and was
loaded using a different class loader. Both the servlet and the JSP
were able to find the bean class, but the different class loaders
loaded the bean class separately, so that it was not *recognized* as
the same class. So I had this interesting experience: the following
directives in my JSP:
<%@ page language="java" import="com.delphis.webapps.foo.*" %>
<jsp:useBean id="fooBean" scope="request" class="FooBean"/>
compiled to code like this:
import com.delphis.webapps.foo.*;
// ...
public void _jspService(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
// ...
FooBean fooBean = (FooBean) request.getAttribute("fooBean");
and when that line of code was executed, I got this:
ClassCastException: com.delphis.webapps.foo.FooBean
I couldn't cast the attribute value to a FooBean because it was a
FooBean.
I understand what was happening, but that doesn't make it any less
annoying.
--
Glenn Vanderburg
Delphi Consultants, LLC
glv@delphis.com
Re: TomCat Feature Requests
Posted by James Todd <ja...@eng.sun.com>.
[cc'ing tomcat-dev]
Jonathan Pierce wrote:
>
> I'm glad to hear that loading servlets from URLs is also supported. I probably
> should have read more of the documentation before sending my post to the list.
nada problem. i have a feeling other folks have or will
have similiar questions.
i should've been a bit more explicit about loading servlets
via url as i'm not sure my explation is exactly what your
looking for ... but i think it is. here goes:
if you specify a docbase as "http://foo.bar/bop"
the hosting server effectively will become a
proxy server forwarding the requests to the
specified uri
- on the other hand -
if you specify a fully qualified war (web application
archive) docbase [note: check out jdk 1.2.x JarURLConnection]
you can effectively pull web applications from across
the web hosted in a centralized location which inturn
will get expanded (as a configuration flag) internally.
such a war docbase looks like:
war:http://foo.bar/bop.war
note: from the above you can probably get
a feeling as to why i would like to see
an admin tool ... as there are more features
under the covers that are just dying to be
exploited.
local (ie file protocol) war docbases look like:
bop.war
war:file:///bop.war
> changes which would occur if any of its classes changed. This might be a problem
> though if two servlets share the same library classes in different jar files
> since other jar files with the same classes may not have changed.
there are problems a plenty ... that doesn't mean we shouldn't
do it though ... it just means we should probably compare notes
and tread lightly with respect to class loaders.
>
> As far as the admin tool is concerned, I think it might be better to make this
> an optional component to keep the installation and configuration as simple as
> possible. I don't think people mind editing the XML file.
yep ... that is the the lowest common denominator. that
said, the hooks to stop/start/add web apps is all there
in tomcat hence my thoughts quite awhile back as to why
not build up an admin tool (command line, ui) to start
taking advantage of the these features.
hope this helps,
- james
>
> hi jonathan -
>
> firstly this is a great topic to continue on
> the tomcat-dev aliase.
>
> regarding the servlet loader it is intended to
> meet the minimal requirements as specified by
> the servlet 2.2 spec
> (http://java.sun.com/products/servlet/2.2), namely
> web application classes are loaded from WEB-INF/classes
> and web application libraries are loaded from
> WEB-INF/lib/*jar. i think this meets some of your
> requirements.
>
> as to class reloading this is a much requested feature
> which would be nice to address. there are a variety
> of approaches which have been discussed on this and
> other aliases. we should continue the discussion and
> see as to how best to proceed.
>
> as to the loading servlets from a url, per servlet 2.2
> and tomcat's interpretation there of, it is possible
> to specify a web appliation document base via an http
> url today. the entire web application can be archived
> in a war (web application archive) file and distributed
> from a centralized location.
>
> as to the nt and iis issues, good points i hope someone
> can address.
>
> lastly, i've been floating the idea for a bit to
> kick off a tomcat admin project. to that end i believe
> there are about 5 or so folks that are interested in
> proceeding and a couple of other folks who offer opinions
> from time to time. based on your stated objectives i
> have a feeling you'd be interested in seeing a more
> sophisticated administration tool for tomcat.
>
> hope this helps,
>
> - james
>
> Jonathan Pierce wrote:
> >
> > Everyone,
> >
> > I just downloaded and built the Jakarta TomCat webserver with my Development
> > environment (CodeWarrior) and tried it out. It seems to work well.
> >
> > I have a few features that I'd like to see added to the distribution to make
> the
> > standalone version of TomCat more useable for deployment.
> >
> > I've written an implementation for many of these features in my own web
> server,
> > but have not yet tried to incorporate them into the TomCat sources. Many of
> > these features also exist in Sun's JavaWebServer product.
> >
> > Please let me know whether any of these features are being discussed. I can
> > assist with the implementation if needed. I'm sure I'm not the only one who
> > wants to deploy TomCat, not just use it for development.
> >
> > 1. Please extend the Servlet Loader to support loading servlets from jar
> files.
> > The jar file name can be the name of the servlet without its package, so
> servlet
> > Package1.Servlet1 would load from file Servlet1.jar
> >
> > 2. Please extend the Servlet Loader to dynamically reload servlets if they
> have
> > changed. This can be done if the jar file date is newer that when the servlet
> > was loaded. This would allow developers to rebuild the servlet without having
> to
> > restart the servlet engine.
> >
> > 3. Please extend the Servlet Loader to support loading servlets from a URL.
> > This would allow the same servlet to be deployed on multiple machines to
> > distribute processing without the need to redistribute it manually.
> >
> > 4. Please include in the distribution a procedure for installing the servlet
> > engine as a service on Windows NT. This can be done using the instsrv.exe and
> > the SrvAny.exe from the Windows NT resource kit. This would allow the servlet
> > engine to be restarted automatically when the machine is rebooted. This should
> > be implemented so that stopping the NT service will shutdown the TomCat
> > webserver.
> >
> > 5. Please consider adding support for Internet Information Server on Windows
> NT
> > using an ISAPI extension that forwards requests from port 80 to the TomCat
> > servlet engine. This is done by the JRun product.
> >
> > -Jonathan Pierce
> > Java Consultant / Web Developer
> > Seagram Co. Ltd.
> > E-mail: jonathan_pierce@Seagram.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org