systemd tomcat script for Linux EL7

[Dale Ogilvie]

Hi all,

I am trying to put together a systemd script for an install of the current 
binary release tomcat7. Follows my current best effort, cobbled together from 
the (RH)EL7 packaged version and some googling... I am trying to use the 
unadulterated tomcat up/down scripts from the binary release.

Any suggestions as to how this might be improved? I'm not sure if I am using 
the right service type here, based on what catalina.sh is doing under the hood. 
That said, it seems to work.

Thanks

Dale

 follows apache-tomcat.service

# Systemd unit file for apache-tomcat
#

[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/apache-tomcat/apache-tomcat.pid
ExecStart=/opt/apache-tomcat/bin/startup.sh
ExecStop=/opt/apache-tomcat/bin/shutdown.sh
SuccessExitStatus=0
User=apache-tomcat
Group=apache-tomcat


[Install]
WantedBy=multi-user.target

* follows setenv.sh commented out sections removed

# Where your java installation lives
JAVA_HOME="/usr/java/latest"

# Where your tomcat installation lives
CATALINA_BASE="/opt/apache-tomcat"
CATALINA_HOME="/opt/apache-tomcat"
CATALINA_OUT="/var/log/apache-tomcat/catalina.out"
JASPER_HOME="/opt/apache-tomcat"
CATALINA_TMPDIR="/opt/apache-tomcat/temp"

CATALINA_OPTS="-Xms1G -Xmx2G"

# What user should run tomcat
TOMCAT_USER="apache-tomcat"

# Run tomcat under the Java Security Manager
SECURITY_MANAGER="false"

# Time to wait in seconds, before killing process
SHUTDOWN_WAIT="90"

# Whether to annoy the user with "attempting to shut down" messages or not
SHUTDOWN_VERBOSE="false"

# Set the TOMCAT_PID location
CATALINA_PID="/var/run/apache-tomcat/apache-tomcat.pid"

# Connector port is 8080 for this tomcat instance
CONNECTOR_PORT="8080"


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

RE: Tomcat 7.0.54 Slow Unpack and Deploy

[Dale Ogilvie]

Process explorer, select columns, Process I/O, delta total bytes might show the 
story.

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Christopher Schultz wrote:

- -1 CPU
+1 I/O

RE: Logging makes a grown man cry

[Dale Ogilvie]

Alec: "That seems like a good solution. Are you able to avoid having a
single giant catalina.out file in $CATALINA_HOME/logs?"

No, we find we can live with that but we try to minimise writes to
stdout etc.  From Chris's note it seems like the ideal solution for us
would be

1. server log4j isolated in server class loader
2. log4j in each webapp as well

But just using standard tomcat logging for the server works adequately
for us too.

Dale


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

RE: Logging makes a grown man cry

[Dale Ogilvie]

>> Dale wrote:
>> We found issues with trying to have log4j in catalina/lib.
>> 
>> That said, it would be nice to use log4j for tomcat, however we found 
>> that the two configurations collided in our slf4j setup.

>You can do this if you put log4j.jar into a server-only ClassLoader.
>That's not configured by default in Tomcat 6+. We should add documentation to 
>show how that can be done, because conflicting loggers are a total pain.

>- -chris

Thanks for that tip.

Dale

RE: Logging makes a grown man cry

[Dale Ogilvie]

Currently we use tomcat configured as out-of-the-box for logging (no
log4j) and log4j.jar and config in the app war file.

We found issues with trying to have log4j in catalina/lib.

That said, it would be nice to use log4j for tomcat, however we found
that the two configurations collided in our slf4j setup. 

Dale

-Original Message-
From: Tomcat Random [mailto:tomcat.ran...@gmail.com] 
Sent: Wednesday, 4 December 2013 7:12 a.m.
To: Tomcat Users List
Subject: Logging makes a grown man cry

So, all I want is to have:

1. one log file that rolls daily (a new file each day), with the date
appended, that catches my own logging code in the app, based on a global
logging level value that I can change (DEBUG, or INFO, or ERROR etc) as
needed.

2. Another log file that rolls daily and consolidates any other output
of the server and app (or two separate files) and also has a logging
level value that can be changed globally.

3. Get rid of the empty localhost. file.

MTIA,
Alec

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

RE: Logging Best Practices on RHEL

[Dale Ogilvie]

We chose slf4j with log4j underneath.

1. slf4j has nice optimal syntax:

Log.debug("The logged in user is {} {}",firstName,lastName);
http://www.slf4j.org/faq.html#logging_performance

2. It has bridging apis to route other logging frameworks. If you are
using other libraries which use a different logging framework, you could
capture these logs via a bridge.
http://www.slf4j.org/legacy.html

Dale

-Original Message-
From: Tomcat Random [mailto:tomcat.ran...@gmail.com] 
Sent: Thursday, 28 November 2013 5:45 a.m.
To: Tomcat Users List
Subject: Logging Best Practices on RHEL

I'm running Tomcat 7.0.42 on RHEL. Currently all my exceptions are
handled with e.printStackTrace() and go to catalina.out, which doesn't
rotate.

Could someone be so kind as to recommend a better way to handle logging,
with specific steps. Daily error logs would be a good start, instead of
one giant catalina.out file.

Best,
Alec

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

RE: Fix your web application so it can cleanly un-deploy and re-deploy - how?

[Dale Ogilvie]

Mark Thomas [mailto:ma...@apache.org] wrote:



>In short, if there is something the Tomcat developers can do to help then we 
>would love to do so - just let us know.

Many thanks Mark, I'll definitely take careful notes next time I look at this 
and report back.

Dale

RE: Fix your web application so it can cleanly un-deploy and re-deploy - how?

[Dale Ogilvie]

Martin  Gainty wrote:

>How did Mattias Jiderhamn's library help?

It resolved one of the memory leaks, which allowed me to progress on to the 
next leak :-(

Dale

Fix your web application so it can cleanly un-deploy and re-deploy - how?

[Dale Ogilvie]

Chris made the following good suggestion in another thread:

"Can I make a suggestion? Fix your web application so it can cleanly un-deploy 
and re-deploy and then simply do a hot deployment?"

I've been down this track with our own Spring web apps and found it to be quite 
a deep rabbit hole where a number of 3rd party libs are used. We get the issue 
where the webapp classloader is not GC'ed due to classes in the libraries we 
use not being terminated cleanly. Which means we get a big permgen memory leak 
when we redeploy the app. The "occasional tomcat restart" workaround is 
effective, if nasty.

I did what Chris suggested for one of our apps and I think I got to 3rd party 
library problem number FIVE (an oracle jdbc driver connection timer) before I 
gave up in disgust. As I recall undisposed thread locals were a common theme. I 
used various strategies to resolve the prior issues in things as simple as 
logging frameworks, JMS queuing libraries, underlying http client code etc. 
Strategies such as:

1. Specifically calling a low level library finalization routine in a context 
listener or Spring lifecycle bean
2. Updating the 3rd party library to a later version which fixed the leak
3. Including Mattias Jiderhamn's active leak prevention library

I would so love it if Tomcat could just throw away the entire webapp memory 
footprint on undeploy... Tomcat 7x memory leak protection wasn't good enough 
for our app a few months ago.

Or failing that, if anyone can share successful strategies for "Fixing your web 
application so it can cleanly un-deploy and re-deploy" please do.

Dale

Ref: http://wiki.apache.org/tomcat/MemoryLeakProtection
Ref: https://github.com/mjiderhamn/classloader-leak-prevention

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, 7 November 2013 10:44 a.m.
To: Tomcat Users List
Subject: Re: how to bounce tomcat remote?


Can I make a suggestion? Fix your web application so it can cleanly un-deploy 
and re-deploy and then simply do a hot deployment?

Buggy java native call kills tomcat

[Dale Ogilvie]

Hi all,

 

Saw this recently... Some java native code included in our tomcat
deployment contained an error, which caused a JVM segfault when a
webapp called the routine.

 

I was startled by the fact that this native code error brought down the
entire tomcat instance (all 15+ web apps) due to a fault in a native
library (installed in tomcat/lib) called by one app.

 

This would have been very scary if this happened in PROD instead of
dev/test.

 

My question: can we protect ourselves from total instance failure, i.e.
restrict the damage to the death of just the app calling the native
library? Is there a way to make the tomcat VM survive a badly written
native component?

 

Thanks

 

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 

>Not quite. My point was the loading of the EL implementation is likely to be 
>triggered by user code. If the webapp class loader is the TCCL loader than 
>classes from the web app will be loaded before those from the >container. If 
>the web app contains container classes then it is possible that they get 
>loaded from the webapp rather than from Tomcat.
>(Enabling the security manager enables additional class loading checks that 
>would stop this). Those classes from the webapp then have references held to 
>them. They will work right up unto the point Tomcat tries to >access the class 
>outside of the webapp they were loaded from.
>
>Mark

I'm still not quite sure what you are saying matches exactly what I'm seeing 
Mark. The webapp classloader IS the TCCL loader. No problem at all that the app 
containing the  "container classes" will load those in preference to the actual 
Tomcat ones. Ok.

However, what I see is this, in time order:

1. App2 (containing container classes) is deployed by TC at TC startup

2. App1 (not containing container classes) is deployed by TC at TC startup

3. A web request is made of App1 to load a JSP that uses EL

4. The vm ("-verbose:class") reports class LOAD from app2:

[Loaded javax.el.ExpressionFactory from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]

5. Class cast exception occurs somewhat later

So, it appears to me that the class *loading* is occurring "from" app1 in step 
4. I'm only pushing this because it kind looks "buggy" to me.

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

>-Original Message-
>From: Pid * [mailto:p...@pidster.com] 
>
>Where is that dependency JSP jar from?
>It should not be in WEB-INF/lib if it's providing JSP functionality.
>
>
>p

The manifest for the jar says "JSP 2.1 Jasper implementation from Glassfish", 
and yeah it was bad practice for maven to include that in our app2 for us.

Regardless of where the jar is coming from, it still seems bad to me that 
Tomcat will respond to my request of app1 by loading a class from 
app2/WEB-INF/lib/jsp-2.1-6.1.14.jar.

I think Mark Thomas was saying that Tomcat was preventing loading of classes 
outside of Tomcat and app1, the vm classloading output seems to suggest 
otherwise.

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

So, I ran with JVM option "-verbose:class" 
Then I requested a jsp from app1 and the console printed:

...
[Loaded javax.el.ExpressionFactory from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.el.ELContext from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.ELContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/app2/WEB-INF/lib/jsp-2.1-6.1.14.jar]
...

This seems to indicate that the class is being loaded by app1 from 
app2/WEB-INF/lib/jsp-2.1-6.1.14.jar. No?

Dale

RE: tomcat and DB oracle problem - only in higher versions

[Dale Ogilvie]

Does this help?

 

https://forums.oracle.com/forums/thread.jspa?threadID=279238

 

 

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 

>The above shows the problem (along with several other classes loaded
from that location).  
>Looks like you have some hard-coded links to the local file system
buried inside the webapp's META-INF entries - making the .war file
decidedly non-portable. 
>This doesn't explain why Tomcat isn't protecting itself from
ill-mannered webapps, but it does indicate that your process for
constructing webapps needs looking into.
>
> - Chuck

The app containing jsp-2.1xxx.jar is assembled by eclipse's maven
integration. There is nothing untoward I can see in MANIFEST.MF or
META-INF in general. No hard coded links I can detect (where should they
be?) and the app deploys and runs the same from windows workstation to
linux test server. Possibly what you are seeing as a problem is just the
way eclipse does things...

Dale

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

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com] 
Sent: Monday, 13 August 2012 5:46 p.m.
To: users@tomcat.apache.org

>Dale,
>
>Are you running this under Eclipse (looks like it)? If so, what happens
when you run the same test outside of Eclipse?
>
>/mde/

Well, the ClassCastException first showed itself on our standalone
tomcat instance on test. For "debugging" I moved to my workstation and
eclipse.

The test system has many apps deployed, my workstation just the two
apps. *Behavior* is the same in both environments, class loading output
comes from the eclipse environment.

Dale

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

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Daniel Mikusa [mailto:dmik...@vmware.com] 

>Maybe try adding the JVM option "-verbose:class" to "bin/setenv.sh".  This 
>option will cause the JVM to log when a class is loaded and from where it was 
>loaded.
>Dan

The following class load output excerpt results when I request a jsp from app1 
(wtpwebapps/PromotionCodes/) after both app2 (wtpwebapps/OsirisTest) and app1 
have been loaded in Tomcat startup. 

After the load of javax.el.ExpressionFactory, various loads from app2 
(wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar) occur.



[Loaded javax.el.ExpressionFactory from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.el.ELContext from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.ELContextImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.el.ELException from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ExpressionFactory$CacheValue from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ExpressionFactory$CacheKey from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.el.ExpressionFactoryImpl from 
file:/C:/apache-tomcat-7.0.27/lib/jasper-el.jar]
[Loaded javax.el.ValueExpression from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.el.ValueExpressionLiteral from 
file:/C:/apache-tomcat-7.0.27/lib/jasper-el.jar]
[Loaded org.apache.jasper.runtime.ProtectedFunctionMapper from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.el.ELResolver from file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.servlet.jsp.el.ImplicitObjectELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.el.MapELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ResourceBundleELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ListELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.ArrayELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.el.BeanELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.servlet.jsp.el.ScopedAttributeELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.el.CompositeELResolver from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded javax.servlet.jsp.JspWriter from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded org.apache.jasper.runtime.JspWriterImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.servlet.jsp.tagext.BodyContent from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded org.apache.jasper.runtime.BodyContentImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.servlet.jsp.el.VariableResolver from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.el.VariableMapper from 
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.VariableMapperImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.servlet.jsp.el.ExpressionEvaluator from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded org.apache.jasper.runtime.ExpressionEvaluatorImpl from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded org.apache.jasper.security.SecurityUtil from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OsirisTest/WEB-INF/lib/jsp-2.1-6.1.14.jar]
[Loaded javax.servlet.jsp.tagext.TryCatchFinally from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.servlet.jsp.tagext.IterationTag from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded javax.servlet.jsp.tagext.TagSupport from 
file:/C:/apache-tomcat-7.0.27/lib/jsp-api.jar]
[Loaded org.springframework.web.servlet.tags.RequestContextAwareTag from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/PromotionCodes/WEB-INF/lib/org.springframework.web.servlet-3.0.5.RELEASE.jar]
[Loaded org.springframework.web.servlet.tags.HtmlEscapingAwareTag from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/PromotionCodes/WEB-INF/lib/org.springframework.web.servlet-3.0.5.RELEASE.jar]
[Loaded org.springframework.web.servlet.tags.MessageTag from 
file:/C:/sandpit-28/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/PromotionCodes/WEB-

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 

>1. Tomcat 7.0.26 and earlier has static field
JspApplicationContextImpl.ExpressionFactory, so the EL implementation is
effectively shared between web applications.

Thanks for that info about the earlier bug in 7.0.26 Konstantin.

>2. I do not know why you are observing the issue with 7.0.27.
>Either the fix was incomplete,
>or maybe the JSPs were compiled with an earlier version of Tomcat. Try
clearing the work folder so that they are recompiled.
>or it is caused specifically by "other vendor" using jasper package
names in their classes. E.g. when some jasper classes were loaded by
Tomcat by the first time, it might be loaded from 3rd party JAR instead
of Tomcat.

The work directory would have been empty when the apps started up with
7.0.27, it wasn't an in place upgrade from the earlier 7.x version. I
also specifically cleaned the app1 work directory while I was trying to
figure out what was happening.

It does concern me that there was a known issue that was fixed, and here
I am seeing this EL impl instance sharing between apps in the "fixed
version".

Mark's "Don't do that" in terms of loading container jars in apps
generally is a solution, but the trick is we didn't create the problem
intentionally. We got scuppered by a maven dependency and Tomcat didn't
protect us. Ideally bad behaviour of an app should not break the other
apps in the container. 

Dale




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

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Thursday, 9 August 2012 8:22 p.m.
To: Tomcat Users List
Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot 
be cast to org.apache.jasper.el.ELContextImpl

>> Dale Ogilvie  wrote:
>>
>> ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to 
>> org.apache.jasper.el.ELContextImpl
>>
>>That says to me that app1 already has an instance of 
>>org.apache.jasper.runtime.ELContextImpl which it is trying to cast to 
>>the tomcat version.  So your statement that "Tomcat prevents a class 
>>loaded in app2 from being visible in app1" seems to be false.

>Does that cast succeed? No. Why? Because the class isn't visible to app1. 

Thanks again for your explanations here Mark. Apologies if you thought I was 
calling your credentials into question. Nothing of any sort entered into my 
mind. 

Trying not to be annoying, just to gain clarity. I'll rephrase your comment 
above for clarity of what I believe you are saying.

"Does that cast of the org.apache.jasper.runtime.ELContextImpl  instance 
succeed? No. Why? Because the org.apache.jasper.runtime.ELContextImpl class 
isn't visible to app1."

If app1 has an instance of org.apache.jasper.runtime.ELContextImpl (provided by 
app2) whose class it knows nothing about, shouldn't the exception be:

ClassNotFoundException org.apache.jasper.runtime.ELContextImpl

NOT

ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to 
org.apache.jasper.el.ELContextImpl

The latter error does not tell me that the class 
org.apache.jasper.runtime.ELContextImpl isn't visible to app1.

Dale


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

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, 8 August 2012 7:44 p.m.
To: Tomcat Users List
Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot 
be cast to org.apache.jasper.el.ELContextImpl

>>Dale Ogilvie  wrote:
>>So you are saying that Tomcat should not be responsible for preventing
>>app1 from unintentionally loading a class from 
>>app2/WEB-INF/lib/[jetty-jsp-el].jar?

>No I am not saying that. The reason you see the exception is because Tomcat 
>(well, with the help of the JVM) prevents a class loaded from one application 
>being visible to another application.

Thanks for your help Mark. I think your understanding doesn't match what is 
being reported. I'll lay it out as I see it, for your consideration:

App1 *does not have* the jetty EL implementation class 
org.apache.jasper.runtime.ELContextImpl anywhere in its classloader tree
App2 *has* the jetty EL implementation EL class 
org.apache.jasper.runtime.ELContextImpl in WEB-INF/lib

When app1 is accessed and an EL expression is encountered in a jsp this error 
results:

ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to 
org.apache.jasper.el.ELContextImpl

That says to me that app1 already has an instance of 
org.apache.jasper.runtime.ELContextImpl which it is trying to cast to the 
tomcat version.  So your statement that "Tomcat prevents a class loaded in app2 
from being visible in app1" seems to be false. App1 according to the error 
message has an instance of org.apache.jasper.runtime.ELContextImpl from app2, 
and it can't be cast to the expected class.

Or am I reading this error message incorrectly?

1. org.apache.jasper.runtime.ELContextImpl is from app2
2. org.apache.jasper.el.ELContextImpl is the normal tomcat class expected in 
app1
3. The error message from app1 is ClassCastException 
org.apache.jasper.runtime.ELContextImpl cannot be cast to 
org.apache.jasper.el.ELContextImpl

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 

>Again, that class is not a Tomcat class. As far as I can tell, that is party 
>of Jetty's JSP/EL implementation. 

>Anyway, if you start adding JARs from one container into another then all 
>sorts of things can and will go wrong. I see no way to protect Tomcat against 
>this.

>Mark

So you are saying that Tomcat should not be responsible for preventing app1 
from unintentionally loading a class from app2/WEB-INF/lib/[jetty-jsp-el].jar?

I thought that this was a contravention of Tomcat classloading rules. Is your 
point that the jetty jar is doing some "magic" to force its class into another 
apps classloader tree, and this sort of thing is actually allowable for an app 
using "container" jars?

If you could provide some more details on how one can intentionally inject your 
own classes into other apps for their use, that would be interesting, but it 
does sound like a bit of a security hole.

Note, I don't know very much about the technical details of classloaders, I am 
just trying to understand how something occurred which seems to be against how 
things are supposed to work.

P.S. The jetty jar actually appeared in app2 due to maven dependencies, it was 
not added as a direct dependency for app2.

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

Daniel Mikusa [mailto:dmik...@vmware.com] wrote:

>You would be using a shared class loader if you are placing JAR files used by 
>multiple deployed web applications into the
>$CATALINA_BASE/lib or $CATALINA_HOME/lib directory.  Are you placing any JAR 
>files into those folders?  

We have placed three JDBC driver jars in $CATALINA_HOME/lib. I presume this is 
irrelevant to this issue. The class in question 
org.apache.jasper.runtime.ELContextImpl only appears to be in a jar located in 
app2/WEB-INF/lib, yet it is being loaded for app1. I have verified that the 
class is NOT in $CATALINA_HOME/lib. If we remove app2 from tomcat, the 
ClassCastException disappears from app1. Further, removing the jar containing 
org.apache.jasper.runtime.ELContextImpl  from app2 also resolves the issue.

There does seem to be a problem that app2 is sharing classes with app1 from 
app2/WEB-INF/lib. How can this happen?

>Maybe try adding the JVM option "-verbose:class" to "bin/setenv.sh".  This 
>option will cause the JVM to log when a class is loaded and from where it was 
>loaded.

I'll look into that. 

>Dan

Thanks.

Dale

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

>They are.  However, if you have classes in a shared classloader used by
both webapps, and such a class is coded badly, references can leak from
one webapp to another.
>
>BTW, jcifs.http.NtlmHttpFilter hasn't been viable for some years (no
possibility of supporting NTLMv2), so you might want to use something
that actually works, such as waffle or Jespa.
>
> - Chuck

We don't intentionally use any shared classloader magic... Both of these
apps use the Spring framework 3.x. I *guess* that linking to a shared
classloader would have to be something designed into both of these apps,
or could it happen accidentally?

So either tomcat has a bug leaking class references between apps, or our
two separate apps (from a developer and design standpoint) somehow elect
to use the same classloader by default. Any thoughts on how to determine
which of these it is?

I admit to be surprized to see jcifs in there myself, I didn't write
this app, just have to support it.

Dale

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

RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

2012/8/3 Dale Ogilvie :
> Hi,
>
> I'm seeing this problem below appearing now with one of our web-apps,
google has not helped me so far... There have been no changes with the
web app in question, which was working, so I'm picking something is
going on with either the tomcat or OS (virtualized) environment, but
what? Any tips as to how to figure out what is going on?
>
> root cause
>
> java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl
cannot be cast to org.apache.jasper.el.ELContextImpl
>
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContex
tImpl.java:982)
>
org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspx_meth_c_005fo
ut_005f0(promoCodeWelcome_jsp.java:301)
>
org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspService(promoC
odeWelcome_jsp.java:171)
>
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
>
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:432)
>
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
>
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
>
org.springframework.web.servlet.view.InternalResourceView.renderMergedOu
tputModel(InternalResourceView.java:238)
>
org.springframework.web.servlet.view.AbstractView.render(AbstractView.ja
va:250)
>
org.springframework.web.servlet.DispatcherServlet.render(DispatcherServl
et.java:1047)
>
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherS
ervlet.java:817)
>
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherSe
rvlet.java:719)
>
org.springframework.web.servlet.FrameworkServlet.processRequest(Framewor
kServlet.java:644)
>
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.
java:549)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:125)
>
> The app is deployed on Tomcat 7.0.27, java 1.6_026, erroring jsp line:
>
> 
>

