[
http://jira.codehaus.org/browse/MTOMCAT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=254720#action_254720
]
Ryan Connolly edited comment on MTOMCAT-76 at 2/4/11 9:11 PM:
--------------------------------------------------------------
Setting the following in your project pom with the context and WebappLoader set
to reloadable will demonstrate the default scanning and reloading of the
context.
{code}<outputDirectory>src/main/webapp/WEB-INF/classes</outputDirectory>{code}
As no one would EVER want to compile to anywhere inside the source tree, this
is merely a demonstration and should NOT be used as a workaround :)
was (Author: rynam0):
Setting the following in your project pom with the context and WebappLoader
set to reloadable will demonstrate the default scanning and reloading of the
context.
<outputDirectory>src/main/webapp/WEB-INF/classes</outputDirectory>. As no one
would EVER want to compile to anywhere inside the source tree, this is merely a
demonstration and should NOT be used as a workaround :)
> As a plugin user I would like reloadable contexts so that my development
> times are reduced.
> -------------------------------------------------------------------------------------------
>
> Key: MTOMCAT-76
> URL: http://jira.codehaus.org/browse/MTOMCAT-76
> Project: Maven 2.x Tomcat Plugin
> Issue Type: Improvement
> Affects Versions: 1.1
> Reporter: Ryan Connolly
>
> It is a known limitation that context reloading does not take place with a
> simple compilation in the current project or to a redeployment of a compile
> time dependency.
> As tomcat will scan WEB-INF/classes and WEB-INF/lib for class changes and the
> plugin uses neither of these paths in the classpath, context reloading simply
> does not occur even when context.setReloadable(true) is added and the current
> WebappLoader instance is also set to reloadable.
> It seems more likely that this feature could be achieved by adding a scanner
> (a la jetty-utils' Scanner class or what has been proposed in MTOMCAT-15)
> that will monitor ${build.outputDirectory} and any compile/runtime dependency
> artifacts by default.
> - Quick and dirty: (add jetty-utils dependency and use their Scanner class)
> - Perhaps more correct for project: (figure out how the current scanning
> works and determine whether the Embedded API exposes this functionality or
> not. If not, create a scanner.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
