You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Jan-Henrik Haukeland <ha...@tildeslash.com> on 1999/10/18 23:59:45 UTC
a few comments
Great to finally be able to browse through the tomcat code. I have a
few observations/questions (that are probably already on someones
agenda, but since they are not mentioned in the TODO file I though I
would bring them up here for clarification)
1) We need a real Logger for servlets and the engine. Is this going to
be moved from JSERV1_1DEV to Tomcat?
2) It would have been great if we could design the Servlet class
loader like we have in JSERV1_1DEV so that we can have pluggable
ClassLoaders. That way we can (e.g.) have a Java2 classloader that can
give servlets loaded a code source, so it's possible to control
security permissions for servlets loaded via a Policy file. This is
important in a multi hosting servlet environment, for example for ISPs
that are hosting servlets.
3) I hope that the Valve concept from JSERV1_1DEV will not be lost and
moved to Tomcat, so it's possible to pre/post process a request/respons.
Are there any plans for doing this?
4) What does this warning in some of the class files means:
// WARNING: Some of the APIs in this class are used by J2EE.
// Please talk to harishp@eng.sun.com before making any changes.
Does this mean that development of the J2EE component collection is
dependent of Tomcat? I know that Servlets/JSP are supposed to be a
part of J2EE, but is this coupling so close to create limitations
on class and method names/signatures?
5) Is the Tomact package design frozen or is it possible to break it
up into a more general, pluggable and flexible structure like what we
have in JSERV1_1DEV?
--
Jan-Henrik Haukeland
Re: Problem with isWorkDirPersistent
Posted by "Anil K. Vijendran" <ak...@eng.sun.com>.
Hi Luc,
I'll get someone to test this soon. This hasn't been tested in a while with
so many changes going on.
Glad you find things easy to build and use.
Luc Saint-Elie wrote:
> Bonjour (Hello)
>
> System : P200/64mb/NT4SP4
> Version : jakarta-tomcat_19991018194940_tar.gz
>
> Every things goes fine (and congratulations to Apache/SUN/IBM guys for
> making build tools so easy to use for non specialists..) except that
> setting isWorkDirPersistent to true crashes my JVM (setting to false and
> evry thing runs without problem)
>
> Any idea ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
Peace, Anil +<:-)
Problem with isWorkDirPersistent
Posted by Luc Saint-Elie <ls...@imaginet.fr>.
Bonjour (Hello)
System : P200/64mb/NT4SP4
Version : jakarta-tomcat_19991018194940_tar.gz
Every things goes fine (and congratulations to Apache/SUN/IBM guys for
making build tools so easy to use for non specialists..) except that
setting isWorkDirPersistent to true crashes my JVM (setting to false and
evry thing runs without problem)
Any idea ?
Re: symlinks in webapps under jakarta?
Posted by ja...@almery.com.
Harish Prabandham writes:
> The reason why the check is performed is the following:
>
> On Windows,
>
> foo.html and foo.html. are treated as the one and the same
> file.
>
> If you protect foo.html, and request foo.html. then the no
> security checks are performed.
>
> Several companies got a lot of adverse press about an
> year and a half ago for not catching this ......
>
>
> There are other issues involved in not doing the checks
> but I can't think of them rightaway......
>
>
> For now please leave the check in there.....
I would like to suggest some documentation, then, both in the source
file and the FAQ about why symlinks cannot be used on Unix systems.
It might save someone else an hour of head scratching, and you won't
have to answer this question again and again.
<patch>
Index: faq
===================================================================
RCS file: /home/cvspublic/jakarta-tomcat/src/etc/faq,v
retrieving revision 1.3
diff -u -r1.3 faq
--- faq 1999/10/16 20:46:55 1.3
+++ faq 1999/10/19 02:40:43
@@ -15,7 +15,7 @@
* Three, you're using JDK 1.1.x on a Windows platform. It's
a known bug (see Readme) that the server doesn't serve files
in this configuration. Use JDK 1.2.x instead.
- * And four, on a Windows platform you have installed Tomcat in
+ * Four, on a Windows platform you have installed Tomcat in
a directory with a path part longer than 8 characters, e.g.
C:\Program Files\jakarta, and run the "startup" script from
a command tool after you have cd'd to the directory using
@@ -28,6 +28,12 @@
> cd "C:\Program Files\jakarta"
> startup
+ * Five, on a Unix platform, you are attempting to access a file
+ that is a symbolic link. Due to limitations in the Windows
+ platform, a check is made in
+ org.apache.tomcat.core.DefaultServlet that tests whether the
+ absolute name of a file equals the canonical name. This test
+ precludes the use of symbolic links.
Q: I am getting a 500 Error, what does it mean?
</patch>
<patch>
Index: DefaultServlet.java
===================================================================
RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/DefaultServlet.java,v
retrieving revision 1.2
diff -u -r1.2 DefaultServlet.java
--- DefaultServlet.java 1999/10/15 00:34:30 1.2
+++ DefaultServlet.java 1999/10/19 02:45:23
@@ -351,6 +351,7 @@
absPath = FilePathUtil.patch(absPath);
+ // this test prevents symlinks from being served on Unix platforms
if (! absPath.equals(canPath)) {
response.sendError(response.SC_NOT_FOUND);
</patch>
--
Jay Doane | vivid studios | doane@vivid.com
Re: symlinks in webapps under jakarta?
Posted by James Davidson <du...@x180.com>.
> There are other issues involved in not doing the checks
> but I can't think of them rightaway......
Case sensitivity, or lack thereof on Windows. This catches that a request to
"/foo/bar" is not the same as "fOO/bAR".
Also, foo.jsp. doesn't get mapped to the JSP servlet, but goes to the
default servlet which shoves out the content of the file -- bad bad bad bad.
Any other solution is going to be *much* more involved and will have to be
tested thouroughly. This means whoever comes up with a better fix needs to
provide a comprehensive set of tests to make sure it doesn't bust.
.duncan
Re: symlinks in webapps under jakarta?
Posted by Harish Prabandham <Ha...@Eng.Sun.COM>.
The reason why the check is performed is the following:
On Windows,
foo.html and foo.html. are treated as the one and the same
file.
If you protect foo.html, and request foo.html. then the no
security checks are performed.
Several companies got a lot of adverse press about an
year and a half ago for not catching this ......
There are other issues involved in not doing the checks
but I can't think of them rightaway......
For now please leave the check in there.....
Thanx
Harish
ja@almery.com wrote:
> ja@almery.com writes:
>
> > I created a file: examples/foo.html, which I can access fine from
> > http://localhost:8080/examples/foo.html
> >
> > But when I create a symlink to foo.html in the same directory, called
> > bar.html, and try to access http://localhost:8080/examples/bar.html,
> > I get "Error: 404\n No detailed message".
> >
> > Is this a bug? feature?
> >
> > Server Info: Tomcat Web Server/2.2 (JSP 1.1; Servlet 2.2; Java
> > 1.3beta; SunOS 5.6 sparc; java.vendor=Sun Microsystems Inc.)
>
> Well, I tracked down the reason that symlinks won't work. There is a
> line (~354) in org.apache.tomcat.core.DefaultServlet that compares a
> file's absolute and canonical names, and refuses to serve it if they
> don't match. A simple (and almost certainly wrong) solution is to
> remove the test.
>
> What is the reason that this comparison is made?
>
> Jay
> --
> Jay Doane | vivid studios | doane@vivid.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
symlinks in webapps under jakarta?
Posted by ja...@almery.com.
ja@almery.com writes:
> I created a file: examples/foo.html, which I can access fine from
> http://localhost:8080/examples/foo.html
>
> But when I create a symlink to foo.html in the same directory, called
> bar.html, and try to access http://localhost:8080/examples/bar.html,
> I get "Error: 404\n No detailed message".
>
> Is this a bug? feature?
>
> Server Info: Tomcat Web Server/2.2 (JSP 1.1; Servlet 2.2; Java
> 1.3beta; SunOS 5.6 sparc; java.vendor=Sun Microsystems Inc.)
Well, I tracked down the reason that symlinks won't work. There is a
line (~354) in org.apache.tomcat.core.DefaultServlet that compares a
file's absolute and canonical names, and refuses to serve it if they
don't match. A simple (and almost certainly wrong) solution is to
remove the test.
What is the reason that this comparison is made?
Jay
--
Jay Doane | vivid studios | doane@vivid.com
symlinks in webapps under jakarta?
Posted by ja...@almery.com.
Hi,
I created a file: examples/foo.html, which I can access fine from
http://localhost:8080/examples/foo.html
But when I create a symlink to foo.html in the same directory, called
bar.html, and try to access http://localhost:8080/examples/bar.html,
I get "Error: 404\n No detailed message".
Is this a bug? feature?
Server Info: Tomcat Web Server/2.2 (JSP 1.1; Servlet 2.2; Java
1.3beta; SunOS 5.6 sparc; java.vendor=Sun Microsystems Inc.)
Thanks,
Jay
--
Jay Doane | vivid studios | doane@vivid.com
Re: a few comments
Posted by James Davidson <du...@x180.com>.
> > BTW, It doesn't look like Servlets are reloaded if the originating
> > source file (class/jar file) is changed, did I miss something and if
> > not, is this intentionally?
>
> I believe this is not implemented yet. I would imagine the only way this
can be
> done is by creating a new classloader. Unfortunately, we didn't have an
> opportunity to do that in the past because of issues involving classes in
one
> loader trying to access classes in another. This hasn't been a hot button
in the
> past because people can always create a new context and put the new
servlet there.
> Agreed, this is not great.
To add just a little bit more, it's made harder by new spec requirements
that when a servlet needs to be reloaded, you really need to drop the
context and recreate it so that you don't have any chance of
classcastexceptions or static refereces going awry.
Jon has dealt with this and can tell you that it's not a walk in the park.
.duncan
Re: a few comments
Posted by Craig McClanahan <cm...@mytownnet.com>.
"Anil K. Vijendran" wrote:
> Jan-Henrik Haukeland wrote:
>
> > Another thing, it would have been greate if we could use something
> > similar to Craig's LifeCycle interface (from JSERV1_1DEV), such a
> > design makes it easier to manage pluggable components like a Loader
> > and Logger (and so on).
>
> This sounds interesting. Can you explain more? Thanks.
>
I can take a crack at this one.
The JSERV1_1DEV architecture was based on making nearly every piece of the servlet
container a plug-replaceable component. The configuration file allowed you to select
a particular Java class to implement your context, your virtual host, your session
manager (so you could plug in session persistence, for example), and so on. Even the
Valves that were added (similar in concept to Interceptors in Tomcat) could be
selected dynamically at configure time.
The challenge in all of these cases was to conveniently initialize all these
components. Constructors with arguments were out, because I wanted to use
Class.newInstance() to create them. Hence, I needed a common interface that made
initialization easy. While I was at it, we added generalized "start" and "stop" calls
as well, so that a component could do graceful startup and shutdown too. The result
is an interface called Lifecycle, with three methods:
public interface Lifecycle {
public void configure(Properties props, String prefix)
throws LifecycleException;
public void start() throws LifecycleException;
public void stop() throws LifecycleException;
}
The general model for instantiating a new object went like this:
* Identify the class name of the implementation class
(from a config parameter or default setting)
* Create a new instance of that class.
* If the implementation class is an instance of
Lifecycle, call it's configure method and pass
on a Properties object and a property name
prefix. (In a Tomcat based implementation
this would probably be an XMLTree of the
portion of the configuration that is relevant
to this component).
The configure() method is conceptually similar to the init() method of a servlet, and
stop() is conceptually similar to destroy(). I separated the "start processing
requests" method from initialization because I liked the ability to reconfigure by
doing: stop(), configure(), start() -- they probably don't really have to be
different.
This model proved to be quite flexible and easy to understand, and I would recommend
it highly for Tomcat components. However, we should also examine the current state of
the Avalon framework (on the java.apache.org site), which was not fleshed out in
nearly the current level of detail when I needed LIfecycle. Avalon's "block" concept
is supposed to include lifecycle type support and a bunch of other things.
Craig McClanahan
Re: a few comments
Posted by "Anil K. Vijendran" <ak...@eng.sun.com>.
Jan-Henrik Haukeland wrote:
> "Craig R. McClanahan" <cm...@mytownnet.com> writes:
>
> > > > 2) It would have been great if we could design the Servlet class
> > > > loader like we have in JSERV1_1DEV so that we can have pluggable
> > > > ClassLoaders. That way we can (e.g.) have a Java2 classloader that can
> > > > give servlets loaded a code source, so it's possible to control
> > > > security permissions for servlets loaded via a Policy file. This is
> > > > important in a multi hosting servlet environment, for example for ISPs
> > > > that are hosting servlets.
> > >
> > > Yep. Once again, this would be great to see.
> > >
> >
> > Haven't thought about this one at all yet, but agree that it would be great.
>
> If you find it interesting, I could try to port the Loader interface
> and SecureLoader to Tomcat. In addition most of the methods in the
> current ServletLoader should probably be moved to a LoaderUtil class
> so that different class loaders can re-use code and use a LoaderUtil
> class for delegation.
>
> From what I have seen of the code after a quick browse, this will
> include work to create a Loader interface similar to what we have in
> JSERV1_1DEV and have org.apache.tomcat.core.ServletLoader implement
> this and make org.apache.tomcat.core.Container use a Loader type
> instead. This should be transparent to the rest of the codebase.
An alternative is to have the ability to set a delegate on ServletLoader. This
delegate is a ClassLoader. This is how the J2EE implementation does it.
> BTW, It doesn't look like Servlets are reloaded if the originating
> source file (class/jar file) is changed, did I miss something and if
> not, is this intentionally?
I believe this is not implemented yet. I would imagine the only way this can be
done is by creating a new classloader. Unfortunately, we didn't have an
opportunity to do that in the past because of issues involving classes in one
loader trying to access classes in another. This hasn't been a hot button in the
past because people can always create a new context and put the new servlet there.
Agreed, this is not great.
> Another thing, it would have been greate if we could use something
> similar to Craig's LifeCycle interface (from JSERV1_1DEV), such a
> design makes it easier to manage pluggable components like a Loader
> and Logger (and so on).
This sounds interesting. Can you explain more? Thanks.
--
Peace, Anil +<:-)
Re: a few comments
Posted by Jan-Henrik Haukeland <ha...@tildeslash.com>.
"Craig R. McClanahan" <cm...@mytownnet.com> writes:
> > > 2) It would have been great if we could design the Servlet class
> > > loader like we have in JSERV1_1DEV so that we can have pluggable
> > > ClassLoaders. That way we can (e.g.) have a Java2 classloader that can
> > > give servlets loaded a code source, so it's possible to control
> > > security permissions for servlets loaded via a Policy file. This is
> > > important in a multi hosting servlet environment, for example for ISPs
> > > that are hosting servlets.
> >
> > Yep. Once again, this would be great to see.
> >
>
> Haven't thought about this one at all yet, but agree that it would be great.
If you find it interesting, I could try to port the Loader interface
and SecureLoader to Tomcat. In addition most of the methods in the
current ServletLoader should probably be moved to a LoaderUtil class
so that different class loaders can re-use code and use a LoaderUtil
class for delegation.
Re: a few comments
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
[Moving this discussion to TOMCAT-DEV where it really belongs]
James Davidson wrote:
> > 1) We need a real Logger for servlets and the engine. Is this going to
> > be moved from JSERV1_1DEV to Tomcat?
>
> I'd be happy to see this done. We just need to make sure that whatever we do
> is pluggable so that other folks can plug in their own logger if they embed
> the server into their application (like the J2EE RI does).
>
There are actually a couple different types of loggers that might be
appropriate. Here's a suggestion on how to deal with each of them:
* The output from ServletContext.log() and friends:
Consistent with the new packaging structure I'm working on for
security realms, it seems reasonable to define a new package:
org.apache.tomcat.logger
with a Logger interface that matches the various log()
signatures in ServletContext. Context would simply
delegate its log calls to a Logger instance whose real
class is selected at configure time. The default class
would just write to System.out or whatever it does now.
We need a consistent way to configure the class names
of all these components. Originally I was thinking to
add attributes to the server.dtd, but context initialization
parameters can deal with most of this, using mechanisms
that already exist.
* Web server type access log:
In JSERV1_1DEV this was done with a "Valve", which
is somewhat similar to an Interceptor in the Tomcat
architecture. I haven't looked in detail, but I think you
could do this kind of logging in a postInvoke() method.
I want to look at the Interceptor approach in more
depth before suggesting any changes -- but it seems
reasonable to think that most things Valves can do
will be possible with Interceptors as well.
* Debugging logs:
Personally, I've felt the Apache JServ 1.0 mechanisms
of filtering messages based on "channels" was overkill
for a servlet container, and pretty application specific
to boot. For my own apps, I use ServletContext.log()
with keywords in the message string that I can "grep"
for to find information from a particular source, or
related to a particular error.
>
> > 2) It would have been great if we could design the Servlet class
> > loader like we have in JSERV1_1DEV so that we can have pluggable
> > ClassLoaders. That way we can (e.g.) have a Java2 classloader that can
> > give servlets loaded a code source, so it's possible to control
> > security permissions for servlets loaded via a Policy file. This is
> > important in a multi hosting servlet environment, for example for ISPs
> > that are hosting servlets.
>
> Yep. Once again, this would be great to see.
>
Haven't thought about this one at all yet, but agree that it would be great.
>
> > 3) I hope that the Valve concept from JSERV1_1DEV will not be lost and
> > moved to Tomcat, so it's possible to pre/post process a request/respons.
> > Are there any plans for doing this?
>
> I don't know of any yet. Feel free. :)
>
As above, I think Interceptors will play this role, perhaps after being
generalized a little. One thing we need to be able to do is intercept service
requests to the whole container, and to the ContextManager, so that an
administrator can configure things globally. One of the needs for this
(authentication and access control) are being dealt with separately because of
the 2.2 spec requirements, but there are other reasons to want global
interceptors.
>
> > 4) What does this warning in some of the class files means:
> > // WARNING: Some of the APIs in this class are used by J2EE.
> > // Please talk to harishp@eng.sun.com before making any changes.
> >
> > Does this mean that development of the J2EE component collection is
> > dependent of Tomcat? I know that Servlets/JSP are supposed to be a
> > part of J2EE, but is this coupling so close to create limitations
> > on class and method names/signatures?
>
> The J2EE Reference Implementation uses Tomcat at it's servlet / jsp
> container. This warning means that the RI team relies upon that interface.
> It's a little bit confusing as it *doesn't* mean that J2EE itself relies up
> on it. Just the RI.
>
> > 5) Is the Tomact package design frozen or is it possible to break it
> > up into a more general, pluggable and flexible structure like what we
> > have in JSERV1_1DEV?
>
> It's open source. It's never frozen. :) However, it has to be able to
> satisfy the following:
>
> 1) Standalone operation
> 2) Connected operation with Apache via a variety of mechanisms
> 3) Connected operation with other web servers
> 4) Embedded operation (like in the J2EE RI)
>
> Craig is busy in the source, so I'd bet that he's already got a plan for
> moving stuff into place. :)
>
I wouldn't call it a plan yet, but certainly a lot of ideas ;-). With
JSERV1_1DEV we had the luxury of building an architecture from the ground up --
here, the pragmatic course would be to evolve Tomcat into a more
component-based architecture that makes it easier to plug in to other server
environments, easier to add connectors to, and still powerful enough to run
stand alone. There is *lots* of fun to be had.
>
> .duncan
>
Craig
Re: a few comments
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
[Moving this discussion to TOMCAT-DEV where it really belongs]
James Davidson wrote:
> > 1) We need a real Logger for servlets and the engine. Is this going to
> > be moved from JSERV1_1DEV to Tomcat?
>
> I'd be happy to see this done. We just need to make sure that whatever we do
> is pluggable so that other folks can plug in their own logger if they embed
> the server into their application (like the J2EE RI does).
>
There are actually a couple different types of loggers that might be
appropriate. Here's a suggestion on how to deal with each of them:
* The output from ServletContext.log() and friends:
Consistent with the new packaging structure I'm working on for
security realms, it seems reasonable to define a new package:
org.apache.tomcat.logger
with a Logger interface that matches the various log()
signatures in ServletContext. Context would simply
delegate its log calls to a Logger instance whose real
class is selected at configure time. The default class
would just write to System.out or whatever it does now.
We need a consistent way to configure the class names
of all these components. Originally I was thinking to
add attributes to the server.dtd, but context initialization
parameters can deal with most of this, using mechanisms
that already exist.
* Web server type access log:
In JSERV1_1DEV this was done with a "Valve", which
is somewhat similar to an Interceptor in the Tomcat
architecture. I haven't looked in detail, but I think you
could do this kind of logging in a postInvoke() method.
I want to look at the Interceptor approach in more
depth before suggesting any changes -- but it seems
reasonable to think that most things Valves can do
will be possible with Interceptors as well.
* Debugging logs:
Personally, I've felt the Apache JServ 1.0 mechanisms
of filtering messages based on "channels" was overkill
for a servlet container, and pretty application specific
to boot. For my own apps, I use ServletContext.log()
with keywords in the message string that I can "grep"
for to find information from a particular source, or
related to a particular error.
>
> > 2) It would have been great if we could design the Servlet class
> > loader like we have in JSERV1_1DEV so that we can have pluggable
> > ClassLoaders. That way we can (e.g.) have a Java2 classloader that can
> > give servlets loaded a code source, so it's possible to control
> > security permissions for servlets loaded via a Policy file. This is
> > important in a multi hosting servlet environment, for example for ISPs
> > that are hosting servlets.
>
> Yep. Once again, this would be great to see.
>
Haven't thought about this one at all yet, but agree that it would be great.
>
> > 3) I hope that the Valve concept from JSERV1_1DEV will not be lost and
> > moved to Tomcat, so it's possible to pre/post process a request/respons.
> > Are there any plans for doing this?
>
> I don't know of any yet. Feel free. :)
>
As above, I think Interceptors will play this role, perhaps after being
generalized a little. One thing we need to be able to do is intercept service
requests to the whole container, and to the ContextManager, so that an
administrator can configure things globally. One of the needs for this
(authentication and access control) are being dealt with separately because of
the 2.2 spec requirements, but there are other reasons to want global
interceptors.
>
> > 4) What does this warning in some of the class files means:
> > // WARNING: Some of the APIs in this class are used by J2EE.
> > // Please talk to harishp@eng.sun.com before making any changes.
> >
> > Does this mean that development of the J2EE component collection is
> > dependent of Tomcat? I know that Servlets/JSP are supposed to be a
> > part of J2EE, but is this coupling so close to create limitations
> > on class and method names/signatures?
>
> The J2EE Reference Implementation uses Tomcat at it's servlet / jsp
> container. This warning means that the RI team relies upon that interface.
> It's a little bit confusing as it *doesn't* mean that J2EE itself relies up
> on it. Just the RI.
>
> > 5) Is the Tomact package design frozen or is it possible to break it
> > up into a more general, pluggable and flexible structure like what we
> > have in JSERV1_1DEV?
>
> It's open source. It's never frozen. :) However, it has to be able to
> satisfy the following:
>
> 1) Standalone operation
> 2) Connected operation with Apache via a variety of mechanisms
> 3) Connected operation with other web servers
> 4) Embedded operation (like in the J2EE RI)
>
> Craig is busy in the source, so I'd bet that he's already got a plan for
> moving stuff into place. :)
>
I wouldn't call it a plan yet, but certainly a lot of ideas ;-). With
JSERV1_1DEV we had the luxury of building an architecture from the ground up --
here, the pragmatic course would be to evolve Tomcat into a more
component-based architecture that makes it easier to plug in to other server
environments, easier to add connectors to, and still powerful enough to run
stand alone. There is *lots* of fun to be had.
>
> .duncan
>
Craig
Re: a few comments
Posted by James Davidson <du...@x180.com>.
> 1) We need a real Logger for servlets and the engine. Is this going to
> be moved from JSERV1_1DEV to Tomcat?
I'd be happy to see this done. We just need to make sure that whatever we do
is pluggable so that other folks can plug in their own logger if they embed
the server into their application (like the J2EE RI does).
> 2) It would have been great if we could design the Servlet class
> loader like we have in JSERV1_1DEV so that we can have pluggable
> ClassLoaders. That way we can (e.g.) have a Java2 classloader that can
> give servlets loaded a code source, so it's possible to control
> security permissions for servlets loaded via a Policy file. This is
> important in a multi hosting servlet environment, for example for ISPs
> that are hosting servlets.
Yep. Once again, this would be great to see.
> 3) I hope that the Valve concept from JSERV1_1DEV will not be lost and
> moved to Tomcat, so it's possible to pre/post process a request/respons.
> Are there any plans for doing this?
I don't know of any yet. Feel free. :)
> 4) What does this warning in some of the class files means:
> // WARNING: Some of the APIs in this class are used by J2EE.
> // Please talk to harishp@eng.sun.com before making any changes.
>
> Does this mean that development of the J2EE component collection is
> dependent of Tomcat? I know that Servlets/JSP are supposed to be a
> part of J2EE, but is this coupling so close to create limitations
> on class and method names/signatures?
The J2EE Reference Implementation uses Tomcat at it's servlet / jsp
container. This warning means that the RI team relies upon that interface.
It's a little bit confusing as it *doesn't* mean that J2EE itself relies up
on it. Just the RI.
> 5) Is the Tomact package design frozen or is it possible to break it
> up into a more general, pluggable and flexible structure like what we
> have in JSERV1_1DEV?
It's open source. It's never frozen. :) However, it has to be able to
satisfy the following:
1) Standalone operation
2) Connected operation with Apache via a variety of mechanisms
3) Connected operation with other web servers
4) Embedded operation (like in the J2EE RI)
Craig is busy in the source, so I'd bet that he's already got a plan for
moving stuff into place. :)
.duncan