I found the problem, but I am confused as to WHY it is a problem.
*Another webapp* on the same tomcat instance includes the following jar
in its WEB-INF/lib:

jsp-2.1-6.1.14.jar

This jar contains the offending class
"org.apache.jasper.runtime.ELContextImpl".

If I remove this *other* application  (app2) from the server, the
ClassCastException in app1 goes away.

I thought the WEB-INF/lib directories for different applications were
isolated from each other, but in this case it appears app1 is using a
class from app2. This seems rather bad to me.

Thoughts?


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

ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl

[Dale Ogilvie]

Hi,

I'm seeing this problem below appearing now with one of our web-apps, google 
has not helped me so far... There have been no changes with the web app in 
question, which was working, so I'm picking something is going on with either 
the tomcat or OS (virtualized) environment, but what? Any tips as to how to 
figure out what is going on?

root cause 

java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl cannot be 
cast to org.apache.jasper.el.ELContextImpl

org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:982)

org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspx_meth_c_005fout_005f0(promoCodeWelcome_jsp.java:301)

org.apache.jsp.WEB_002dINF.views.promoCodeWelcome_jsp._jspService(promoCodeWelcome_jsp.java:171)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)

org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238)

org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)

org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1047)

org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:817)

org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)

org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)

org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:125)

The app is deployed on Tomcat 7.0.27, java 1.6_026, erroring jsp line: 



