[PROPOSAL] UDP support for Catalina

[Diether Samaey <di...@alcatel.be>]

Catalina currently only supports TCP (through ServerSockets), are there any
plans to support UDP in the near future ?  Some (non-HTTP) servlet
implementations (e.g. SIP-servlets) might need it for communication with
UDP-only clients.

Cheers,

Diether

Re: [Catalina] Resources

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

> Remy Maucherat wrote:
>
> > java.lang.IllegalArgumentException: Context relative path
> > \jsp\dates\date.jsp must start with /
> >  at
> >
org.apache.tomcat.resources.ResourcesBase.validate(ResourcesBase.java:1107)
> >  at
> >
org.apache.tomcat.resources.FileResources.getRealPath(FileResources.java:165
> > )
> >  at
> >
org.apache.tomcat.core.ApplicationContext.getRealPath(ApplicationContext.jav
> > a:333)
> >  at
> >
org.apache.jasper.JspEngineContext.getRealPath(JspEngineContext.java:359)
> > <snip/>
> >
> > I guess the validate method has to be made more tolerant ...
>
> I'm OK with translating "\" to "/", I guess, but it should be done
> consistently,
> and very early in each of the spots validate() is already called --
> perhaps:
>
>     path = normalize(path);
>     validate(path);
>
> and the "normalize" method can do this change if it needs to.

I'll fix that this evening (unless you fix it before, of course).

> True ... but we can embed smartness in a properties file where the key
> is the
> URL scheme and the value is class name to use; basically the way
> Authenticators
> are looked up based on login method.  That way, people using Catalina
> can add
> custom extensions to the list of supported resource bases by defining
> their own
> URL scheme prefixes -- which they are going to have to do anyway to
> return
> something useful from getResource() -- and add a mapping to a property
> file with
> no changes to the code of ContextConfig.
>
> The default should be to use FileResources if we can't figure out
> anything
> else.  That covers the case where a relative or absolute pathname is
> used
> without the "file:" prefix.

All right, that makes sense.

> > [snip]
> > And if you look at my implementation, you'll notice that indeed I'm not
> > using it (and the getResourceBean method I planned to add is commented
out.
> > Basically, I read the code a bit too quickly.
>
> Let's go ahead and remove the code we don't need (including the unused
> imports),
> now that it is clear the code will not be required.
>
> As you probably saw, I added another patch that improves the speed of
> this
> parsing when it is done -- avoids StringTokenizer, and uses
> unsynchronized
> access to collection classes (because this is all local variables so
> there is no
> opportunity for multi thread access to cause problems).
>
> > > > I guess after all those changes are made, I'll have to do another
rounds
> > of
> > > > benchmarks :-)
> > >
> > > Should be interesting :-)
> >
> > Of course, the biggest gain would probably come if we started using some
> > buffer operations (arraycopy ...) to do most string operations.
>
> Yep, as long as we're talking byte arrays.  Once you start talking about
> Strings, we have to deal with the i18n issues, which (as Costin can
> attest to
> :-) get pretty sticky.

True.

> I thought about that one quite a bit.  Basically, we have to decide
> whether we
> want the user to be able to modify files in the docBase directory, and
> have
> those changes recognized even when the old version was cached.  The way
> to
> detect changes seems to be to flow through the cache for the "last
> modified"
> check (although you can probably use any cached value for the file
> length safely
> -- modifying this will have set the last modified date anyway).

In the cache I had in in DefaultServlet, the entries were valid for 30s,
after which they had to be revalidated.

> For JarResources, I explicitly assumed (as stated in the class comments
> in the
> Javadoc) that you won't be trying to modify the JAR file while the app
> is
> running -- if you want to change things, you need to restart the app.
> That's
> why it pre-caches all the file and directory entries out of the JAR, and
> only
> caches the data according to the cacheable() policy.

