Re: static content not served for non-root apps via mod_jk

[Eric P]

I remember now why static content works for my ROOT app.  I have
Apache aliases set-up pointing to specific system directories for all
static content.

For example, I have all images for the ROOT app aliased here.
Alias /img /opt/tomcat7/webapps/ROOT/img

Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all


But is there a better approach for this so that I don't have to create
static content aliases for each new Tomcat app I deploy?  I would be
stuck using a unique alias for every app which seems crazy.

Thanks,
Eric

2012/1/13 Eric P :
> Hi all,
>
> I'm having trouble getting Apache to serve static content (jpg, css, js, 
> etc.) for Tomcat apps via mod_jk for any
> application except the ROOT Tomcat app.  The ROOT app shows static content 
> just fine.
>
> I have the following Apache settings attempting to point *all* requests to 
> Tomcat and unsetting certain static content
> extensions so that Apache will serve them.
>
> ...clip...
> # Send everything to Tomcat
> JkMount /* ajp13
>
> # And then unsend static content so that httpd will serve it
> JkUnMount /*.js ajp13
> JkUnMount /*.css ajp13
> JkUnMount /*.jpg ajp13
> JkUnMount /*.png ajp13
> JkUnMount /*.gif ajp13
> ...clip...
>
> These settings work for the ROOT Tomcat app but not for anything else 
> including Tomcat's manager app.
>
> FYI. when I access via Tomcat's port/web server everything works.
> E.g., http://localhost:8080/manager/html
>
> But not when I access via port 80.
> E.g., http://localhost/manager/html
>
> I"m seeing a 404 Not Found for all static content via port 80/Apache (again, 
> the only exception is any static content
> belonging to the ROOT Tomcat app).  I'm experiencing the exact same behavior 
> on both an Ubuntu and CentOS.
>
> Thanks for any ideas.
> Eric

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

static content not served for non-root apps via mod_jk

[Eric P]

Hi all,

I'm having trouble getting Apache to serve static content (jpg, css, js, etc.) 
for Tomcat apps via mod_jk for any
application except the ROOT Tomcat app.  The ROOT app shows static content just 
fine.

I have the following Apache settings attempting to point *all* requests to 
Tomcat and unsetting certain static content
extensions so that Apache will serve them.

...clip...
# Send everything to Tomcat
JkMount /* ajp13

# And then unsend static content so that httpd will serve it
JkUnMount /*.js ajp13
JkUnMount /*.css ajp13
JkUnMount /*.jpg ajp13
JkUnMount /*.png ajp13
JkUnMount /*.gif ajp13
...clip...

These settings work for the ROOT Tomcat app but not for anything else including 
Tomcat's manager app.

FYI. when I access via Tomcat's port/web server everything works.
E.g., http://localhost:8080/manager/html

But not when I access via port 80.
E.g., http://localhost/manager/html

I"m seeing a 404 Not Found for all static content via port 80/Apache (again, 
the only exception is any static content
belonging to the ROOT Tomcat app).  I'm experiencing the exact same behavior on 
both an Ubuntu and CentOS.

Thanks for any ideas.
Eric

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 7.0.22+ fd leak with APR/native

[Arijit Ganguly]

I am curious to know if this leak is related to unix sockets, or the IPv6
file handles. I have seen a similar issue with the NIO HTTP handler, where
it does not close some connections properly and they incarnate as file
handles corresponding to unix sockets (all pointing to same inode number).
Even 7.0.21 has problems.

Thanks,
Arijit

On Fri, Jan 13, 2012 at 4:24 PM, Mike Wertheim  wrote:

> Has a bug been logged for this issue (what seems to be a file descriptor
> leak)?
>
> On Tue, Jan 3, 2012 at 1:17 PM, Mark Thomas  wrote:
> > I am trying to bring together all the information I have gleaned on this
> > so far from the multiple threads to try and find the common factors.
> >
> > So far I have:
> > - 7.0.21 is OK
> > - 7.0.22 has an fd leak
> > - 7.0.23 has an fd leak and may leak faster than 7.0.22
> > - occurs with APR/native
> > - does not occur with BIO
> > - has been observed in HTTP & HTTPS
> > - use of Comet does not trigger it
> > - use of compression does not trigger it
> > - separate connection and keep-alive timeouts does not trigger it
> >
> > It may be related to POST processing.
> >
> > I have tried (and so far failed) to reproduce this. I'll be looking at
> > POST processing next. In the meantime, here are some further questions
> > to try and narrow things down:
> >
> > 1. Does the application where this is observed make use of Servlet 3.0
> > async requests?
> >
> > 2. Does this leak occur when the NIO connector is used?
> >
> > 3. Are there any exceptions in the logs that weren't present in 7.0.21
> > or earlier?
> >
> > 4. Does the leak occur if sendfile is disabled?
> >
> > I also have reviewing the 7.0.21 to 7.0.22 changes on my todo list but
> > there are quite a few as I was refactoring the connectors to reduce code
> > duplication and ironically, reduce maintenance requirements, at the time.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: 7.0.22+ fd leak with APR/native

[Mike Wertheim]

Has a bug been logged for this issue (what seems to be a file descriptor leak)?

On Tue, Jan 3, 2012 at 1:17 PM, Mark Thomas  wrote:
> I am trying to bring together all the information I have gleaned on this
> so far from the multiple threads to try and find the common factors.
>
> So far I have:
> - 7.0.21 is OK
> - 7.0.22 has an fd leak
> - 7.0.23 has an fd leak and may leak faster than 7.0.22
> - occurs with APR/native
> - does not occur with BIO
> - has been observed in HTTP & HTTPS
> - use of Comet does not trigger it
> - use of compression does not trigger it
> - separate connection and keep-alive timeouts does not trigger it
>
> It may be related to POST processing.
>
> I have tried (and so far failed) to reproduce this. I'll be looking at
> POST processing next. In the meantime, here are some further questions
> to try and narrow things down:
>
> 1. Does the application where this is observed make use of Servlet 3.0
> async requests?
>
> 2. Does this leak occur when the NIO connector is used?
>
> 3. Are there any exceptions in the logs that weren't present in 7.0.21
> or earlier?
>
> 4. Does the leak occur if sendfile is disabled?
>
> I also have reviewing the 7.0.21 to 7.0.22 changes on my todo list but
> there are quite a few as I was refactoring the connectors to reduce code
> duplication and ironically, reduce maintenance requirements, at the time.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Interactive Services Detection

[Pid]

On 13/01/2012 19:47, Shoffey, Montreal wrote:
> 
> Tomcat 64-bit is running on Windows 2008 Server. I have an application
> that is using Apache + Tomcat 6.0.30 and the application seems to be
> running fine.
> 
> The popup error is from Interactive Services Detection with the message
> that tomcat6.exe is requesting attention.

Any more detail than that?  It's a bit tricky to know what's happened
without any more information.


> In the Tomcat properties, I have Log on as Local System account and the
> Allow service to interact with desktop is checked.
> 
> If I disable the service, I would just be ignoring the problem and not
> fixing it.

Disable which service?  The Tomcat one?


> Is this an unhandled exception of some kind? Can someone help me fix
> this? 

There are a number of log files in the 'logs' directory of your Tomcat
installation.  Have a look in each file for additional information and
report back.


p


> v/r
> Montreal
> _
> Gail "Montreal" Shoffey
> VA Office of Information and Technology IT Workforce Development
> 304-262-7713 Office
> 202-400-7970 Mobile
> 304-262-7701 FAX
> Visit the ITWD Portal
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: Tomcat 7 (64 bit) does not seem to honor session timeout?

[Paul Joseph]

This was a false alarm.  My apologies.
Paul

On 1/12/2012 8:24 AM, Pid wrote:

On 11/01/2012 21:50, Paul Joseph wrote:

Hi there,

I am running the Cocoon (2.11) servlet in Tomcat 7.0.23 (64 bit version)
on Windows 2008 R2 (and also in 32 bit on Redhat linux).  I am using the
Java 1.6 JRE.

I have my session timeout set in web.xml to 60 minutes.

Just to clarify, which web.xml file?


However I find that with about 44 minutes of inactivity that my session
appears to have expired.

Can you reproduce this with a simple single Servlet application?


p


I tried it with the default 30 minute time out and found that after
about 25 minutes my session had expired...

Is there any one else who has had this issue...or what could I be doing
wrong?

best
Paul



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JDK Version Mismatch

[Mark Eggers]

- Original Message -

> From: deniz 
> To: users@tomcat.apache.org
> Cc: 
> Sent: Thursday, January 12, 2012 11:25 PM
> Subject: RE: JDK Version Mismatch
> 
> Hello Chuck,
> 
> thank you for your response, I have changed tomcat env to 1.7 so i am not
> getting the error right now. 
> 
> i have another question about the same issue but i am not quite sure if this
> is the right place...
> 
> so right now eclipse doesnt support jdk 1.7 and you need to download a
> maintenance version to use it. it really works well except something: you
> cant create webapps with it. so to overcome the problem what should i do? I
> have tried something and till now it "seems" okay... I have created 
> and
> compiled my class files with jdk 1.7 and then put them in a jar and included
> that jar file in my webapp project on jdk 1.6 which i create jsp files. is
> this a feasible way to fix the problem? or should i change the classes in my
> webapp folder under tomcat manually, with jdk 1.7 compiled classes? 
> 
> thank you in advance again... 
>

Or use an IDE that fully supports JDK 7.

. . . . just my two cents.
/mde/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Interactive Services Detection

[Shoffey, Montreal]

Tomcat 64-bit is running on Windows 2008 Server. I have an application
that is using Apache + Tomcat 6.0.30 and the application seems to be
running fine.

The popup error is from Interactive Services Detection with the message
that tomcat6.exe is requesting attention.

In the Tomcat properties, I have Log on as Local System account and the
Allow service to interact with desktop is checked.

If I disable the service, I would just be ignoring the problem and not
fixing it.

Is this an unhandled exception of some kind? Can someone help me fix
this? 


v/r
Montreal
_
Gail "Montreal" Shoffey
VA Office of Information and Technology IT Workforce Development
304-262-7713 Office
202-400-7970 Mobile
304-262-7701 FAX
Visit the ITWD Portal



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: About certificates in Tomcat SSL support

[James Lampert]

Mark H. Wood wrote:

As already pointed out, there's your problem.  To identify a networked
service, the value of CN should be the FQDN of the host providing the
service.  (This is why people suddenly became interested in securing
DNS:  we are relying on it to validate certificate bindings to services!)

Yes, the prompts are confusing.  A recent release of OpenSSL, for
example, just updated the CN prompt from "Common Name (eg, YOUR name)"
to "Common Name (e.g. server FQDN or YOUR name)".


Thanks for the additional detail.

We now have the customer set up with a less-frightening self-signed 
certificate, specific to their domain, pending installation of a 
CA-signed certificate (which I sincerely hope is domain-specific).


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: About certificates in Tomcat SSL support

[Mark H. Wood]

On Thu, Jan 12, 2012 at 09:14:28AM -0800, James Lampert wrote:
> Scenario:
> 
> I created a self-signed certificate for the box I was testing:
> CN = James Lampert

As already pointed out, there's your problem.  To identify a networked
service, the value of CN should be the FQDN of the host providing the
service.  (This is why people suddenly became interested in securing
DNS:  we are relying on it to validate certificate bindings to services!)

Yes, the prompts are confusing.  A recent release of OpenSSL, for
example, just updated the CN prompt from "Common Name (eg, YOUR name)"
to "Common Name (e.g. server FQDN or YOUR name)".

> OU = Development Lab
> O = Touchtone Corporation
> L = Costa Mesa
> ST = California
> C = US
> 
> I then installed it into the Tomcat server on that box. Connecting to 
> the site with Firefox, I was told that the certificate was not trusted, 
> and asked whether to trust it. After I said to trust it, Firefox now 
> lets me in without further question.

Yup.  A certificate not already trusted must be validated by a higher
authority.  If it is signed by another certificate, that is the
authority (subject to validation itself); if self-signed, the only
available higher authority is you.

> Then, I temporarily installed the certificate on a customer's Tomcat 
> server, just to verify that SSL support was working there. When I 
> connected to it with Firefox, the initial message questioning the 
> validity of the certificate said something about it being for a 
> different server (so far as I'm aware, it isn't for *any* particular 
> server).

I would consider that the proper behavior.

> Looking at the two Tomcat servers in Microsloth Imploder, even after 
> telling it to trust the certificate, I consistently get a message, "The 
> security certificate presented by this website was issued for a 
> different website's address."

I'm concerned that you did *not* get this from the first instance of
Firefox, since that cert. couldn't possibly identify *any* networked
service.  The browser should complain, because there is no DNS domain
named "James Lampert".

> Looking at the two Tomcat servers in a different version of Firefox, on 
> a different WinDoze box, both Tomcat servers give me the message, that 
> it is not trusted because it is self-signed, and that it is only valid 
> for James Lampert.

Every root CA certificate is self-signed.  Your cert. is not trusted
because no one told the client to trust the certificate at the top of
the chain of signatures which, for a self-signed certificate, is that
very certificate.  There's nothing inherent in any certificate which
makes it trustworthy; someone has to tell each client which
authorities to trust, thus which end certificates it can validate
without help.  Browsers usually don't kick up a fuss because their
makers have made that trust decision for you with regard to bales of
CAs' certificates before you got your copy of the browser.

> Also: we have a CA-signed certificate that we use to sign JARs. Is that 
> the same sort of certificate used for Tomcat?

In that both are (presumably) X.509 certificates, yes.  Otherwise you
need to describe "same sort" more precisely.

Typically you would want to use a cert. signed by a well-known CA, so
that most browsers will have already been told to trust that CA and so
will be able to validate your certificate without bothering the user.

If you coin your own cert.s then anyone who uses the affected servers
will have to add those cert.s to their truststores or put up with the
"are you sure you want to trust these guys?" dialog every time they
visit.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are smart.


pgpKV6HHHE0Jj.pgp
Description: PGP signature

Re: Clarification regarding JULI logger

[Pid]

On 13/01/2012 11:04, Parthiban P wrote:
> Dear Team,
> 
> We are using TOMCAT-JULI logger for logging purpose in our application.
> 
> We bundle tomcat(6.0.28) in our product and start the tomcat when our
> product is started (i.e. we start tomcat from our product-startup-code).
> 
> For debugging purpose our application needs to change the Logger LEVEL
> dynamically. When tried to implement this using
> LogManager.getLogger(className).setLevel(requiredLevel) we found that its
> not working. And when analyzed the JULI code we found that it is searching
> for the loggers of the currentClassLoader classes only (i.e. not searching
> the loggers from parentClassLoader). Kindly advise us how to proceed
> further to handle our use-case.

What is changing the log level and where is the code doing it located,
relative to your other applications?


> Is it advisable for us to change the
> ClassLoaderLogInfo.getClassLoaderInfo() method accordingly?

Probably not.  Have you looked at the JMX MBeans for JUL?


p

> Need your help at the earliest.
> 
> Thanks
> 
> Parthiban P
> 


-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: periodic (60 sec) problem from Vysper bosh servlet embedded in Tomcat 7.0.23

[Pid]

> -Original Message-
> From: Pid [mailto:p...@pidster.com] 
> Sent: Wednesday, January 11, 2012 4:30 AM
> To: Tomcat Users List
> Subject: Re: periodic (60 sec) problem from Vysper bosh servlet embedded in 
> Tomcat 7.0.23
> 
> On 10/01/2012 21:04, Bob DeRemer wrote:
>> Tomcat Community,
>>
>>  
>>
>> I'm not sure if this should be posted here or on the Mina/Vysper list, 
>> but since the problem seems to be around Jetty Servlet3 continuation 
>> functionality within the context of Tomcat, I thought I'd post here first.
> 
> Which version of Tomcat, exactly?
> 
> On 12/01/2012 12:02, Bob DeRemer wrote:
> Tomcat 7.0.23 64-bit on windows server 2008 R2 64-bit

Please don't top-post.


>> PROBLEM
>>
>> We're using vysper in an embedded mode and have modified the 
>> BoshServlet to work in the context of our web application.  The Vysper 
>> bosh servlet seems to make use of Jetty servlet3 continuation, and 
>> we're getting the following stack trace every 60 seconds.  60 seconds 
>> seems to be the default bosh session timeout when there is no activity:

Are you expecting the timeout to fire at this point, for those requests?

The request seems to think it is in the "DISPATCHING" state - is this
perhaps a long running stream of events?


>> I'm not sure what's going on with the low-level servlet3 continuation 
>> stuff, but if anyone has any suggestions/recommendations, I'd greatly 
>> appreciate it.

I would also investigate whether that library supports a particular
version of Tomcat.


p

>> Thanks,
>>
>> Bob
>>
>>  
>>
>> SEVERE: null
>>
>> _java.lang.IllegalStateException_: Calling [asyncDispatch()] is not 
>> valid for a request with Async state [DISPATCHING]
>>
>>   at
>> org.apache.coyote.AsyncStateMachine.asyncDispatch(_AsyncStateMachine.j
>> ava:256_)
>>
>>   at
>> org.apache.coyote.http11.Http11AprProcessor.actionInternal(_Http11AprP
>> rocessor.java:468_)
>>
>>   at
>> org.apache.coyote.http11.AbstractHttp11Processor.action(_AbstractHttp1
>> 1Processor.java:834_)
>>
>>   at org.apache.coyote.Request.action(_Request.java:344_)
>>
>>   at
>> org.apache.catalina.core.AsyncContextImpl.dispatch(_AsyncContextImpl.j
>> ava:185_)
>>
>>   at
>> org.apache.catalina.core.AsyncContextImpl.dispatch(_AsyncContextImpl.j
>> ava:146_)
>>
>>   at
>> org.apache.catalina.core.AsyncContextImpl.dispatch(_AsyncContextImpl.j
>> ava:140_)
>>
>>   at
>> org.eclipse.jetty.continuation.Servlet3Continuation.resume(_Servlet3Co
>> ntinuation.java:153_)
>>
>>   at
>> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.writ
>> e0(_BoshBackedSessionContext.java:233_)
>>
>>   at
>> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.requ
>> estExpired(_BoshBackedSessionContext.java:451_)
>>
>>   at
>> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.acce
>> ss$000(_BoshBackedSessionContext.java:46_)
>>
>>   at
>> org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext$1.on
>> Timeout(_BoshBackedSessionContext.java:605_)
>>
>>   at
>> org.eclipse.jetty.continuation.Servlet3Continuation$2.onTimeout(_Servl
>> et3Continuation.java:90_)
>>
>>   at
>> org.apache.catalina.core.AsyncListenerWrapper.fireOnTimeout(_AsyncList
>> enerWrapper.java:45_)
>>
>>   at
>> org.apache.catalina.core.AsyncContextImpl.timeout(_AsyncContextImpl.ja
>> va:118_)
>>
>>   at
>> org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(_CoyoteAdapt
>> er.java:292_)
>>
>>   at
>> org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(_Abstra
>> ctHttp11Processor.java:1515_)
>>
>>   at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(_
>> AbstractProtocol.java:523_)
>>
>>   at
>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(_AprEndpoin
>> t.java:1817_)
>>
>>   at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
>> Source)
>>
>>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
>> Source)
>>
>>   at java.lang.Thread.run(Unknown Source)
>>
>>  
>>
>>  
>>
>>  
>>
>> *Bob DeRemer*
>>
>> *Senior Director, Architecture and Development*
>>
>>  
>>
>> Description: Description: Description: Description:
>> cid:image001.png@01CBE3DE.51A12030
>>
>> http://www.thingworx.com 
>>
>> Skype: bob.deremer.thingworx
>>
>> O: 610.594.6200 x812
>>
>> M: 717.881.3986
>>
>>  
>>
> 
> 


-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: Accessing peer certificates of SSL in tomcat

[Pid]

On 13/01/2012 12:03, ciphe wrote:
> Hi,
> 
> I have setup tomcat to be accessible through SSL, both client and
> server authenticate each other. (i.e. Client must present a certificate to
> server and vice versa, much like what is described in this link -
> http://java-notes.com/index.php/two-way-ssl-on-tomcat).
> 
> Now, I'd like to access the certificate presented by client inside a
> servlet. Any ideas how it can be done?

Did you mean to send two copies of this email?

Have you read the relevant sections of the appropriate version of the
Servlet Spec?  (You didn't say which version of Tomcat, so I'll guess
6.0.x) See: SRV.3.7

You may also benefit from reading:

 http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

and

 http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html


p
-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Accessing peer certificates of SSL in tomcat

[ciphe]

Hi,

I have setup tomcat to be accessible through SSL, both client and
server authenticate each other. (i.e. Client must present a certificate to
server and vice versa, much like what is described in this link -
http://java-notes.com/index.php/two-way-ssl-on-tomcat).

Now, I'd like to access the certificate presented by client inside a
servlet. Any ideas how it can be done?



Thanks.

Re: Tomcat default initial context factory values

[Pid]

On 13/01/2012 01:39, 이재만 wrote:
> 
> hi there.
> what's default values at tomcat when i write some client programs on tomcat.
> java.naming.factory.initial = ?
> provide url = ?
>  
> thanks.

Please don't reply to an existing thread unless you are contributing to
it.  If you wish to ask a new question, start a wholly new email rather
than editing a reply to another thread - which is called thread hijacking.


p


-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Clarification regarding JULI logger

[Parthiban P]

Dear Team,

We are using TOMCAT-JULI logger for logging purpose in our application.

We bundle tomcat(6.0.28) in our product and start the tomcat when our
product is started (i.e. we start tomcat from our product-startup-code).

For debugging purpose our application needs to change the Logger LEVEL
dynamically. When tried to implement this using
LogManager.getLogger(className).setLevel(requiredLevel) we found that its
not working. And when analyzed the JULI code we found that it is searching
for the loggers of the currentClassLoader classes only (i.e. not searching
the loggers from parentClassLoader). Kindly advise us how to proceed
further to handle our use-case.

Is it advisable for us to change the
ClassLoaderLogInfo.getClassLoaderInfo() method accordingly?

Need your help at the earliest.

Thanks

Parthiban P

AW: AW: How much connections are handled per thread?

[Uwe . Hellmann]

Hello together,

the developers have committed now that indeed there is a library implemented in 
the application which causes the below discussed error.
Something about a filter which uses a static component for URL and the passed 
username.

Just wanted to let you know.

Uwe


-Ursprüngliche Nachricht-
Von: Hellmann, Uwe 
Gesendet: Donnerstag, 22. Dezember 2011 08:22
An: users@tomcat.apache.org
Betreff: AW: AW: How much connections are handled per thread?

Hello Chris,

you helped me enough with all the infos or hints you and the other persons on 
this list have provided.
I can't provide any code, because I am not allowed to do so. My work is to try 
to prove that it is not 
our infrastructure including tomcat which does create this issue.
Until now I am not that firm in java-coding so I think searching in the 
applications code would be 
useless at least for me and it is not my job. Like I said before you all helped 
me much, now it is time 
for the developers to check.

Kind regards any have a nice Christmas.

Uwe



-Ursprüngliche Nachricht-
Von: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Gesendet: Mittwoch, 21. Dezember 2011 16:41
An: Tomcat Users List
Betreff: Re: AW: How much connections are handled per thread?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Uwe,

On 12/20/11 11:11 AM, uwe.hellm...@t-systems.com wrote:
> I tried everything the last half year to convince him to switch to 
> current tomcat or at least to tomcat 6. It was a waste of energy.

Tomcat 5.5 will experience EOL on 30 September 2012. So, they have about
9 months to get an upgrade into testing before they are flying without a
parachute. Tell them that they can either upgrade while there is support
for the older version, or wait until there is essentially no choice
(some security bug found that will not be fixed) before making a hasty
upgrade.

> But on the other hand I have to prove that it is not tomcats
> failure which causes this issues. *sigh*

One cannot prove a negative. If Tomcat were exchanging parameter
values between requests don't you think the entire world would fall
apart? Given that only your webapp appears to be suffering from this
problem, the logical conclusion is that the problem is in the webapp.
I'm not saying there definitely is NOT a problem with Tomcat, but the
odds are against Tomcat being the problem.

You ave provided virtually no information across both of your
discussion threads other than "we issue request to X and get no
parameter value somewhere". We can't read your code. We can't read
your mind. Given those circumstances, we cannot help you. If you want
to send your developers here so they can give us more information,
maybe we /can/ help.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7x/fwACgkQ9CaO5/Lv0PB2vACdF1s7RIodWYCFY9LrbsPAqYG4
ktQAn1/fTYmH2zkY5LiIgnDK+E+iDkRc
=ftTS
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Strategy to prohibit concurrent users authenticated through Tomcat

[chris derham]

>
> I am using Tomcat 7.0.11 and use Form Authentication (via
>> j_security_check) to authenticate through the Tomcat server.
>> Currently, two users with the same username can log into my application
>> from two different computers and concurrently access the app.
>> Is there a way to prohibit a user from authenticating if a user with the
>> same username has previously authenticated and still has an active session?
>>
>> We use spring security in a web app that is deployed in tomcat. It has
built in support for this - you can configure to either disallow subsequent
sessions, or kill the first session and allow subsequent sessions. This
should explain it better than I can
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/session-mgmt.html.
Don't know how big a task it would be for you to move to this, but it works
really well for us

If you provide a bit more information about what you are trying/need to do,
> someone my come up with a better idea.
> For example, what is the real problem - in your application - when two
> people at different computers login with the same user-id ?
>
> +1

Chris