Thanks

Dale

RE: 7.0.25 to 7.0.27 requires -Xmx32m to go to -Xmx512m

[Dale Ogilvie]

Just a thought from someone who knows nothing more than the contents of this 
thread about the issue.

Would it make sense to only cache classes within a jar? i.e. empty the cache 
when moving on to scan the next jar?

Possibly one might get enough performance benefit from intra-jar class 
hierarchies to not have to pay to have every class in memory for every jar.

Dale

RE: Tomcat Classloader leaks

[Dale Ogilvie]

Mark Thomas wrote:

>Your rant would be better aimed at the developers of the third party
libraries and JVMs that create the problems in the first place rather
than at the community that has worked hard to:
>- prevent them causing an issue in the first place [1], [2]
>- cleans up the mess they leave behind where it can [3]
>- is trying to educate folks on what the problems are [4]

Thanks for that info Mark, that looks like a great summary of the
problem and what Tomcat is doing to help. Some reading for me later.

Dale


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

Tomcat Classloader leaks

[Dale Ogilvie]

In our webapps running on Tomcat 7 we have seen quite a number of
classloader memory leaks. The end result is that after a number of
application reloads and redeploys, we run out of permanent generation
memory and Tomcat stops responding. We can see the evidence of this sort
of issue thanks to the new memory leak reporting in TC6+

 