Well, I'm pretty much neutral on caching policies. However, the more
aggressive we are, the better the benchmarks. Perhaps we could have
configuration options for this so that the user could tweak for performance
once the website is put in production (IIS has options like this) ?

> > The servlets benchs went down a bit lately (around 5% overall). The
> > benchmark I use doesn't use the "language" header, so there was no
> > improvements because of that, but I'm sure the real world performance
went
> > up quite a bit.
> >
> > >   * Leave out any entries for WEB-INF and META-INF (trying to follow
the
> > >     links would fail anyway, so there is no reason to show them)
> >
> > Actually, that was working, but I think it's a security problem to
display
> > them.
> >
>
> Yep ... they no longer display.  I also cleaned up a few other details
> that
> weren't quite right in the rendered HTML.

Some shading problems at the top of the table.

> > I found a problem with the rewriting of some characters in the URL.
"%20" is
> > no longer converted into " " (I think it was working at one point, but I
> > can't really remember. I added that in ResourcesBase.normalize. Do you
think
> > it's the right place for that ?
> > If you're +1, I'm committing the (very small) fix.
>
> +1 to fix (i.e. URL encode) the hyperlink that is part of the "<a
> href="xxxx">
> element.  The displayed filename should still have the spaces in it.

Right. I forgot to fix the link ...

> > I'll work on the WebDAV servlet for the immediate future.
> > Propfind is already done, so you can browse the site using Webfolders.
>
> Cool.

I'll try to have PUT and the namespace operations (mkcol, copy, move,
delete) working soon.

Remy

Re: [Catalina] Resources

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

Remy Maucherat wrote:

> > Currently, Jasper uses native file I/O to do it's "last modified" check
> > of the
> > JSP page source file.  Therefore, I would not expect it to work when
> > trying to
> > run using JarResources instead of FileResources.
>
> java.lang.IllegalArgumentException: Context relative path
> \jsp\dates\date.jsp must start with /
>  at
> org.apache.tomcat.resources.ResourcesBase.validate(ResourcesBase.java:1107)
>  at
> org.apache.tomcat.resources.FileResources.getRealPath(FileResources.java:165
> )
>  at
> org.apache.tomcat.core.ApplicationContext.getRealPath(ApplicationContext.jav
> a:333)
>  at
> org.apache.jasper.JspEngineContext.getRealPath(JspEngineContext.java:359)
> <snip/>
>
> I guess the validate method has to be made more tolerant ...

I'm OK with translating "\" to "/", I guess, but it should be done
consistently,
and very early in each of the spots validate() is already called --
perhaps:

    path = normalize(path);
    validate(path);

and the "normalize" method can do this change if it needs to.



>

> > > > OK, I'm +1 for this.  The
> > > > context config class (org.apache.tomcat.startup.ContextConfig also
> needs
> > > to be
> > > > modified to select the correct Resources implementation if one hasn't
> > > already
> > > > been installed.  (Right now it defaults to StandardResources).
> > >
> > > I replaced that with FileResources.
> > > I don't know what you mean by "selecting the right Resources". How will
> it
> > > be done ?
> > >
> >
> > I'm envisioning an addition to ContextConfig that does this, similar to
> > the way
> > that it picks the right Authenticator based on which login method you
> > want.  The
> > way that process works is like this:
> > * ContextConfig is added as a LifecycleListener to the Context
> >   when it is created, so it finds out about start() and stop() events
> >   sent to the Context.
> > * During processing of the start() event, it calls the
> >   authenticatorConfig() method which looks at your web.xml
> >   settings and installs the right kind of Valve.
> >
> > Right now, ContextConfig.start() includes the following code:
> >
> >     if (context.getResources() == null) {
> >         ... log debug message ...
> >         context.setResources(new StandardResources));
> >     }
> >
> > which hard codes the StandardResources implementation if the sysadmin
> > did not
>
> Now, it's FileResources :-)
>
> > configure one explicitly in server.xml.  If we made this logic a little
> > smarter,
> > it could call context.getDocBase() and examine the result.  A simple
> > rule (until
> > we have more than two kinds) would be to say if the docBase string
> > starts with
> > "jar:", install a JarResources instance; otherwise install a
> > FileResources
> > instance.  Later on, if we had other standard choices available, we'd
> > just make
> > the if statement a little smarter.
>
> Ok, but we can only be smart for implementations we already know (file, jar,
> ...). That was my point.
>

