Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/30 Knute Snortum ksnor...@catalystitservices.com:
See below:
-Original Message-
From: Knute Snortum [mailto:ksnor...@catalystitservices.com]
Sent: Wednesday, August 29, 2012 3:05 PM
To: Tomcat Users List
Subject: RE: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Wednesday, August 29, 2012 9:32 AM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering
of context files?
[section deleted]
What cli are you using ?
If I understand you, it's this:
mvn clean install tomcat:run -P development
I'm making that up because it's actually run from an Eclipse form.
When I run that from the command line in the project folder, I get the
same results so I think it's right...
I just noticed that the CLI should be:
mvn clean install tomcat7:run -P development
...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1
version that we were excepting. I also notice the debug flag (-e?)
and that gives me a ton of info. Should I repost the output, or some
of it?
Add as an attachment?
Regarding the flag have a look at what mvn -h says :-) (-X is for full
debug trace)
Maybe in a jira issue yes but not sure that will help
BTW do you have any sample project to reproduce your issue ?
It would be complex to do this, but I'm going to try. I'm not sure
how I would post that.
Just share a project via bitbucket or github.
Is there anything else I should do? I don't want to report this as a bug if
it's working as designed. But I was hoping I wouldn't have to setup my own,
private Tomcat server to do development.
Thanks for the project that helps me to understand your problem :-)
The filtering here is done by the maven-war-plugin so the tomcat7
doesn't have any idea of that !
The plugin use warSourceDirectory
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-plugin/run-mojo.html#warSourceDirectory
So by default web.xml is src/main/webapp/WEB-INF/web.xml and the file
is not filtered
In your case you can add
warSourceDirectory${project.build.directory}/${project.artifactId}-${project.version}/warSourceDirectory
to the tomcat7 plugin configuration
and run: mvn clean install tomcat7:run
and it looks it works no more debug mode and it will use the filtered file.
HTH
I created a test project in Github:
https://github.com/ksnortum/Tomcat7MavenPluginTester
It demonstrates what I believe is a bug in tomcat7-maven-plugin. The
Tomcat server that is created does not use the configuration files
(e.g.: web.xml) in the war file or the war directory that is created.
It uses the project files, that is, the ones in src/main/webapp/WEB-
INF. If you use Maven web resource filtering, the war file is changed
but the project file isn't. This is correct. But if tomcat7-maven-
plugin doesn't use the war configuration files, then how can you
properly test the war file?
- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
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
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Friday, August 31, 2012 6:58 AM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
2012/8/30 Knute Snortum ksnor...@catalystitservices.com:
See below:
-Original Message-
From: Knute Snortum [mailto:ksnor...@catalystitservices.com]
Sent: Wednesday, August 29, 2012 3:05 PM
To: Tomcat Users List
Subject: RE: tomcat7-maven-plugin doesn't understand Maven filtering
of context files?
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Wednesday, August 29, 2012 9:32 AM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven
filtering of context files?
[section deleted]
What cli are you using ?
If I understand you, it's this:
mvn clean install tomcat:run -P development
I'm making that up because it's actually run from an Eclipse
form.
When I run that from the command line in the project folder, I get
the same results so I think it's right...
I just noticed that the CLI should be:
mvn clean install tomcat7:run -P development
...with tomcat7 not tomcat. This gives me the Tomcat
2.0-beta-1
version that we were excepting. I also notice the debug flag (-e?)
and that gives me a ton of info. Should I repost the output, or
some
of it?
Add as an attachment?
Regarding the flag have a look at what mvn -h says :-) (-X is for
full debug trace)
Maybe in a jira issue yes but not sure that will help
BTW do you have any sample project to reproduce your issue ?
It would be complex to do this, but I'm going to try. I'm not
sure
how I would post that.
Just share a project via bitbucket or github.
Is there anything else I should do? I don't want to report this as a
bug if it's working as designed. But I was hoping I wouldn't have to
setup my own, private Tomcat server to do development.
Thanks for the project that helps me to understand your problem :-)
The filtering here is done by the maven-war-plugin so the tomcat7
doesn't have any idea of that !
The plugin use warSourceDirectory
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat7-maven-
plugin/run-mojo.html#warSourceDirectory
So by default web.xml is src/main/webapp/WEB-INF/web.xml and the file is
not filtered
In your case you can add
warSourceDirectory${project.build.directory}/${project.artifactId}-
${project.version}/warSourceDirectory
to the tomcat7 plugin configuration
and run: mvn clean install tomcat7:run
and it looks it works no more debug mode and it will use the filtered
file.
HTH
That was it! You solved a problem that has been haunting me for about a month!
Thank you.
Just for your notes, the default directory for the Maven filtering plugin is
${project.build.directory}/${project.build.finalName}, and the final name
defaults to ${project.artifactId}-${project.version}. I say that in case you
or anyone uses buildfinalName in their POM.
Thanks again!
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
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: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
See below: -Original Message- From: Knute Snortum [mailto:ksnor...@catalystitservices.com] Sent: Wednesday, August 29, 2012 3:05 PM To: Tomcat Users List Subject: RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files? -Original Message- From: Olivier Lamy [mailto:ol...@apache.org] Sent: Wednesday, August 29, 2012 9:32 AM To: Tomcat Users List Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files? [section deleted] What cli are you using ? If I understand you, it's this: mvn clean install tomcat:run -P development I'm making that up because it's actually run from an Eclipse form. When I run that from the command line in the project folder, I get the same results so I think it's right... I just noticed that the CLI should be: mvn clean install tomcat7:run -P development ...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1 version that we were excepting. I also notice the debug flag (-e?) and that gives me a ton of info. Should I repost the output, or some of it? Add as an attachment? Regarding the flag have a look at what mvn -h says :-) (-X is for full debug trace) Maybe in a jira issue yes but not sure that will help BTW do you have any sample project to reproduce your issue ? It would be complex to do this, but I'm going to try. I'm not sure how I would post that. Just share a project via bitbucket or github. Is there anything else I should do? I don't want to report this as a bug if it's working as designed. But I was hoping I wouldn't have to setup my own, private Tomcat server to do development. I created a test project in Github: https://github.com/ksnortum/Tomcat7MavenPluginTester It demonstrates what I believe is a bug in tomcat7-maven-plugin. The Tomcat server that is created does not use the configuration files (e.g.: web.xml) in the war file or the war directory that is created. It uses the project files, that is, the ones in src/main/webapp/WEB- INF. If you use Maven web resource filtering, the war file is changed but the project file isn't. This is correct. But if tomcat7-maven- plugin doesn't use the war configuration files, then how can you properly test the war file? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/29 Knute Snortum ksnor...@catalystitservices.com:
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Tuesday, August 28, 2012 2:17 PM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
Hi,
Inline
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could
someone direct me to the right place?
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm
using the tomcat7-maven-plugin 2.0-beta-1 to help in development by
running the app in Tomcat inside of the IDE -- or I'm trying. The error
I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException:
Invalid bean definition with name 'dataSource' defined in
ServletContext resource [/WEB-INF/applicationContext.xml]: Could not
resolve placeholder 'db.driverClassName' in string value
[${db.driverClassName}]
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
The odd thing is that in the war file and the directory under target
that the war file is created from, all the place holders have been
correctly substituted. I can see them in an editor. The context file
with the placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file
in the war file or folder? And if it looks in the development folder
for the file, can Maven filtering work with the plugin?.
as you are using gwt maven plugin, I'm not sure that works.
Something you can do is using sys properties in tomcat7/6-maven-plugin
(spring placeholder resolves against sys props too).
Add you sys props as it:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat6-maven-
plugin/examples/add-system-properties.html
Well, I'm using Maven filtering, and the reason for that is my client
requires that I use Maven profiling to set the development and the production
environments. So I'd have to a Maven Tomcat plugin in each profile -- which
maybe I'll do.
I need the GWT plugin because this is a Vaadin project and Vaadin uses GWT.
Below is part of the messages created by Maven et al in my IDE
console. I've left out the clean and testing messages and most of the
stacktrace, which I think is from Spring anyway:
[INFO]
[INFO] --- gwt-maven-plugin:2.4.0:compile (default) @ dpt --- [INFO]
auto discovered modules
[com.catalystitservices.nike.dpt.widgetset.DptWidgetset]
[INFO] com.catalystitservices.nike.dpt.widgetset.DptWidgetset is up to
date. GWT compilation skipped [INFO] [INFO] ---
maven-war-plugin:2.2:war (default-war) @ dpt --- [INFO] Packaging
webapp [INFO] Assembling webapp [dpt] in [C:\Projects\DPT\target\dpt]
[INFO] Processing war project [INFO] Copying webapp webResources
[C:\Projects\DPT\src/main/webapp/] to [C:\Projects\DPT\target\dpt]
[INFO] Copying webapp resources [C:\Projects\DPT\src\main\webapp]
[INFO] Webapp assembled in [1442 msecs] [INFO] Building war:
C:\Projects\DPT\target\dpt.war [INFO] [INFO] ---
tomcat7-maven-plugin:2.0-beta-1:exec-war-only (tomcat-run) @ dpt ---
[INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install)
@ dpt --- [INFO] Installing C:\Projects\DPT\target\dpt.war to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT.war [INFO] Installing C:\Projects\DPT\pom.xml to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT.pom [INFO] Installing
C:\Projects\DPT\target\dpt-1.1-SNAPSHOT-war-exec.jar to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT-exec-war.jar
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries in
your pom ?
There's no duplicate. The one I have looks like this:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version${tomcat7MavenPlugin}/version
...
And my properties look like:
tomcat7MavenPlugin2.0-beta-1
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
[part of message deleted]
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries
in your pom ?
There's no duplicate. The one I have looks like this:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version${tomcat7MavenPlugin}/version
...
And my properties look like:
tomcat7MavenPlugin2.0-beta-1/tomcat7MavenPlugin
Ok but the logs doesn't says that :-)
True. I'm not sure why. I'll fool with it some.
What cli are you using ?
If I understand you, it's this:
mvn clean install tomcat:run -P development
I'm making that up because it's actually run from an Eclipse form. When I run
that from the command line in the project folder, I get the same results so I
think it's right...
I just noticed that the CLI should be:
mvn clean install tomcat7:run -P development
...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1 version
that we were excepting. I also notice the debug flag (-e?) and that gives me a
ton of info. Should I repost the output, or some of it? Add as an attachment?
BTW do you have any sample project to reproduce your issue ?
It would be complex to do this, but I'm going to try. I'm not sure how I would
post that.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/29 Knute Snortum ksnor...@catalystitservices.com:
[part of message deleted]
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries
in your pom ?
There's no duplicate. The one I have looks like this:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version${tomcat7MavenPlugin}/version
...
And my properties look like:
tomcat7MavenPlugin2.0-beta-1/tomcat7MavenPlugin
Ok but the logs doesn't says that :-)
True. I'm not sure why. I'll fool with it some.
What cli are you using ?
If I understand you, it's this:
mvn clean install tomcat:run -P development
I'm making that up because it's actually run from an Eclipse form. When I
run that from the command line in the project folder, I get the same results
so I think it's right...
I just noticed that the CLI should be:
mvn clean install tomcat7:run -P development
...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1 version
that we were excepting. I also notice the debug flag (-e?) and that gives me
a ton of info. Should I repost the output, or some of it? Add as an
attachment?
Regarding the flag have a look at what mvn -h says :-) (-X is for full
debug trace)
Maybe in a jira issue yes but not sure that will help
BTW do you have any sample project to reproduce your issue ?
It would be complex to do this, but I'm going to try. I'm not sure how I
would post that.
Just share a project via bitbucket or github.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message- From: Olivier Lamy [mailto:ol...@apache.org] Sent: Wednesday, August 29, 2012 9:32 AM To: Tomcat Users List Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files? [section deleted] What cli are you using ? If I understand you, it's this: mvn clean install tomcat:run -P development I'm making that up because it's actually run from an Eclipse form. When I run that from the command line in the project folder, I get the same results so I think it's right... I just noticed that the CLI should be: mvn clean install tomcat7:run -P development ...with tomcat7 not tomcat. This gives me the Tomcat 2.0-beta-1 version that we were excepting. I also notice the debug flag (-e?) and that gives me a ton of info. Should I repost the output, or some of it? Add as an attachment? Regarding the flag have a look at what mvn -h says :-) (-X is for full debug trace) Maybe in a jira issue yes but not sure that will help BTW do you have any sample project to reproduce your issue ? It would be complex to do this, but I'm going to try. I'm not sure how I would post that. Just share a project via bitbucket or github. I created a test project in Github: https://github.com/ksnortum/Tomcat7MavenPluginTester It demonstrates what I believe is a bug in tomcat7-maven-plugin. The Tomcat server that is created does not use the configuration files (e.g.: web.xml) in the war file or the war directory that is created. It uses the project files, that is, the ones in src/main/webapp/WEB-INF. If you use Maven web resource filtering, the war file is changed but the project file isn't. This is correct. But if tomcat7-maven-plugin doesn't use the war configuration files, then how can you properly test the war file? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could someone
direct me to the right place?
Yes, this is the list.
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm using
the tomcat7-maven-plugin 2.0-beta-1 to help in development by running the app
in Tomcat inside of the IDE -- or I'm trying. The error I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean
definition with name 'dataSource' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Could not resolve placeholder
'db.driverClassName' in string value [${db.driverClassName}]
applicationContext.xml is my Spring context file. I have placeholders in
it to point to the correct database based on Maven profiles and filtering.
So a piece of applicationContext.xml looks like this:
bean id=dataSource class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=usernamevalue=${db.username} /
property name=passwordvalue=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean that does
not have the placeholders replaced yet.
Usually it is Spring job to resolve those.
(It has nothing to to with Tomcat or Maven).
See org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
The odd thing is that in the war file and the directory under target that the
war file is created from, all the place holders have been correctly
substituted. I can see them in an editor. The context file with the
placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file in the
war file or folder? And if it looks in the development folder for the file,
can Maven filtering work with the plugin?.
Below is part of the messages created by Maven et al in my IDE console. I've
left out the clean and testing messages and most of the stacktrace, which I
think is from Spring anyway:
(...)
28.08.2012 10:14:01 ERROR (ContextLoader.java:307) - Context initialization
failed
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean
definition with name 'dataSource' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Could not resolve placeholder
'db.driverClassName' in string value [${db.driverClassName}]
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Tuesday, August 28, 2012 11:15 AM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could
someone direct me to the right place?
Yes, this is the list.
Thanks
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm
using the tomcat7-maven-plugin 2.0-beta-1 to help in development by
running the app in Tomcat inside of the IDE -- or I'm trying. The error
I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException:
Invalid bean definition with name 'dataSource' defined in ServletContext
resource [/WEB-INF/applicationContext.xml]: Could not resolve
placeholder 'db.driverClassName' in string value [${db.driverClassName}]
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
Usually it is Spring job to resolve those.
(It has nothing to to with Tomcat or Maven).
See
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
Well, I'm using Maven filtering, but regardless, I thought the whole point of
the tomcat7-maven-plugin was to run the *war* file, not the development
(project) files. If it doesn't, it's useless to me. Or maybe I should ask,
How does one run the war file created with mvn clean install in the IDE
(Eclipse)?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
Usually it is Spring job to resolve those.
(It has nothing to to with Tomcat or Maven).
See
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
Well, I'm using Maven filtering, but regardless, I thought the whole point of
the tomcat7-maven-plugin was to run the *war* file, not the development
(project) files.
Your question was about applicationContext.xml. That is an essential
part of a Spring web application. It is not just a project file.
Now you are changing the topic...
Tomcat knows nothing about Spring, and context has different meaning
in Tomcat (referring to the META-INF/context.xml file in a web
application, see Tomcat Configuration Reference in Tomcat 7
documentation).
If you need apply filtering to your data file (that
applicationContext.xml one), shouldn't you configure so explicitly
somewhere?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Tuesday, August 28, 2012 12:02 PM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks
like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url}
/
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
Usually it is Spring job to resolve those.
(It has nothing to to with Tomcat or Maven).
See
org.springframework.beans.factory.config.PropertyPlaceholderConfigure
r
Well, I'm using Maven filtering, but regardless, I thought the whole
point of the tomcat7-maven-plugin was to run the *war* file, not the
development (project) files.
Your question was about applicationContext.xml. That is an essential
part of a Spring web application. It is not just a project file.
Now you are changing the topic...
I'm not trying to. It's the applicationContext.xml file that gets changed by
Maven filtering, then it gets put into the war file by the tomcat plugin. I
want the plugin to run the war run, not the still in the project with the
placeholders. That's what I thought it did.
Tomcat knows nothing about Spring, and context has different meaning
in Tomcat (referring to the META-INF/context.xml file in a web
application, see Tomcat Configuration Reference in Tomcat 7
documentation).
If you need apply filtering to your data file (that
applicationContext.xml one), shouldn't you configure so explicitly
somewhere?
I do, and it works perfectly. It creates my context files with the database
data in them as it should. These files are built into a war file. I want the
Tomcat plugin to run the war file.
When I manually deploy the war file that is created, it works perfectly. I
thought the point of the Tomcat plugin was that I didn't have to manually
deploy the war file.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
Hi,
Inline
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could someone
direct me to the right place?
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm using
the tomcat7-maven-plugin 2.0-beta-1 to help in development by running the app
in Tomcat inside of the IDE -- or I'm trying. The error I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean
definition with name 'dataSource' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Could not resolve placeholder
'db.driverClassName' in string value [${db.driverClassName}]
applicationContext.xml is my Spring context file. I have placeholders in
it to point to the correct database based on Maven profiles and filtering.
So a piece of applicationContext.xml looks like this:
bean id=dataSource class=org.apache.commons.dbcp.BasicDataSource
destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=usernamevalue=${db.username} /
property name=passwordvalue=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean that does
not have the placeholders replaced yet.
The odd thing is that in the war file and the directory under target that the
war file is created from, all the place holders have been correctly
substituted. I can see them in an editor. The context file with the
placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file in the
war file or folder? And if it looks in the development folder for the file,
can Maven filtering work with the plugin?.
as you are using gwt maven plugin, I'm not sure that works.
Something you can do is using sys properties in tomcat7/6-maven-plugin
(spring placeholder resolves against sys props too).
Add you sys props as it:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat6-maven-plugin/examples/add-system-properties.html
Below is part of the messages created by Maven et al in my IDE console. I've
left out the clean and testing messages and most of the stacktrace, which I
think is from Spring anyway:
[INFO]
[INFO] --- gwt-maven-plugin:2.4.0:compile (default) @ dpt ---
[INFO] auto discovered modules
[com.catalystitservices.nike.dpt.widgetset.DptWidgetset]
[INFO] com.catalystitservices.nike.dpt.widgetset.DptWidgetset is up to date.
GWT compilation skipped
[INFO]
[INFO] --- maven-war-plugin:2.2:war (default-war) @ dpt ---
[INFO] Packaging webapp
[INFO] Assembling webapp [dpt] in [C:\Projects\DPT\target\dpt]
[INFO] Processing war project
[INFO] Copying webapp webResources [C:\Projects\DPT\src/main/webapp/] to
[C:\Projects\DPT\target\dpt]
[INFO] Copying webapp resources [C:\Projects\DPT\src\main\webapp]
[INFO] Webapp assembled in [1442 msecs]
[INFO] Building war: C:\Projects\DPT\target\dpt.war
[INFO]
[INFO] --- tomcat7-maven-plugin:2.0-beta-1:exec-war-only (tomcat-run) @ dpt
---
[INFO]
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ dpt ---
[INFO] Installing C:\Projects\DPT\target\dpt.war to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT.war
[INFO] Installing C:\Projects\DPT\pom.xml to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT.pom
[INFO] Installing C:\Projects\DPT\target\dpt-1.1-SNAPSHOT-war-exec.jar to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1-SNAPSHOT-exec-war.jar
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries
in your pom ?
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ dpt ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ dpt ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
[INFO]
[INFO] --- tomcat-maven-plugin:1.1:run (default-cli) @ dpt ---
[INFO] Running war on http://localhost:8080/dpt
[INFO] Creating Tomcat server configuration at C:\Projects\DPT\target\tomcat
Aug 28, 2012 10:13:59 AM org.apache.catalina.startup.Embedded start
INFO: Starting tomcat server
Aug 28, 2012 10:14:00 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
Aug 28, 2012 10:14:00 AM org.apache.catalina.core.ApplicationContext log
INFO: Set web app root system property:
RE: tomcat7-maven-plugin doesn't understand Maven filtering of context files?
-Original Message-
From: Olivier Lamy [mailto:ol...@apache.org]
Sent: Tuesday, August 28, 2012 2:17 PM
To: Tomcat Users List
Subject: Re: tomcat7-maven-plugin doesn't understand Maven filtering of
context files?
Hi,
Inline
2012/8/28 Knute Snortum ksnor...@catalystitservices.com:
If this is the wrong mailing list for tomcat7-maven-plugin, could
someone direct me to the right place?
I'm developing a Vaadin web app in Eclipse Juno on Windows 7 and I'm
using the tomcat7-maven-plugin 2.0-beta-1 to help in development by
running the app in Tomcat inside of the IDE -- or I'm trying. The error
I'm getting is:
org.springframework.beans.factory.BeanDefinitionStoreException:
Invalid bean definition with name 'dataSource' defined in
ServletContext resource [/WEB-INF/applicationContext.xml]: Could not
resolve placeholder 'db.driverClassName' in string value
[${db.driverClassName}]
applicationContext.xml is my Spring context file. I have
placeholders in it to point to the correct database based on Maven
profiles and filtering. So a piece of applicationContext.xml looks like
this:
bean id=dataSource
class=org.apache.commons.dbcp.BasicDataSource destroy-method=close
property name=driverClassName
value=${db.driverClassName} /
property name=url value=${db.url} /
property name=username
value=${db.username} /
property name=password
value=${db.password} /
property name=maxActive value=10 /
property name=maxIdle value=1 /
/bean
As you can see, Tomcat (or Spring?) is finding the dataSource bean
that does not have the placeholders replaced yet.
The odd thing is that in the war file and the directory under target
that the war file is created from, all the place holders have been
correctly substituted. I can see them in an editor. The context file
with the placeholders is the one still sitting in my development folder.
So my question is, why isn't the Tomcat plugin seeing the context file
in the war file or folder? And if it looks in the development folder
for the file, can Maven filtering work with the plugin?.
as you are using gwt maven plugin, I'm not sure that works.
Something you can do is using sys properties in tomcat7/6-maven-plugin
(spring placeholder resolves against sys props too).
Add you sys props as it:
http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/tomcat6-maven-
plugin/examples/add-system-properties.html
Well, I'm using Maven filtering, and the reason for that is my client requires
that I use Maven profiling to set the development and the production
environments. So I'd have to a Maven Tomcat plugin in each profile -- which
maybe I'll do.
I need the GWT plugin because this is a Vaadin project and Vaadin uses GWT.
Below is part of the messages created by Maven et al in my IDE
console. I've left out the clean and testing messages and most of the
stacktrace, which I think is from Spring anyway:
[INFO]
[INFO] --- gwt-maven-plugin:2.4.0:compile (default) @ dpt --- [INFO]
auto discovered modules
[com.catalystitservices.nike.dpt.widgetset.DptWidgetset]
[INFO] com.catalystitservices.nike.dpt.widgetset.DptWidgetset is up to
date. GWT compilation skipped [INFO] [INFO] ---
maven-war-plugin:2.2:war (default-war) @ dpt --- [INFO] Packaging
webapp [INFO] Assembling webapp [dpt] in [C:\Projects\DPT\target\dpt]
[INFO] Processing war project [INFO] Copying webapp webResources
[C:\Projects\DPT\src/main/webapp/] to [C:\Projects\DPT\target\dpt]
[INFO] Copying webapp resources [C:\Projects\DPT\src\main\webapp]
[INFO] Webapp assembled in [1442 msecs] [INFO] Building war:
C:\Projects\DPT\target\dpt.war [INFO] [INFO] ---
tomcat7-maven-plugin:2.0-beta-1:exec-war-only (tomcat-run) @ dpt ---
[INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install)
@ dpt --- [INFO] Installing C:\Projects\DPT\target\dpt.war to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT.war [INFO] Installing C:\Projects\DPT\pom.xml to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT.pom [INFO] Installing
C:\Projects\DPT\target\dpt-1.1-SNAPSHOT-war-exec.jar to
C:\Users\ksnortum\.m2\repository\com\nike\dpt\dpt\1.1-SNAPSHOT\dpt-1.1
-SNAPSHOT-exec-war.jar
[INFO]
[INFO] tomcat-maven-plugin:1.1:run (default-cli) @ dpt
you are using an old version here ? Don't you have duplicate entries in
your pom ?
There's no duplicate. The one I have looks like this:
plugin
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat7-maven-plugin/artifactId
version${tomcat7MavenPlugin}/version
...
And my properties look like:
tomcat7MavenPlugin2.0-beta-1/tomcat7MavenPlugin
[INFO]
[INFO] --- maven-resources-plugin:2.5
