Re: Help with overriding default cookie name

2015-04-29 Thread Brian Jones 

Chris,

Thanks for getting back to me. I did end up solving the problem, and it 
was not a bug or related in any way to what Tomcat is doing. It ended up 
being a (very buried) property setting of the application that is not 
documented anywhere. A lot of grep-ing lead me to the realization. After 
setting the property, Tomcat behaves as expected and obeys the 
application's desired cookie name.


Thanks again for letting me bounce my ideas off you, much appreciated!

Cheers,

Brian Jones
Programmer/Analyst
Information Technology Services
Support Services Building, Suite 4300
Western University
(519) 661-2111 x86969
bjone...@uwo.ca

On 2015-04-29 05:18 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brian,

On 4/21/15 3:21 PM, Brian Jones wrote:

Chris, thanks for getting back to me!


I'm trying to override the default cookie name (JSESSIONID) for
one of my Tomcat7 instances. I put the following in
$catalina_home/conf/context.xml:

Context sessionCookieName=MyCookie


That will change the session cookie name for all applications
deployed on the server, and not just one web application. Is that
what you wanted ?


Yes, this is what I'm after. I'm working on an enterprise
application which is comprised of over 70 webapps all working
together. I need to change it for everything, as they all obey a
single cookie.


However, after restarting Tomcat, the setting isn't being
applied; the cookie always remains as JSESSIONID rather than
MyCookie.

My environment is: tomcat 7.0.39, java 1.7.0_79, kubuntu
14.10.

Can anyone shed some light on how/where
$catalina_home/conf/context.xml is loaded? Or any ideas,
suggestions, etc are appreciated.


I would have expected what you did to work. Do you have a
separate CATALINA_BASE as well as a CATALINA_HOME? If so, the
CATALINA_BASE/conf/context.xml will *completely override* the one
in CATALINA_HOME/conf/context.xml.


I don't believe so, output from ./shutdown.sh:

Using CATALINA_BASE:   /opt/apache-tomcat-7.0.39 Using
CATALINA_OWL:   /opt/apache-tomcat-7.0.39 Using CATALINA_TMPDIR:
/opt/apache-tomcat-7.0.39/temp Using JRE_HOME:
/usr/lib/jvm/java-7-openjdk-amd64 Using CLASSPATH:
/opt/apache-tomcat-7.0.39/bin/bootstrap.jar:/opt/apache-tomcat-7.0.39/

bin/tomcat-juli.jar






It would probably be better to set the configuration in your web
application's META-INF/context.xml file. Give that a try and see
if it gives you the desired effect.


The problem with doing this, is that as the application is open
source, modifying each subtool's context.xml would fork me from the
community.

The only reason I'm trying to accomplish this, is because I have
two versions of the application running in two different Tomcats;
one is the community version, one is my institution's
localized/modifyied version. I need to be able to run both
simultaneously for comparison purposes.

However, because both Tomcats/applications are using the same
JSESSIONID as the cookie name, if I start a session on one Tomcat,
it invalidates the session on the other.

Anything else you can think of? Do you perhaps know how/where
Tomcat is loading up the $catalina_home/conf/context.xml file? If
that is known, I can perhaps modify (hack) it to point explicitly
to the context.xml file that I have the sessionCookieName set.


Sorry for the delayed response.