True ... but we can embed smartness in a properties file where the key
is the
URL scheme and the value is class name to use; basically the way
Authenticators
are looked up based on login method.  That way, people using Catalina
can add
custom extensions to the list of supported resource bases by defining
their own
URL scheme prefixes -- which they are going to have to do anyway to
return
something useful from getResource() -- and add a mapping to a property
file with
no changes to the code of ContextConfig.

The default should be to use FileResources if we can't figure out
anything
else.  That covers the case where a relative or absolute pathname is
used
without the "file:" prefix.

>
> [snip]
> >
> > One thing that is puzzling me a little, though ... why do you need
> > access to the
> > DirectoryBean object in DefaultServlet?  If you ask for
> > getResourceAsStream() on
> > a resource path that is a directory, it's going to give you back the
> > expanded
> > text of that directory already (or a null if you've configured it not to
> > expand
> > directory listings).
>
> And if you look at my implementation, you'll notice that indeed I'm not
> using it (and the getResourceBean method I planned to add is commented out.
> Basically, I read the code a bit too quickly.

Let's go ahead and remove the code we don't need (including the unused
imports),
now that it is clear the code will not be required.

>
> BTW, I struggled a bit to make the directory browser work, as I had a lot of
> path related problems.
>
> > > I saw the new class. I planned to reuse some of the Tomcat header
> parsing
> > > functions, but I never had time to rewrite that part (the
> StringTokenizer is
> > > the biggest problem right now, IMO; for example, IE includes the
> "language"
> > > header in each request, so this part of the code is actually used most
> of
> > > the time ;-) ).
> >
> > Yah, parsing Accept-Language is a little more intricate, so I only used
> > the new
> > class for the request line itself at the moment.
>

As you probably saw, I added another patch that improves the speed of
this
parsing when it is done -- avoids StringTokenizer, and uses
unsynchronized
access to collection classes (because this is all local variables so
there is no
opportunity for multi thread access to cause problems).

> >
> > >
> > > I guess after all those changes are made, I'll have to do another rounds
> of
> > > benchmarks :-)
> >
> > Should be interesting :-)
>
> Of course, the biggest gain would probably come if we started using some
> buffer operations (arraycopy ...) to do most string operations.
>

Yep, as long as we're talking byte arrays.  Once you start talking about
Strings, we have to deal with the i18n issues, which (as Costin can
attest to
:-) get pretty sticky.

>
> The benchmarks right now are not that great for static files, because a lot
> of operations are uncached, like the calls to File.length() and
> File.lastModified().
>

I thought about that one quite a bit.  Basically, we have to decide
whether we
want the user to be able to modify files in the docBase directory, and
have
those changes recognized even when the old version was cached.  The way
to
detect changes seems to be to flow through the cache for the "last
modified"
check (although you can probably use any cached value for the file
length safely
-- modifying this will have set the last modified date anyway).

For JarResources, I explicitly assumed (as stated in the class comments
in the
Javadoc) that you won't be trying to modify the JAR file while the app
is
running -- if you want to change things, you need to restart the app. 
That's
why it pre-caches all the file and directory entries out of the JAR, and
only
caches the data according to the cacheable() policy.

>
> The servlets benchs went down a bit lately (around 5% overall). The
> benchmark I use doesn't use the "language" header, so there was no
> improvements because of that, but I'm sure the real world performance went
> up quite a bit.
>
> >   * Leave out any entries for WEB-INF and META-INF (trying to follow the
> >     links would fail anyway, so there is no reason to show them)
>
> Actually, that was working, but I think it's a security problem to display
> them.
>

