Re: tomcat 7 slow to deploy web applications on m1 mac

[Robert J. Carr]

On Tue, Jan 4, 2022 at 2:50 PM Mark Thomas  wrote:

>
>
> On 04/01/2022 19:23, Robert J. Carr wrote:
> > I've been using tomcat for many years but unfortunately I'm stuck on
> > version 7 (long story).  I recently picked up a new workstation, an Apple
> > M1 MacBook (M1 Max - macOS 12.1), and I installed the ARM version of Azul
> > Zulu (1.8.0_312), and by all accounts everything is really fast, as you'd
> > expect.  A compile that took about 3.5 minutes on a 2016 x86 MacBook now
> > takes about 50 seconds on ARM.
> >
> > However, deploying web applications (context deploy via web service) is
> > much slower compared to x86.  One app used to take about 3-4 seconds and
> > the other near instantaneous are now taking 42 and 11 seconds,
> > respectively, and very consistently.  The same is true for tomcat
> restarts
> > when the custom apps are registered.  Without any custom apps tomcat
> starts
> > in under one second.  App reloads are a bit faster than deploy, but still
> > very slow compared to x86.  The only thing different I can tell is the
> > workstation (and thus, architecture).
> >
> > I started on Tomcat version 7.0.109 (newest at the time), but reverted
> to a
> > known working 7.0.76 thinking it might be the issue, but nothing changed,
> > i.e., still noticing the huge delay during deployment, down to the same
> > amount of delay time.
> >
> > The only noticeable issue in the logs is this line:
> >
> >> At least one JAR was scanned for TLDs yet contained no TLDs. Enable
> debug
> > logging for this logger for a complete list of JARs that were scanned but
> > no TLDs were found in them.
> >
> > This was also in the x86 logs that I never addressed, so I think it's a
> red
> > herring; however, when monitoring the logs after a deploy, that is the
> last
> > line printed before it idles for 10-40 seconds.  Also, the application
> with
> > more jar files is the one that takes longer to start, so I thought I'd
> > investigate.
> >
> > I started by adding this to 'logging.properties'
> >
> >  org.apache.jasper.compiler.TldLocationsCache.level = FINE
> >
> > But nothing new was printed, even when setting to FINEST.  Researching
> > around, and reading 'catalina.properties', I added all of the jars from
> the
> > web application to this property:
> >
> >  org.apache.catalina.startup.TldConfig.jarsToSkip=...
> >
> > And the TLD warning went away, but the long multi-second pause persisted.
> > Searching around more, I came across this document:
> >
> >
> https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp
> >
> > I had already added the entropy fix to my startup script (and I don't see
> > any SecureRandom warnings in the logs):
> >
> >  -Djava.security.egd=file:/dev/./urandom
> >
> > So that doesn't appear to be related to my issue.
> >
> > As I said, my config is now exactly the same as it was on x86, so
> anything
> > new I try from here is just completely guessing.  I'm hoping somebody has
> > an idea so I can stop guessing.
> >
> > Please let me know if there's any information that would help, but I
> tried
> > to provide all of the relevant details I know of.
>
> My usual advice is to get a profiler and see what is going on.
>
> I use YourKit - primarily because they give me a free license to use for
> Tomcat development. Other profilers are available.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Hi Mark-

Thanks so much for the profiler recommendation; I'm old enough that I
should have considered this, but I thought it was some deep issue with
tomcat related somehow to the new architecture.

Turns out I was wrong.

The issue was actually from doing an 'InetAddress.getLocalHost()' call,
from within log4j, and this was causing a 5 second timeout.  My guess is
log4j is making this call once per logger/appender, and since my larger
application has more of these, that's why it was taking so much longer for
that one.

So why is it timing out?  Seems to be a peculiarity with java 8 and macOS
and looks to still exist.  See here:


https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds

https://stackoverflow.com/questions/39636792/jvm-takes-a-long-time-to-resolve-ip-address-for-localhost/39698914#39698914

Since this is a new workstation I hadn't touched the hosts file and that
was the difference compared to my previous config (which I must have set
just by coincidence).

So, false alarm, nothing to do with tomcat, but thanks again for leading me
in the right direction!

Cheers-
Robert

Re: tomcat 7 slow to deploy web applications on m1 mac

[Robert J. Carr]

On Tue, Jan 4, 2022 at 2:50 PM Mark Thomas  wrote:

>
> On 04/01/2022 19:23, Robert J. Carr wrote:
> > I've been using tomcat for many years but unfortunately I'm stuck on
> > version 7 (long story).  I recently picked up a new workstation, an Apple
> > M1 MacBook (M1 Max - macOS 12.1), and I installed the ARM version of Azul
> > Zulu (1.8.0_312), and by all accounts everything is really fast, as you'd
> > expect.  A compile that took about 3.5 minutes on a 2016 x86 MacBook now
> > takes about 50 seconds on ARM.
> >
> > However, deploying web applications (context deploy via web service) is
> > much slower compared to x86.  One app used to take about 3-4 seconds and
> > the other near instantaneous are now taking 42 and 11 seconds,
> > respectively, and very consistently.  The same is true for tomcat
> restarts
> > when the custom apps are registered.  Without any custom apps tomcat
> starts
> > in under one second.  App reloads are a bit faster than deploy, but still
> > very slow compared to x86.  The only thing different I can tell is the
> > workstation (and thus, architecture).
> >
> > I started on Tomcat version 7.0.109 (newest at the time), but reverted
> to a
> > known working 7.0.76 thinking it might be the issue, but nothing changed,
> > i.e., still noticing the huge delay during deployment, down to the same
> > amount of delay time.
> >
> > The only noticeable issue in the logs is this line:
> >
> >> At least one JAR was scanned for TLDs yet contained no TLDs. Enable
> debug
> > logging for this logger for a complete list of JARs that were scanned but
> > no TLDs were found in them.
> >
> > This was also in the x86 logs that I never addressed, so I think it's a
> red
> > herring; however, when monitoring the logs after a deploy, that is the
> last
> > line printed before it idles for 10-40 seconds.  Also, the application
> with
> > more jar files is the one that takes longer to start, so I thought I'd
> > investigate.
> >
> > I started by adding this to 'logging.properties'
> >
> >  org.apache.jasper.compiler.TldLocationsCache.level = FINE
> >
> > But nothing new was printed, even when setting to FINEST.  Researching
> > around, and reading 'catalina.properties', I added all of the jars from
> the
> > web application to this property:
> >
> >  org.apache.catalina.startup.TldConfig.jarsToSkip=...
> >
> > And the TLD warning went away, but the long multi-second pause persisted.
> > Searching around more, I came across this document:
> >
> >
> https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp
> >
> > I had already added the entropy fix to my startup script (and I don't see
> > any SecureRandom warnings in the logs):
> >
> >  -Djava.security.egd=file:/dev/./urandom
> >
> > So that doesn't appear to be related to my issue.
> >
> > As I said, my config is now exactly the same as it was on x86, so
> anything
> > new I try from here is just completely guessing.  I'm hoping somebody has
> > an idea so I can stop guessing.
> >
> > Please let me know if there's any information that would help, but I
> tried
> > to provide all of the relevant details I know of.
>
> My usual advice is to get a profiler and see what is going on.
>
> I use YourKit - primarily because they give me a free license to use for
> Tomcat development. Other profilers are available.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org