I just wanted you to try to configure using META-INF/context.xml to
see if that made the difference. That test will determine whether this
is a bug in Tomcat (the feature doesn't work) or if Tomcat does not
allow certain things to be overridden locally (e.g. the cookie name)
and therefore this is an enhancement.

I rather think that your expectations are reasonable, so assuming it's
not a bug, I'm +1 for supporting site-wide cookie-name changes.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQUq/AAoJEBzwKT+lPKRYYroP/Ao8Vdb2eL5ExJruAZdS/xKt
dzd2pVn4UTFXc1Pl8j7ShmlnBgm9VK6ls8NyGQTtshsNjO0/NaYof6mrBgiwZdAU
cnZci10Oz1er3qLHY5kBC1gnWajba3pg37hMPYWvwLTNvypnPwpCotBAnzHRbDDO
rU+MoGwxyi54YgAF26ewC2WUd9dy8kbLZdBis3PfE+bVNt8Ao/iA+8u9vjFzOfRv
nYaY0HxnV8VbiE54kLTdmbBQtfA3YpTyzxNZCEb5XP0AZvhQazqUQSmw773UBW2c
p9ovKirJ1axahdMfqYQ12HWE7ajeiONU9Q3PatVjC5fy+/uNMiGKm77cq9gr6MGG
JDe+PTcNNpsKVwyz+h5RzjnJALrW1GuUaxMb5NhgRMEHK6Vgo37lmkN2Db4f494Q
WkFkdjV03+ylQ88M8M+s+ubDKNVmZ0WalJsQrhePa9Q3LjTD8W71jSe5IMJT2MwP
8SEP4o4MPORaH9BlJJVYHBVYHgfuFnhXV2zqaOKph1fTvuczKjuL9LXmOlpalNsv
N0FPo/1X4NkMGf2tNAO1UzF5xc/FMSllH6wuFKC3cmTHvxaqwUdcZeV0vWxbIo1c
HLwhCxCPaYDuA5xgIS3JCr1HXlXY1bAQHsCWCFwbcc1C73me5qAsF0UliEC9h5mZ
Sh0kPbkRrI0bJA6Kcm0v
=jK03
-END PGP SIGNATURE-

-
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

Help with overriding default cookie name

2015-04-21 Thread Brian Jones 

Hello,

I'm trying to override the default cookie name (JSESSIONID) for one of 
my Tomcat7 instances. I put the following in 
$catalina_home/conf/context.xml:


Context sessionCookieName=MyCookie

However, after restarting Tomcat, the setting isn't being applied; the 
cookie always remains as JSESSIONID rather than MyCookie.


My environment is: tomcat 7.0.39, java 1.7.0_79, kubuntu 14.10.

Can anyone shed some light on how/where $catalina_home/conf/context.xml 
is loaded? Or any ideas, suggestions, etc are appreciated.


Cheers,

Brian Jones
Programmer/Analyst
Information Technology Services
Support Services Building, Suite 4300
Western University
(519) 661-2111 x86969
bjone...@uwo.ca

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

Re: Help with overriding default cookie name

2015-04-21 Thread Brian Jones 

Chris, thanks for getting back to me!


I'm trying to override the default cookie name (JSESSIONID) for one
of my Tomcat7 instances. I put the following in
$catalina_home/conf/context.xml:

Context sessionCookieName=MyCookie


That will change the session cookie name for all applications deployed
on the server, and not just one web application. Is that what you wanted
?


Yes, this is what I'm after. I'm working on an enterprise application 
which is comprised of over 70 webapps all working together. I need to 
change it for everything, as they all obey a single cookie.



However, after restarting Tomcat, the setting isn't being applied;
the cookie always remains as JSESSIONID rather than MyCookie.

My environment is: tomcat 7.0.39, java 1.7.0_79, kubuntu 14.10.

Can anyone shed some light on how/where
$catalina_home/conf/context.xml is loaded? Or any ideas,
suggestions, etc are appreciated.


I would have expected what you did to work. Do you have a separate
CATALINA_BASE as well as a CATALINA_HOME? If so, the
CATALINA_BASE/conf/context.xml will *completely override* the one in
CATALINA_HOME/conf/context.xml.


I don't believe so, output from ./shutdown.sh:

Using CATALINA_BASE:   /opt/apache-tomcat-7.0.39
Using CATALINA_OWL:   /opt/apache-tomcat-7.0.39
Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.39/temp
Using JRE_HOME:/usr/lib/jvm/java-7-openjdk-amd64
Using CLASSPATH: 
/opt/apache-tomcat-7.0.39/bin/bootstrap.jar:/opt/apache-tomcat-7.0.39/bin/tomcat-juli.jar




It would probably be better to set the configuration in your web
application's META-INF/context.xml file. Give that a try and see if it
gives you the desired effect.


The problem with doing this, is that as the application is open source, 
modifying each subtool's context.xml would fork me from the community.


The only reason I'm trying to accomplish this, is because I have two 
versions of the application running in two different Tomcats; one is the 
community version, one is my institution's localized/modifyied version. 
I need to be able to run both simultaneously for comparison purposes.


However, because both Tomcats/applications are using the same JSESSIONID 
as the cookie name, if I start a session on one Tomcat, it invalidates 
the session on the other.


Anything else you can think of? Do you perhaps know how/where Tomcat is 
loading up the $catalina_home/conf/context.xml file? If that is known, I 
can perhaps modify (hack) it to point explicitly to the context.xml file 
that I have the sessionCookieName set.


Thanks again,

Brian

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

RE: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
o   Tried running the .bat file from the command line directly piping output
to a local .txt file; all that gets piped to the .txt file is the java
environment variables that are being used

startup.bat is equivalent to calling catalina.bat start

Try using catalina.bat run instead.

- This command works, but then output is not seen on the console. I'm trying
to achieve normal funcationality, where the console displays all output, but
is DUPLICATED in the log file (which should normally be stdout.log or
catalina.out)

o   Modified catalina.bat to pipe %EXECJAVA% . %ACTION% commands to log file
(didn't work, nothing in the log file)

It would be nice to see the actual command line that starts Tomcat's
Bootstrap. The JVM keys that configure  java.util.logging should be there.

- I don't know what you mean by this.

o   Followed instructions at
http://tomcat.apache.org/tomcat-5.5-doc/logging.html to set up logging

Maybe 7.0 docs will be more understandable.

- 7.0 docs are not applicable, as I'm dealing with v5.5.33, and cannot
upgrade to newer versions of Tomcat because 5.5.33 is the only version
supported by the software project I'm working on (as stated in previous
message)

o  Tried log4j; log files didn't contain exception messages

Did you restore original configuration after these experiments? Did
you remove log4j.jar?

- Yes, restored to original configuration. If I remove the log4j-x.x.x.jar
file, it will then throw multiple exceptions like
java.lang.NoClassDefFoundError: org/apache/log4j/Priority while starting
Tomcat

o  Contents of logging.properties file (located in BOTH /common/classes/ and
/conf/ folders):

It should be only in conf.

- The instructions at http://tomcat.apache.org/tomcat-5.5-doc/logging.html
clearly state that the file is to be placed in common/classes. Even so, I
removed it from that directory, but get the same result

Try to simplify your configuration.:

- following your instructions I simplified the logging.properties file to
the 1 entry you suggested. This produced some confusing results. The log
file now contains MOST of the output; some exceptions found in the log; the
console was empty, but one exception was logged in the console and not in
the log file. Ideally (and what I think is normal behavior for Tomcat) it
should be putting all output to the console, and duplicating all output to
the log file.

- I then did another experiment, keeping the more verbose logging.properties
file, and adding the following:

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level
= INFO

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
1catalina.org.apache.juli.FileHandler

- With this change, I can see all output in the console, and I can see that
it's now putting some of the output in two different files,
catalina.date.log and localhost.date.log
- At this point, I'm just confused as to what and why certain output is
being put in one file versus the other
- And it's still throwing exceptions about not being able to find log4j
- Using the above addition to the more verbose logging.properties file and
KEEPING the log4j.jar file in the common/lib folder produces some more
confusion
- All output is shown in the console, there are no log4j exceptions
thrown, but the log files are empty again.

Any more ideas? It seems like the modification to the logging.properties
file was very close to achieving the goal, if only it didn't keep throwing
exceptions about log4j.

Thanks again,

Brian J.


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

RE: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
The verbose file I was referring to was the original content of the
logging.properties file that I pasted in the previous message.

Brian J.


-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Friday, October 21, 2011 2:24 PM
To: Tomcat Users List
Subject: Re: Tomcat produces empty/missing log files

2011/10/21 Brian Jones bjone...@uwo.ca:

        It would be nice to see the actual command line that starts
Tomcat's
 Bootstrap. The JVM keys that configure  java.util.logging should be there.

 - I don't know what you mean by this.


I mean catalina.bat purpose is to prepare and call java.exe. I'd
like to see the real command line that starts java.exe.


 o   Followed instructions at
 http://tomcat.apache.org/tomcat-5.5-doc/logging.html to set up logging

        Maybe 7.0 docs will be more understandable.

 - 7.0 docs are not applicable, as I'm dealing with v5.5.33, and cannot
 upgrade to newer versions of Tomcat because 5.5.33 is the only version
 supported by the software project I'm working on (as stated in previous
 message)