Generally we can trace this back to service semantics library code,
ActiveMQ, Quartz, etc. I spent a fair bit of time hunting out these sort
of issues, squashing some of them by explicitly calling specific
finalization routines in each library, on context closure.

 

My question is, why is it that we have to be bothered by this
show-stopper memory leak? When the application is unloaded by Tomcat, it
should go away completely, regardless of (for example) unstopped threads
in library foo.

 

My semi-rant is inspired by the following recent comment by Mladen Turk.

 

"Entire IIS worker process recycling is meant for handling crappy .NET
applications with memory and resource leaks."

 

So, why can't Tomcat completely clean up our crappy java apps ;-) when a
reload is requested? 

 

Thanks

 

Dale

 

RE: How to configure certificate file (*.cer) in Tomcat 6

[Dale Ogilvie]

FYI, Here's how we did it with APR for local workstation SSL.

Download APR from here: http://tomcat.apache.org/download-native.cgi

Copy the files (openssl.exe and tc-native.dll)  into the tomcat bin
directory

Set up your SSL connector, pointing to your CA signed server
SSLCertificateFile and the CA as SSLCACertificateFile:



-Original Message-
From: Geet Chandra [mailto:gee...@gmail.com] 
Sent: Thursday, 2 February 2012 3:05 p.m.
To: Tomcat Users List
Subject: Re: How to configure certificate file (*.cer) in Tomcat 6

Thanks Chris!!!

Please tell steps to configure *.cer certificate file.



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

RE: Tomcat proxy configuration for serverside http requests

[Dale Ogilvie]

>> André Warnier wrote: 
>> Just to complete your report :
>> - is the JVM used in both cases exactly the same ?
>> - are either one of the Tomcats (or both) using the "native APR" library ?
>>   (although I have no idea really if this is relevant or not when a 
>> webapp makes its own connections)

>Could the app contain code which uses a specific proxy?

>p

The same Sun 1.6.29 jvm is being used in both instances, and native APR is not 
involved here.

I don't believe app code is to blame as the proxy chosen is not a normal one 
for our environments. It looks more like it is being "discovered" to me. I have 
used CXF code to specifically set the proxy, and nonProxyHosts. If I do this, 
if the web service host defined in nonProxyHosts it will fall back through the 
"alien" proxy.

i.e. For Tomcat:

1. No known proxy set: Client IP at the web service appears as proxy A
2. CXF code to set to Proxy B: Client IP is proxy B
3. CXF code to set to Proxy B and App Server hostname in nonProxyhosts: Client 
IP is proxy A
4. Tomcat jvm -Dhttp.proxy=proxyA and -Dhttp.nonProxyHosts=appserver: Client IP 
is app server (desired outcome)
 
Whereas the same code running on the console as the tomcat user never uses 
proxy A, unless specifically asked to in CXF code.

I would like to know where that proxy is coming from.

Dale

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

Tomcat proxy configuration for serverside http requests

[Dale Ogilvie]

Hi,

 

Weird issue, perhaps someone can explain how this might be happening
from a tomcat perspective...

 

I have some CXF generated web service client code that calls a web
service that operates on an IP whitelist. If I run this code from the
shell as the tomcat owner user "apache_tomcat" on the app server (RHEL6)
the webservice reports that the client ip is the app server. This is as
expected, it is making a direct http connection to the web service.

 

If I wrap this exact same code in a jsp and deploy it to tomcat 7.0.20
on the app server, where tomcat is running as user "apache_tomcat", the
client ip is reported as one of our internal proxy servers. This should
not be happening.

 

There are no http_proxy environment variables set for either
apache_tomcat or root. The tomcat jvm has no -Dhttp.proxy settings. But,
it seems that the code running in tomcat is pulling a proxy definition
from somewhere.

 

Any ideas where this proxy is coming from? We can't find anything at all
on the OS. Is tomcat or java itself proactively searching for available
proxies?

 

The only way to get the behaviour we want is to use -Dhttp.proxy and
-DnonProxyHosts statements on the tomcat jvm command line. If we do
this, we can at least get a proxy on the same continent J

 

Thanks

 

Dale

 

RE: Tomcat OOM errors..

[Dale Ogilvie]

Permgen memory leaks can cause those permgen OOM.

One common cause is webapps not cleaning up after themselves on context
shutdown. This leaks every loaded class from the webapp into the permgen
whenever the application is unloaded.

Knowing this one can workaround these leaks by being careful with
application redeploys, or restarting tomcat occasionally, if you can't
locate and fix the leaks in the webapp.

-Original Message-
From: celtic man [mailto:dheerajman...@hotmail.com] 
Sent: Friday, 4 November 2011 4:26 a.m.
To: users@tomcat.apache.org
Subject: Tomcat OOM errors..


