logging.properties and Filter problem

[Ronny Batty]

Hi there,
 
I've created a logging.properties file in the WEB-INF/classes directory of
one of my web contexts. This file sets the logging level to SEVERE and
defines a Filter class which exists within a .jar file in the same web
context.
 
The Filter is initialized and works as expected when using Tomcat 5.5.17 on
Windows 2K, my deployment on Linux using Tomcat 5.5.13 does not initialize
the Filter (I have a Sysout in the class constructor). On both deployments
the logging level appears to be working correctly so logging.properties is
at least being read.
 
The only other difference apart from the OS and Tomcat versions is the fact
that the Linux deployment has more than one web context defined in
server.xml. Any help would be greatly appreciated.
 
Ronny.

RE: logging.properties and Filter problem

[Ronny Batty]

Thanks for the response Chuck. I posted the question in the hope that it
might have been a configuration problem that someone else may have
experienced before. We have several sites happily running on 5.5.13 on Linux
and I would prefer not to upgrade the server and potentially introduce
different problems, if at all possible.

When I mentioned contexts we actually have several Host elements defined,
each with a single Context element, we have several domains all pointing to
the same server that each need their own webapps/ROOT.

-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: 24 October 2006 16:49
To: Tomcat Users List
Subject: RE: logging.properties and Filter problem

> From: Ronny Batty [mailto:[EMAIL PROTECTED]
> Subject: logging.properties and Filter problem
>  
> The Filter is initialized and works as expected when using Tomcat 
> 5.5.17 on Windows 2K, my deployment on Linux using Tomcat 5.5.13 does 
> not initialize the Filter

It would seem that moving up to a later level might be the first thing to
try.  No one's going to look at a problem not reproducible in the current
level.

> The only other difference apart from the OS and Tomcat versions is the 
> fact that the Linux deployment has more than one web context defined 
> in server.xml.

You do realize that defining _any_  elements in server.xml is
strongly discouraged?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.

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



--
No virus found in this incoming message.
Checked by AVG.

 


-
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: logging.properties and Filter problem

[Ronny Batty]

Thanks for your help, everything is working fine now, I did a clean rebuild
of the entire webapp and that inadvertantly fixed the problem. I can only
guess that there was a synchronization issue between our staging and live
servers that resulted in the logging config files not being copied across
properly. Once again thanks for the assistance.

Ronny.
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: 24 October 2006 17:20
To: Tomcat Users List
Subject: RE: logging.properties and Filter problem

> From: Ronny Batty [mailto:[EMAIL PROTECTED]
> Subject: RE: logging.properties and Filter problem
> 
> We have several sites happily running on
> 5.5.13 on Linux and I would prefer not to upgrade the server and 
> potentially introduce different problems, if at all possible.

It would still be worthwhile to try 5.5.17 (or 5.5.20) on a test Linux box
and see if the problem is resolved.

> When I mentioned contexts we actually have several Host elements 
> defined, each with a single Context element, we have several domains 
> all pointing to the same server that each need their own webapps/ROOT.

You would normally do this with a separate appBase attribute for each
.  If you want to share the appBase, then you can put a separate
ROOT.xml file in conf/Catalina/[host] for each host you have defined.
The  element in each ROOT.xml would point to the appropriate
docBase for that host.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.

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



--
No virus found in this incoming message.
Checked by AVG.

 


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

Wildcard role-name in auth-constraint.

[Ronny Batty]

I am using the containers JDBCRealm but would like to allow any
authenticated users (without roles) to access protected resources. I realise
that the handling of * was modified to comply with
the Servlet specification in Tomcat 5.5.x but is it really necessary to give
all users an essentially meaningless role under these circumstances.
 
The point that David Delbecq made at the end of discussion Thread
http://marc.theaimsgroup.com/?l=tomcat-user

&m=113898307102307&w=2 is very valid and there are also repercussions when
using the JDBCRealm. Our system allows users to create their own accounts
and in order to upgrade to the latest version of Tomcat we will need to add
code to also insert records in the user_role link table, the fact that
foreign keys aren't used in the link table means that we are also creating
duplicates of all our usernames.
 
I realise this change was necessary to conform with the Servlet
specification but a workaround would be greatly appreciated. Thanks in
advance.
 
Ronny.