Have you tried reading them? I spent good time trying to improve those
docs, to better explain what is going on, but wouldn't backport those
to 5.5.x



 - Yes, restored to original configuration. If I remove the log4j-x.x.x.jar
 file, it will then throw multiple exceptions like
 java.lang.NoClassDefFoundError: org/apache/log4j/Priority while starting
 Tomcat

??? What throws it?
There should be a stacktrace.


Maybe you shall start with a fresh copy of 5.5.33?


 o  Contents of logging.properties file (located in BOTH /common/classes/
and
 /conf/ folders):

        It should be only in conf.

 - The instructions at http://tomcat.apache.org/tomcat-5.5-doc/logging.html
 clearly state that the file is to be placed in common/classes.

Huh. The doc is wrong there.

The file in common/classes will take priority over the one in conf,
but I'd say that that is an unusual configuration.

 Even so, I
 removed it from that directory, but get the same result

        Try to simplify your configuration.:

 - following your instructions I simplified the logging.properties file to
 the 1 entry you suggested. This produced some confusing results. The log
 file now contains MOST of the output; some exceptions found in the log;
the
 console was empty, but one exception was logged in the console and not in
 the log file.

Which one?

 Ideally (and what I think is normal behavior for Tomcat) it
 should be putting all output to the console, and duplicating all output to
 the log file.