I see these errors(tomcat 6) :

Exception in thread "http-bio-8080-exec-21"
java.lang.OutOfMemoryError: PermGen space Exception in thread
"com.mchange.v2.async.ThreadPoolAsynchronousRunner
$PoolThread-#0" java.lang.OutOfMemoryError: PermGen space

And checked the the JAVA parameters : CATALINA_OPTS=-Xmx4000M

Do i need to change that to
=-Xms2048M -Xmx2048M -XX:Permsize=512m - XX:MaxPermsize=512m  ??


Anticipating a favorable reply.
--
View this message in context:
http://old.nabble.com/Tomcat-OOM-errors..-tp32773665p32773665.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
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: How to close all connections in a Tomcat container db connection pool?

[Dale Ogilvie]

Thanks Chris. Not as simple as I'd hoped, about as complicated as I expected 
:-) 

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, 12 May 2011 1:56 a.m.
To: Tomcat Users List
Subject: Re: How to close all connections in a Tomcat container db connection 
pool?

Hope that helps,
- -chris

How to close all connections in a Tomcat container db connection pool?

[Dale Ogilvie]

Hi,

We just had an issue in production on tomcat 6, a web application was
getting strange errors from the oracle database:

java.sql.SQLException: ORA-06508: PL/SQL: could not find program unit
being called in Package

Our configuration uses a database pool in GlobalNamingResources of
server.xml

  
  

  

The cause of the error was the db admin patching a db package underlying
one used by our web-app. Post patch all the packages appeared valid to
the admin, but not to our app using db connections established prior to
the db patching.

We redeployed our app, but the error persisted. The only way to remove
the db error was to restart tomcat. Possibly, there was something wrong
with the database connections in the pool, not reflecting the new state
of the database.

Is there any way to tell the running Tomcat to clean out the connection
pool, so that it throws away all the established connections, and
establishes new ones for the applications. I don't really want to have
to stop all the applications on our server to deal with this sort of
issue.

Thanks

Dale

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

RE: jndi-lookup fails, cured by tomcat restart

[Dale Ogilvie]

There are a few of them, examples below. Some work for us to track down
it would seem.

SEVERE: The web application [/OLP] appears to have started a thread
named [ActiveMQ Scheduler] but has failed to stop it. This is very
likely to create a memory leak.
SEVERE: The web application [/OLP] appears to have started a thread
named [InactivityMonitor Async Task:
java.util.concurrent.threadpoolexecutor$wor...@413fdef7[state = 0, empty
queue]] but has failed to stop it. This is very likely to create a
memory leak.
SEVERE: The web application [/OLP] appears to have started a thread
named [TcpSocketClose:
java.util.concurrent.threadpoolexecutor$wor...@d91afbc[state = 0, empty
queue]] but has failed to stop it. This is very likely to create a
memory leak.
SEVERE: The web application [/OLP] appears to have started a thread
named
[org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-1]
but has failed to stop it. This is very likely to create a memory leak.
SEVERE: The web application [/OLP] created a ThreadLocal with key of
type [java.lang.ThreadLocal] (value [java.lang.threadlo...@5fb5d830])
and a value of type
org.springframework.security.core.context.SecurityContextImpl] (value
[org.springframework.security.core.context.securitycontexti...@:
Null authentication]) but failed to remove it when the web application
was stopped. This is very likely to create a memory leak.


-Original Message-
From: Pid [mailto:p...@pidster.com] 
Sent: Wednesday, 15 December 2010 12:00 p.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart

On 14/12/2010 22:35, Dale Ogilvie wrote:
> 
> We'll investigate the leak issue, there /are/ leaks from Spring active

> mq code.

Mind posting the leak warning from the logs?


p

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, 15 December 2010 11:15 a.m.
> To: Tomcat Users List
> Subject: Re: jndi-lookup fails, cured by tomcat restart
> 
> Dave,
> 
> On 12/14/2010 4:56 PM, Dale Ogilvie wrote:
>> Redeployment that first caused the issue was using manager web-app. 
>> We
> 
>> tried other deployment options after that.
> 
>> OS is RHEL5.x
> 
>> Aha, scanning the logs around the first error I found the following 
>> in
> 
>> catalina.2010-12-08.log. This message (and friends) is appearing 
>> prior
> 
>> to the first failure to deploy our app.
> 
>> Dec 8, 2010 7:09:33 PM
>> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor
>> processChildren
>> SEVERE: Exception invoking periodic operation:
>> java.lang.OutOfMemoryError: PermGen space
> 
> If you start Tomcat fresh, deploy your webapp, then undeploy, do you 
> get any warnings about memory leaks? The manager webapp has a "Find
Leaks"
> button that you can click to see if Tomcat has detected any leaks.
> 
> If there /are/ leaks, it means that multiple re-deployments will 
> ultimately lead to permgen exhaustion.
> 
> -chris

-
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



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

RE: jndi-lookup fails, cured by tomcat restart

[Dale Ogilvie]

We'll investigate the leak issue, there /are/ leaks from Spring active
mq code.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, 15 December 2010 11:15 a.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dave,

On 12/14/2010 4:56 PM, Dale Ogilvie wrote:
> Redeployment that first caused the issue was using manager web-app. We

> tried other deployment options after that.
> 
> OS is RHEL5.x
> 
> Aha, scanning the logs around the first error I found the following in

> catalina.2010-12-08.log. This message (and friends) is appearing prior

> to the first failure to deploy our app.
> 
> Dec 8, 2010 7:09:33 PM
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor
> processChildren
> SEVERE: Exception invoking periodic operation:
> java.lang.OutOfMemoryError: PermGen space

If you start Tomcat fresh, deploy your webapp, then undeploy, do you get
any warnings about memory leaks? The manager webapp has a "Find Leaks"
button that you can click to see if Tomcat has detected any leaks.

If there /are/ leaks, it means that multiple re-deployments will
ultimately lead to permgen exhaustion.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0H7H4ACgkQ9CaO5/Lv0PC80gCgobxkhO7O5qMcxtFBGB6t39PX
etwAnjwEPiJmpeyxqdGJg5DzWNkz/SAX
=vfMa
-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
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: jndi-lookup fails, cured by tomcat restart

[Dale Ogilvie]

I am not the developer who caused the issue, but...

Redeployment that first caused the issue was using manager web-app. We
tried other deployment options after that.

OS is RHEL5.x

Aha, scanning the logs around the first error I found the following in
catalina.2010-12-08.log. This message (and friends) is appearing prior
to the first failure to deploy our app.

Dec 8, 2010 7:09:33 PM
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor
processChildren
SEVERE: Exception invoking periodic operation:
java.lang.OutOfMemoryError: PermGen space

An out-of-resource error such as this is quite likely the cause, any
comments from anyone as to the likely cause, or troubleshooting?

Follows our tomcat process info, we use MaxPermSize 512M

tomcat6  13184  0.2 27.0 2018392 538840 ?  Sl   Dec12   6:21
/usr/lib/jvm/java-1.6.0/bin/java -Xms512M -Xmx1G -XX:MaxPermSize=512M
-Djava.library.path=/opt/apache-tomcat/lib -classpath
:/opt/apache-tomcat/bin/bootstrap.jar:/opt/apache-tomcat/bin/tomcat-juli
.jar: -Dcatalina.base=/opt/apache-tomcat
-Dcatalina.home=/opt/apache-tomcat -Djava.endorsed.dirs=
-Djava.io.tmpdir=/opt/apache-tomcat/temp
-Djava.util.logging.config.file=/opt/apache-tomcat/conf/logging.properti
es -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] 
Sent: Wednesday, 15 December 2010 5:42 a.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart

2010/12/14 Dale Ogilvie :
>
> The thing is that the code is working fine now, without the fully 
> qualified jndi-name.