Yep ... they no longer display.  I also cleaned up a few other details
that
weren't quite right in the rendered HTML.

>
> I found a problem with the rewriting of some characters in the URL. "%20" is
> no longer converted into " " (I think it was working at one point, but I
> can't really remember. I added that in ResourcesBase.normalize. Do you think
> it's the right place for that ?
> If you're +1, I'm committing the (very small) fix.
>

+1 to fix (i.e. URL encode) the hyperlink that is part of the "<a
href="xxxx">
element.  The displayed filename should still have the spaces in it.

>
> I'll work on the WebDAV servlet for the immediate future.
> Propfind is already done, so you can browse the site using Webfolders.
>

Cool.

>
> Remy
>

Craig

Re: [Catalina] Resources

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

> Currently, Jasper uses native file I/O to do it's "last modified" check
> of the
> JSP page source file.  Therefore, I would not expect it to work when
> trying to
> run using JarResources instead of FileResources.

java.lang.IllegalArgumentException: Context relative path
\jsp\dates\date.jsp must start with /
 at
org.apache.tomcat.resources.ResourcesBase.validate(ResourcesBase.java:1107)
 at
org.apache.tomcat.resources.FileResources.getRealPath(FileResources.java:165
)
 at
org.apache.tomcat.core.ApplicationContext.getRealPath(ApplicationContext.jav
a:333)
 at
org.apache.jasper.JspEngineContext.getRealPath(JspEngineContext.java:359)
<snip/>

I guess the validate method has to be made more tolerant ...

> > > OK, I'm +1 for this.  The
> > > context config class (org.apache.tomcat.startup.ContextConfig also
needs
> > to be
> > > modified to select the correct Resources implementation if one hasn't
> > already
> > > been installed.  (Right now it defaults to StandardResources).
> >
> > I replaced that with FileResources.
> > I don't know what you mean by "selecting the right Resources". How will
it
> > be done ?
> >
>
> I'm envisioning an addition to ContextConfig that does this, similar to
> the way
> that it picks the right Authenticator based on which login method you
> want.  The
> way that process works is like this:
> * ContextConfig is added as a LifecycleListener to the Context
>   when it is created, so it finds out about start() and stop() events
>   sent to the Context.
> * During processing of the start() event, it calls the
>   authenticatorConfig() method which looks at your web.xml
>   settings and installs the right kind of Valve.
>
> Right now, ContextConfig.start() includes the following code:
>
>     if (context.getResources() == null) {
>         ... log debug message ...
>         context.setResources(new StandardResources));
>     }
>
> which hard codes the StandardResources implementation if the sysadmin
> did not

Now, it's FileResources :-)

> configure one explicitly in server.xml.  If we made this logic a little
> smarter,
> it could call context.getDocBase() and examine the result.  A simple
> rule (until
> we have more than two kinds) would be to say if the docBase string
> starts with
> "jar:", install a JarResources instance; otherwise install a
> FileResources
> instance.  Later on, if we had other standard choices available, we'd
> just make
> the if statement a little smarter.

Ok, but we can only be smart for implementations we already know (file, jar,
...). That was my point.

> > > > - I'll modify DefaultServlet to use Resources (while leaving in the
old
> > > > code, just in case).
> > > >
> > >
> > > +1.
> > >
> > > PS:  Sorry for meddling in org.apache.tomcat.connector at the same
time
> > you
> > > were -- I was going through all the packages doing the changes for
> > > collections.  The change I checked in incorporated the fix you posted,
so
> > > everything should be up to date.  Still passes Watchdog 100%.
> >
> > It seems the merge was successful. Basically, I was toying with Slide
and
> > found that bug. At first, I was all worried since my attempts to use PUT
> > with large entities were failing with out of bounds exceptions :-)
> >
>
> One thing that is puzzling me a little, though ... why do you need
> access to the
> DirectoryBean object in DefaultServlet?  If you ask for
> getResourceAsStream() on
> a resource path that is a directory, it's going to give you back the
> expanded
> text of that directory already (or a null if you've configured it not to
> expand
> directory listings).