In production you wouldn't want that output on console. It is harder
to rotate catalina.out.


 - I then did another experiment, keeping the more verbose
logging.properties
 file, and adding the following:

        org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level
 = INFO

 org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
 1catalina.org.apache.juli.FileHandler

 - With this change, I can see all output in the console, and I can see
that
 it's now putting some of the output in two different files,
 catalina.date.log and localhost.date.log

http://www.catb.org/~esr/faqs/smart-questions.html

What is those verbose logging.properties and why those lines? You
are asking something, but are not providing facts. Do you expect
guesses as an answer?


Best regards,
Konstantin Kolinko

-
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: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
Please find below the context of logging.properties (updated, the 'verbose'
copy, rather than the minimalized copy you had suggested previously):

# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the License); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an AS IS BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler,
5host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler


# Handler specific properties.
# Describes specific configuration info for Handlers.


1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.

2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.

3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.

4admin.org.apache.juli.FileHandler.level = FINE
4admin.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4admin.org.apache.juli.FileHandler.prefix = admin.

5host-manager.org.apache.juli.FileHandler.level = FINE
5host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5host-manager.org.apache.juli.FileHandler.prefix = host-manager.

java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter



# Facility specific properties.
# Provides extra control for each logger.


org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
1catalina.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
2localhost.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].lev
el = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].han
dlers = 3manager.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/admin].handl
ers = 4admin.org.apache.juli.FileHandler

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager
].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager
].handlers = 5host-manager.org.apache.juli.FileHandler

# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.session.ManagerBase.level = FINE


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

RE: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
Thanks again for your insight into the problem.

Following your advice, I started from a fresh install of Tomcat 5.5.33.
I noticed that log4j.1.2.16.jar is included in the common/lib folder by
default.

The only modification I made was the small addition to logging.properties:

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level
= INFO

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
1catalina.org.apache.juli.FileHandler