Good suggestion, thanks!  I’ll report back what I discover.



-- 
Thanks-
Robert

tomcat 7 slow to deploy web applications on m1 mac

[Robert J. Carr]

I've been using tomcat for many years but unfortunately I'm stuck on
version 7 (long story).  I recently picked up a new workstation, an Apple
M1 MacBook (M1 Max - macOS 12.1), and I installed the ARM version of Azul
Zulu (1.8.0_312), and by all accounts everything is really fast, as you'd
expect.  A compile that took about 3.5 minutes on a 2016 x86 MacBook now
takes about 50 seconds on ARM.

However, deploying web applications (context deploy via web service) is
much slower compared to x86.  One app used to take about 3-4 seconds and
the other near instantaneous are now taking 42 and 11 seconds,
respectively, and very consistently.  The same is true for tomcat restarts
when the custom apps are registered.  Without any custom apps tomcat starts
in under one second.  App reloads are a bit faster than deploy, but still
very slow compared to x86.  The only thing different I can tell is the
workstation (and thus, architecture).

I started on Tomcat version 7.0.109 (newest at the time), but reverted to a
known working 7.0.76 thinking it might be the issue, but nothing changed,
i.e., still noticing the huge delay during deployment, down to the same
amount of delay time.

The only noticeable issue in the logs is this line:

> At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug
logging for this logger for a complete list of JARs that were scanned but
no TLDs were found in them.

This was also in the x86 logs that I never addressed, so I think it's a red
herring; however, when monitoring the logs after a deploy, that is the last
line printed before it idles for 10-40 seconds.  Also, the application with
more jar files is the one that takes longer to start, so I thought I'd
investigate.

I started by adding this to 'logging.properties'

org.apache.jasper.compiler.TldLocationsCache.level = FINE

But nothing new was printed, even when setting to FINEST.  Researching
around, and reading 'catalina.properties', I added all of the jars from the
web application to this property:

org.apache.catalina.startup.TldConfig.jarsToSkip=...

And the TLD warning went away, but the long multi-second pause persisted.
Searching around more, I came across this document:

https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp

I had already added the entropy fix to my startup script (and I don't see
any SecureRandom warnings in the logs):

-Djava.security.egd=file:/dev/./urandom

So that doesn't appear to be related to my issue.

As I said, my config is now exactly the same as it was on x86, so anything
new I try from here is just completely guessing.  I'm hoping somebody has
an idea so I can stop guessing.

Please let me know if there's any information that would help, but I tried
to provide all of the relevant details I know of.

Thanks!

Robert

Re: inconsistency with session persistence

[Robert J. Carr]

Hi Mark-

Thanks again for the response.

I fixed the credential handler config, it just had a superfluous attribute,
so the WARNING went away and as you predicted didn't change the session
outcome.  Now when stopping and starting tomcat I'm not seeing any log
higher than an INFO, it is appears to be doing this cleanly, but my problem
persists.

I'll take a look at the http to see what is going on with the session
tokens and cookies, thanks for the advice.  However, it's still strange to
me that it works for an app restart, meaning from the application
perspective it is correctly implemented, e.g., with respect to
serialization, but not a server restart, although the docs indicate these
should work the same.

I know sessions are intertwined with single sign-on.  Are we sure this
isn't the problem?  As I said, I need to turn on single sign-on to fix
another login bug, but I might be able to turn it off if it'd help in
diagnosing this problem.

Thanks-
Robert

Re: inconsistency with session persistence

[Robert J. Carr]

Hi Mark-

Thanks for the response.

> > * if the application is undeployed and redeployed (while the server
> >remains running) a new session is silently generated, and any contents
> >disappear, but the user maintains her authentication
>
> As expected. Redeploy (undeploy+deploy)  != reload (stop+start)

This is a good point and why I sent the follow-up email.  However, I'd
expect the undeploy+deploy to be the one to completely clean out and
invalidate the session, but the distinction isn't important for my
situation.

> > * if the server is shut down and restarted then everything seems to
> >disappear, as I then get a 403 when trying to access the protected page
>
> Expected behaviour here will depend on whether a server shutdown shuts
down Tomcat cleanly. From your description it sounds like it does not.

I just re-ran my test getting the same result, i.e., after a server restart
a previously accessible request now gives a 403.  Looking at the logs, the
shutdown seems fine (i.e., nothing above INFO), and there were only a few
lines, but this one might be relevant:

INFO [localhost-startStop-2]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextDestroyed()

On subsequent startup there are a lot more logs, but one warning that
doesn't seem relevant:

WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin
[SetPropertiesRule]{Server/Service/Engine/Realm/Realm/CredentialHandler}
Setting property 'keyLength' to '256' did not find a matching property.

But maybe it is?  There was also this session relevant line:

INFO [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log SessionListener:
contextInitialized()

So not sure what is going on.  I'll see if I can figure out if that WARNING
is causing issues.  Thanks for the guidance, but please let me know if
there's anything else I can look at.

Robert

Re: inconsistency with session persistence

[Robert J. Carr]

Actually, there's a small correction to my session persistence description
from before.   From the doc I referenced here:


https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Special_Features

It says:

> Whenever Apache Tomcat is shut down normally and restarted, or when an
application reload is triggered, the ... All such saved sessions will then
be deserialized and activated ...

But here's what I'm finding:

 * if the application is restarted then the session and its contents are
maintained as expected

 * if the application is undeployed and redeployed (while the server
remains running) a new session is silently generated, and any contents
disappear, but the user maintains her authentication

 * if the server is shut down and restarted then everything seems to
disappear, as I then get a 403 when trying to access the protected page

Again, this isn't consistent with the documentation, so not sure what I'm
doing wrong.

Thanks-
Robert

inconsistency with session persistence

[Robert J. Carr]

I've read around the docs and various help sites trying to figure this out,
by my situation isn't matching anything I've read, so looking for a little
extra help.

Here's my config: [tomcat 8.5.24 | java 8.0 | macos 10.14]

According to here:
https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Special_Features

It says a session should normally persist if the application is reloaded or
the server restarted, however, that is not the behavior I'm experiencing.
Here's what happens:

When a user logs in I create a session and store in it a single custom
object that I’ve marked serializable, and all of its members are
serializable (just Strings and an Instant).

When the application restarts both the session and the contents seem to be
restored as expected.  But if the application is undeployed and redeployed
the session seems to get recreated automatically, with a new session id
(and negotiated through cookies with the client), but the contents of the
session are now gone.

To explain a bit differently, I have a test page that allows access only to
an authenticated user.  This test page will spit out both the session id
and the contents of the session object.

If I login normally and go to this page everything is fine.  If I reload my
application and then reload this page then everything stays the same as
expected, and I'm sure this page isn't being cached (my verification has to
do with the Instant I mentioned earlier).

But if I undeploy and redeploy the application, or restart the server, then
I can still reload this protected page without having to login, but two
things are different:

 1) there's a new session id
 2) the session contents are now unavailable