IIRC, Spring adds a prefix to the name before doing the lookup (as seen
from the logs fragment).

How do you perform your deployment? Do you use the manager webapp, or
rely on autodeployment?

When dealing with the context.xml file the usual caveat is when there is
a stale copy of it in conf/Catalina/localhost/

Anything else in the logs? Are there messages before your app tries to
start up? (E.g. Tomcat reporting that the app was deployed)?

What is your OS?

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: jndi-lookup fails, cured by tomcat restart

[Dale Ogilvie]

Thanks for that clarification. 

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, 14 December 2010 11:23 p.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart

On 13/12/2010 22:52, Dale Ogilvie wrote:
>  
> propsFileName is the name of the bean, which should be initialized 
> with the string value from the JNDI entry "propertiesFileName" defined

> in $CATALINA_HOME/conf/context.xml
> 
> This was working, stopped working until a tomcat restart, and is 
> working again now. My concern is that this may be a bug in tomcat
> 
> So what happens is that tomcat startup creates a JNDI environment 
> entry in the "cross-application" context called "propertiesFileName".

Just to be clear, there is no global or cross-application context.
Entries in CATALINA_BASE/conf/context.xml are merged with the
application's context.xml and become part of the application's context
configuration. This means that if you define a resource in
CATALINA_BASE/conf/context.xml and you have 20 contexts you will get 20
instances of that resource - one for each context.

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: jndi-lookup fails, cured by tomcat restart

[Dale Ogilvie]

The thing is that the code is working fine now, without the fully
qualified jndi-name. Then an app redeployment and it stopped working.
Then an apache restart and it started working again...

I found something on Google about having apache jars in WEB-INF/lib, but
I don't think this was/is the case for our app.

http://java.ittoolbox.com/groups/technical-functional/jsp-l/javaxnamingn
amenotfoundexception-name-javacomp-is-not-bound-in-this-context-3603504


-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com] 
Sent: Tuesday, 14 December 2010 12:46 p.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart

Dale,

What happens if you try changing the jndi-name to its fully qualified
version?

java:comp/env/propertiesFileName

Then change the context.xml file name to propertiesFileName (no leading
slash)?

I'm basing these comments on some similar issues I've seen in the Spring
forums, and similar configuration issues when using Hibernate with
Tomcat.

Don't ask me to explain why this worked for a long time, and then all of
a suddenly decided not to work.

Hope this helps.

. . . . just a guess.

/mde/


- Original Message ----
From: Dale Ogilvie 
To: Tomcat Users List 
Sent: Mon, December 13, 2010 2:52:09 PM
Subject: RE: jndi-lookup fails, cured by tomcat restart


propsFileName is the name of the bean, which should be initialized with
the string value from the JNDI entry "propertiesFileName" defined in
$CATALINA_HOME/conf/context.xml

This was working, stopped working until a tomcat restart, and is working
again now. My concern is that this may be a bug in tomcat 

So what happens is that tomcat startup creates a JNDI environment entry
in the "cross-application" context called "propertiesFileName". 



When each spring app starts, the code  in the application
context takes the JNDI environment entry and initializes a bean using
the id "propsFileName" with it.

Finally a spring PropertyPlaceholderConfigurer is created using the
propsFileName bean for the location of the properties file. We use this
to 

 

 

Looking more closely at the debug log, this line looks quite suspicious
"Name comp is not bound". comp is the root of the environment hierarchy,
why would that be missing?

2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name
[java:comp/env/propertiesFileName] not found - trying original name
[propertiesFileName]. javax.naming.NameNotFoundException: Name comp is
not bound in this Context **
org.springframework.jndi.JndiObjectFactoryBean 

Log context follows:

2010-12-08 19:29:11,108 DEBUG ** Creating instance of bean
'propsFileName' **
org.springframework.beans.factory.support.DefaultListableBeanFactory
2010-12-08 19:29:11,116 DEBUG ** Eagerly caching bean 'propsFileName' to
allow for resolving potential circular references **
org.springframework.beans.factory.support.DefaultListableBeanFactory
2010-12-08 19:29:11,158 DEBUG ** Invoking afterPropertiesSet() on bean
with name 'propsFileName' **
org.springframework.beans.factory.support.DefaultListableBeanFactory
2010-12-08 19:29:11,158 DEBUG ** Looking up JNDI object with name
[java:comp/env/propertiesFileName] **
org.springframework.jndi.JndiTemplate
2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name
[java:comp/env/propertiesFileName] not found - trying original name
[propertiesFileName]. javax.naming.NameNotFoundException: Name comp is
not bound in this Context **
org.springframework.jndi.JndiObjectFactoryBean
2010-12-08 19:29:11,161 DEBUG ** Looking up JNDI object with name
[propertiesFileName] ** org.springframework.jndi.JndiTemplate
2010-12-08 19:29:11,164 INFO  ** Destroying singletons in
org.springframework.beans.factory.support.defaultlistablebeanfact...@493
02473: defining beans
[propsFileName,org.springframework.beans.factory.config.PropertyPlacehol
derConfigure
2010-12-08 19:29:11,165 ERROR ** Context initialization failed **
org.springframework.web.context.ContextLoader

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, 14 December 2010 9:46 a.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dale,

On 12/13/2010 3:08 PM, Dale Ogilvie wrote:
> We are using a spring jndi-lookup to pull the name of a context file 
> from the global "environment" in our apps. We have set this up in 
> tomcat
> 6.0.29 like so:
> 
> $CATALINA_HOME/conf/context.xml

Technically speaking, I think that's the default local environment, not
the global environment. You can define  entries at the
 level in server.xml which would be truly "global". It's all
semantics for this discussion and shouldn't impact this case.

>  value="classpath:test-application.properties" type="java.lang.String"

RE: jndi-lookup fails, cured by tomcat restart

[Dale Ogilvie]

 
propsFileName is the name of the bean, which should be initialized with
the string value from the JNDI entry "propertiesFileName" defined in
$CATALINA_HOME/conf/context.xml

This was working, stopped working until a tomcat restart, and is working
again now. My concern is that this may be a bug in tomcat 

So what happens is that tomcat startup creates a JNDI environment entry
in the "cross-application" context called "propertiesFileName". 



When each spring app starts, the code  in the application
context takes the JNDI environment entry and initializes a bean using
the id "propsFileName" with it.

Finally a spring PropertyPlaceholderConfigurer is created using the
propsFileName bean for the location of the properties file. We use this
to 

 

 

Looking more closely at the debug log, this line looks quite suspicious
"Name comp is not bound". comp is the root of the environment hierarchy,
why would that be missing?

2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name
[java:comp/env/propertiesFileName] not found - trying original name
[propertiesFileName]. javax.naming.NameNotFoundException: Name comp is
not bound in this Context **
org.springframework.jndi.JndiObjectFactoryBean 

Log context follows:

2010-12-08 19:29:11,108 DEBUG ** Creating instance of bean
'propsFileName' **
org.springframework.beans.factory.support.DefaultListableBeanFactory
2010-12-08 19:29:11,116 DEBUG ** Eagerly caching bean 'propsFileName' to
allow for resolving potential circular references **
org.springframework.beans.factory.support.DefaultListableBeanFactory
2010-12-08 19:29:11,158 DEBUG ** Invoking afterPropertiesSet() on bean
with name 'propsFileName' **
org.springframework.beans.factory.support.DefaultListableBeanFactory
2010-12-08 19:29:11,158 DEBUG ** Looking up JNDI object with name
[java:comp/env/propertiesFileName] **
org.springframework.jndi.JndiTemplate
2010-12-08 19:29:11,161 DEBUG ** Converted JNDI name
[java:comp/env/propertiesFileName] not found - trying original name
[propertiesFileName]. javax.naming.NameNotFoundException: Name comp is
not bound in this Context **
org.springframework.jndi.JndiObjectFactoryBean
2010-12-08 19:29:11,161 DEBUG ** Looking up JNDI object with name
[propertiesFileName] ** org.springframework.jndi.JndiTemplate
2010-12-08 19:29:11,164 INFO  ** Destroying singletons in
org.springframework.beans.factory.support.defaultlistablebeanfact...@493
02473: defining beans
[propsFileName,org.springframework.beans.factory.config.PropertyPlacehol
derConfigure
2010-12-08 19:29:11,165 ERROR ** Context initialization failed **
org.springframework.web.context.ContextLoader

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, 14 December 2010 9:46 a.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart

-----BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dale,

On 12/13/2010 3:08 PM, Dale Ogilvie wrote:
> We are using a spring jndi-lookup to pull the name of a context file 
> from the global "environment" in our apps. We have set this up in 
> tomcat
> 6.0.29 like so:
> 
> $CATALINA_HOME/conf/context.xml

Technically speaking, I think that's the default local environment, not
the global environment. You can define  entries at the
 level in server.xml which would be truly "global". It's all
semantics for this discussion and shouldn't impact this case.

>  value="classpath:test-application.properties" type="java.lang.String"
> override="true"/>
> 
> This has worked fine for lots of applications, but last week it 
> started failing for one application when it was redeployed. This 
> results in the application failing to start.
> 
> The error message below suggests that the environment value cannot be 
> found.
> 
> Tomcat 6.0.29 log output:
>  
> 2010-12-08 19:27:24,674 DEBUG ** Invoking afterPropertiesSet() on bean

> with name 'propsFileName' **

'propsFileName' != 'propertiesFileName'

Are you sure you're looking at the right configuration file?

> org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 'propsFileName': Invocation of init method 
> failed; nested exception is javax.naming.NameNotFoundException: Name 
> propertiesFileName is not bound in this Context

Perhaps propsFileName is bound, but not propertiesFileName.

> Spring application web.xml
> 
> 
> contextConfigLocation
> 
> classpath:applicationContext-shared.xml
> 
> 
> 
> 
>  
> org.springframework.web.context.ContextLoaderListener<
> /l
> istener-class>
> 
> 
> applicationContext-Shared.xml
> 
>  />
> 
>  class="

RE: How to configure JNDI resource

[Dale Ogilvie]

This is how we do it in a spring app, with a resourcelink in context.xml

conf/server.xml

  

  

META-INF/context.xml



  


WEB-INF/applicationContext.xml


 




-Original Message-
From: Abid Hussain [mailto:dilax.huss...@googlemail.com] 
Sent: Tuesday, 14 December 2010 5:19 a.m.
To: users@tomcat.apache.org
Subject: How to configure JNDI resource

Hi all,

I've a question about how to configure a datasource to be accessed via
JNDI.

I have a datasource configured in server.xml (In
Server/GlobalNamingResources/Resource).

In the documentation
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Resource_Def
initions
it says that that a resource/datasource can be declared in the context
element of a webapp like this:

  ...
  
  ...


Also it is written that it is possible to declare a resource inside
web.xml:

  Employees Database for HR Applications
  jdbc/EmployeeDB
  javax.sql.DataSource
  Container


My question is:
1) is it enough to declare the needed resource inside web.xml or
2) do I have to declare it also in the context element for accessing it
via JNDI?