I experienced the same results:
- on first run, everything is fine but logs are empty.
- second run I removed the log4j jar file
- Tomcat now produces the output in the log files, but now complains
several times about ClassDefNotFound for log4j

Cheers,

Brian J.


-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Friday, October 21, 2011 2:24 PM
To: Tomcat Users List
Subject: Re: Tomcat produces empty/missing log files

2011/10/21 Brian Jones bjone...@uwo.ca:

        It would be nice to see the actual command line that starts
Tomcat's
 Bootstrap. The JVM keys that configure  java.util.logging should be there.

 - I don't know what you mean by this.


I mean catalina.bat purpose is to prepare and call java.exe. I'd
like to see the real command line that starts java.exe.


 o   Followed instructions at
 http://tomcat.apache.org/tomcat-5.5-doc/logging.html to set up logging

        Maybe 7.0 docs will be more understandable.

 - 7.0 docs are not applicable, as I'm dealing with v5.5.33, and cannot
 upgrade to newer versions of Tomcat because 5.5.33 is the only version
 supported by the software project I'm working on (as stated in previous
 message)

Have you tried reading them? I spent good time trying to improve those
docs, to better explain what is going on, but wouldn't backport those
to 5.5.x



 - Yes, restored to original configuration. If I remove the log4j-x.x.x.jar
 file, it will then throw multiple exceptions like
 java.lang.NoClassDefFoundError: org/apache/log4j/Priority while starting
 Tomcat

??? What throws it?
There should be a stacktrace.


Maybe you shall start with a fresh copy of 5.5.33?


 o  Contents of logging.properties file (located in BOTH /common/classes/
and
 /conf/ folders):

        It should be only in conf.

 - The instructions at http://tomcat.apache.org/tomcat-5.5-doc/logging.html
 clearly state that the file is to be placed in common/classes.

Huh. The doc is wrong there.

The file in common/classes will take priority over the one in conf,
but I'd say that that is an unusual configuration.

 Even so, I
 removed it from that directory, but get the same result

        Try to simplify your configuration.:

 - following your instructions I simplified the logging.properties file to
 the 1 entry you suggested. This produced some confusing results. The log
 file now contains MOST of the output; some exceptions found in the log;
the
 console was empty, but one exception was logged in the console and not in
 the log file.

Which one?

 Ideally (and what I think is normal behavior for Tomcat) it
 should be putting all output to the console, and duplicating all output to
 the log file.

In production you wouldn't want that output on console. It is harder
to rotate catalina.out.


 - I then did another experiment, keeping the more verbose
logging.properties
 file, and adding the following:

        org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level
 = INFO

 org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
 1catalina.org.apache.juli.FileHandler

 - With this change, I can see all output in the console, and I can see
that
 it's now putting some of the output in two different files,
 catalina.date.log and localhost.date.log

http://www.catb.org/~esr/faqs/smart-questions.html

What is those verbose logging.properties and why those lines? You
are asking something, but are not providing facts. Do you expect
guesses as an answer?


Best regards,
Konstantin Kolinko

-
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: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
My mistake. The distro doesn't include the .jar by default. The project I
deploy to Tomcat automatically sticks the log4j.jar file there.

Sorry for the confusion; I overlooked this step.

Brian J


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, October 21, 2011 3:23 PM
To: Tomcat Users List
Subject: Re: Tomcat produces empty/missing log files

On 21/10/2011 20:18, Brian Jones wrote:
 Thanks again for your insight into the problem.
 
 Following your advice, I started from a fresh install of Tomcat 5.5.33.
 I noticed that log4j.1.2.16.jar is included in the common/lib folder by
 default.

No it isn't. Where are you getting this Tomcat distribution from?

Mark

-
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: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
Yes, it appears that the project I'm deploying is relying on log4j for
logging; so when I remove the log4j.jar file, it obviously complains that it
can't find it.