By hooking up a session listener I can confirm that a new session is being
silently created, although the session is never getting destroyed.

So what's going on here?  This doesn't seem to be what the docs describe.
This scenario is causing problems because the session data I store includes
authentication info for an external resource, so my users are effectively
only 1/2 logged in, and in a weird state.

Two more small details:

 * The doc I referenced talks about Persistent Managers, but I'm not using
anything non-standard.

 * The one non-standard thing I am using is the single-sign-on valve, but
this was only to overcome a different (reported) bug I found dealing with
programmatic logins (long story).

Thanks for any help!

Robert

Re: capturing response output in filter

[Robert J. Carr]

On Mon, Jan 29, 2018 at 9:27 AM, Mark Thomas <ma...@apache.org> wrote:
>
> On 29/01/18 17:19, Robert J. Carr wrote:
> > I have a Filter that uses the output stream from the response of the
> > servlet in the chain.  In order to do this I create a custom response
> > wrapper that has a custom servlet output stream.
> >
> > This works fine, but in moving to a newer Java EE API there have been a
> > couple new (abstract) methods added to servlet output stream, and my
> > application needs to (unfortunately) work in both Tomcat 7 and Tomcat
8+.
> >
> > So, is there any other way to capture the response output stream that
> > doesn't rely on this?  If not, any recommendations on how to straddle
these
> > tomcat/java versions?
> >
> > The only thing I can think of, but haven't tried, is to compile against
> > Tomcat 7, but run that application in Tomcat 8+.
>
> Try the other way. Compile against Tomcat 8+, run on Tomcat 7. The
> additional methods should just be ignored on Tomcat 7.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Hi Mark-

Thanks for the quick response.  You're right, for a different method that
was added in a different situation this is what I do.  But for the
ServletOutputStream, they added this method:

setWriteListener(WriteListener writeListener)

Which includes the WriteListener, that was also added.  So I don't think I
can use the technique you suggest, unless I want to do some sort of
conditional dependency injection.

Or maybe I'm missing something?

Thanks!

capturing response output in filter

[Robert J. Carr]

I have a Filter that uses the output stream from the response of the
servlet in the chain.  In order to do this I create a custom response
wrapper that has a custom servlet output stream.

This works fine, but in moving to a newer Java EE API there have been a
couple new (abstract) methods added to servlet output stream, and my
application needs to (unfortunately) work in both Tomcat 7 and Tomcat 8+.

So, is there any other way to capture the response output stream that
doesn't rely on this?  If not, any recommendations on how to straddle these
tomcat/java versions?

The only thing I can think of, but haven't tried, is to compile against
Tomcat 7, but run that application in Tomcat 8+.

Thanks!

tomcat version question

[Robert J. Carr]

Hello.

There is a "which version" page on the main site which is really useful,
and it lists all the versions of the various specs related to the version
of tomcat, but a really important one IMO that is missing is the Java EE
version, so I can look up the api docs.

Is there a reason why this is omitted?  Currently, I have to look up the
servlet spec, and then cross reference that with the Java EE to find the
appropriate docs.

Or am I missing something?

Thanks-
Robert

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

On Tue, Jan 23, 2018 at 1:03 PM, Robert J. Carr <rjc...@gmail.com> wrote:

> On Tue, Jan 23, 2018 at 9:54 AM, Konstantin Kolinko <
> knst.koli...@gmail.com> wrote:
>
>> 2018-01-22 11:25 GMT+03:00 Robert J. Carr <rjc...@gmail.com>:
>> > Hi Mark, everyone-
>> >
>> > I've constructed a sample app of ~5 files.  The code is bundled in the
>> jar
>> > file in the WEB-INF/lib directory.  Here's a public url for the
>> application
>> > (test.war; 8K):
>> >
>> >
>> > https://drive.google.com/file/d/1mZRXrm90F4WN3mizqoqrWYmQ1HH
>> frSS4/view?usp=sharing
>> >
>>
>> Thank you for the sample application! It is easy to reproduce the issue.
>>
>> I filed it into Bugzilla:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=62036
>>
>> I went on to upload your test.war there (I fixed some typos in web.xml
>> and repacked). I hope that you do not mind.
>>
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> Hi Konstantin-
>
> Thanks for looking into this, and yes, it's fine to share the example
> application.
>
> It looks like you've already done some research.  I'll follow the defect
> ticket and see what happens.  I was hoping there was just some
> configuration I was missing, so I'll still hold out for that.
>
> Thanks again for the time, and a special thanks for confirming I'm not
> crazy! :)
>
> Robert
>
>
Hi Mark, Konstantin-

I looked in on that defect ticket and it appears you found and fixed a
problem.  Great!  But I also noticed you said the same problems were
happening for you in 8 and 8.5 and even happening in the same version of 8
I was testing against.

So I went and grabbed a clean version of 8.0.43 and sure enough, you're
right, I'm seeing the same problems there as well.  But this is good news,
as it means there's a config that can likely fix the problem.

I was in the process of writing this long email, hoping you could help me
find the config that makes the difference, and *finally* I found it.  Turns
out if you turn on single sign-on then this bug doesn't present itself.  I
had forgot I had turned that on in my test server.

So, although you fixed the bug, I thought you'd like to have that
information.  And to say thanks for indirectly helping me to find a
solution!

Cheers-
Robert

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

On Tue, Jan 23, 2018 at 9:54 AM, Konstantin Kolinko <knst.koli...@gmail.com>
wrote:

> 2018-01-22 11:25 GMT+03:00 Robert J. Carr <rjc...@gmail.com>:
> > Hi Mark, everyone-
> >
> > I've constructed a sample app of ~5 files.  The code is bundled in the
> jar
> > file in the WEB-INF/lib directory.  Here's a public url for the
> application
> > (test.war; 8K):
> >
> >
> > https://drive.google.com/file/d/1mZRXrm90F4WN3mizqoqrWYmQ1HHfr
> SS4/view?usp=sharing
> >
>
> Thank you for the sample application! It is easy to reproduce the issue.
>
> I filed it into Bugzilla:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62036
>
> I went on to upload your test.war there (I fixed some typos in web.xml
> and repacked). I hope that you do not mind.
>
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Hi Konstantin-

Thanks for looking into this, and yes, it's fine to share the example
application.

It looks like you've already done some research.  I'll follow the defect
ticket and see what happens.  I was hoping there was just some
configuration I was missing, so I'll still hold out for that.

Thanks again for the time, and a special thanks for confirming I'm not
crazy! :)

Robert

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

Hi Mark, everyone-

I've constructed a sample app of ~5 files.  The code is bundled in the jar
file in the WEB-INF/lib directory.  Here's a public url for the application
(test.war; 8K):


https://drive.google.com/file/d/1mZRXrm90F4WN3mizqoqrWYmQ1HHfrSS4/view?usp=sharing

To reproduce the problem in tomcat 8.5.24 (for me):

 1)  make a user available with the role "testrole" (I just user
tomcat-users)

 2) startup tomcat, copy the war file into webapps

 3) go to the application homepage, index.jsp should auto load

 4) enter username and password and login; it should change to the username
you're authenticated with

 5) hit the auth test link and it should give you a success message

 6) hit the same link again and it should give you a 403

If you want to see how things are changing, I created an unprotected page
called /authinfo (no jsp) that shows the logged in user and role.  Here's
what it shows as you proceed through the test:

 * no user or role
 * user and role
 * user, but no role

If you do this same process in tomcat 8 (8.0.43, for me) it works fine,
particularly, the you can hit the link as many times as you want and the
roles never go away until you logout.  And generally, the login/test/logout
works perfectly, where in 8.5 even if you logout it doesn't always log you
back in the next time either.  Sometimes its takes several attempts.

Hopefully this is enough to give me some guidance.  Some more info, if it
helps:

 * macOS 10.13
 * jdk1.8.0_131

Please let me know if you have any questions.  Thanks again for the help!

Robert

(Note: I ripped this code from a larger codebase, so please don't hold me
to the strictest coding standards :) )



On Fri, Jan 19, 2018 at 12:37 AM, Robert J. Carr <rjc...@gmail.com> wrote:
>
> OK, thanks Mark, I'll try to come up with a test plan, but I'm seriously
pressed for time as this has eaten two full days.  Thanks again for the
help!
>
> On Fri, Jan 19, 2018 at 12:14 AM, Mark Thomas <ma...@apache.org> wrote:
>>
>> On 18/01/18 22:03, Robert J. Carr wrote:
>> > (Bear with me as there are a lot of details; I'll try to be as clear as
>> > possible)
>> >
>> > I've been setting up a simple application in tomcat 8.0 where some
>> > resources are protected but others aren't.  I want to login using AJAX
>> > instead of FORM or BASIC so I don't have any login-config specified in
my
>> > deployment descriptor (nor any security-roles defined).
>> >
>> > For testing, I have a custom form that sends login info asynchronously
to
>> > an unprotected login service which calls login().  On the same page as
the
>> > login form, I have a test button that makes an asynchronous request to
a
>> > protected resource (using a @ServletSecurity annotation).  As expected,
>> > before calling login (and thus login()) I get a 403, but after doing
the
>> > login() I get a 200 and can see the response text.  This all works
fine in
>> > tomcat 8.0.
>> >
>> > However, when I try the application in tomcat 8.5, with the same
server and
>> > application config, something different happens.  I do the login and
call
>> > the protected resource and get the 200 as before, but now every
subsequent
>> > call to the protected resource returns a 403.  I thought maybe there
was
>> > something peculiar about this specific protected resource, but not the
>> > case, any protected resource works the first time, but not subsequent
times.
>> >
>> > To confirm what is going on, I created an unprotected resource that
>> > provides auth info, and I can see after I login() it reports my
username
>> > and my affiliated roles (using isUserInRole() for known role names).
And I
>> > can refresh this info any number of times and it doesn't change.  But
as
>> > soon as I access a protected resource, twice, the unprotected auth info
>> > still shows my username, but now my roles are stripped.
>> >
>> > Thinking there is something wrong with login(), I change to using
BASIC and
>> > run similar tests, never using the login() call, and everything works
fine;
>> > notably, I can access a protected resource more than once.
>> >
>> > Strangely, what I also unexpectedly noticed is now that I have BASIC
>> > specified, when I do use login() things are working fine now even if I
>> > never get a BASIC prompt.  So, I can access a protected resource more
than
>> > once.
>> >
>> > I know this sounds like a weird state issue, but I've restarted web
>> > servers, browsers, deployed, undeployed, and redeployed apps dozens and
>> > dozens of time.  And I even confirmed the 200 and subsequent 403 calls
were
>

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

OK, thanks Mark, I'll try to come up with a test plan, but I'm seriously
pressed for time as this has eaten two full days.  Thanks again for the
help!

On Fri, Jan 19, 2018 at 12:14 AM, Mark Thomas <ma...@apache.org> wrote:

> On 18/01/18 22:03, Robert J. Carr wrote:
> > (Bear with me as there are a lot of details; I'll try to be as clear as
> > possible)
> >
> > I've been setting up a simple application in tomcat 8.0 where some
> > resources are protected but others aren't.  I want to login using AJAX
> > instead of FORM or BASIC so I don't have any login-config specified in my
> > deployment descriptor (nor any security-roles defined).
> >
> > For testing, I have a custom form that sends login info asynchronously to
> > an unprotected login service which calls login().  On the same page as
> the
> > login form, I have a test button that makes an asynchronous request to a
> > protected resource (using a @ServletSecurity annotation).  As expected,
> > before calling login (and thus login()) I get a 403, but after doing the
> > login() I get a 200 and can see the response text.  This all works fine
> in
> > tomcat 8.0.
> >
> > However, when I try the application in tomcat 8.5, with the same server
> and
> > application config, something different happens.  I do the login and call
> > the protected resource and get the 200 as before, but now every
> subsequent
> > call to the protected resource returns a 403.  I thought maybe there was
> > something peculiar about this specific protected resource, but not the
> > case, any protected resource works the first time, but not subsequent
> times.
> >
> > To confirm what is going on, I created an unprotected resource that
> > provides auth info, and I can see after I login() it reports my username
> > and my affiliated roles (using isUserInRole() for known role names).
> And I
> > can refresh this info any number of times and it doesn't change.  But as
> > soon as I access a protected resource, twice, the unprotected auth info
> > still shows my username, but now my roles are stripped.
> >
> > Thinking there is something wrong with login(), I change to using BASIC
> and
> > run similar tests, never using the login() call, and everything works
> fine;
> > notably, I can access a protected resource more than once.
> >
> > Strangely, what I also unexpectedly noticed is now that I have BASIC
> > specified, when I do use login() things are working fine now even if I
> > never get a BASIC prompt.  So, I can access a protected resource more
> than
> > once.
> >
> > I know this sounds like a weird state issue, but I've restarted web
> > servers, browsers, deployed, undeployed, and redeployed apps dozens and
> > dozens of time.  And I even confirmed the 200 and subsequent 403 calls
> were
> > exactly the same; notably, both had the same session cookie information.
> >
> > So, if this isn't a tomcat bug, which of course I'm very hesitant to
> imply,
> > then maybe there is something that changed in the configuration that was
> > optional before but maybe isn't now?  Maybe I have to specify BASIC or
> FORM
> > even if I never plan to use it?  Any other suggestions?
>
> Create the simplest possible test case that demonstrates this so folks
> can investigate? There are enough moving parts that trying to reproduce
> this solely from your description is likely to miss something.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

In my last (long) email I described how adding a BASIC login-config changes
things and the roles are no longer getting stripped when using login()
(even when never triggering a basic prompt).  I figured I'd use this as a
workaround until I figure out what is really going wrong.  However, now
I've noticed there is another problem, which may or may not be related.

As described before, when I first login using login() and have BASIC
configured it works as expected.  I can hit a protected resources as many
times as I want and it works fine and the roles remain intact.

But then I'll logout (again, all asynchronously from the same page) which
both invalidates the session and calls logout() on the request, try to hit
the protected resource, and get denied as expected.  But then when I login
using the same mechanism that worked before it seems to all work, but I'm
still denied access to the resource.  If I login *again*, then it works
fine.

Investigating, after I do that login (which is failing) I can see it makes
a principal available and creates a new session and I record the ID.  I can
see that session ID being sent in the cookies of the subsequent protected
resource request which returns the 401.  But when I do a logout I can pull
the same session that was created, but now the principal is null, even
though it existed when I logged in just moments before.

So, instead of the roles being stripped as before, in this case the entire
principal is being removed, but only when you login after an initial
successful login, or maybe after a logout() call?

I feel like I'm going crazy here.  None of this is happening in tomat 8.0.
It is all working as expected.  This is a minimal test application with
essentially a default tomcat config in both versions.

Was anything (significant) changed to login() between tomcat 8.5 and 9 that
could be related?

Thanks-
Robert

roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

(Bear with me as there are a lot of details; I'll try to be as clear as
possible)

I've been setting up a simple application in tomcat 8.0 where some
resources are protected but others aren't.  I want to login using AJAX
instead of FORM or BASIC so I don't have any login-config specified in my
deployment descriptor (nor any security-roles defined).

For testing, I have a custom form that sends login info asynchronously to
an unprotected login service which calls login().  On the same page as the
login form, I have a test button that makes an asynchronous request to a
protected resource (using a @ServletSecurity annotation).  As expected,
before calling login (and thus login()) I get a 403, but after doing the
login() I get a 200 and can see the response text.  This all works fine in
tomcat 8.0.

However, when I try the application in tomcat 8.5, with the same server and
application config, something different happens.  I do the login and call
the protected resource and get the 200 as before, but now every subsequent
call to the protected resource returns a 403.  I thought maybe there was
something peculiar about this specific protected resource, but not the
case, any protected resource works the first time, but not subsequent times.

To confirm what is going on, I created an unprotected resource that
provides auth info, and I can see after I login() it reports my username
and my affiliated roles (using isUserInRole() for known role names).  And I
can refresh this info any number of times and it doesn't change.  But as
soon as I access a protected resource, twice, the unprotected auth info
still shows my username, but now my roles are stripped.

Thinking there is something wrong with login(), I change to using BASIC and
run similar tests, never using the login() call, and everything works fine;
notably, I can access a protected resource more than once.

Strangely, what I also unexpectedly noticed is now that I have BASIC
specified, when I do use login() things are working fine now even if I
never get a BASIC prompt.  So, I can access a protected resource more than
once.

I know this sounds like a weird state issue, but I've restarted web
servers, browsers, deployed, undeployed, and redeployed apps dozens and
dozens of time.  And I even confirmed the 200 and subsequent 403 calls were
exactly the same; notably, both had the same session cookie information.

So, if this isn't a tomcat bug, which of course I'm very hesitant to imply,
then maybe there is something that changed in the configuration that was
optional before but maybe isn't now?  Maybe I have to specify BASIC or FORM
even if I never plan to use it?  Any other suggestions?

Thanks for reading.

Robert

oauth guidance

[Robert J. Carr]

I'm looking to use some kind of combined realm where I can authenticate
(and authorize) users both using the built-in login-config and externally
using oauth.  Ideally, in both cases, I'd be able to have access to roles,
but this isn't a necessity.

You see this sort of thing a lot now, where you have the option to "login
with google" or "login with facebook" or even login using the site's own
credentials.

There seems to be very little information about this out there, though, for
use in tomcat or java ee.  All queries about oauth and tomcat lead to
JASPIC.  I found this question, which is nearly my exact situation, and the
accepted solution there was indeed JASPIC:

https://stackoverflow.com/questions/39058200/tomcat-realm-for-oauth2

But I can find almost no examples of how JASPIC works or what it offers
(beyond the tomcat docs), but only that it is supported in tomcat starting
with 8.5.  I can use tomcat 8.5, so that isn't a problem, but the only
example provider seems to be the one for google, and it isn't super clear
how it all works.

So I'm just looking for any guidance on what road to start down, given my
requirements.  It seems I could write my own realm, but then I'm not sure
how I'd fit in the oauth token flow.  I could use jaspic, but then I'm not
sure if I'd be able to use the regular security-constraints.  Or I could
manage all of the auth myself with various filters and sessions, but that
seems silly given the java ee machinery that's already available.

Any suggestions?

Thanks!
Robert

Re: Configuring DIGEST auth for manager

[Robert J. Carr]

Hi Philippe-

I'm new to the list, and didn't see the previous response either, but I
just did this recently do a similar config so I might have some guidance.