And, if 2) is correct what is the use to declare a resouce in the
webapps web.xml when it has been already declared in the context element
of the webapp?

Regards,

Abid

-
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

jndi-lookup fails, cured by tomcat restart

[Dale Ogilvie]

Hi there,

Apologies if my previous email ended up linked to another thread. A JNDI
lookup started failing mysteriously, and rather than shrug shoulders I'd
prefer to nail down what went wrong, if possible.

We are using a spring jndi-lookup to pull the name of a context file
from the global "environment" in our apps. We have set this up in tomcat
6.0.29 like so:

$CATALINA_HOME/conf/context.xml



This has worked fine for lots of applications, but last week it started
failing for one application when it was redeployed. This results in the
application failing to start.

The error message below suggests that the environment value cannot be
found.

Tomcat 6.0.29 log output:
 
2010-12-08 19:27:24,674 DEBUG ** Invoking afterPropertiesSet() on bean
with name 'propsFileName' **
org.springframework.beans.factory.support.DefaultListableBeanFactory
2010-12-08 19:27:24,674 DEBUG ** Looking up JNDI object with name
[java:comp/env/propertiesFileName] **
org.springframework.jndi.JndiTemplate
2010-12-08 19:27:24,677 DEBUG ** Converted JNDI name
[java:comp/env/propertiesFileName] not found - trying original name
[propertiesFileName]. javax.naming.NameNotFoundException: Name comp is
not bound in this Context ** org.springframe
2010-12-08 19:27:24,677 DEBUG ** Looking up JNDI object with name
[propertiesFileName] ** org.springframework.jndi.JndiTemplate
2010-12-08 19:27:24,679 INFO  ** Destroying singletons in
org.springframework.beans.factory.support.defaultlistablebeanfact...@226
5b1ac: defining beans
[propsFileName,org.springframework.beans.factory.config.PropertyPlacehol
derConfigure
2010-12-08 19:27:24,681 ERROR ** Context initialization failed **
org.springframework.web.context.ContextLoader
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name
'org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#
0' defined in class path resource [applicationContext-shared.xml]:
Cannot resolve reference to bean 'propsFileName' while setting bean
property 'location'; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'propsFileName': Invocation of init method failed; nested
exception is javax.naming.NameNotFoundException: Name propertiesFileName
is not bound in this Context

Numerous redeployments, failed to resolve the issue for the app.

I restarted tomcat, and the problem went away. I don't want to encounter
such a problem on production, any thoughts as to why this might have
happened? It seems like the global context value went missing for one
app, across redeployments of that app, until tomcat was bounced to
restore it. 

The relevant bits of the application config are below:

Spring application web.xml


contextConfigLocation

classpath:applicationContext-shared.xml




 
org.springframework.web.context.ContextLoaderListener


applicationContext-Shared.xml




   


Thanks

Dale


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

jndi-lookup fails, cured by tomcat restart

[Dale Ogilvie]

Hi there,

We are using a spring jndi-lookup to pull the name of a context file
from the global "environment" in our apps. We have set this up in tomcat
6.0.29 like so:

$CATALINA_HOME/conf/context.xml



This has worked fine for lots of applications, but last week it started
failing for one application when it was redeployed. This results in the
application failing to start.

The error message below suggests that the environment value cannot be
found.

Tomcat 6.0.29 log output:
 
2010-12-08 19:27:24,674 DEBUG ** Invoking afterPropertiesSet() on bean
with name 'propsFileName' **
org.springframework.beans.factory.support.DefaultListableBeanFactory
2010-12-08 19:27:24,674 DEBUG ** Looking up JNDI object with name
[java:comp/env/propertiesFileName] **
org.springframework.jndi.JndiTemplate
2010-12-08 19:27:24,677 DEBUG ** Converted JNDI name
[java:comp/env/propertiesFileName] not found - trying original name
[propertiesFileName]. javax.naming.NameNotFoundException: Name comp is
not bound in this Context ** org.springframe
2010-12-08 19:27:24,677 DEBUG ** Looking up JNDI object with name
[propertiesFileName] ** org.springframework.jndi.JndiTemplate
2010-12-08 19:27:24,679 INFO  ** Destroying singletons in
org.springframework.beans.factory.support.defaultlistablebeanfact...@226
5b1ac: defining beans
[propsFileName,org.springframework.beans.factory.config.PropertyPlacehol
derConfigure
2010-12-08 19:27:24,681 ERROR ** Context initialization failed **
org.springframework.web.context.ContextLoader
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name
'org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#
0' defined in class path resource [applicationContext-shared.xml]:
Cannot resolve reference to bean 'propsFileName' while setting bean
property 'location'; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'propsFileName': Invocation of init method failed; nested
exception is javax.naming.NameNotFoundException: Name propertiesFileName
is not bound in this Context

Numerous redeployments, failed to resolve the issue for the app.

I restarted tomcat, and the problem went away. I don't want to encounter
such a problem on production, any thoughts as to why this might have
happened? It seems like the global context value went missing for one
app, across redeployments of that app, until tomcat was bounced to
restore it. 

The relevant bits of the application config are below:

Spring application web.xml


contextConfigLocation

classpath:applicationContext-shared.xml




 
org.springframework.web.context.ContextLoaderListener


applicationContext-Shared.xml




   


Thanks

Dale

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

RE: Tomcat5.5: Apache Tomcat Native library ... not found

[Dale Ogilvie]

 
Perhaps the INFO message needs to sound less alarming? It sounds like it
is describing a quality bug to me, akin to running tomcat in
"development" mode if you are not using APR. If the missing library is
not really required for production use, how about:

INFO: The optional Apache Tomcat Native library was not found on the
java.library.path: See http://tomcat.apache.org/tomcat-5.5-doc/apr.html
for more information.

I take your point about it being an INFO level message, but perhaps that
gets lost in the "optimal performance in production" phrase. 

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: Saturday, 2 October 2010 5:11 a.m.
To: Tomcat Users List
Subject: RE: Tomcat5.5: Apache Tomcat Native library ... not found

> From: Steve Ryder [mailto:sry...@jsrsys.com]
> Subject: Tomcat5.5: Apache Tomcat Native library ... not found

> How do it fix this? 
> INFO: The Apache Tomcat Native library which allows optimal 
> performance in production environments was not found on the
java.library.path:

There's nothing to "fix" - it's an INFO message.  If you want to use
APR, read the doc about building and installing it for your platform.
Note that it uses a completely different SSL mechanism than the pure
Java connectors.

http://tomcat.apache.org/tomcat-5.5-doc/apr.html

 - Chuck


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

RE: APR & Tomcat...

[Dale Ogilvie]

 
Reasons to use httpd being what? We historically have used httpd and
mod_proxy_ajp, but less being more I'm considering a tomcat only setup. 

The reason we used httpd in the past was "httpd serves static content
better".

One other reason that comes to mind is httpd url rewrite support,
assuming tomcat can't help in this area. Any others?

Dale

/still hoping my tomcat download license doesn't get revoked before
tomcat 7 is released/

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, 20 July 2010 9:51 a.m.
To: Tomcat Users List
Subject: Re: APR & Tomcat...

There certainly are reasons to use Apache httpd out in front of Tomcat,
but performance isn't one of them.

- -chris

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

RE: Keeping tomcat up-to-date on linux

[Dale Ogilvie]

 
My intent is purely to find the best solution for an up-to-date tomcat on linux.

If we have to pay for an up-to-date tomcat on linux we will. Indeed we would 
prefer to roll up the cost for up-to-date tomcat in our current commercial 
distro fees.

>From responses it seems:

1. that there is no up-to-date tomcat package on non-free linux.

2. that .tar.gz is the only up-to-date option on linux generally.

3. that .tar.gz is considered a workable option.

I smile at the "gift horse in mouth" statements.

A free gift can vary greatly in it's final value, depending on it's actual 
usefulness and how many hidden costs it brings with it.


-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: Friday, 21 May 2010 10:05 a.m.
To: Tomcat Users List
Subject: Re: Keeping tomcat up-to-date on linux

Hi.

I think in all of this, you may be overlooking one element : the distributions 
you seem to be talking about are free, and made by volunteers who donate their 
time.
That includes Tomcat.
There are other distributions which are not free, where the people making them 
actually get paid for doing so, and for testing them together with other 
packages, and for handling a whole concept of "global releases".
For those you pay, and you are then entitled to complain (to them) if they lag 
behind, or do not provide the tools you would wish for.

It is your choice to subscribe to one or the other.  As often mentioned on this 
forum also, contributions are always welcome.

In my country, there is a proverb : if you receive a horse (as a present, for 
free), then you should not check his teeth.

My apologies if I misinterpreted your post below.

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

RE: Keeping tomcat up-to-date on linux

[Dale Ogilvie]

* We are serious about our tomcat install, and find configuration file
and jvm tweaks about all we need to do.
* Agreed that most distro's (apart from the rolling release ones such as
gentoo, arch) are lagging behind. This is the problem in my view.
* I would rather delegate the responsibility for security patches to the
distro, like I do for kernel security patches.
* I want security and feature updates to the other software on the
distro, hence they are not unsolicited. Because these updates occur on
the test/dev system first, after passing distro QA, it seems pretty
unlikely a problem will effect our tomcat install on PROD.

Distros are all about delegation of *maintenance* responsibility to the
distro from the end-user. This frees up the end-user to actually build
apps, not the app-server.

Current distros seem to be not interested in maintaining tomcat packages
at the minor version release level. Pity.

But then again, responses seem to be that the .tar.gz "package" is good
enough for the community. Perhaps that is my answer.

Thanks!

Dale

-Original Message-
From: Harry Metske [mailto:harry.met...@gmail.com] 
Sent: Thursday, 20 May 2010 6:33 p.m.
To: Tomcat Users List
Subject: Re: Keeping tomcat up-to-date on linux

I agree with Hassan,

our reasons to use the tar.gz install method :

* in most serious Tomcat environments you need more control over the
installation and configuration than the distro managed version offers.
* most distro's (especially RHEL) are lagging behind, so you don't get
the latest stuff you need
* we also keep an eye on this list and the tomcat website for updates,
and for security patching we use some sort of subscription service from
McAfee, so that should tell us if there are any security patches that
need to be applied quickly.
* it is usable and the same for all platforms we use
* makes the separation of duty easier with our Linux administrators, at
least I am sure I don't get unsolicited updates to my tomcat
installations when they run an update on every package on every linux
box
* we run multiple Tomcat instances on the same OS image, that is not
what the disto is facilitating
* better open source support

But the distro packaged version could be very usable for the masses and
non-pro use.

my two cents

regards,
Harry


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

RE: Keeping tomcat up-to-date on linux

[Dale Ogilvie]

 
Yes, the release gap is an issue for me as well. Hence this email trail
:-)