And if you look at my implementation, you'll notice that indeed I'm not
using it (and the getResourceBean method I planned to add is commented out.
Basically, I read the code a bit too quickly.
BTW, I struggled a bit to make the directory browser work, as I had a lot of
path related problems.

> > I saw the new class. I planned to reuse some of the Tomcat header
parsing
> > functions, but I never had time to rewrite that part (the
StringTokenizer is
> > the biggest problem right now, IMO; for example, IE includes the
"language"
> > header in each request, so this part of the code is actually used most
of
> > the time ;-) ).
>
> Yah, parsing Accept-Language is a little more intricate, so I only used
> the new
> class for the request line itself at the moment.
>
> >
> > I guess after all those changes are made, I'll have to do another rounds
of
> > benchmarks :-)
>
> Should be interesting :-)

Of course, the biggest gain would probably come if we started using some
buffer operations (arraycopy ...) to do most string operations.

The benchmarks right now are not that great for static files, because a lot
of operations are uncached, like the calls to File.length() and
File.lastModified().

The servlets benchs went down a bit lately (around 5% overall). The
benchmark I use doesn't use the "language" header, so there was no
improvements because of that, but I'm sure the real world performance went
up quite a bit.

>   * Leave out any entries for WEB-INF and META-INF (trying to follow the
>     links would fail anyway, so there is no reason to show them)

Actually, that was working, but I think it's a security problem to display
them.

I found a problem with the rewriting of some characters in the URL. "%20" is
no longer converted into " " (I think it was working at one point, but I
can't really remember. I added that in ResourcesBase.normalize. Do you think
it's the right place for that ?
If you're +1, I'm committing the (very small) fix.

I'll work on the WebDAV servlet for the immediate future.
Propfind is already done, so you can browse the site using Webfolders.

Remy

Re: [Catalina] Resources

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

Remy Maucherat wrote:

> > Agree that these should not go into Resources interface, at least for now.
>
> Ok.
>
> > The DirectoryBean and ResourcesBean classes also need to be made public in
> that
> > case - right now they are package private.
> >
> > > - I'll remove StandardResources at the same time. Are you +1 with this ?
> > >
> >
> > Once you are satisfied that the new code works (for static files and
> servlets
> > -- JSPs won't work yet due to Jasper restrictions)
>
> I don't know anything about Jasper, so well ...
>

Currently, Jasper uses native file I/O to do it's "last modified" check
of the
JSP page source file.  Therefore, I would not expect it to work when
trying to
run using JarResources instead of FileResources.

>
> > OK, I'm +1 for this.  The
> > context config class (org.apache.tomcat.startup.ContextConfig also needs
> to be
> > modified to select the correct Resources implementation if one hasn't
> already
> > been installed.  (Right now it defaults to StandardResources).
>
> I replaced that with FileResources.
> I don't know what you mean by "selecting the right Resources". How will it
> be done ?
>

I'm envisioning an addition to ContextConfig that does this, similar to
the way
that it picks the right Authenticator based on which login method you
want.  The
way that process works is like this:
* ContextConfig is added as a LifecycleListener to the Context
  when it is created, so it finds out about start() and stop() events
  sent to the Context.
* During processing of the start() event, it calls the
  authenticatorConfig() method which looks at your web.xml
  settings and installs the right kind of Valve.

Right now, ContextConfig.start() includes the following code:

    if (context.getResources() == null) {
        ... log debug message ...
        context.setResources(new StandardResources));
    }

which hard codes the StandardResources implementation if the sysadmin
did not
configure one explicitly in server.xml.  If we made this logic a little
smarter,
it could call context.getDocBase() and examine the result.  A simple
rule (until
we have more than two kinds) would be to say if the docBase string
starts with
"jar:", install a JarResources instance; otherwise install a
FileResources
instance.  Later on, if we had other standard choices available, we'd
just make
the if statement a little smarter.

>
> > > - I'll modify DefaultServlet to use Resources (while leaving in the old
> > > code, just in case).
> > >
> >
> > +1.
> >
> > PS:  Sorry for meddling in org.apache.tomcat.connector at the same time
> you
> > were -- I was going through all the packages doing the changes for
> > collections.  The change I checked in incorporated the fix you posted, so
> > everything should be up to date.  Still passes Watchdog 100%.
>
> It seems the merge was successful. Basically, I was toying with Slide and
> found that bug. At first, I was all worried since my attempts to use PUT
> with large entities were failing with out of bounds exceptions :-)
>

