Patches and TC 4.1

[Remy Maucherat <re...@apache.org>]

> David Weinrich wrote:
>
> Now that it's an Apache project, I am +1 for using it ... both here, and
as an
> implementation of org.apache.catalina.Logger for the general purpose
logging
> that goes on inside Catalina.

+1.
Will it be required to build ?

> I will be examining your patches (and Kief's work on session persistence)
over
> the weekend -- look for some commits and/or questions later on.

I was planning to do that, but as I already have a number of items in my
tasklist it would have taken a while before I applied them.

TC 4.1 should be running fine again. There are no known issues (even with
WebDAV) except an unimplemented call in the ServletContext.
The "old" Resources are now gone and replaced with JNDI DirContext. After a
few adjustements are made, the DefaultServlet / WebdavServlet should be able
to serve resources from any DirContext implementation (of course, if the
result of a lookup isn't the special wrapper type Resource or an input
stream, the string representation of the object will be served, which isn't
that useful).

The JARs which are in the /WEB-INF/lib directory in the webapp are still
loaded from the filesystem, which may or may not be a problem. Classes in
/WEB-INF/classes are correctly loaded through URLs. I know why this happen,
and there's no easy way around. One solution I found is providing a more
complete classloader for the webapps. I'll try to do that, see how good or
bad it turns out, and commit it if it works ok (it will be called
WebappClassLoader).

I'll probably do some clenup work in DefaultServlet and WebdavServlet next,
as the algorithms could be made more efficient (they were adapted for the
Resources' naming conventions, which were not the same as the JNDI naming
conventions).

I'd like to make a few proposals :
- Move the org.apache.naming package and subpackages, which is part of the
Catalina subproject right now, and make it an independent Tomcat subproject.
- Do the same for the org.apache.catalina.util package (and rename it
org.apache.tomcat.util).

Remy

Re: Patches and TC 4.1

[Remy Maucherat <re...@apache.org>]

> Remy Maucherat wrote:

> I have an issue with 4.1 code (fresh from CVS) at the moment -- the JSP
examples
> do not run correctly.  That is, any JSP page that references a bean class
that
> is loaded from WEB-INF/classes or WEB-INF/lib fails to find that class.

The classpath generation for Jasper was broken. It should be fixed now.

> > I'd like to make a few proposals :
> > - Move the org.apache.naming package and subpackages, which is part of
the
> > Catalina subproject right now, and make it an independent Tomcat
subproject.
> > - Do the same for the org.apache.catalina.util package (and rename it
> > org.apache.tomcat.util).
> >
>
> By this, do you mean make them separate top-level subdirectories under
> jakarta-tomcat-4.1?

Yes.

> If so, I'm +1.

Ok, I'll make the changes next week.

Remy

Re: Patches and TC 4.1

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Remy Maucherat wrote:

> > David Weinrich wrote:
> >
> > Now that it's an Apache project, I am +1 for using it ... both here, and
> as an
> > implementation of org.apache.catalina.Logger for the general purpose
> logging
> > that goes on inside Catalina.
>
> +1.
> Will it be required to build ?
>

If we agree to use it (log4j) to implement standard functionality, then it
will.  If we use it only for optional stuff, we could make the build scripts
smart enough to recognize this and not compile the optional features, although
IMHO this is *much* more confusing to users who expect a binary distribution to
be "complete".

>
> > I will be examining your patches (and Kief's work on session persistence)
> over
> > the weekend -- look for some commits and/or questions later on.
>
> I was planning to do that, but as I already have a number of items in my
> tasklist it would have taken a while before I applied them.
>
> TC 4.1 should be running fine again. There are no known issues (even with
> WebDAV) except an unimplemented call in the ServletContext.
> The "old" Resources are now gone and replaced with JNDI DirContext. After a
> few adjustements are made, the DefaultServlet / WebdavServlet should be able
> to serve resources from any DirContext implementation (of course, if the
> result of a lookup isn't the special wrapper type Resource or an input
> stream, the string representation of the object will be served, which isn't
> that useful).
>

I have an issue with 4.1 code (fresh from CVS) at the moment -- the JSP examples
do not run correctly.  That is, any JSP page that references a bean class that
is loaded from WEB-INF/classes or WEB-INF/lib fails to find that class.

>
> The JARs which are in the /WEB-INF/lib directory in the webapp are still
> loaded from the filesystem, which may or may not be a problem. Classes in
> /WEB-INF/classes are correctly loaded through URLs. I know why this happen,
> and there's no easy way around. One solution I found is providing a more
> complete classloader for the webapps. I'll try to do that, see how good or
> bad it turns out, and commit it if it works ok (it will be called
> WebappClassLoader).
>
> I'll probably do some clenup work in DefaultServlet and WebdavServlet next,
> as the algorithms could be made more efficient (they were adapted for the
> Resources' naming conventions, which were not the same as the JNDI naming
> conventions).
>
> I'd like to make a few proposals :
> - Move the org.apache.naming package and subpackages, which is part of the
> Catalina subproject right now, and make it an independent Tomcat subproject.
> - Do the same for the org.apache.catalina.util package (and rename it
> org.apache.tomcat.util).
>

By this, do you mean make them separate top-level subdirectories under
jakarta-tomcat-4.1?  If so, I'm +1.

>
> Remy
>

Craig