Where you have algorithm="*SHA-256*", for digest.sh too, you shouldn't need
the asterisks.  Why are you using those?

> Set the last part of password following "password1234:" in

This should also include the iterations.  It should be something like:

$1$b9c950640e1b3740e98acb93e669c65766f6670dd1609ba91ff41052ba48c6f3

Good luck!

Robert

On Fri, Dec 8, 2017 at 12:59 AM, Philippe Mouawad <
p.moua...@ubik-ingenierie.com> wrote:
>
> Hi Mark,
> Sorry but I didn't receive the reply otherwise I wouldn't be asking again.
> I'll see the archives then.
>
> Thanks
> Regards
>
> On Fri, Dec 8, 2017 at 9:20 AM, Mark Thomas  wrote:
>
> > On 07/12/17 21:24, Philippe Mouawad wrote:
> > > Hello,
> > > Last ping hoping to get some help.
> >
> > If you aren't going to read the replies Chris has already given you to
> > your original question and your subsequent ping there isn't much more we
> > can do to help you.
> >
> > Mark
> >
> >
> > >
> > > Thanks
> > >
> > > On Wed, Nov 8, 2017 at 10:19 PM, Philippe Mouawad <
> > > p.moua...@ubik-ingenierie.com> wrote:
> > >
> > >> Hello,
> > >> Any feedback on this ?
> > >> Thanks
> > >>
> > >> On Sun, Nov 5, 2017 at 9:16 PM, Philippe Mouawad <
> > >> p.moua...@ubik-ingenierie.com> wrote:
> > >>
> > >>> Hello,
> > >>> I am having issues making Digest auth work in Tomcat 8.5.23 for
manager
> > >>> application.
> > >>>
> > >>> I have done the following:
> > >>>
> > >>> 1) Edit server.xml and have set MessageDigestCredentialHandler with
> > >>> SHA-256
> > >>>   
> > >>> 
> > >>>  > >>> resourceName="*UserDatabase*">
> > >>>   
> > >>> 
> > >>>   
> > >>>
> > >>> 2) Generated password using:
> > >>> ./digest.sh -a *SHA-256* -h org.apache.catalina.realm.
> > MessageDigestCredentialHandler
> > >>> -i 1 -s 0 password1234
> > >>>
> > >>> I also tried :
> > >>> ./digest.sh -a SHA-256 -h org.apache.catalina.realm.
> > MessageDigestCredentialHandler
> > >>> -i 1 -s 0 tomcat:UserDatabase:password1234
> > >>>
> > >>> 3) Set the last part of password following "password1234:" in
> > >>> tomcat-users.xml
> > >>> 
> > >>> 
> > >>> 
> > >>>  > >>> roles="manager-gui,admin,manager"/>
> > >>>
> > >>> 4) Edit /webapps/manager/WEB-INF/web.xml
> > >>>
> > >>> 
> > >>> DIGEST
> > >>> UserDatabase
> > >>>   
> > >>>
> > >>> I then try to login to http://localhost:8080/manager/html and enter
> > >>> admin and password1234
> > >>> it fails.
> > >>>
> > >>> There must be something I am missing.
> > >>>
> > >>> Sorry if I misread some documentation or if my question is stupid,
> > these
> > >>> are the docs I have seen:
> > >>> - https://tomcat.apache.org/tomcat-8.5-doc/config/credentialha
> > >>> ndler.html#MessageDigestCredentialHandler Note the start of this
part
> > is
> > >>> not that clear for me. I think my format is
> > >>> *salt$iterationCount$encodedCredential* - a hex encoded salt,
> > iteration
> > >>> code and a hex encoded credential, each separated by $
> > >>>
> > >>> I have also tried solutions described here without success:
> > >>> - http://www.techpaste.com/2013/05/enable-password-encryption-
> > >>> policy-tomcat-7/
> > >>> - https://stackoverflow.com/questions/39967289/how-to-use-dige
> > >>> st-authentication-in-tomcat-8-5
> > >>> - https://stackoverflow.com/questions/2978884/tomcat-digest-wi
> > >>> th-manager-webapp
> > >>>
> > >>> Regards
> > >>> Philippe
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Cordialement.
> > >> Philippe Mouawad.
> > >> Ubik-Ingénierie
> > >>
> > >> UBIK LOAD PACK Web Site 
> > >>
> > >> UBIK LOAD PACK on TWITTER 
> > >>
> > >>
> > >
> > >
> >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
> Ubik-Ingénierie
>
> UBIK LOAD PACK Web Site 
>
> UBIK LOAD PACK on TWITTER 

Re: Is it possible to externally authenticate using OAuth?

[Robert J. Carr]

Hi Mark-

Thanks for the quick reply and I'll look into Authenticators.

Since you suggest 8.5.x, does that mean I was on the right track with
JASPIC?

Thanks again!

Robert


On Fri, Dec 8, 2017 at 12:26 AM, Mark Thomas <ma...@apache.org> wrote:

> On 08/12/17 07:08, Robert J. Carr wrote:
> > [tomcat 8, java 8, ubuntu xenial]
> >
> > I have setup security constraints that allow certain resources to only be
> > accessed by authorized users. The users are authenticated using either
> > BASIC or FORM, where a username and password is provided, and this works
> > great.
> >
> > However, I'd also like to allow users to authenticate externally using an
> > oauth provider. Is this possible?  Note that I can already acquire the
> > access tokens for the user, and from there I can get the username and
> other
> > profile metadata as necessary.
> >
> > But how do I then log the user into tomcat? The only way I can think to
> > make this work is to take this username and create a tomcat account,
> maybe
> > setting the access token as the password if it matters. Then I could do a
> > programmatic tomcat login on behalf of the user, so she is locally
> > authenticated and a session is created. On subsequent logins I'd just
> > update the password to the new access token.
> >
> > But this seems like a hack, and when it comes to users and security I'd
> > prefer to avoid hacks.
> >
> > It looks like JASPIC might offer a solution for this? Unfortunately, it
> > looks like it became available starting at 8.5 but I'm stuck using 8.
> >
> > Are there any other options?
>
> A custom Authenticator (that extends AuthenticatorBase) would be the
> standard way of handling this.
>
> Given 8.0.x is approaching end of life (2018-06-30), it might be less
> effort to look at switching to 8.5.x.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Is it possible to externally authenticate using OAuth?

[Robert J. Carr]

[tomcat 8, java 8, ubuntu xenial]

I have setup security constraints that allow certain resources to only be
accessed by authorized users. The users are authenticated using either
BASIC or FORM, where a username and password is provided, and this works
great.

