RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot be cast to org.apache.jasper.el.ELContextImpl
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: Application name
Op 05-08-12 23:54, Mark Eggers schreef:
On 8/5/2012 2:09 PM, Konstantin Kolinko wrote:
2012/8/6 Marco de Booij marco.develo...@debooy.eu:
Hello,
I have tried to find the answer but I could not find a (to me) clear
answer.
I build my applications with Maven and as a result my war file is like
myapp-web-1.2.3.war. The static content is delivered by the Apache Web
Server so I use this server to access the application deployed in
Tomcat
7.0.27:
JkMount /myapp-web-0.1.0-SNAPSHOTworker1
JkMount /myapp-web-0.1.0-SNAPSHOT/* worker1
JkMount /myapp worker1
JkMount /myapp/* worker1
I want to use the myapp since this will remain the same even if the
version
changes. In the war file I have a context.xml file in the META-INF at
'root' level (not in the one in the classes directory) with the
content:
?xml version=1.0 encoding=UTF-8?
Context path=/myapp /
The path attribute is invalid in a context.xml file.
Read the Context chapter in the Configuration Reference in Tomcat
7.0 documentation.
I read it but it was not really clear to me. Must be because I am not
really familiar with the way that Tomcat is configured. I just switched
from Glassfish to Tomee and I just tried to find the way to define in my
war file the name that I want the user to use in the URL. Glassfish let
you enter this at deployment time and WebLogic has a context-root tag in
the weblogic.xml or application.xml file.
It is true that the path value is incorrect. Somehow the // was inserted
after copy paste and I did not see it :-( same goes for the 2 last
JkMount lines. They should be similar to the first 2 :-( I changed it in
this mail.
The application works fine if I use
http://localhost/myapp-web-0.1.0-SNAPSHOT but when I use
http://localhost/myapp I only get the welcome page and when I try to
get
another page then I get an error message:
javax.naming.NameNotFoundException: Name [app/AppName] is not bound
in this
Context. Unable to find [app].
In the manager application of Tomcat I see both names in the
application
list.
I was able to use this in Glassfish. There I could define a
application name
in the console when I deployed the application. Is it also possible
with
Tomcat or do I need to rename the war file to myapp.war before I
deploy the
application?
The recommended way is to rename the war.
Note, I've not tried this but from the documentation it should work.
1. Create another directory at the same level as webapps - call it apps
2. Copy your appname-1.2.3-SNAPSHOT.war there
3. Create an appname.xml file and place it in conf/Catalina/[hostname]
Context docBase=${catalina.base}/apps/appname-1.2.3-SNAPSHOT.war/
(At least I think ${catalina.base} will be interpolated)
It is important to note that the war file (and docBase) CANNOT be
inside the enclosing host's appBase (as defined in server.xml). Thus,
you cannot point this inside of $CATALINA_BASE/webapps - the default
location of appBase.
See the following for more detail:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
On second thought, just rename the war file.
. . . . just my two cents.
/mde/
Thanks for the explanation. It looks very complicated to me. If someone
wants to deploy your application he/she needs to do the same. I think
that I will go for the rename of the war file. I will try to use the
##version in the name to keep track of the version number.
-
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: Context variation problems -- localhost versus VPS
On 28.07.2012, at 00:01, Caldarale, Charles R wrote: From: David Woosley [mailto:dwoos...@appnation.com] Please note that I am not using any webapps or ROOT folders. You *must* have a webapp named ROOT - no exceptions. Excuse me, but where's that requirement coming from? I usually don't have any root web app, and requests that are not mapped to any existing web app are intended to fail. Is there any problem with that? Thanks Rainer - 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
- Original Message - 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? 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? 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? 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 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Context variation problems -- localhost versus VPS
From: Rainer Frey [mailto:rainer.f...@inxmail.de] Subject: Re: Context variation problems -- localhost versus VPS On 28.07.2012, at 00:01, Caldarale, Charles R wrote: You *must* have a webapp named ROOT - no exceptions. Excuse me, but where's that requirement coming from? To quote from the Tomcat doc for Context: In addition, a Context must be present with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. Failure to provide a default webapp results in undefined behavior, with some versions of Tomcat displaying only a blank page when a request cannot be mapped to any defined Context. - 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
Application redeploy with keeping conf/Catalina/localhost/appName.xml
Hi, I have the environment specific properties defined in an application context file located $CATALINA_BASE/conf/Catalina/localhost/appName.xml. It works fine, but when I redeploy an application (e.g. by replacing a WAR file) the context file is removed (in my applications there is no /META-INF/context.xml file defined in WAR). I dig a little bit and found related issues and discussions, like: https://issues.apache.org/bugzilla/show_bug.cgi?id=34840 I've found an workaround to use symlinks (which are not removed), but it looks quite fragile. What is the recommended solution to make an application redeploy and to keep a context file defined in Tomcat configuration directory? Apache 7.0.29, Linux. Regards Marcin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat redirection
We want to do a redirect based on context of the URL. We don't use apache and For example say https://anydomain.com/orders/* To https://anydomain/mtcepage I know how to do in apache but not tomcat... Thanks, Brad
Re: tomcat redirection
On 8/6/2012 9:02 AM, Finkeldei, Brad wrote: We want to do a redirect based on context of the URL. We don't use apache and For example say https://anydomain.com/orders/* To https://anydomain/mtcepage I know how to do in apache but not tomcat... Thanks, Brad This comes up quite a bit in the mailing list. Archives are searchable and online. http://tuckey.org/urlrewrite/ . . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: resource configuration for jndi mail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 8/5/12 6:16 PM, Mark Eggers wrote: This system currently does not have nonlocal mail capabilities. Do you mean that you can only connect to localhost:25 or that you can (and must) connect to Gmail in order to send email to non-local destinations? I suspect you mean the latter. The only other applications at this point (Icinga, Redmine) talk to a GMail service account directly. I'm really at a tipping point here - configure postfix to forward nonlocal mail to GMail using the service account, or configure (another) direct connection. Direct-connect isn't too bad, though it might be nice to have postfix doing the queuing (and re-trying) for you locally. Just to get things running, I'm thinking of using the direct connection and defining all of the parameters in a Resource element in context.xml. I understand from the documentation that I can define the host name with the attribute mail.smtp.host. Will translating the other properties I need to send mail via GMail to attributes work (port, password, auth, and so on)? The other mechanism is to set these in CATALINA_OPTS. The latter makes these values more easily accessible (casual ps command for example). See the JNDI Resources HOWTO: http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html Specifically, there is this passage under Configure Tomcat's Resource Factory (the one for mail/Session... there are like 5 of those titles in the JNDI HOWTO but only one for SMTP): Additional resource attributes and values will be converted to properties and values and passed to javax.mail.Session.getInstance(java.util.Properties) as part of the java.util.Properties collection. In addition to the properties defined in Annex A of the JavaMail specification, individual providers may also support additional properties like password. You can find big lists of properties that can you set in the following locations: http://java.sun.com/products/javamail/javadocs/javax/mail/package-summary.html http://javamail.kenai.com/nonav/javadocs/com/sun/mail/smtp/package-summary.html http://java.sun.com/products/javamail/javadocs/javax/mail/internet/package-summary.html I suppose it's time to set up postfix. Not a terrible idea, though not strictly necessary. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAf6/EACgkQ9CaO5/Lv0PDYLgCgp1IEYjBbcULySyfKN/JPTDIW +sYAn1fO7JW8j/+AR0zQbY37BXOiYJKO =EYXv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat redirection
Thanks I am seeing that in a lot of threads I've been researching. Have a good one!! Brad -Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Monday, August 06, 2012 11:06 AM To: users@tomcat.apache.org Subject: Re: tomcat redirection On 8/6/2012 9:02 AM, Finkeldei, Brad wrote: We want to do a redirect based on context of the URL. We don't use apache and For example say https://anydomain.com/orders/* To https://anydomain/mtcepage I know how to do in apache but not tomcat... Thanks, Brad This comes up quite a bit in the mailing list. Archives are searchable and online. http://tuckey.org/urlrewrite/ . . . . just my two cents /mde/ - 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: Issue with sudo + init script
-Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] $SU - this is the su command to run If you're running SELinux, you'll need to set this to /sbin/runuser. This was it! SELinux is unfortunately set to disabled (as it conflicts with HBSS, which is required), but changing su to runuser (which I'd not heard of before) solved the issue. I ended up with this: /sbin/runuser tomcat -m -c $CATALINA_HOME/bin/catalina.sh start -security I don't think I'll do much more with variables, as I only have one or two Tomcat servers, so it doesn't have to be all that flexible. Thanks very much, --Ray smime.p7s Description: S/MIME cryptographic signature
Re: resource configuration for jndi mail
Ah, careful reading (not Sunday evening reading) is your friend. I missed the above paragraph. The JNDI part I was clear on. What I missed was the Additional resource attributes and values will be converted to properties part. This appears in the Tomcat 7 documentation, but not the Tomcat 6 documentation. You can find big lists of properties that can you set in the following locations: http://java.sun.com/products/javamail/javadocs/javax/mail/package-summary.html http://javamail.kenai.com/nonav/javadocs/com/sun/mail/smtp/package-summary.html http://java.sun.com/products/javamail/javadocs/javax/mail/internet/package-summary.html There are a lot of properties available, but unfortunately there is no password. However, the hint is there (in the paragraph that you quoted). After trolling the source for Tomcat 6 (and a bit of searching on the Internet), it appears that a password can be specified. The source in question is: org.apache.naming.factory.MailSessionFactory.java The attribute is password (in the Resource definition). That looks like the only additional (non JavaMail API) attribute / property that this factory supports (hence the hint). I suppose it's time to set up postfix. Not a terrible idea, though not strictly necessary. - -chris I've never been fond of maintaining the same information in multiple places, so postfix is probably good in this environment. Sounds like I should submit a couple of patches to the documentation. 1. Add the paragraph from Tomcat 7 back into Tomcat 6 2. Add a paragraph to both stating that Tomcat's MailSessionFactory supports password as the only additional attribute / property. Thanks, Chris. . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: resource configuration for jndi mail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 8/6/12 12:59 PM, Mark Eggers wrote: There are a lot of properties available, but unfortunately there is no password. However, the hint is there (in the paragraph that you quoted). After trolling the source for Tomcat 6 (and a bit of searching on the Internet), it appears that a password can be specified. The source in question is: org.apache.naming.factory.MailSessionFactory.java The attribute is password (in the Resource definition). That looks like the only additional (non JavaMail API) attribute / property that this factory supports (hence the hint). I actually didn't know that. I had forgotten to mention that this is a possibilty: Session session = ... ; //get from JNDI Transport tx = session.getTransport(...); tx.connect(host, rt, username, password); ...but if Tomcat will do it for you, why not let it? I've never been fond of maintaining the same information in multiple places, so postfix is probably good in this environment. Sounds like I should submit a couple of patches to the documentation. 1. Add the paragraph from Tomcat 7 back into Tomcat 6 2. Add a paragraph to both stating that Tomcat's MailSessionFactory supports password as the only additional attribute / property. That would be great. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAgBEcACgkQ9CaO5/Lv0PDrZACfXTySVuyiB5bGiqAAHmkZtbmE L4MAmwRBK7p2SFuAQg7DGgqGjEB2Ot/4 =xYjg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
SSL Documentation Suggestion
I have a suggestion after just going through the process of configuring SSL using this link: http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html#Configuration I would recommend having completely separate sections for each of the SSL implementations (e.g APR or JSSE). The problem is, if you are unfamiliar with the process, it is ambiguous which implementation some of the steps are geared towards. For example, the line: To create a new keystore from scratch, containing a single self-signed Certificate, execute the following from a terminal command line... My understanding (and I'm still not 100% sure!) is that this will not work if you are using Http11AprProtocol. In that case you must follow different steps. Namely, you must do something like so: openssl req \ -x509 -nodes -days 365 \ -newkey rsa:1024 -keyout mycert.pem -out mycert.pem And I would suggest including a sample code fragment like that in the documentation in order to mirror the process outlined when using the keytool. In addition the section towards the end on CSR is similarly ambiguous. So overall, I think this particular page of the documentation leaves a lot to be desired. If there is any agreement on this point, I could attempt to contribute some of these changes if desired. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[Tomcat 7] Why can't you use automatic deployment and exploded WAR when docBase is outside appBase?
Dear all, I am going to divide my question in 2. The first part concerns a change in Tomcat7's behaviour (vs Tomcat6) that I would like to understand. The 2nd question is what lead me to the question, and it's a practical Java issue - where help is also appreciated. Onwards to the questions. Consider the following context file jamesbond.xml in $CATALINA_BASE/conf/[engine_name]/[host_name]): Context docBase=/srv/apps/jamesbond.war unpackWAR=true debug=0 privileged=true Environment name=my.env value=VAL type=java.lang.String override=true/ /Context *1)* In Tomcat 6 you'd update the war at /srv/apps and it would automatically be redeployed and exploded. However, in Tomcat 7 this isn't happening. From the docs (http://tomcat.apache.org/tomcat-7.0-doc/config/host.html), a new important text that wasn't in 6 reads: unpackWARs - (...) WAR files located outside of the Host's *appBase* will not be expanded. And in http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic%20Application%20Deployment: - When using automatic deployment, the docBase defined by an XML Contexthttp://tomcat.apache.org/tomcat-7.0-doc/config/context.htmlfile should be outside of the appBase directory. If this is not the case, difficulties may be experienced deploying the web application or the application may be deployed twice. The deployIgnore attribute can be used to avoid this situation. Both these rules means you can't have automatic deployment of files outside appBase and explode them (into appBase). Why is this? How can one have the same behaviour as in Tomcat 6: have the war* outisde appBase*, use a context xml like the one above and have the application exploded. *2) *The motivation for this is a simple code ServletContext.getRealPath(/) to create a simple temporary inputstream that works in Tomcat6 but doesn't in Tomcat7 (because getRealPath(/) will return null). Setting up a dedicated directory seems a bit of a hassle for a temporary inputstream. Cheers, Miguel Almeida
RE: [Tomcat 7] Why can't you use automatic deployment and exploded WAR when docBase is outside appBase?
From: Miguel Almeida [mailto:migueldealme...@gmail.com] Subject: [Tomcat 7] Why can't you use automatic deployment and exploded WAR when docBase is outside appBase? The motivation for this is a simple code ServletContext.getRealPath(/) to create a simple temporary inputstream that works in Tomcat6 but doesn't in Tomcat7 (because getRealPath(/) will return null). And, if you check the servlet spec, getRealPath() is *never* guaranteed to work. Your code should be using either getResourceAsStream() or looking at the javax.servlet.context.tempdir context attribute to find where it can create temporary files. - 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
Re: resource configuration for jndi mail
On 8/6/2012 10:52 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 8/6/12 12:59 PM, Mark Eggers wrote: There are a lot of properties available, but unfortunately there is no password. However, the hint is there (in the paragraph that you quoted). After trolling the source for Tomcat 6 (and a bit of searching on the Internet), it appears that a password can be specified. The source in question is: org.apache.naming.factory.MailSessionFactory.java The attribute is password (in the Resource definition). That looks like the only additional (non JavaMail API) attribute / property that this factory supports (hence the hint). I actually didn't know that. I had forgotten to mention that this is a possibilty: Session session = ... ; //get from JNDI Transport tx = session.getTransport(...); tx.connect(host, rt, username, password); ...but if Tomcat will do it for you, why not let it? I've never been fond of maintaining the same information in multiple places, so postfix is probably good in this environment. Sounds like I should submit a couple of patches to the documentation. 1. Add the paragraph from Tomcat 7 back into Tomcat 6 2. Add a paragraph to both stating that Tomcat's MailSessionFactory supports password as the only additional attribute / property. That would be great. Thanks, - -chris Minor enhancements submitted for Tomcat 6 and 7 with svn diffs. https://issues.apache.org/bugzilla/show_bug.cgi?id=53664 Tomcat 6 https://issues.apache.org/bugzilla/show_bug.cgi?id=53665 Tomcat 7 /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat 7] Why can't you use automatic deployment and exploded WAR when docBase is outside appBase?
On 8/6/2012 12:40 PM, Caldarale, Charles R wrote: From: Miguel Almeida [mailto:migueldealme...@gmail.com] Subject: [Tomcat 7] Why can't you use automatic deployment and exploded WAR when docBase is outside appBase? The motivation for this is a simple code ServletContext.getRealPath(/) to create a simple temporary inputstream that works in Tomcat6 but doesn't in Tomcat7 (because getRealPath(/) will return null). And, if you check the servlet spec, getRealPath() is *never* guaranteed to work. Your code should be using either getResourceAsStream() or looking at the javax.servlet.context.tempdir context attribute to find where it can create temporary files. - Chuck +1 I just spent the better part of a week ferreting out exactly this mess. The original application would read from and write to files inside the web application. Even worse, the original application hard-coded the path in a set of variables set at web application load time. This meant that every time the server was changed, the application moved, or the application name changed, the war file had to be unpacked, these values changed, and then the war file had to be repacked. Use getResourceAsStream() for things you need to read. Put those items in WEB-INF/classes or in a jar in WEB-INF/lib. If you need to write temporary files, use java.io.tmpdir, file.separator, and possibly createTempFile(). Tomcat (catalina.sh) sets java.io.tmpdir to $CATALINA_BASE/temp for your convenience by default. . . . just my (somewhat frustrated) 2 cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat 7] Why can't you use automatic deployment and exploded WAR when docBase is outside appBase?
Thanks for the input regarding 2). What's the difference between using javax.servlet.context.tempdir vs java.io.tmpdir ? Also, do you know the answer to 1 - ie, why did the change occur regarding not exploding when the WAR is outside appBase? On Mon, Aug 6, 2012 at 9:32 PM, Mark Eggers its_toas...@yahoo.com wrote: On 8/6/2012 12:40 PM, Caldarale, Charles R wrote: From: Miguel Almeida [mailto:migueldealmeida@gmail.**commigueldealme...@gmail.com ] Subject: [Tomcat 7] Why can't you use automatic deployment and exploded WAR when docBase is outside appBase? The motivation for this is a simple code ServletContext.getRealPath(/* *) to create a simple temporary inputstream that works in Tomcat6 but doesn't in Tomcat7 (because getRealPath(/) will return null). And, if you check the servlet spec, getRealPath() is *never* guaranteed to work. Your code should be using either getResourceAsStream() or looking at the javax.servlet.context.tempdir context attribute to find where it can create temporary files. - Chuck +1 I just spent the better part of a week ferreting out exactly this mess. The original application would read from and write to files inside the web application. Even worse, the original application hard-coded the path in a set of variables set at web application load time. This meant that every time the server was changed, the application moved, or the application name changed, the war file had to be unpacked, these values changed, and then the war file had to be repacked. Use getResourceAsStream() for things you need to read. Put those items in WEB-INF/classes or in a jar in WEB-INF/lib. If you need to write temporary files, use java.io.tmpdir, file.separator, and possibly createTempFile(). Tomcat (catalina.sh) sets java.io.tmpdir to $CATALINA_BASE/temp for your convenience by default. . . . just my (somewhat frustrated) 2 cents. /mde/ --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Tomcat 7] Why can't you use automatic deployment and exploded WAR when docBase is outside appBase?
On 8/6/2012 1:43 PM, Miguel Almeida wrote: Thanks for the input regarding 2). What's the difference between using javax.servlet.context.tempdir vs java.io.tmpdir ? Also, do you know the answer to 1 - ie, why did the change occur regarding not exploding when the WAR is outside appBase? Please don't top post. I just switched to using a real mail client and I now know why others lament so much about this. Anyway, from the fine documentation at: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html workDir Pathname to a scratch directory to be provided by this Context for temporary read-write use by servlets within the associated web application. This directory will be made visible to servlets in the web application by a servlet context attribute (of type java.io.File) named javax.servlet.context.tempdir as described in the Servlet Specification. If not specified, a suitable directory underneath $CATALINA_BASE/work will be provided. So in short, read the Servlet Specification. (This is also of type File, while the property is of type String.) I suspect that if you use javax.servlet.context.tempdir, the scratch space will be under CATALINA_BASE/work/[Engine]/[host]/[app]. [Engine] is by default Catalina [host] is by default localhost [app] is your web application context name This is different than java.io.tmpdir, which is set to CATALINA_BASE/temp. One of the nice things about using javax.servlet.context.tempdir is that it's deleted when you undeploy your application. Another nice thing about javax.servlet.context.tempdir is that you get a location per web application, not a location per Tomcat. This means that various contexts can't step on each other. One of the not so nice things about javax.servlet.context.tempdir is that it normally doesn't exist outside of a servlet container or web application server. This means that if you do unit testing, you'll have to define that property when you run tests with -Djavax.servlet.context.tempdir=somewhere-i-can-write and open this as a file (see above for comments about type). For your answer to question 1, I guess you'll have to read any discussion on the development mailing list. Searchable archives are available online. I'm just a user, and while I casually read the development list I don't currently don't participate. . . . just my 2 cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AjpNio Invalid message received on header
On 06.08.2012 23:39, Yasser wrote: I am using Tomcat 7.0.29 fronted with Apache 2.2.22 modproxy. Configured Ajp as the protocol in httpd.conf and AjpNioProtocol in server.xml. After the server starts, the logs are filled with the following message: *Severe: Invalid message received with signature 20599 com.apache.coyote.ajp.AjpMessage processHeader* It could be anything trying to talk to your AJP port. 20599 should mean, that the first two bytes of the package are P (=80) and w (=119), because 80*256 + 119 = 20599. It seem syou need to sniff your AJP port and see, from which system the packets come. You could also check netstat -an for connections to your AJP port and check whether there are connections coming from some unexpected system. Sniffing would be more reliable though. There are no requests sent to the web or tomcat server and it still throws that error at an interval of 20 seconds. Access logs in tomcat and apache show that no request is coming in. What is causing the invalid message error ? If even the first packet doesn't make sense, then there will be no access log entry. Here is the configuration : httpd.conf ProxyPass /wl http:// ip : port /wl ProxyPassReverse /wl http:// ip : port /wl server.xml Connector port=port protocol=org.apache.coyote.ajp.AjpNioProtocol connectionTimeout=2 acceptorThreadCount=2 maxThreads=600 redirectPort=8443 / Regards, Rainer - 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
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