One thing that is puzzling me a little, though ... why do you need
access to the
DirectoryBean object in DefaultServlet?  If you ask for
getResourceAsStream() on
a resource path that is a directory, it's going to give you back the
expanded
text of that directory already (or a null if you've configured it not to
expand
directory listings).

>
> > PPS: One of the areas of performance improvement I want to play with a
> little
> > at some point is the parsing speed inside HttpProcessor.  Right now it
> uses
> > StringTokenizer and some other stuff that is pretty expensive -- I want to
> copy
> > the basic idea that Costin put into the Tomcat 3.2 connectors (parsing for
> > "start" and "end" points, then pulling out substrings), but want to do it
> in a
> > more general purpose StringParser class so it's reusable, and so that the
> > connector can parse more than one kind of string if it needs to (the
> current
> > code uses instance variables in the underlying class to save state).
>
> I saw the new class. I planned to reuse some of the Tomcat header parsing
> functions, but I never had time to rewrite that part (the StringTokenizer is
> the biggest problem right now, IMO; for example, IE includes the "language"
> header in each request, so this part of the code is actually used most of
> the time ;-) ).

Yah, parsing Accept-Language is a little more intricate, so I only used
the new
class for the request line itself at the moment.

>
> I guess after all those changes are made, I'll have to do another rounds of
> benchmarks :-)

Should be interesting :-)

>
> Remy

Craig

Re: [Catalina] Resources

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

> Agree that these should not go into Resources interface, at least for now.

Ok.

> The DirectoryBean and ResourcesBean classes also need to be made public in
that
> case - right now they are package private.
>
> > - I'll remove StandardResources at the same time. Are you +1 with this ?
> >
>
> Once you are satisfied that the new code works (for static files and
servlets
> -- JSPs won't work yet due to Jasper restrictions)

I don't know anything about Jasper, so well ...

> OK, I'm +1 for this.  The
> context config class (org.apache.tomcat.startup.ContextConfig also needs
to be
> modified to select the correct Resources implementation if one hasn't
already
> been installed.  (Right now it defaults to StandardResources).

I replaced that with FileResources.
I don't know what you mean by "selecting the right Resources". How will it
be done ?

> > - I'll modify DefaultServlet to use Resources (while leaving in the old
> > code, just in case).
> >
>
> +1.
>
> PS:  Sorry for meddling in org.apache.tomcat.connector at the same time
you
> were -- I was going through all the packages doing the changes for
> collections.  The change I checked in incorporated the fix you posted, so
> everything should be up to date.  Still passes Watchdog 100%.

It seems the merge was successful. Basically, I was toying with Slide and
found that bug. At first, I was all worried since my attempts to use PUT
with large entities were failing with out of bounds exceptions :-)

> PPS: One of the areas of performance improvement I want to play with a
little
> at some point is the parsing speed inside HttpProcessor.  Right now it
uses
> StringTokenizer and some other stuff that is pretty expensive -- I want to
copy
> the basic idea that Costin put into the Tomcat 3.2 connectors (parsing for
> "start" and "end" points, then pulling out substrings), but want to do it
in a
> more general purpose StringParser class so it's reusable, and so that the
> connector can parse more than one kind of string if it needs to (the
current
> code uses instance variables in the underlying class to save state).