However, what I don't understand is why Tomcat refuses to log to the log
files if there is a log4j.jar file present in the common/lib folder.
Shouldn't it be looking for the log4j.properties file to determine if it
uses log4j or commons? I verified that there is indeed no such
log4j.properties file, and the logging.properties file is in the correct
location.

The project I'm (attempting) to work on is a well known open source
enterprise LMS system. It is a very large system, comprised of 100+ sub
projects within the project itself. Building and dependencies are handled by
Maven. Not sure if that info helps with anything.

Thanks again,

Brian J.


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, October 21, 2011 3:31 PM
To: Tomcat Users List
Subject: Re: Tomcat produces empty/missing log files

On 21/10/2011 20:27, Brian Jones wrote:
 My mistake. The distro doesn't include the .jar by default. The project I
 deploy to Tomcat automatically sticks the log4j.jar file there.
 
 Sorry for the confusion; I overlooked this step.

That begs the question What else is it doing? since it appears to be
breaking the Tomcat logging configuration.

Mark

-
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: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
Konstantine and Mark,

Thanks to both of you for your revelations; without you two I would truly be
lost.

That defiantly makes sense. Are there any known workarounds for using
java.util.logging instead of log4j even if the log4j.jar file is present?

Thanks again for allowing me to pick your brain.

Brian J


-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Friday, October 21, 2011 3:40 PM
To: Tomcat Users List
Subject: Re: Tomcat produces empty/missing log files

2011/10/21 Brian Jones bjone...@uwo.ca:
 Yes, it appears that the project I'm deploying is relying on log4j for
 logging; so when I remove the log4j.jar file, it obviously complains that
it
 can't find it.

 However, what I don't understand is why Tomcat refuses to log to the log
 files if there is a log4j.jar file present in the common/lib folder.
 Shouldn't it be looking for the log4j.properties file to determine if it
 uses log4j or commons?

That commons is a wrapper that autoselects either java.util.logging or
log4j

See http://commons.apache.org/logging/

logging.properties is configuration file for java.util.logging.


Dropping in log4j*.jar is enough to confuse the wrapper so that
effectively logging.properties is not used at all.

-
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: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
Charles,

Thanks for your reply.

I'm not able to do as you suggested, because the software project is not
managed by me, or my parent company. It is an open source enterprise system
that is managed by a community and a foundation.

Also, it isn't just one project. The system I'm deploying is comprised of
100+ sub projects, that are all independent web apps which all interact
together. Your suggestion would require me to go into 100+ projects to make
those changes. Even if I wanted to make those changes, then I would be
working on a separate branch of the source, and would thusly isolate my
development from the community's.

Regards,

Brian J


-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: Friday, October 21, 2011 3:47 PM
To: Tomcat Users List
Subject: RE: Tomcat produces empty/missing log files

 From: Brian Jones [mailto:bjone...@uwo.ca] 
 Subject: RE: Tomcat produces empty/missing log files

 Are there any known workarounds for using java.util.logging
 instead of log4j even if the log4j.jar file is present?

If you only want log4j for a specific webapp rather than for Tomcat itself,
put log4j.jar in WEB-INF/lib of the webapp, and the properties file in
WEB-INF/classes.

 - 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 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: Tomcat produces empty/missing log files

2011-10-21 Thread Brian Jones 
Yes, but the dependencies are not managed locally, it's done using a remote
maven repository.
Thus, it would affect the entire community. No?

Brian J.


-Original Message-
From: David kerber [mailto:dcker...@verizon.net] 
Sent: Friday, October 21, 2011 4:26 PM
To: Tomcat Users List
Subject: Re: Tomcat produces empty/missing log files

On 10/21/2011 3:53 PM, Brian Jones wrote:
 Charles,

 Thanks for your reply.

 I'm not able to do as you suggested, because the software project is not
 managed by me, or my parent company. It is an open source enterprise
system
 that is managed by a community and a foundation.

 Also, it isn't just one project. The system I'm deploying is comprised of
 100+ sub projects, that are all independent web apps which all interact
 together. Your suggestion would require me to go into 100+ projects to