However, I'd also like to allow users to authenticate externally using an
oauth provider. Is this possible?  Note that I can already acquire the
access tokens for the user, and from there I can get the username and other
profile metadata as necessary.

But how do I then log the user into tomcat? The only way I can think to
make this work is to take this username and create a tomcat account, maybe
setting the access token as the password if it matters. Then I could do a
programmatic tomcat login on behalf of the user, so she is locally
authenticated and a session is created. On subsequent logins I'd just
update the password to the new access token.

But this seems like a hack, and when it comes to users and security I'd
prefer to avoid hacks.

It looks like JASPIC might offer a solution for this? Unfortunately, it
looks like it became available starting at 8.5 but I'm stuck using 8.

Are there any other options?

Thanks!

Robert

strangeness with MemoryUserDatabase

[Robert J. Carr]

Yesterday I asked a question about using tomcat authorization with httpd
authentication.  Here's the subject: httpd authentication with tomcat
authorization. I'm still awaiting a response, but I thought I'd come up
with a solution anyway.  I've got something working, but wanted to dig a
bit deeper.  Again, this is in Tomcat 6.0.41.

I overrode the UserDatabaseRealm to take advantage of its creation of the
MemoryUserDatabase and all I needed to do was override the hasRole().  When
asking it to print the database, I get a reasonable result:


MemoryUserDatabase[id=UserDatabase,pathname=conf/tomcat-users.xml,groupCount=0,roleCount=11,userCount=9]

And when asking it to give me users and roles with findUser() and
findRole() it works fine.

However, when I try to iterate over all the users and roles the iterator is
always empty.  This is true for the groups as well.  Looking at the code
from MemoryUserDatabase seems straight forward enough:

public Iterator getUsers() {
synchronized (users) {
return (users.values().iterator());
}
}

But as I said, this iterator is always empty. I'm not sure how this is
possible given the findUser(), that works, is equally simple:

public User findUser(String username) {
synchronized (users) {
return ((User) users.get(username));
}
}

And the iterators seem to be empty either when first loaded from the
UserDatabaseRealm in start() or when in the hasRole().

I'm not reporting a problem of my own, since I'm not using the iterators,
but just wanted to report the strangeness that I'm seeing.

httpd authentication with tomcat authorization

[Robert J. Carr]

I have a setup where httpd is doing my (basic) authentication but I need
tomcat (6, if it matters) to manage the roles and do the authorization.
The link between httpd and tomcat is through the ajp connector and on this
connector's config I've added:

tomcatAuthentication=false

This passes the authenticated user name as expected, but even if I have
this user listed in my tomcat-users.xml file, I get a 403 (access denied).

I'm using the standard UserDatabaseRealm and I'm happy to continue using it
with the tomcat-users.xml file. What I've learned, however, is that when
tomcatAuthentication is off then instead of the UserDatabaseRealm producing
the principal (GenericPrincipal) it is produced by the connector (I think)
and is then a CoyotePrincipal.

So, because it is unrecognized, the UserDatabaseRealm rejects this
principal in the hasRole() method and it always returns false.

The Realm API seems straight forward enough, but before I create my own and
parse the users file and package my realm to place in the container and
probably a few other steps I'm wondering if there's something simpler I
could do that's already out there?  This seems like a reasonably common
thing but I couldn't find anything relevant.

Thanks for the time!

DefaultServlet, WebDAV, and Permissions

[Robert J. Carr]

I sent this out last week and didn't get any responses ... just wanted
to make sure it hit the list and didn't get dropped somewhere.  Any
help is appreciated!



I'm using the WebDAV servlet in tomcat 5.5.22 and I'm having some
issues that I was hoping I could get sorted out.  First of all, I'm
seeing reams and reams of these in the logs:

Aug 8, 2007 5:15:30 PM org.apache.catalina.core.ApplicationContext log
INFO: webdav: DefaultServlet.doPut: couldn't delete temporary file: null

They seem to happen on every access ... lists, puts, etc.  Ideas?  Are
they benign and should I just turn down the log level?

The second problem is much more involved, so please bear with me.  I
have started tomcat as myself, say 'jack'.  The user 'jack' is a
memeber of the group 'hill'.  The user 'jill' is also a member of the
group 'hill'.  In web.xml I have specified a dav folder of /webdav.
That folder is owned by 'jack' and group writable by 'hill' (755).
Inside of /webdav I have two folders:

drwxrwxr-x  2 jack hill  4096 Aug  1 14:01 f1
drwxrwxr-x  2 jill hill 69632 Aug  8 17:15 f2

As user 'jack', on the server, I can create (or touch) a file in both
folders 'f1' and 'f2'.  If I remotely mount the file system with
WebDAV, I can also write to the folder 'f1', but now I can't write to
'f2'.  Mounting with Finder on Mac gives me a strange (and incorrect)
error (talking about filenames being to long), and using sitecopy I
get a 409 (conflict) error.

I understand that Java doesn't deal with permissions, but shouldn't it
just try to write the file and respond to what the OS tells it can be
done?  Or is something else going on?  Are my two problems related?
Is this a problem in DefaultServlet in general?

Thanks for taking a look!

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

WebDAV, DefaultServlet, and Permissions

[Robert J. Carr]

I'm using the WebDAV servlet in tomcat 5.5.22 and I'm having some
issues that I was hoping I could get sorted out.  First of all, I'm
seeing reams and reams of these in the logs:

Aug 8, 2007 5:15:30 PM org.apache.catalina.core.ApplicationContext log
INFO: webdav: DefaultServlet.doPut: couldn't delete temporary file: null

They seem to happen on every access ... lists, puts, etc.  Ideas?  Are
they benign and should I just turn down the log level?

The second problem is much more involved, so please bear with me.  I
have started tomcat as myself, say 'jack'.  The user 'jack' is a
memeber of the group 'hill'.  The user 'jill' is also a member of the
group 'hill'.  In web.xml I have specified a dav folder of /webdav.
That folder is owned by 'jack' and group writable by 'hill' (755).
Inside of /webdav I have two folders:

drwxrwxr-x  2 jack hill  4096 Aug  1 14:01 f1
drwxrwxr-x  2 jill hill 69632 Aug  8 17:15 f2

As user 'jack', on the server, I can create (or touch) a file in both
folders 'f1' and 'f2'.  If I remotely mount the file system with
WebDAV, I can also write to the folder 'f1', but now I can't write to
'f2'.  Mounting with Finder on Mac gives me a strange (and incorrect)
error (talking about filenames being to long), and using sitecopy I
get a 409 (conflict) error.

I understand that Java doesn't deal with permissions, but shouldn't it
just try to write the file and respond to what the OS tells it can be
done?  Or is something else going on?  Are my two problems related?
Is this a problem in DefaultServlet in general?