I saw the new class. I planned to reuse some of the Tomcat header parsing
functions, but I never had time to rewrite that part (the StringTokenizer is
the biggest problem right now, IMO; for example, IE includes the "language"
header in each request, so this part of the code is actually used most of
the time ;-) ).
I guess after all those changes are made, I'll have to do another rounds of
benchmarks :-)

Remy

Re: [Catalina] Resources

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

Remy Maucherat wrote:

> Hi Craig,
>
> The move to Resources is going smoothly. It should be done later today if I
> can solve some issues.
>
> - The directory browse (and others) are generated by the DirectoryBean.
> That's fine, but there is no way to access either ResourceBean or
> DirectoryBean from outside ResourcesBase, so we should add the following
> function to ResourcesBase :
> ResourceBean getResourceBean(String path) or something like that. It's
> probably not a good idea to add it to the Resources interface (to avoid
> creating a dependency).
> This is needed for DefaultServlet.
>

Agree that these should not go into Resources interface, at least for now.

The DirectoryBean and ResourcesBean classes also need to be made public in that
case - right now they are package private.

>
> - I'll remove StandardResources at the same time. Are you +1 with this ?
>

Once you are satisfied that the new code works (for static files and servlets
-- JSPs won't work yet due to Jasper restrictions) OK, I'm +1 for this.  The
context config class (org.apache.tomcat.startup.ContextConfig also needs to be
modified to select the correct Resources implementation if one hasn't already
been installed.  (Right now it defaults to StandardResources).


>
> - I'll modify DefaultServlet to use Resources (while leaving in the old
> code, just in case).
>

+1.

>
> Remy
>

Craig

PS:  Sorry for meddling in org.apache.tomcat.connector at the same time you
were -- I was going through all the packages doing the changes for
collections.  The change I checked in incorporated the fix you posted, so
everything should be up to date.  Still passes Watchdog 100%.

PPS: One of the areas of performance improvement I want to play with a little
at some point is the parsing speed inside HttpProcessor.  Right now it uses
StringTokenizer and some other stuff that is pretty expensive -- I want to copy
the basic idea that Costin put into the Tomcat 3.2 connectors (parsing for
"start" and "end" points, then pulling out substrings), but want to do it in a
more general purpose StringParser class so it's reusable, and so that the
connector can parse more than one kind of string if it needs to (the current
code uses instance variables in the underlying class to save state).

[Catalina] Resources

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

Hi Craig,

The move to Resources is going smoothly. It should be done later today if I
can solve some issues.

- The directory browse (and others) are generated by the DirectoryBean.
That's fine, but there is no way to access either ResourceBean or
DirectoryBean from outside ResourcesBase, so we should add the following
function to ResourcesBase :
ResourceBean getResourceBean(String path) or something like that. It's
probably not a good idea to add it to the Resources interface (to avoid
creating a dependency).
This is needed for DefaultServlet.

- I'll remove StandardResources at the same time. Are you +1 with this ?

- I'll modify DefaultServlet to use Resources (while leaving in the old
code, just in case).

Remy

Re: [PROPOSAL] UDP support for Catalina

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

Diether Samaey wrote:

> Catalina currently only supports TCP (through ServerSockets), are there any
> plans to support UDP in the near future ?  Some (non-HTTP) servlet
> implementations (e.g. SIP-servlets) might need it for communication with
> UDP-only clients.

In principle, this seems like it would be straightforward, using
DatagramSockets underneath.  You could even make the request look (to
the rest
of Catalina) like it was really an HTTP request; or you could implement
your
own mapping and support for generic servlets, depending on your
requirements.

I don't have any personal plans to implement this in the near term, but
I'd be
happy to answer questions for someone who wanted to take a crack at it.

>
> Cheers,
>
> Diether
>

Craig McClanahan