Re: tomcat7-maven-plugin and mail
The war itself deploys to a Tomcat instance on a testing machine just fine - that Tomcat includes the javamail and activation in it's installation hence they are declared as provided in our project's POM. This boils down to not knowing if the extra dependencies within the maven plugin are actually deployed and deployed prior to booting the war archive. On 2 December 2014 at 19:11, Chris Gamache cgama...@gmail.com wrote: Unless you're doing something unconventional, it shouldn't be painful. We may getting off-topic, but if you would like to post your project pom and any parents, I'll take a peek and see if there's anything that leaps out at me. My gut says your build is omitting dependencies that Maven expects to be in the classpath but they aren't in your Tomcat environment. When you unpack your war, do you see all the jarfiles you expect in WEB-INF/libs? Look for missing jars or multiple versions of the same dependencies (that's a dog that has bitten me many times). If the jars aren't there they would have to be in the Java runtime classpath or in Tomcat's global classpath, yes? You mentioned integration testing... Your war works with other servlet containers? Perhaps there is a dependency that the other containers provide as a standard that tomcat does not. On Tue, Dec 2, 2014 at 4:52 AM, James Green james.mk.gr...@gmail.com wrote: What you wrote as a set of suggestions was my original attempt. Then I read (possibly spuriously) that Tomcat ignored either mailx or activation when shipped inside a WAR, and that if both Tomcat (via it's lib/) and the WAR contained either of those then the duplicate JAR would result in an error. So as a result I spotted someone on SO suggesting the above for the maven-war-plugin. However that does not work either. I am aware of the transitive dependencies thing, I was minded anyway to mark those two as provided and ship them to Tomcat via Puppet. I am however still unable to integration test against Tomcat as it cannot find the class. This appears to be far more painful than expected :( James On 1 December 2014 at 18:05, Chris Gamache cgama...@gmail.com wrote: A few things you might take a look at. I don't think the Tomcat plugin requires javax.mail or activation by itself. That part of the plugin definition probably isn't doing what you intended it to do. I think you might want to remove the extraDependencies section. By including project ... dependencies dependency groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId versionyour_version_here/version /dependency /dependencies /project You'll get javax.mail as a transitive dependency. The Maven WAR plugin is smart enough to include your dependencies and their transitive dependencies in your war file. Even though you're looking up the mail Session using JNDI, I still think you'll be needing the commons email as a compiled dependency unless you've put it in the classpath yourself. If you have put it in the classpath, using provided scope will not include transitive dependencies, of which there are several for commons-email. If that's the route you want to go, you'll need to download and put commons-email's dependencies in the classpath along with commons-email. IMO and FWIW, self-managing dependencies like this complicates your project deployment scheme. The size overhead of including your project's dependencies in the each war is so worth it when Maven can handle making sure the dependency artifacts are where they need to be. On Mon, Dec 1, 2014 at 8:17 AM, James Green james.mk.gr...@gmail.com wrote: Is there a way of getting this to work? We have a Maven project that depends on Apache's commons-email. We use JNDI to look up a mail Session. We use the following in our POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration contextFiletomcat/context.xml/contextFile port9000/port path/foo/path forktrue/fork extraDependencies extraDependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /extraDependency
Re: tomcat7-maven-plugin and mail
What you wrote as a set of suggestions was my original attempt. Then I read (possibly spuriously) that Tomcat ignored either mailx or activation when shipped inside a WAR, and that if both Tomcat (via it's lib/) and the WAR contained either of those then the duplicate JAR would result in an error. So as a result I spotted someone on SO suggesting the above for the maven-war-plugin. However that does not work either. I am aware of the transitive dependencies thing, I was minded anyway to mark those two as provided and ship them to Tomcat via Puppet. I am however still unable to integration test against Tomcat as it cannot find the class. This appears to be far more painful than expected :( James On 1 December 2014 at 18:05, Chris Gamache cgama...@gmail.com wrote: A few things you might take a look at. I don't think the Tomcat plugin requires javax.mail or activation by itself. That part of the plugin definition probably isn't doing what you intended it to do. I think you might want to remove the extraDependencies section. By including project ... dependencies dependency groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId versionyour_version_here/version /dependency /dependencies /project You'll get javax.mail as a transitive dependency. The Maven WAR plugin is smart enough to include your dependencies and their transitive dependencies in your war file. Even though you're looking up the mail Session using JNDI, I still think you'll be needing the commons email as a compiled dependency unless you've put it in the classpath yourself. If you have put it in the classpath, using provided scope will not include transitive dependencies, of which there are several for commons-email. If that's the route you want to go, you'll need to download and put commons-email's dependencies in the classpath along with commons-email. IMO and FWIW, self-managing dependencies like this complicates your project deployment scheme. The size overhead of including your project's dependencies in the each war is so worth it when Maven can handle making sure the dependency artifacts are where they need to be. On Mon, Dec 1, 2014 at 8:17 AM, James Green james.mk.gr...@gmail.com wrote: Is there a way of getting this to work? We have a Maven project that depends on Apache's commons-email. We use JNDI to look up a mail Session. We use the following in our POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration contextFiletomcat/context.xml/contextFile port9000/port path/foo/path forktrue/fork extraDependencies extraDependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /extraDependency extraDependency groupIdjavax.activation/groupId artifactIdactivation/artifactId version1.1.1/version /extraDependency /extraDependencies /configuration executions execution idstart/id goals goalrun-war-only/goal /goals phasepre-integration-test/phase /execution execution idshutdown/id goals goalshutdown/goal /goals phasepost-integration-test/phase /execution /executions /plugin Deployment fails with the following: java.lang.ClassNotFoundException: javax.mail.Session I have both mail and activation listed in the POM's dependencies with a scope of provided. Is further magic required? Thanks, James
tomcat7-maven-plugin and mail
Is there a way of getting this to work? We have a Maven project that depends on Apache's commons-email. We use JNDI to look up a mail Session. We use the following in our POM: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId configuration failOnMissingWebXmlfalse/failOnMissingWebXml /configuration /plugin plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration contextFiletomcat/context.xml/contextFile port9000/port path/foo/path forktrue/fork extraDependencies extraDependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version /extraDependency extraDependency groupIdjavax.activation/groupId artifactIdactivation/artifactId version1.1.1/version /extraDependency /extraDependencies /configuration executions execution idstart/id goals goalrun-war-only/goal /goals phasepre-integration-test/phase /execution execution idshutdown/id goals goalshutdown/goal /goals phasepost-integration-test/phase /execution /executions /plugin Deployment fails with the following: java.lang.ClassNotFoundException: javax.mail.Session I have both mail and activation listed in the POM's dependencies with a scope of provided. Is further magic required? Thanks, James
Documentation on Connectors needs updating
Ref http://tomcat.apache.org/tomcat-8.0-doc/connectors.html Those new to Tomcat will not know what a connector is. I presume it's the network protocol used to listen and respond to external requests... For HTTP it is suggested to use AJP clustering as performance is higher than that of mod_proxy. For AJP it talks of use in a single-server environment and how it's worse than that of HTTP, then for clustering to use AJP. It then says to use JK or mod_proxy with AJP. As the reader, I have no idea where to sit. First mod_proxy can be used but AJP ought to be for performance, yet you can use mod_proxy with AJP. I'm... Puzzled. Since I've not dealt with this beyond getting Apache to mod_proxy to the default Tomcat port 8080 before I'm in no position to clean this up I'm afraid but it looks like clarity is needed. Just my opinion. James
Maven Plugin: Documentation error?
Referencing http://tomcat.apache.org/maven-plugin-trunk/executable-war-jar.html The question I find most obvious when reading this is about the packaging. The war module apparently needs to be war or jar; the pom module apparently needs to be war. Confused! Also, having both listed on the same page. Some might infer you need both. Perhaps it is missing an all-important _or_? Thanks, James
Re: [OT] [Fwd: TomEE Professional Support]
I received this too. This is deeply wrong. I subscribed to Apache lists, not a commercial one. I look forward to seeing what the investigation reveals and what actions take place. On 14 November 2013 08:25, Pid p...@pidster.com wrote: On 13/11/2013 14:53, Gurkan Erdogdu wrote: Hello all, When an Apache project founder[1] starts spamming the Apache community, Sorry but how could you say spamming the Apache Community? without knowing me and how I have been contributing to the Apache community and projects? It's obviously unsolicited commercial email, which is the common base definition of spam. It also seems to me that sending it falls below the standard that one expects from members of the Apache community - I don't recall it happening before. there can and ought to be consequences. What do you mean? Doesn't Apache have some minimu standards for this? He seems to be a project committer, but hasn't contributed any code in about a year. I am PMC Chair of OpenWebBeans project. I think you don't know the roles of PMC Chair, please learn from here before talking. Lastly, I get everyday huge amount of such marketing emails from all big known software vendors. I am sure you also receive such emails. If I am not interested, I simply unsubscribe from the list, this is not a really big problem to discuss! If you received such email from my email address, and not interested please unsubscribe from the list and you will never get a such email again. Best Gurkan On Wednesday, November 13, 2013 4:24 PM, Tim Watts t...@cliftonfarm.org wrote: On Wed, 2013-11-13 at 14:56 +0100, Leon Rosenberg wrote: I got it too. I think its easier to delete and forget it, as to debate about it. ;-) When an Apache project founder[1] starts spamming the Apache community, there can and ought to be consequences. ___ [1] At least that's his claim in the email. Their website doesn't post any PMC member list that I could find. Doesn't Apache have some minimum standards for this? He seems to be a project committer, but hasn't contributed any code in about a year. regards Leon On Wed, Nov 13, 2013 at 2:15 PM, André Warnier a...@ice-sa.com wrote: Hi. I got the following email in my personal email inbox. Isn't there some rule, or at least some matter of self-control, in not using email addresses collected on this list for commercial promotion ? Original Message From: - Wed Nov 13 13:48:37 2013 X-Mozilla-Status: 0001 X-Mozilla-Status2: Return-Path: bounce-mc.us3_22715643.227889-aw=ice-sa.com@mail173. us4.mcsv.net X-Original-To: a...@ice-sa.com Delivered-To: andre.warn...@ice-sa.com Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=205.201.128.173; helo=mail173.us4.mcsv.net; envelope-from=bounce-mc.us3_22715643.227889-aw=ice-sa.com@ mail173.us4.mcsv.net; receiver=a...@ice-sa.com Received: from mail173.us4.mcsv.net (mail173.us4.mcsv.net[205.201.128.173]) by tor.combios.es (Postfix) with ESMTP id DCFAB3C0AD2 for a...@ice-sa.com; Wed, 13 Nov 2013 13:48:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d= mail173.us4.mcsv.net; h=Subject:From:Reply-To:To:Date:Message-ID:List- Unsubscribe:Sender:Content-Type:MIME-Version; i=gurkanerdogdu=3Dyahoo.com@ mail173.us4.mcsv.net; bh=Mxp5nGTBAhJ4tiDlAEgNxpJYWwM=; b=Ocyx3ymgzmK11vA3/+524g885jWe0hlVlLQwFLGw052EepxX/u3JqrGTIZv6+afps8yWKhHqpMRz DR1JqSg9JPIfmn6xVzPvr5X/5Ve5g78ZKmZm5BmxmCRNyqB4fIc5+iLuIas31KKRImjm5cpEh8P5 RAauIo5RquVVHcBgVbU= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d= mail173.us4.mcsv.net; b=BmLvRK7R5zl2/VRFdLZ09BJy50nOQFBXLcUoHLPQqfO o7DkgQbmi8Ug7bwNHNpotAwBLuXBIp2sW w8nzt6XeIcHys59itcvcLBKCt6zoR1 vBv1RFw1OMSwlwuilV8u0zcNtNcav+LdWoW8zAnksyWOWL /knOPWkSMr9PbtPhtB4=; Received: from (127.0.0.1) by mail173.us4.mcsv.net id hgdqg0174lg1 for a...@ice-sa.com; Wed, 13 Nov 2013 12:47:58 + (envelope-from bounce-mc.us3_22715643.227889-aw=ice-sa@mail173.us4.mcsv.net) Subject: TomEE Professional Support From: Apache TomEE Support gurkanerdo...@yahoo.com Reply-To: Apache TomEE Support gurkanerdo...@yahoo.com To: a...@ice-sa.com Date: Wed, 13 Nov 2013 12:47:58 + Message-ID: 9781cf0ccdac7604f1f7fd52ea052bfdbb3.20131113124746@mail173. us4.mcsv.net X-Mailer: MailChimp Mailer - **CID105b909b64a052bfdbb3** X-Campaign: mailchimp9781cf0ccdac7604f1f7fd52e.105b909b64 X-campaignid: mailchimp9781cf0ccdac7604f1f7fd52e.105b909b64 X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=9781cf0ccdac7604f1f7fd52eid= 105b909b64e=a052bfdbb3 X-MC-User: 9781cf0ccdac7604f1f7fd52e x-accounttype: ff List-Unsubscribe: mailto:unsubscribe-9781cf0ccdac7604f1f7fd52e- 105b909b64-a052bfd...@mailin1.us2.mcsv.net?subject=unsubscribe,
Non-invasive configuration by extension?
Hi, I need to configure TomEE to work with SSL connections. I see Tomcat documentation talking about how to edit the server.xml file. Is it possible to supply a small fragment XML file that Tomcat's configuration includes, similar to the way Linux distros now have software that looks in conf.d files? That way I can have the original XML file untouched and merely extend it to our own needs? Otherwise I'm looking at having to merge in changes at later points - more work for us. Thanks, James
Re: Inno Setup Script?
Getting quite frustrated now. Here's the line the installer is now running: C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe //IS//Tomcat7 --DisplayName=Apache Tomcat 7 --JavaHome=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\ --Install=C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe --Jvm=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\bin\client\jvm.dll --JvmOptions=-Djava.io.tmpdir=C:\Program Files\Our Local Services\tomcat\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=C:\Program Files\Our Local Services\tomcat\conf\logging.properties; --Classpath=C:\Program Files\Our Local Services\tomcat\bin\bootstrap.jar;C:\Program Files\Our Local Services\tomcat\bin\tomcat-juli.jar --StartMode=jvm --StopMode=jvm --StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start --StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop --LogPath=C:\Program Files\Our Local Services\tomcat\logs --LogLevel=DEBUG If I subsequently run tomcat7w.exe, the JVM home is not set, nor are lots of other matters. Again, we're seeing error code 1 from Tomcat. EIther I'm doing something dumb or this just doesn't work as described. James
Re: Inno Setup Script?
A follow-up with the solution. This works: C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe //IS//Tomcat7 --DisplayName=Apache Tomcat 7 --JavaHome=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit --Install=C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe --Jvm=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\bin\client\jvm.dll --JvmOptions=-Djava.io.tmpdir=C:\Program Files\Our Local Services\tomcat\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=C:\Program Files\Our Local Services\tomcat\conf\logging.properties; --Classpath=C:\Program Files\Our Local Services\tomcat\bin\bootstrap.jar;C:\Program Files\Our Local Services\tomcat\bin\tomcat-juli.jar --StartMode=jvm --StopMode=jvm --StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start --StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop --LogPath=C:\Program Files\Our Local Services\tomcat\logs --LogLevel=DEBUG This does not: C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe //IS//Tomcat7 --DisplayName=Apache Tomcat 7 --JavaHome=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\ --Install=C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe --Jvm=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\bin\client\jvm.dll --JvmOptions=-Djava.io.tmpdir=C:\Program Files\Our Local Services\tomcat\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=C:\Program Files\Our Local Services\tomcat\conf\logging.properties; --Classpath=C:\Program Files\Our Local Services\tomcat\bin\bootstrap.jar;C:\Program Files\Our Local Services\tomcat\bin\tomcat-juli.jar --StartMode=jvm --StopMode=jvm --StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start --StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop --LogPath=C:\Program Files\Our Local Services\tomcat\logs --LogLevel=DEBUG The difference is that in the working line the value for JavaHome does NOT end with a backslash. This was finally identified by comparing registry data between our custom installer and the official one. Now to build much the same but for HSQL... James On 11 April 2013 10:08, James Green james.mk.gr...@gmail.com wrote: Getting quite frustrated now. Here's the line the installer is now running: C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe //IS//Tomcat7 --DisplayName=Apache Tomcat 7 --JavaHome=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\ --Install=C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe --Jvm=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\bin\client\jvm.dll --JvmOptions=-Djava.io.tmpdir=C:\Program Files\Our Local Services\tomcat\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=C:\Program Files\Our Local Services\tomcat\conf\logging.properties; --Classpath=C:\Program Files\Our Local Services\tomcat\bin\bootstrap.jar;C:\Program Files\Our Local Services\tomcat\bin\tomcat-juli.jar --StartMode=jvm --StopMode=jvm --StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start --StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop --LogPath=C:\Program Files\Our Local Services\tomcat\logs --LogLevel=DEBUG If I subsequently run tomcat7w.exe, the JVM home is not set, nor are lots of other matters. Again, we're seeing error code 1 from Tomcat. EIther I'm doing something dumb or this just doesn't work as described. James
Re: Inno Setup Script?
I was hoping I could avoid that. Currently the thinking is to unpack the tomcat distribution, re-package inside a custom installer, and call bin\tomcat7.exe as per the windows service document. And indeed this works - to a point. The installer logs says: C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe //IS//Tomcat7 --DisplayName=Apache Tomcat 7 --JavaHome=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\ --Install=C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe --Jvm=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\bin\client\jvm.dll --StartMode=jvm --StopMode=jvm --StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start --StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop While this installs a service, as soon as I attempt to start it I get a failure. Nothing is logged by Tomcat, but in the event service I get the following recorded: The Apache Tomcat 7 service terminated with service-specific error Incorrect function.. If I take the full command as executed by the installer, there is no feedback at the command prompt and the service is shown as installed. I am therefore lost as to what I'm looking at as a problem. Any ideas where to go? Thanks, James On 8 April 2013 18:38, Konstantin Kolinko knst.koli...@gmail.com wrote: 2013/4/8 James Green james.mk.gr...@gmail.com: I have a need to distribute an application that works inside Tomcat to a number of customers. I can build an Inno Setup script to most of the work, but rather than re-inventing what looks like quite a complex wheel, has anyone build an installer script for Tomcat already that they could share? In our case we're bundling our own JRE which needs setting when installing the service... Tomcat installer is built using NSIS (Nullsoft Scriptable Install System) . The script is res/tomcat.nsi BTW, if you are using a custom value for HTTP port, do not forget to also change the shutdown port number (8005). I have seen a number of software that forgets to change that. You can set it to -1 when external shutdown is not needed, e.g. when you run as a service. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Inno Setup Script?
On 10 April 2013 11:55, Konstantin Kolinko knst.koli...@gmail.com wrote: 2013/4/10 James Green james.mk.gr...@gmail.com: I was hoping I could avoid that. (...) While this installs a service, as soon as I attempt to start it I get a failure. Nothing is logged by Tomcat, but in the event service I get the following recorded: The Apache Tomcat 7 service terminated with service-specific error Incorrect function.. 1. Top-posting is bad. 2. Tomcat version = ? 7.0.39 3. Some versions of commons-daemon are broken. Try the latest one. Am trying. I can locate all files apart from commons-daemon-native.tar.gz - where does this originate from? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Inno Setup Script?
On 10 April 2013 12:47, Konstantin Kolinko knst.koli...@gmail.com wrote: 2013/4/10 James Green james.mk.gr...@gmail.com: On 10 April 2013 11:55, Konstantin Kolinko knst.koli...@gmail.com wrote: 2013/4/10 James Green james.mk.gr...@gmail.com: I was hoping I could avoid that. (...) While this installs a service, as soon as I attempt to start it I get a failure. Nothing is logged by Tomcat, but in the event service I get the following recorded: The Apache Tomcat 7 service terminated with service-specific error Incorrect function.. 1. Top-posting is bad. 2. Tomcat version = ? 7.0.39 3. Some versions of commons-daemon are broken. Try the latest one. Am trying. I can locate all files apart from commons-daemon-native.tar.gz - where does this originate from? You need http://commons.apache.org/proper/commons-daemon/download_daemon.cgi - browse download area - binaries - windows So that tar.gz file is merely the sources? Am not going to worry too much about that at this stage then! C:\Program Files\Our Local Services\tomcat\bin\tomcat7. exe //IS//Tomcat7 --DisplayName=Apache Tomcat 7 --JavaHome=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\ --Install=C:\Program Files\Our Local Services\tomcat\bin\tomcat7.exe --Jvm=C:\Program Files\Our Local Services\tomcat\..\java-7-32bit\bin\client\jvm.dll --StartMode=jvm --StopMode=jvm --StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start --StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop That command is not enough. There is no classpath, there is no logging configuration (neither for the service itself nor for java.util.logging). There is no configuration for Tomcat itself (catalina.home, catalina.base). Hmm I was merely following http://tomcat.apache.org/tomcat-7.0-doc/windows-service-howto.html#Installing_services to the letter. This does not specify a classpath unless you look under the section Updating services. The other matters are also not mentioned. Where might I find the defaults I need? Is path to Jvm a correct one? I think that is OK, but it could be simplified a bit. The path is dynamic and supplied by the installer. I merely climb up one level to locate our dedicated copy of the JRE. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Inno Setup Script?
I have a need to distribute an application that works inside Tomcat to a number of customers. I can build an Inno Setup script to most of the work, but rather than re-inventing what looks like quite a complex wheel, has anyone build an installer script for Tomcat already that they could share? In our case we're bundling our own JRE which needs setting when installing the service... Thanks, James
Context.xml ignored.
We have a war archive that includes a netbeans-generated context.xml for tomcat deployment. If we drop this war into webapps, the context root remains that of the war filename. Has there been a regression in recent 7.x releases in this regard? Interestingly, a colleague confirms that this is happening also in her independent project (again in 7.x I believe). If we run from netbeans, the context is set as expected. Thanks, James Sent from my iPad - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context.xml ignored.
On 3 March 2013 11:34, Konstantin Kolinko knst.koli...@gmail.com wrote: 2013/3/3 James Green james.mk.gr...@gmail.com: We have a war archive that includes a netbeans-generated context.xml for tomcat deployment. If we drop this war into webapps, the context root remains that of the war filename. As expected, in any of 7.0., 6.0 and even 5.5 . Have you read the docs (Context chapter in Configuration reference)? I did. Allow me to digress a little to provide insight into how I read the documentation. First I got to the main documentation and click section 4: Deployer. Scroll down to Deploying on a running Tomcat server - this is exactly what I want. I read that provided autoDeploy is set to true Tomcat will unpack .war files deployed to something called appBase - this seems to mean the webapps folder when Googling around for application deployment directory in Tomcat. No idea at this point if autoDeploy is true or not, one way to find out - try it. Sure enough the war file gets consumed. So now I have a war deployed. Easy enough. Now to set the URL path. There a lot of talk about Context Descriptors on that page, and at the top one seems to be read from webapps/[my-war-file]/META-INF/context.xml. Perfect, but what goes in it? Elsewhere, I find Config, and in there we find Context. Aha! Parallel Deployment? Nope don't want that. Naming? I read that several times, and I have no idea still what is trying to be expressed. Does it even apply to me? Not sure, let's move on and see if anything else seems directly related to what I'm doing. Defining a Context: That's what I want. First option - META/INF/context.xml. Aha. Do we have an example with sensible example values to change? No. OK, let's see if Netbeans can help out. Set the project to run inside Tomcat, and deploy to my named context path. After running, I have a META-INF/context.xml with a couple of attributes that match the documentation. Perfect. I can deploy from Netbeans, but still deploying by dropping into the webapps folder doesn't have the fully desired effect. If I do the same with Glassfish using it's config file, I do get the desired effect. Seems simple enough... Wonder what's different... OK I've digressed enough, and still I've not spotted anything clear and concise telling me what I'm doing wrong. Apologies if I am being really, really, blind! Thanks, James
Re: Context.xml ignored.
On 3 March 2013 14:32, Mark Thomas ma...@apache.org wrote: On 03/03/2013 14:24, James Green wrote: On 3 March 2013 11:34, Konstantin Kolinko knst.koli...@gmail.com wrote: 2013/3/3 James Green james.mk.gr...@gmail.com: So now I have a war deployed. Easy enough. Now to set the URL path. There a lot of talk about Context Descriptors on that page, and at the top one seems to be read from webapps/[my-war-file]/META-INF/context.xml. Perfect, but what goes in it? Elsewhere, I find Config, and in there we find Context. Aha! Parallel Deployment? Nope don't want that. Naming? I read that several times, and I have no idea still what is trying to be expressed. Does it even apply to me? Not sure, let's move on Stop here. The naming section is exactly the bit you need to understand. I'm sure there is scope to improve the docs so if you explain where you start to get lost we can look at improving the wording / adding additional explanation as required. users-h...@tomcat.apache.org Diving straight into the Naming section then we describe a relationship involving these elements: - Context Name - Context Version - Context Path - Base file name Is the base file name the name of the war file built? Are the context elements name, version and path, supposed to come from the context.xml file? Other than path, they are not listed in the attributes further down the page. So now I'm being told that a set of rules apply when no version is specified. Still no idea where a version gets specified though: is it read from the war filename? Going to have to ignore this for now. Now on to something that appears reasonably clear: If you want to deploy a WAR file or a directory using a context path that is not related to the base file name - yes! then one of the following options must be used to prevent double-deployment - double deployment? Does this still apply to deployment in general or some particular circumstance in which double-deployment would happen? Disable autoDeploy and deployOnStartup and define all Contexts in server.xml - given the dynamic nature of our development, that is definitely not desirable Locate the WAR and/or directory outside of the Host's appBase and use a context.xml file with a docBase attribute to define it. - you want me to hook in the war from outside Tomcat? Not clear why I would want to do that. If I may digress some further: Looking at the FAQ, under Deployment, I'm am told that META-INF/context.xml is still recommended for Tomcat 7. I am still left wondering what I should be doing... James
Re: Context.xml ignored.
On 3 March 2013 15:51, Mark Thomas ma...@apache.org wrote: On 03/03/2013 15:29, James Green wrote: On 3 March 2013 14:32, Mark Thomas ma...@apache.org wrote: On 03/03/2013 14:24, James Green wrote: On 3 March 2013 11:34, Konstantin Kolinko knst.koli...@gmail.com wrote: 2013/3/3 James Green james.mk.gr...@gmail.com: So now I have a war deployed. Easy enough. Now to set the URL path. There a lot of talk about Context Descriptors on that page, and at the top one seems to be read from webapps/[my-war-file]/META-INF/context.xml. Perfect, but what goes in it? Elsewhere, I find Config, and in there we find Context. Aha! Parallel Deployment? Nope don't want that. Naming? I read that several times, and I have no idea still what is trying to be expressed. Does it even apply to me? Not sure, let's move on Stop here. The naming section is exactly the bit you need to understand. I'm sure there is scope to improve the docs so if you explain where you start to get lost we can look at improving the wording / adding additional explanation as required. users-h...@tomcat.apache.org Diving straight into the Naming section then we describe a relationship involving these elements: - Context Name - Context Version - Context Path - Base file name Is the base file name the name of the war file built? Are the context elements name, version and path, supposed to come from the context.xml file? Other than path, they are not listed in the attributes further down the page. OK. Lets address the above. Once you are happy you understand what is going on, I'll suggest an update to the docs that you can review. Context path is as defined in the Servlet specification. Context name is the unique identifier for a context within a host. If no version is specified (none is needed unless parallel deployment is being used) then context name is identical the the context path. If a version is specified then ##ContextVersion is appended to the context path to create the context name. Context version is a version identifier that is used under parallel deployment when multiple versions of the same application are deployed with the same context path. Base file name is the common part of the file named used for the WAR (baseFileName.war) directory (baseFileName) or context.xml file (baseFileName.xml) from which the application is deployed. Context name is derived from base file name by: - replacing any single '#' characters with '/' - if the base file name starts with ROOT, replacing ROOT with the empty string - if the base file name does not start with ROOT, pre-pending a leading '/' The base file name controls the context path. If you want to change the context path, the simplest solution is to change the base file name. Fine. But this is not as described on this page: http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html Here, again, i'm told that META-INF/context.xml provides the context descriptor. It also states that dropping the war into webapps/ will consume the web application. Again, in the FAQ, there holds a reference to this file for deployment purposes. I seem not to be alone in thinking this is the case. A simple Google revealed: http://stackoverflow.com/questions/2593472/define-servlet-context-in-war-file If you are suggesting that META-INF/context.xml is not used for the purposes of defining the context path, then quite a few references need to be removed. If you are not suggesting this, then I am still missing the reason why my context.xml does not deploy the application to the path I supply. Thanks for providing your time on this matter so far. James
Re: Context.xml ignored.
On 3 March 2013 17:58, Mark Thomas ma...@apache.org wrote: On 03/03/2013 16:22, James Green wrote: On 3 March 2013 15:51, Mark Thomas ma...@apache.org wrote: snip/ The base file name controls the context path. If you want to change the context path, the simplest solution is to change the base file name. Fine. But this is not as described on this page: http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html Here, again, i'm told that META-INF/context.xml provides the context descriptor. It also states that dropping the war into webapps/ will consume the web application. Again, in the FAQ, there holds a reference to this file for deployment purposes. OK. Where on that page does it say that the context.xml file is used to define the context path? Maybe an explicit statement that this is not the case is required. I am clearly inferring too much. An explicit statement would certainly help reduce confusion, and perhaps cause the Netbeans people to avoid putting the path attribute into the context element - presumably they took the view that it was supported? At this point may I ask what reason prevents you from supporting such a deployment facility? I am surprised that so much of what I would expect is supported, yet this pretty significant part is not. I'm curious now as to why. May I ask ask how deployment is usually carried out it development and project environments? Is it usually doing using the HTTP api (which is I presume the way Netbeans interacts with Tomcat)? Thanks again for your time. I would appreciate it if the documentation would clarify that the part of the webapp cannot be set within the deployed webapp itself. James
Re: Context.xml ignored.
On 3 March 2013 19:44, Mark Thomas ma...@apache.org wrote:
On 03/03/2013 19:25, James Green wrote:
I am clearly inferring too much. An explicit statement would certainly
help
reduce confusion, and perhaps cause the Netbeans people to avoid putting
the path attribute into the context element - presumably they took the
view
that it was supported?
It was supported about 10 years and 4 major versions ago.
At this point may I ask what reason prevents you from supporting such a
deployment facility? I am surprised that so much of what I would expect
is
supported, yet this pretty significant part is not. I'm curious now as to
why.
The issue was that it lead to lots of problems when coupled with
automatic deployment. For example, if you have foo.war and bar.war in
your webapps directory and bar.war contains a context.xml file that
declares a path of /foo what happens?
Now that is a relatively simple case where the desired behaviour could
be documented and Tomcat coded to implement it. However once all the
moving parts are taken into account:
- name of WAR file
- presence (or not) of context.xml with a path defined
- automatic deployment enabled (or not)
- context.xml file extracted to ${CATALINA_BASE}/enginename/hostname
(or not)
- deployment of a new application that may (or may not conflict with
some of the above
- deployment order (context.xml, WAR, dir)
- detection of changes to context.xml and automatic re-deployment
- expansion (or not) of WAR file into corresponding directory
it rapidly reached the point where the code was extremely fragile and
still had plenty of bugs. The decision was taken, therefore, to link the
base file name and context name as previously described. This removed
nearly all of the nasty edge cases, made for much simpler code and made
the overall process a lot easier to understand.
Fair enough. I appreciate the explanation - seems reasonable to me.
May I ask ask how deployment is usually carried out it development and
project environments? Is it usually doing using the HTTP api (which is I
presume the way Netbeans interacts with Tomcat)?
Unlikely. I usually see the following process:
- stop the instance
- copy the WAR
- start the instance
I'll admit now to now having yet read any documentation on this - but is
there a graceful shutdown procedure? Similar to apache2ctl graceful, but
one that allows threads to complete naturally whilst preventing new inbound
network connections to be accepted? I am of course thinking that such a
stop/copy/start solution must be sat behind a proxy.
I rarely see production deployments deploying via HTTP. YMMV.
Thanks again for your time. I would appreciate it if the documentation
would clarify that the part of the webapp cannot be set within the
deployed
webapp itself.
I'm assuming s/part/path/
Indeed.
I'll take a look at that shortly.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