Thanks for taking a look!

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CGIServlet

[Robert J. Carr]

Both.  You've made the incorrect assumption that made visible means
made visible to web applications, which is incorrect.  A classloader
makes classes and resources visible to whoever has access to the
classloader; webapps do not have access to the Catalina classloader.


...


Tomcat is the one that processes the servlet mappings, so the CGIServlet
needs to be visible only to Tomcat, not the rest of the webapp.


GREAT explanation ... I hadn't looked at it this way.  Thank you very
much!  Knowing is half the battle. :)

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CGIServlet

[Robert J. Carr]

Thanks for the quick reply, I don't believe I've tried that, but it
isn't the complete solution I was looking for.  Remember, tomcat (5.5)
is shipped with the CGIServlet jar in a package named
/server/lib/servlets-cgi.renametojar.  Using your solution would
remove the servlet setup from the global web.xml, but still require an
admin to rename the jar.  Sure, not a big deal, but an installation
requirement I'd like to avoid.

So I guess the question comes down to classloading, and I'm getting
confused there.  On, this page:

http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html

It says:

Catalina - This class loader is initialized to include all classes
and resources required to implement Tomcat 5 itself. These classes and
resources are TOTALLY invisible to web applications. All unpacked
classes and resources in $CATALINA_HOME/server/classes, as well as
classes and resources in JAR files under $CATALINA_HOME/server/lib,
are made visible through this class loader.

So I'm not following, are the resources TOTALLY invisible to web
applications  or are they made visible through this class loader?
The two parts seem contradictory to me.  Is is saying the actual
*files* are inivisble, but the classes (in either classes or lib) are
made visible by the classloader?  Again, not sure.

If they are TOTALLY invisible then your suggestion wouldn't work, as
the CGIServlet is in /server/lib.  However, the WebdavServlet runs in
a stand-alone webapp and it is also located in /server/lib.

So, in summary, you're saying the only way I can get CGIServlet
defined in a single webapp is to leave servlets-cgi.jar in /server/lib
and require an administrator to rename it?



On 6/30/07, Mark Thomas [EMAIL PROTECTED] wrote:

Robert J. Carr wrote:
 To do this, I simply put the servlet definitions into my own web.xml,
 and then put the servlets-cgi.jar into my own lib.  When doing this, I
 get a ClassNotFound exception on CGIServlet.

Try just putting the definition in your web.xml and leave the jar where
it is.

Mark


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebdavServlet

[Robert J. Carr]

Hey Mark-

Thanks for the quick reply, and what you're saying confirms my
assumption that the filter solution that is provided isn't going to
work for me.

However, I claim that the initial bug report is *exactly* the problem
I'm having.  If the filter solution doesn't address the problem, then
why was the report labeled fixed and closed?

Also, I'm not quite following what you're saying here (which could
mean I didn't explain my problem clearly):


The way the webdav servlet is written, it exposes the whole of the
webapp.


Agreed, that's what I'm finding and trying to avoid.


Mapping it to /edit/* allows the content to be exposed at an
alternative url.


Sure, but the content exposed would still be the whole of the webapp, right?


The idea is that normal users access /your-app/*, a
system admin can edit contant via /your-app/edit/*.


Not following what a system admin has to do with anything.  The 'edit'
folder would just be implied ... both normal users and system
admin would still be exposed to the whole of the webapp, right?

On 6/30/07, Mark Thomas [EMAIL PROTECTED] wrote:

Robert J. Carr wrote:
 I'd like to add the webdav servlet to my own web application.  I can
 do this and it works, but it treats the root of my webapp as the root
 of the dav share.

The way the webdav servlet is written, it exposes the whole of the
webapp. Mapping it to /edit/* allows the content to be exposed at an
alternative url. The idea is that normal users access /your-app/*, a
system admin can edit contant via /your-app/edit/*.

To do what you want to do would require:
- changes to the webdav servlet
- placing the edtiable content in a separate (sub-)context
- blocking webdav methods for urls that should not be editable

Mark


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CGIServlet

[Robert J. Carr]

I'd like to use some basic CGI in my webapp but I don't want to rely
on server admins to set it up per the directions of the how to (found
at http://tomcat.apache.org/tomcat-5.5-doc/cgi-howto.html).  When I
follow those directions, everything works fine, however I'd like to
put the CGIServlet definition into my own webapp.

To do this, I simply put the servlet definitions into my own web.xml,
and then put the servlets-cgi.jar into my own lib.  When doing this, I
get a ClassNotFound exception on CGIServlet.

At first I was pretty stumped by this, because I was sure the classes
were there to be found, but after digging a bit deeper, I think it was
just a bad exception.  I'm guessing the reason I'm getting the error
is because CGIServlet.jar imports two other classes:

import org.apache.catalina.Globals;
import org.apache.catalina.util.IOTools;

Those classes are located in catalina.jar and catalina-optional.jar,
respectively, which are both in servert/lib, which aren't visible to
webapps.

I can try putting those two jars into my webapp, but it is likely to
cascade and those jars need jars, etc.  So, my question is, what would
be the best approach for getting the CGISerlet into my own webapp
without having to set it up at a global level?  Or maybe I'm wrong in
my ClassNotFound diagnosis?  Thanks!

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

WebdavServlet

[Robert J. Carr]

I'd like to add the webdav servlet to my own web application.  I can
do this and it works, but it treats the root of my webapp as the root
of the dav share.  I would like to have my webapp do more than webdav,
so I was hoping I could specify that only a portion of my webapp is
visible to dav.  I initially (naively) though setting up a simple
servlet mapping would fix it, similar to this:

servlet-mapping
 servlet-namewebdav/servlet-name
 url-pattern/dav/*/url-pattern
/servlet-mapping

But then realized this has nothing to do with the share point.  So
then I thought it would be set as an init-param, but looking at the
docs there is no such parameter, but the top of WebdavServlet.java
says this:

* Check out http://issues.apache.org/bugzilla/show_bug.cgi?id=40160
for a Filter
* that allows you to map this servlet anywhere inside a web
application, not just
* the /* URL pattern.

So this sounds like what I'm after.  I look at the issue and the guys
initial report seems exactly like my situation.  After that, another
guy posts a solution using a filter, and although I'm far from a
filter expert, this doesn't seem like a solution at all.  The code has
typos in it, so that makes me even more suspicious that it wasn't
tested.

So I'm hoping someone can provide a solution for me, or if the filter
*does* work, explain how/why, because what I've seen just seems to
cover request made for specific microsoft resources.

Thanks!

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]