make
 those changes. Even if I wanted to make those changes, then I would be
 working on a separate branch of the source, and would thusly isolate my
 development from the community's.

I doubt that, because you're not modifying any source code, just moving 
libraries around.


-
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

Tomcat produces empty/missing log files

2011-10-20 Thread Brian Jones 
-  Environment: Windows 7 Professional, SP1 64-bit, Tomcat 5.5.33

-  Logging level set to INFO

-  CATALINA_OPTS: -Dsun.lang.ClassLoader.allowArraySyntax=true

-  No JAVA_OPTS environment variable

-  JAVA_HOME points to JDK 1.6.0_26

-  NOT installed as a Windows service. Tomcat starts/runs/stops fine
using startup.bat and shutdown.bat

-  Applications deploy properly, can be accessed and used properly

-  Tomcat admin console can be accessed and used properly

-  The problem is that the log files are always empty (0kb)

-  The following log files are produced by Tomcat, but are always
empty:

o   admin.date.log

o   catalina.date.log

o   host-manager.date.log

o   localhost.date.log

o   manager.date.log

-  The following log files are NOT produced by Tomcat (missing)

o   stdout.log

o   stderr.log

o   catalina.out

-  I’ve tried several workarounds to produce the log files properly,
all without success

o   Tried running the .bat file from the command line directly piping output
to a local .txt file; all that gets piped to the .txt file is the java
environment variables that are being used

o   Modified catalina.bat to pipe %EXECJAVA% … %ACTION% commands to log file
(didn’t work, nothing in the log file)

o   Followed instructions at
http://tomcat.apache.org/tomcat-5.5-doc/logging.html to set up logging

§  Tried log4j; log files didn’t contain exception messages

§  Tried commons logging; no change (log files still empty)

o   Followed the only previous mail-list item that seemed similar to my
situation: http://www.mail-archive.com/users@tomcat.apache.org/msg74244.html

§  Followed all responses; same result; this thread doesn’t seem to be
solved

§  (I do not receive VM instantiation errors like the user in that thread
does)

-  I can’t upgrade to a newer version of Tomcat because 5.5.33 is
the only version supported by the project I’m working on

 

Contents of logging.properties file (located in BOTH /common/classes/ and
/conf/ folders):

 

# Licensed to the Apache Software Foundation (ASF) under one or more

# contributor license agreements.  See the NOTICE file distributed with

# this work for additional information regarding copyright ownership.

# The ASF licenses this file to You under the Apache License, Version 2.0

# (the License); you may not use this file except in compliance with

# the License.  You may obtain a copy of the License at

#

# http://www.apache.org/licenses/LICENSE-2.0

#

# Unless required by applicable law or agreed to in writing, software

# distributed under the License is distributed on an AS IS BASIS,

# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

# See the License for the specific language governing permissions and

# limitations under the License.

 

handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler,
5host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

 

.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler

 



# Handler specific properties.

# Describes specific configuration info for Handlers.



 

1catalina.org.apache.juli.FileHandler.level = FINE

1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs

1catalina.org.apache.juli.FileHandler.prefix = catalina.

 

2localhost.org.apache.juli.FileHandler.level = FINE

2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs

2localhost.org.apache.juli.FileHandler.prefix = localhost.

 

3manager.org.apache.juli.FileHandler.level = FINE

3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs

3manager.org.apache.juli.FileHandler.prefix = manager.

 

4admin.org.apache.juli.FileHandler.level = FINE

4admin.org.apache.juli.FileHandler.directory = ${catalina.base}/logs

4admin.org.apache.juli.FileHandler.prefix = admin.

 

5host-manager.org.apache.juli.FileHandler.level = FINE

5host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs

5host-manager.org.apache.juli.FileHandler.prefix = host-manager.

 

java.util.logging.ConsoleHandler.level = FINE

java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter

 

 



# Facility specific properties.

# Provides extra control for each logger.



 

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers =
2localhost.org.apache.juli.FileHandler

 

org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].lev
el = INFO