Parallelism is achieved for us for other software by package updating
the test/dev server and testing that prior to performing the same
updates on prod. There is no need for us to have two versions of tomcat
running on the same host. So, if the package manager would just stay
up-to-date with tomcat releases it would mean we wouldn't have to have
special practices for Tomcat 6.

I'm pleased to hear that the upgrade process is trivial with your setup.
If you're going to have special practices, they might as well be simple.

On what did you base your init.d scripts? And what is your underlying
distro? We use redhat/fedora.

Dale

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

RE: Keeping tomcat up-to-date on linux

[Dale Ogilvie]

Hassan Schroeder wrote:

> I watch this list for announcements of new releases and install them
:-)

I'm hoping for something a bit more distro managed. Presumably your
method means you have to maintain your own init.d scripts and use the
"tar xzvf" method of installation, outside of your distro package
management system.

On Windows, I at least have an installer that takes care of these tasks
for me.

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

Keeping tomcat up-to-date on linux

[Dale Ogilvie]

Hi,

The current release is 6.0.26, March 2010.

RHEL5.x is running with Tomcat 5.5.

Fedora 12 is on 6.0.20, June 2009 vintage. 

Ubuntu 10.04 is on 6.0.24 from Jan 2010.

Ideally, the equivalent of a "yum update" would track tomcat releases so
that soon after a tomcat release the tomcat6 package would move to the
next minor release. Does this happen for any distro out there?

What do people do to keep their tomcat patched up?

Thanks

Dale


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