DO NOT REPLY [Bug 30450] java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
https://issues.apache.org/bugzilla/show_bug.cgi?id=30450 --- Comment #2 from sey yseu...@daum.net 2011-12-21 08:04:49 UTC --- It does not always occur.. very rarely. We use 5.0.28.. I see this bug somedays ago.(In reply to comment #1) I can't reproduce your error using 5.0.28. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Two cents from a side On Tue, Dec 20, 2011 at 11:21 PM, Sylvain Laurent sylvain.laur...@m4x.org wrote: On 20 déc. 2011, at 12:22, Mark Thomas wrote: Where I disagree is on whether a switch to Maven lowers that barrier to entry. I agree it lowers it for folks that already know Maven but don't know Ant but that it raises it for folks that know Ant but don't know Maven. Knowing ant does not mean knowing how to build a particular project. That's the big drawback of ant over maven : there's no convention/standard way of doing things. IMHO knowing maven is worth the investment and can be applied to so many projects that the return on investment is quite quick. whether I run ant release or mvn clean install there is no real difference to a new user, so I'd deny the argument. And in any complex build there are at least as many possibilities to achieve something with mvn as with ant, so standardization of the poms is a myth which mvn tries to sell (To start with something parent and aggregator in one pom or different, aggregator in parent folder or separate folder etc). Having said this, we moved all our projects to mvn about a year ago and we did't regret it. We did mainly because of dependency/publication management (after trying to publish to nexus with ant-ivy for three month) and reproducibility of builds. Together with jenkins/hudson integration it was a total win. /2 cents regards Leon - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 30450] java.lang.ClassNotFoundException: org.apache.jsp.index_jsp
https://issues.apache.org/bugzilla/show_bug.cgi?id=30450 --- Comment #3 from Konstantin Kolinko knst.koli...@gmail.com 2011-12-21 09:11:27 UTC --- (In reply to comment #2) It does not always occur.. very rarely. We use 5.0.28.. I see this bug somedays ago.(In reply to comment #1) I can't reproduce your error using 5.0.28. 5.0.x has been deprecated for several years already. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-110) Support Slf4j bridge logger
[
https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173968#comment-13173968
]
Morten Haraldsen commented on MTOMCAT-110:
--
Hi again, I thought I should simplify your task a bit, and I wrote the
following snippet:
private void installLogger(String loggerName) throws SecurityException,
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,
InvocationTargetException
{
if (slf4j.equals(loggerName))
{
Class? clazz;
try
{
// Check class is available
clazz =
Class.forName(org.slf4j.bridge.SLF4JBridgeHandler, false,
getClass().getClassLoader());
// Remove all JUL handlers
java.util.logging.LogManager.getLogManager().reset();
// Install slf4j bridge handler
final Method method =
clazz.getMethod(install, String.class);
method.invoke(null);
}
catch (ClassNotFoundException e)
{
// TODO: Notify that the class was missing
}
}
else
{
// TODO: Notify unsupported logger type
}
}
Support Slf4j bridge logger
---
Key: MTOMCAT-110
URL: https://issues.apache.org/jira/browse/MTOMCAT-110
Project: Apache Tomcat Maven Plugin
Issue Type: New Feature
Reporter: Morten Haraldsen
Original Estimate: 2h
Remaining Estimate: 2h
As a lot of web-applications use slf4j for logging, it would be nice if you
could support this as a Mojo parameter, like loggingslf4j/logging
This should trigger something like:
java.util.logging.LogManager.getLogManager().reset();
SLF4JBridgeHandler.install();
(requires org.slf4j:jul-to-slf4j on the classpath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Issue Comment Edited] (MTOMCAT-110) Support Slf4j bridge logger
[
https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173968#comment-13173968
]
Morten Haraldsen edited comment on MTOMCAT-110 at 12/21/11 9:27 AM:
Hi again, I thought I should simplify your task a bit, and I wrote the
following snippet:
{code}
private void installLogger(String loggerName) throws SecurityException,
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,
InvocationTargetException
{
if (slf4j.equals(loggerName))
{
Class? clazz;
try
{
// Check class is available
clazz =
Class.forName(org.slf4j.bridge.SLF4JBridgeHandler, false,
getClass().getClassLoader());
// Remove all JUL handlers
java.util.logging.LogManager.getLogManager().reset();
// Install slf4j bridge handler
final Method method =
clazz.getMethod(install, String.class);
method.invoke(null);
}
catch (ClassNotFoundException e)
{
// TODO: Notify that the class was missing
}
}
else
{
// TODO: Notify unsupported logger type
}
}
{code}
was (Author: xaer):
Hi again, I thought I should simplify your task a bit, and I wrote the
following snippet:
private void installLogger(String loggerName) throws SecurityException,
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,
InvocationTargetException
{
if (slf4j.equals(loggerName))
{
Class? clazz;
try
{
// Check class is available
clazz =
Class.forName(org.slf4j.bridge.SLF4JBridgeHandler, false,
getClass().getClassLoader());
// Remove all JUL handlers
java.util.logging.LogManager.getLogManager().reset();
// Install slf4j bridge handler
final Method method =
clazz.getMethod(install, String.class);
method.invoke(null);
}
catch (ClassNotFoundException e)
{
// TODO: Notify that the class was missing
}
}
else
{
// TODO: Notify unsupported logger type
}
}
Support Slf4j bridge logger
---
Key: MTOMCAT-110
URL: https://issues.apache.org/jira/browse/MTOMCAT-110
Project: Apache Tomcat Maven Plugin
Issue Type: New Feature
Reporter: Morten Haraldsen
Original Estimate: 2h
Remaining Estimate: 2h
As a lot of web-applications use slf4j for logging, it would be nice if you
could support this as a Mojo parameter, like loggingslf4j/logging
This should trigger something like:
java.util.logging.LogManager.getLogManager().reset();
SLF4JBridgeHandler.install();
(requires org.slf4j:jul-to-slf4j on the classpath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Issue Comment Edited] (MTOMCAT-110) Support Slf4j bridge logger
[
https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173968#comment-13173968
]
Morten Haraldsen edited comment on MTOMCAT-110 at 12/21/11 9:35 AM:
Hi again, I thought I should simplify your task a bit, and I wrote the
following snippet:
private void installLogger(String loggerName) throws SecurityException,
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,
InvocationTargetException
{
if (slf4j.equals(loggerName))
{
Class? clazz;
try
{
// Check class is available
clazz = Class.forName(org.slf4j.bridge.SLF4JBridgeHandler);
// Remove all JUL handlers
java.util.logging.LogManager.getLogManager().reset();
// Install slf4j bridge handler
final Method method = clazz.getMethod(install, String.class);
method.invoke(null);
}
catch (ClassNotFoundException e)
{
// TODO: Notify that the class was missing
}
}
else
{
// TODO: Notify unsupported logger type
}
}
was (Author: xaer):
Hi again, I thought I should simplify your task a bit, and I wrote the
following snippet:
{code}
private void installLogger(String loggerName) throws SecurityException,
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,
InvocationTargetException
{
if (slf4j.equals(loggerName))
{
Class? clazz;
try
{
// Check class is available
clazz =
Class.forName(org.slf4j.bridge.SLF4JBridgeHandler, false,
getClass().getClassLoader());
// Remove all JUL handlers
java.util.logging.LogManager.getLogManager().reset();
// Install slf4j bridge handler
final Method method =
clazz.getMethod(install, String.class);
method.invoke(null);
}
catch (ClassNotFoundException e)
{
// TODO: Notify that the class was missing
}
}
else
{
// TODO: Notify unsupported logger type
}
}
{code}
Support Slf4j bridge logger
---
Key: MTOMCAT-110
URL: https://issues.apache.org/jira/browse/MTOMCAT-110
Project: Apache Tomcat Maven Plugin
Issue Type: New Feature
Reporter: Morten Haraldsen
Original Estimate: 2h
Remaining Estimate: 2h
As a lot of web-applications use slf4j for logging, it would be nice if you
could support this as a Mojo parameter, like loggingslf4j/logging
This should trigger something like:
java.util.logging.LogManager.getLogManager().reset();
SLF4JBridgeHandler.install();
(requires org.slf4j:jul-to-slf4j on the classpath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project jakarta-tomcat (in module jakarta-tomcat) failed
On 21/12/2011 07:35, Konstantin Kolinko wrote: This is Tomcat 3.3 (jakarta-tomcat-33.xml in Gump). It is odd that this failed. I suspect because the connectors are shared between 3.3.x, 4.1.x and 5.5.x and r1221282 removed the following method: public void setHeaders(MimeHeaders headers) I'll see how much of the the old, unsupported Tomcat stuff (3.3.x, 4.1.x, 5.0.x) I can remove from Gump. Mark 2011/12/21 Stefan Bodewig bode...@apache.org: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project jakarta-tomcat has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 219 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat : Servlet 2.2 and JSP 1.1 Reference Implementation - jakarta-tomcat-coyote-tomcat3 : Connectors to various web servers Full details are available at: http://vmgump.apache.org/gump/public/jakarta-tomcat/jakarta-tomcat/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [tomcat_core.jar] identifier set to output basename: [tomcat_core] -DEBUG- Output [core_util.jar] identifier set to output basename: [core_util] -DEBUG- Output [container_util.jar] identifier set to output basename: [container_util] -DEBUG- Output [tomcat_modules.jar] identifier set to output basename: [tomcat_modules] -DEBUG- Output [tomcat.jar] identifier set to output basename: [tomcat] -DEBUG- Output [tomcat-util.jar] identifier set to output basename: [tomcat-util] -DEBUG- Output [facade22.jar] identifier set to output basename: [facade22] -DEBUG- Output [jasper.jar] identifier set to output basename: [jasper] -DEBUG- Dependency on jakarta-servletapi exists, no need to add for property servlet22.jar. -DEBUG- Dependency on jmx exists, no need to add for property jmxtools.jar. -DEBUG- Dependency on ant exists, no need to add for property ant.home. -DEBUG- Dependency on jsse exists, no need to add for property jsse.home. -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-tomcat/jakarta-tomcat/gump_work/build_jakarta-tomcat_jakarta-tomcat.html Work Name: build_jakarta-tomcat_jakarta-tomcat (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Djakarta-tomcat-connectors=/srv/gump/public/workspace/jakarta-tomcat-connectors -Djtc.coyote.home=/srv/gump/public/workspace/jakarta-tomcat-connectors/coyote -Djaxp.home=/srv/gump/packages/jaxp-1_3 -Dcommons-modeler.jar=/srv/gump/public/workspace/apache-commons/modeler/dist/commons-modeler-21122011.jar -Djmxtools.jar=/srv/gump/packages/jmx-1_2_1-bin/lib/jmxtools.jar -Djmx.jar=/srv/gump/packages/jmx-1_2_1-bin/lib/jmxri.jar -Dtomcat-util.jar=/srv/gump/public/workspace/jakarta-tomcat-connectors/util/build/lib/tomcat-util.jar -Dant.ho me=/ srv/gump/public/workspace/ant/dist -Dservlet22.jar=/srv/gump/public/workspace/jakarta-servletapi/dist/lib/servlet.jar -Dtomcat-jk.home=/srv/gump/public/workspace/tomcat-connectors-native -Dcommons-logging.jar=/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-21122011.jar -Djtc.http11.home=/srv/gump/public/workspace/jakarta-tomcat-connectors/http11/build -Djsse.home=/srv/gump/packages/jsse1.0.3 tomcat [Working Directory: /srv/gump/public/workspace/jakarta-tomcat] CLASSPATH:
[jira] [Commented] (MTOMCAT-110) Support Slf4j bridge logger
[ https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174031#comment-13174031 ] Olivier Lamy commented on MTOMCAT-110: -- lovely :-) But from where parameter loggerName comes ? IMHO a cli option ? Support Slf4j bridge logger --- Key: MTOMCAT-110 URL: https://issues.apache.org/jira/browse/MTOMCAT-110 Project: Apache Tomcat Maven Plugin Issue Type: New Feature Reporter: Morten Haraldsen Original Estimate: 2h Remaining Estimate: 2h As a lot of web-applications use slf4j for logging, it would be nice if you could support this as a Mojo parameter, like loggingslf4j/logging This should trigger something like: java.util.logging.LogManager.getLogManager().reset(); SLF4JBridgeHandler.install(); (requires org.slf4j:jul-to-slf4j on the classpath) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GUMP@vmgump]: Project jakarta-tomcat (in module jakarta-tomcat) failed
2011/12/21 Mark Thomas ma...@apache.org: On 21/12/2011 07:35, Konstantin Kolinko wrote: This is Tomcat 3.3 (jakarta-tomcat-33.xml in Gump). It is odd that this failed. I suspect because the connectors are shared between 3.3.x, 4.1.x and 5.5.x and r1221282 removed the following method: public void setHeaders(MimeHeaders headers) 1. Looking at http://svn.apache.org/repos/asf/tomcat/archive/tc3.3.x/trunk there is svn:externals property there: connectors https://svn.apache.org/repos/asf/tomcat/connectors/trunk That external points to location that currently does not exist. I would say that it is better to replace it with a copy from the last 3.3.2 tag. (Or add a peg revision to the external, but I do not see a point in having an external there). 2. Here is an answer on what happened in Gump: In jakarta-tomcat-33.xml it says svn repository=asf dir=tomcat/archive/tc3.3.x/trunk/container / so it does not download connectors. The connectors are built separately and it uses them as a dependency: It is jakarta-tomcat-connectors.xml with svn repository=asf dir=tomcat/tc5.5.x/trunk/connectors / I'll see how much of the the old, unsupported Tomcat stuff (3.3.x, 4.1.x, 5.0.x) I can remove from Gump. Good. For starters, from [1] - Project Dependees the following two projects depend on jakarta-tomcat (aka Tomcat 3.3): * commons-jcs * jakarta-tomcat-coyote-tomcat3 [1] http://vmgump.apache.org/gump/public/jakarta-tomcat/jakarta-tomcat/details.html Best regards, Konstantin Kolinko 2011/12/21 Stefan Bodewig bode...@apache.org: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project jakarta-tomcat has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 219 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat : Servlet 2.2 and JSP 1.1 Reference Implementation - jakarta-tomcat-coyote-tomcat3 : Connectors to various web servers Full details are available at: http://vmgump.apache.org/gump/public/jakarta-tomcat/jakarta-tomcat/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [tomcat_core.jar] identifier set to output basename: [tomcat_core] -DEBUG- Output [core_util.jar] identifier set to output basename: [core_util] -DEBUG- Output [container_util.jar] identifier set to output basename: [container_util] -DEBUG- Output [tomcat_modules.jar] identifier set to output basename: [tomcat_modules] -DEBUG- Output [tomcat.jar] identifier set to output basename: [tomcat] -DEBUG- Output [tomcat-util.jar] identifier set to output basename: [tomcat-util] -DEBUG- Output [facade22.jar] identifier set to output basename: [facade22] -DEBUG- Output [jasper.jar] identifier set to output basename: [jasper] -DEBUG- Dependency on jakarta-servletapi exists, no need to add for property servlet22.jar. -DEBUG- Dependency on jmx exists, no need to add for property jmxtools.jar. -DEBUG- Dependency on ant exists, no need to add for property ant.home. -DEBUG- Dependency on jsse exists, no need to add for property jsse.home. -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-tomcat/jakarta-tomcat/gump_work/build_jakarta-tomcat_jakarta-tomcat.html Work Name: build_jakarta-tomcat_jakarta-tomcat (Type: Build) Work ended in a state of : Failed (...) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-110) Support Slf4j bridge logger
[ https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174088#comment-13174088 ] Morten Haraldsen commented on MTOMCAT-110: -- Yes, something like: -logger slf4j Support Slf4j bridge logger --- Key: MTOMCAT-110 URL: https://issues.apache.org/jira/browse/MTOMCAT-110 Project: Apache Tomcat Maven Plugin Issue Type: New Feature Reporter: Morten Haraldsen Original Estimate: 2h Remaining Estimate: 2h As a lot of web-applications use slf4j for logging, it would be nice if you could support this as a Mojo parameter, like loggingslf4j/logging This should trigger something like: java.util.logging.LogManager.getLogManager().reset(); SLF4JBridgeHandler.install(); (requires org.slf4j:jul-to-slf4j on the classpath) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Issue Comment Edited] (MTOMCAT-110) Support Slf4j bridge logger
[
https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174088#comment-13174088
]
Morten Haraldsen edited comment on MTOMCAT-110 at 12/21/11 1:28 PM:
Yes, something like:
-logger slf4j
Edit: Btw, no reason to not move the clazz variable inside the try/catch like
final Class? clazz = ...
PS: Could we have {code} tags turned on?
was (Author: xaer):
Yes, something like:
-logger slf4j
Support Slf4j bridge logger
---
Key: MTOMCAT-110
URL: https://issues.apache.org/jira/browse/MTOMCAT-110
Project: Apache Tomcat Maven Plugin
Issue Type: New Feature
Reporter: Morten Haraldsen
Original Estimate: 2h
Remaining Estimate: 2h
As a lot of web-applications use slf4j for logging, it would be nice if you
could support this as a Mojo parameter, like loggingslf4j/logging
This should trigger something like:
java.util.logging.LogManager.getLogManager().reset();
SLF4JBridgeHandler.install();
(requires org.slf4j:jul-to-slf4j on the classpath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Issue Comment Edited] (MTOMCAT-110) Support Slf4j bridge logger
[
https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173968#comment-13173968
]
Morten Haraldsen edited comment on MTOMCAT-110 at 12/21/11 1:29 PM:
Hi again, I thought I should simplify your task a bit, and I wrote the
following snippet:
private void installLogger(String loggerName) throws SecurityException,
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,
InvocationTargetException
{
if (slf4j.equals(loggerName))
{
try
{
// Check class is available
final Class? clazz =
Class.forName(org.slf4j.bridge.SLF4JBridgeHandler);
// Remove all JUL handlers
java.util.logging.LogManager.getLogManager().reset();
// Install slf4j bridge handler
final Method method = clazz.getMethod(install, null);
method.invoke(null);
}
catch (ClassNotFoundException e)
{
// TODO: Notify that the class was missing
}
}
else
{
// TODO: Notify unsupported logger type
}
}
was (Author: xaer):
Hi again, I thought I should simplify your task a bit, and I wrote the
following snippet:
private void installLogger(String loggerName) throws SecurityException,
NoSuchMethodException, IllegalArgumentException, IllegalAccessException,
InvocationTargetException
{
if (slf4j.equals(loggerName))
{
Class? clazz;
try
{
// Check class is available
clazz = Class.forName(org.slf4j.bridge.SLF4JBridgeHandler);
// Remove all JUL handlers
java.util.logging.LogManager.getLogManager().reset();
// Install slf4j bridge handler
final Method method = clazz.getMethod(install, String.class);
method.invoke(null);
}
catch (ClassNotFoundException e)
{
// TODO: Notify that the class was missing
}
}
else
{
// TODO: Notify unsupported logger type
}
}
Support Slf4j bridge logger
---
Key: MTOMCAT-110
URL: https://issues.apache.org/jira/browse/MTOMCAT-110
Project: Apache Tomcat Maven Plugin
Issue Type: New Feature
Reporter: Morten Haraldsen
Original Estimate: 2h
Remaining Estimate: 2h
As a lot of web-applications use slf4j for logging, it would be nice if you
could support this as a Mojo parameter, like loggingslf4j/logging
This should trigger something like:
java.util.logging.LogManager.getLogManager().reset();
SLF4JBridgeHandler.install();
(requires org.slf4j:jul-to-slf4j on the classpath)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1221719 - in /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner: Tomcat7Runner.java Tomcat7RunnerCli.java
Author: olamy
Date: Wed Dec 21 13:34:54 2011
New Revision: 1221719
URL: http://svn.apache.org/viewvc?rev=1221719view=rev
Log:
[MTOMCAT-111] Make extract directory configurable
Modified:
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
Modified:
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java?rev=1221719r1=1221718r2=1221719view=diff
==
---
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
(original)
+++
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
Wed Dec 21 13:34:54 2011
@@ -77,13 +77,15 @@ public class Tomcat7Runner
public boolean debug = false;
- public boolean clientAuth = false;
-
- public String keyAlias = null;
+public boolean clientAuth = false;
+
+public String keyAlias = null;
public String httpProtocol;
-public File extractDirectory = new File( .extract );
+public String extractDirectory = .extract;
+
+public File extractDirectoryFile;
Catalina container;
@@ -103,8 +105,21 @@ public class Tomcat7Runner
throws Exception
{
- PasswordUtil.deobfuscateSystemProps();
-
+PasswordUtil.deobfuscateSystemProps();
+
+this.extractDirectoryFile = new File( this.extractDirectory );
+if ( !this.extractDirectoryFile.exists() )
+{
+boolean create = this.extractDirectoryFile.mkdirs();
+if ( !create )
+{
+System.out.println( FATAL: impossible to create directory: +
this.extractDirectoryFile.getPath() );
+System.exit( 1 );
+}
+}
+
+debugMessage( use extractDirectory: + extractDirectoryFile.getPath()
);
+
// do we have to extract content
if ( !new File( .extract ).exists() || resetExtract )
{
@@ -126,8 +141,8 @@ public class Tomcat7Runner
System.setProperty( java.io.tmpdir, tmpDir.getAbsolutePath() );
-System.setProperty( catalina.base,
extractDirectory.getAbsolutePath() );
-System.setProperty( catalina.home,
extractDirectory.getAbsolutePath() );
+System.setProperty( catalina.base,
extractDirectoryFile.getAbsolutePath() );
+System.setProperty( catalina.home,
extractDirectoryFile.getAbsolutePath() );
// start with a server.xml
if ( serverXmlPath != null || useServerXml() )
@@ -165,21 +180,21 @@ public class Tomcat7Runner
debugMessage( use connectorHttpProtocol: + connectorHttpProtocol
);
- if (httpPort 0)
- {
- Connector connector = new Connector( connectorHttpProtocol
);
- connector.setPort( httpPort );
-
- if ( httpsPort 0 )
- {
- connector.setRedirectPort( httpsPort );
- }
- // FIXME parameter for that def ? ISO-8859-1
- //connector.setURIEncoding(uriEncoding);
+if ( httpPort 0 )
+{
+Connector connector = new Connector( connectorHttpProtocol );
+connector.setPort( httpPort );
- tomcat.getService().addConnector( connector );
+if ( httpsPort 0 )
+{
+connector.setRedirectPort( httpsPort );
+}
+// FIXME parameter for that def ? ISO-8859-1
+//connector.setURIEncoding(uriEncoding);
+
+tomcat.getService().addConnector( connector );
- tomcat.setConnector( connector );
+tomcat.setConnector( connector );
}
// add a default acces log valve
@@ -193,43 +208,46 @@ public class Tomcat7Runner
{
Connector httpsConnector = new Connector(
connectorHttpProtocol );
httpsConnector.setPort( httpsPort );
-httpsConnector.setSecure(true);
-httpsConnector.setProperty(SSLEnabled, true);
-httpsConnector.setProperty(sslProtocol, TLS);
-
-String keystoreFile =
System.getProperty(javax.net.ssl.keyStore);
-String keystorePass =
System.getProperty(javax.net.ssl.keyStorePassword);
-String keystoreType =
System.getProperty(javax.net.ssl.keyStoreType, jks);
-
+httpsConnector.setSecure( true );
+
svn commit: r1221720 - /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
Author: olamy Date: Wed Dec 21 13:35:07 2011 New Revision: 1221720 URL: http://svn.apache.org/viewvc?rev=1221720view=rev Log: document default value .extract Modified: tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java Modified: tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java URL: http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java?rev=1221720r1=1221719r2=1221720view=diff == --- tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java (original) +++ tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java Wed Dec 21 13:35:07 2011 @@ -82,7 +82,7 @@ public class Tomcat7RunnerCli http protocol to use: HTTP/1.1 or org.apache.coyote.http11.Http11NioProtocol ).create( httpProtocol ); static Option extractDirectory = OptionBuilder.withArgName( extractDirectory ).hasArg().withDescription( -path to extract war content ).create( extractDirectory ); +path to extract war content default value .extract ).create( extractDirectory ); static Options options = new Options(); - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1221721 - /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
Author: olamy
Date: Wed Dec 21 13:35:20 2011
New Revision: 1221721
URL: http://svn.apache.org/viewvc?rev=1221721view=rev
Log:
fix test on hardcoded .extract as now it's a configurable value tru cli
Modified:
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
Modified:
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java?rev=1221721r1=1221720r2=1221721view=diff
==
---
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
(original)
+++
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
Wed Dec 21 13:35:20 2011
@@ -108,20 +108,11 @@ public class Tomcat7Runner
PasswordUtil.deobfuscateSystemProps();
this.extractDirectoryFile = new File( this.extractDirectory );
-if ( !this.extractDirectoryFile.exists() )
-{
-boolean create = this.extractDirectoryFile.mkdirs();
-if ( !create )
-{
-System.out.println( FATAL: impossible to create directory: +
this.extractDirectoryFile.getPath() );
-System.exit( 1 );
-}
-}
debugMessage( use extractDirectory: + extractDirectoryFile.getPath()
);
// do we have to extract content
-if ( !new File( .extract ).exists() || resetExtract )
+if ( !extractDirectoryFile.exists() || resetExtract )
{
extract();
}
@@ -293,7 +284,9 @@ public class Tomcat7Runner
InputStream inputStream = null;
try
{
-URL url = new URL( jar:file: + warPath +
!/META-INF/context.xml );
+String urlStr = jar:file: + warPath + !/META-INF/context.xml;
+debugMessage( search context.xml in url:' + urlStr + ' );
+URL url = new URL( urlStr );
inputStream = url.openConnection().getInputStream();
if ( inputStream != null )
{
@@ -352,8 +345,24 @@ public class Tomcat7Runner
FileUtils.deleteDirectory( extractDirectoryFile );
}
+if ( !this.extractDirectoryFile.exists() )
+{
+boolean created = this.extractDirectoryFile.mkdirs();
+if ( !created )
+{
+System.out.println( FATAL: impossible to create directory: +
this.extractDirectoryFile.getPath() );
+System.exit( 1 );
+}
+}
+
// ensure webapp dir is here
-new File( extractDirectory, webapps ).mkdirs();
+boolean created = new File( extractDirectory, webapps ).mkdirs();
+if ( !created )
+{
+System.out.println(
+FATAL: impossible to create directory: +
this.extractDirectoryFile.getPath() + /webapps );
+System.exit( 1 );
+}
String wars = runtimeProperties.getProperty( WARS_KEY );
populateWebAppWarPerContext( wars );
@@ -369,15 +378,21 @@ public class Tomcat7Runner
{
if ( entry.getKey().equals( / ) )
{
-expand( inputStream, new File( extractDirectory,
webapps/ROOT.war ) );
+File expandFile = new File( extractDirectory,
webapps/ROOT.war );
+debugMessage( expand to file: + expandFile.getPath()
);
+expand( inputStream, expandFile );
}
else
{
-expand( inputStream, new File( extractDirectory,
webapps/ + entry.getValue() ) );
+File expandFile = new File( extractDirectory,
webapps/ + entry.getValue() );
+debugMessage( expand to file: + expandFile.getPath()
);
+expand( inputStream, expandFile );
}
}
else
{
+File expandFile = new File( extractDirectory, webapps/ +
entry.getValue() );
+debugMessage( expand to file: + expandFile.getPath() );
expand( inputStream, new File( extractDirectory,
webapps/ + entry.getValue() ) );
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Closed] (MTOMCAT-111) Make extract directory configurable
[ https://issues.apache.org/jira/browse/MTOMCAT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MTOMCAT-111. Resolution: Fixed done. please test with last SNAPSHOT. Make extract directory configurable --- Key: MTOMCAT-111 URL: https://issues.apache.org/jira/browse/MTOMCAT-111 Project: Apache Tomcat Maven Plugin Issue Type: Improvement Components: tomcat7 Reporter: Morten Haraldsen Assignee: Olivier Lamy Fix For: 2.0 Original Estimate: 1h Remaining Estimate: 1h If one is launching the application bundled as an executable jar/war, it would be nice not to have to be in the directory you want to extract the war file. Now you have Tomcat7Runner.java:86: public File extractDirectory = new File( .extract ); Could you make this an option like -extractDirectory when launching? Thanks again! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-111) Make extract directory configurable
[ https://issues.apache.org/jira/browse/MTOMCAT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174092#comment-13174092 ] Hudson commented on MTOMCAT-111: Integrated in TomcatMavenPlugin #76 (See [https://builds.apache.org/job/TomcatMavenPlugin/76/]) [MTOMCAT-111] Make extract directory configurable olamy : http://svn.apache.org/viewvc/?view=revrev=1221719 Files : * /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java * /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java Make extract directory configurable --- Key: MTOMCAT-111 URL: https://issues.apache.org/jira/browse/MTOMCAT-111 Project: Apache Tomcat Maven Plugin Issue Type: Improvement Components: tomcat7 Reporter: Morten Haraldsen Assignee: Olivier Lamy Fix For: 2.0 Original Estimate: 1h Remaining Estimate: 1h If one is launching the application bundled as an executable jar/war, it would be nice not to have to be in the directory you want to extract the war file. Now you have Tomcat7Runner.java:86: public File extractDirectory = new File( .extract ); Could you make this an option like -extractDirectory when launching? Thanks again! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52380] New: com.businessobjects.wp.om.OMReportElementContainer (Error: INF)
https://issues.apache.org/bugzilla/show_bug.cgi?id=52380 Bug #: 52380 Summary: com.businessobjects.wp.om.OMReportElementContainer (Error: INF) Product: Tomcat 5 Version: 5.5.20 Platform: PC OS/Version: Windows Server 2003 Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: jason.roc...@sap.com Classification: Unclassified Created attachment 28095 -- https://issues.apache.org/bugzilla/attachment.cgi?id=28095 tomcat error log After restarting Tomcat Uses are unable to login to a web application com.businessobjects.wp.om.OMReportElementContainer (Error: INF) The web application is Business Objects Enterprise This is resolved by restarting Tomcat several times until the login works. It appears the issue is caused by Tomcat serializing the session. When Tomcat is stoped and restarted or application server reload is triggered, the standard Manager implementation will attempt to serialize all currently active sessions to a disk file located via the pathname attribute.All such saved sessions will then be de-serialized and activated when the applications server reload is completed. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1221816 - in /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner: Tomcat7Runner.java Tomcat7RunnerCli.java
Author: olamy
Date: Wed Dec 21 17:23:03 2011
New Revision: 1221816
URL: http://svn.apache.org/viewvc?rev=1221816view=rev
Log:
[MTOMCAT-110] Support Slf4j bridge logger.
Modified:
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
Modified:
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java?rev=1221816r1=1221815r2=1221816view=diff
==
---
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
(original)
+++
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java
Wed Dec 21 17:23:03 2011
@@ -32,6 +32,8 @@ import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
import java.net.URL;
import java.util.HashMap;
import java.util.Map;
@@ -87,6 +89,8 @@ public class Tomcat7Runner
public File extractDirectoryFile;
+public String loggerName;
+
Catalina container;
Tomcat tomcat;
@@ -107,6 +111,11 @@ public class Tomcat7Runner
PasswordUtil.deobfuscateSystemProps();
+if ( loggerName != null loggerName.length() 0 )
+{
+installLogger( loggerName );
+}
+
this.extractDirectoryFile = new File( this.extractDirectory );
debugMessage( use extractDirectory: + extractDirectoryFile.getPath()
);
@@ -533,4 +542,34 @@ public class Tomcat7Runner
{
return Boolean.parseBoolean( runtimeProperties.getProperty(
ENABLE_NAMING_KEY, Boolean.FALSE.toString() ) );
}
+
+private void installLogger( String loggerName )
+throws SecurityException, NoSuchMethodException,
IllegalArgumentException, IllegalAccessException,
+InvocationTargetException
+{
+if ( slf4j.equals( loggerName ) )
+{
+
+try
+{
+// Check class is available
+final Class? clazz = Class.forName(
org.slf4j.bridge.SLF4JBridgeHandler );
+
+// Remove all JUL handlers
+java.util.logging.LogManager.getLogManager().reset();
+
+// Install slf4j bridge handler
+final Method method = clazz.getMethod( install, null );
+method.invoke( null );
+}
+catch ( ClassNotFoundException e )
+{
+System.out.println( WARNING: issue configuring slf4j jul
bridge, skip it );
+}
+}
+else
+{
+System.out.println( WARNING: loggerName + loggerName + not
supported, skip it );
+}
+}
}
Modified:
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java?rev=1221816r1=1221815r2=1221816view=diff
==
---
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
(original)
+++
tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java
Wed Dec 21 17:23:03 2011
@@ -84,6 +84,9 @@ public class Tomcat7RunnerCli
static Option extractDirectory = OptionBuilder.withArgName(
extractDirectory ).hasArg().withDescription(
path to extract war content default value .extract ).create(
extractDirectory );
+static Option loggerName = OptionBuilder.withArgName( loggerName
).hasArg().withDescription(
+logger to use: slf4j to use slf4j bridge on top of jul ).create(
loggerName );
+
static Options options = new Options();
@@ -92,7 +95,7 @@ public class Tomcat7RunnerCli
options.addOption( httpPort ).addOption( httpsPort ).addOption(
ajpPort ).addOption( serverXmlPath ).addOption(
resetExtract ).addOption( help ).addOption( debug ).addOption(
sysProps ).addOption(
httpProtocol ).addOption( clientAuth ).addOption( keyAlias
).addOption( obfuscate ).addOption(
-extractDirectory );
+extractDirectory ).addOption( loggerName );
}
@@ -185,6 +188,11 @@ public class Tomcat7RunnerCli
tomcat7Runner.extractDirectory = line.getOptionValue(
extractDirectory.getOpt() );
}
+if ( line.hasOption( loggerName.getOpt()
svn commit: r1221817 - in /tomcat/maven-plugin/trunk: ./ tomcat7-maven-plugin/ tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/
Author: olamy
Date: Wed Dec 21 17:23:22 2011
New Revision: 1221817
URL: http://svn.apache.org/viewvc?rev=1221817view=rev
Log:
feature to add extra resources in the exec war: log4j configuration files
Added:
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/ExtraResource.java
(with props)
Modified:
tomcat/maven-plugin/trunk/pom.xml
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/pom.xml
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
Modified: tomcat/maven-plugin/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/pom.xml?rev=1221817r1=1221816r2=1221817view=diff
==
--- tomcat/maven-plugin/trunk/pom.xml (original)
+++ tomcat/maven-plugin/trunk/pom.xml Wed Dec 21 17:23:22 2011
@@ -413,7 +413,7 @@
dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-utils/artifactId
-version1.0.4/version
+version3.0/version
/dependency
dependency
groupIdcommons-codec/groupId
Modified: tomcat/maven-plugin/trunk/tomcat7-maven-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/pom.xml?rev=1221817r1=1221816r2=1221817view=diff
==
--- tomcat/maven-plugin/trunk/tomcat7-maven-plugin/pom.xml (original)
+++ tomcat/maven-plugin/trunk/tomcat7-maven-plugin/pom.xml Wed Dec 21 17:23:22
2011
@@ -186,6 +186,11 @@
/dependency
dependency
+ groupIdorg.codehaus.plexus/groupId
+ artifactIdplexus-utils/artifactId
+/dependency
+
+dependency
groupIdorg.apache.tomcat.maven/groupId
artifactIdtomcat-maven-plugin-it/artifactId
scopetest/scope
Modified:
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
URL:
http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java?rev=1221817r1=1221816r2=1221817view=diff
==
---
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
(original)
+++
tomcat/maven-plugin/trunk/tomcat7-maven-plugin/src/main/java/org/apache/tomcat/maven/plugin/tomcat7/run/AbstractExecWarMojo.java
Wed Dec 21 17:23:22 2011
@@ -41,6 +41,7 @@ import org.apache.tomcat.maven.runner.To
import org.apache.tomcat.maven.runner.Tomcat7RunnerCli;
import org.codehaus.plexus.archiver.jar.Manifest;
import org.codehaus.plexus.archiver.jar.ManifestException;
+import org.codehaus.plexus.util.DirectoryScanner;
import java.io.File;
import java.io.FileInputStream;
@@ -49,7 +50,9 @@ import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.PrintWriter;
+import java.util.ArrayList;
import java.util.Enumeration;
+import java.util.Iterator;
import java.util.List;
import java.util.Properties;
import java.util.jar.JarEntry;
@@ -212,6 +215,13 @@ public abstract class AbstractExecWarMoj
private ListExtraDependency extraDependencies;
/**
+ * list of extra resources to add in the standalone tomcat jar: your
logger configuration etc
+ *
+ * @parameter
+ */
+private ListExtraResource extraResources;
+
+/**
* Main class to use for starting the standalone jar.
*
* @parameter expression=${maven.tomcat.exec.war.mainClass}
default-value=org.apache.tomcat.maven.runner.Tomcat7RunnerCli
@@ -221,6 +231,7 @@ public abstract class AbstractExecWarMoj
/**
* which connector protocol to use HTTP/1.1 or
org.apache.coyote.http11.Http11NioProtocol
+ *
* @parameter expression=${maven.tomcat.exec.war.connectorHttpProtocol}
default-value=HTTP/1.1
* @required
*/
@@ -431,6 +442,29 @@ public abstract class AbstractExecWarMoj
projectHelper.attachArtifact( project,
attachArtifactClassifierType, attachArtifactClassifier,
execWarJar );
}
+
+if ( extraResources != null )
+{
+for ( ExtraResource extraResource : extraResources )
+{
+
+DirectoryScanner directoryScanner = new DirectoryScanner();
+directoryScanner.setBasedir( extraResource.getDirectory()
);
+directoryScanner.addDefaultExcludes();
+directoryScanner.setExcludes( toStringArray(
extraResource.getExcludes() ) );
+directoryScanner.setIncludes( toStringArray(
extraResource.getIncludes() ) );
+directoryScanner.scan();
+
[jira] [Closed] (MTOMCAT-110) Support Slf4j bridge logger
[ https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MTOMCAT-110. Resolution: Fixed Fix Version/s: 2.0 Assignee: Olivier Lamy committed. please try last SNAPSHOT. note you must add various slf4j files in extraDependencies section to have those included in root class loader. Support Slf4j bridge logger --- Key: MTOMCAT-110 URL: https://issues.apache.org/jira/browse/MTOMCAT-110 Project: Apache Tomcat Maven Plugin Issue Type: New Feature Reporter: Morten Haraldsen Assignee: Olivier Lamy Fix For: 2.0 Original Estimate: 2h Remaining Estimate: 2h As a lot of web-applications use slf4j for logging, it would be nice if you could support this as a Mojo parameter, like loggingslf4j/logging This should trigger something like: java.util.logging.LogManager.getLogManager().reset(); SLF4JBridgeHandler.install(); (requires org.slf4j:jul-to-slf4j on the classpath) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-110) Support Slf4j bridge logger
[ https://issues.apache.org/jira/browse/MTOMCAT-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174238#comment-13174238 ] Hudson commented on MTOMCAT-110: Integrated in TomcatMavenPlugin #77 (See [https://builds.apache.org/job/TomcatMavenPlugin/77/]) [MTOMCAT-110] Support Slf4j bridge logger. olamy : http://svn.apache.org/viewvc/?view=revrev=1221816 Files : * /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7Runner.java * /tomcat/maven-plugin/trunk/tomcat7-war-runner/src/main/java/org/apache/tomcat/maven/runner/Tomcat7RunnerCli.java Support Slf4j bridge logger --- Key: MTOMCAT-110 URL: https://issues.apache.org/jira/browse/MTOMCAT-110 Project: Apache Tomcat Maven Plugin Issue Type: New Feature Reporter: Morten Haraldsen Assignee: Olivier Lamy Fix For: 2.0 Original Estimate: 2h Remaining Estimate: 2h As a lot of web-applications use slf4j for logging, it would be nice if you could support this as a Mojo parameter, like loggingslf4j/logging This should trigger something like: java.util.logging.LogManager.getLogManager().reset(); SLF4JBridgeHandler.install(); (requires org.slf4j:jul-to-slf4j on the classpath) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Discussion]Problem passing parameters to a Method ( Looking for incorrect argument Type )
I'm just following up on this issue as I did not see any responses from the
community. Can anyone help out here?
(See attached file: JSF20EL.war)
Instructions for reproducing this issue are in the previous email attached
below.
Thanks for your time and help,
Regards,
Paul Nicolucci
__
Hello All,
After The following update to the EL:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51177 I am having a
problem when getting values from the RequestParameterMap and sending them
to a method using the EL. For example:
Page1 - use f:param to set some query string parameters:
h:form id=form1 prependId=false
h:outputScript name=jsf.js library=javax.faces
target=head /
h:commandButton id=button1 value=AddMessage
action=#{elOperator.addFacesMessage}/
br/
br/
h:link id=link1 outcome=ELMethodExpression2 value=Link with
Parameters
f:param name=param1 value=param1/
f:param name=param2 value=param2/
/h:link
h:messages/
/h:form
Navigates to Page2:
Page2 - access param1,param2 from param (RequestParameterMap) and send them
to a bean method as arguments:
h:form id=form1 prependId=false
h:outputScript name=jsf.js library=javax.faces
target=head /
!-- Test method expressions while passing parameters --
h:outputText id=out1
value=#{elOperator.generateStringWithParameters
(param.param1,param.param2)}/
/h:form
Bean Method:
public String generateStringWithParameters(String param1, String param2) {
return (param1 + : + param2);
}
When we try to call elOperator.generateStringWithParameters
(param.param1,param.param2) I'm getting the following exception:
javax.faces.FacesException: java.lang.NoSuchMethodException:
com.ibm.ws.jsf.beans.ELOperatorBean.generateStringWithParameters
(java.lang.Object, java.lang.Object)
at
org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.wrap
(ExceptionHandlerImpl.java:241)
at
org.apache.myfaces.shared_impl.context.ExceptionHandlerImpl.handle
(ExceptionHandlerImpl.java:156)
at org.apache.myfaces.lifecycle.LifecycleImpl.render
(LifecycleImpl.java:258)
at javax.faces.webapp.FacesServlet.service
(FacesServlet.java:191)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service
(ServletWrapper.java:1188)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest
(ServletWrapper.java:763)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest
(ServletWrapper.java:454)
at
com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest
(ServletWrapperImpl.java:178)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters
(WebAppFilterManager.java:1020)
at
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest
(CacheServletWrapper.java:87)
at com.ibm.ws.webcontainer.WebContainer.handleRequest
(WebContainer.java:895)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest
(WSWebContainer.java:1662)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready
(WCChannelLink.java:195)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination
(HttpInboundLink.java:452)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest
(HttpInboundLink.java:511)
at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest
(HttpInboundLink.java:305)
at
com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete
(HttpICLReadCallback.java:83)
at
com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted
(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback
(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions
(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed
(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete
(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop
(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run
(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1659)
Caused by: java.lang.NoSuchMethodException:
com.ibm.ws.jsf.beans.ELOperatorBean.generateStringWithParameters
(java.lang.Object, java.lang.Object)
at java.lang.Class.throwNoSuchMethodException(Class.java:282)
at java.lang.Class.getMethod(Class.java:853)
at javax.el.BeanELResolver.invoke(BeanELResolver.java:406)
at javax.el.CompositeELResolver.invoke
(CompositeELResolver.java:137)
at
DO NOT REPLY [Bug 52380] com.businessobjects.wp.om.OMReportElementContainer (Error: INF)
https://issues.apache.org/bugzilla/show_bug.cgi?id=52380 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mark Thomas ma...@apache.org 2011-12-21 18:08:37 UTC --- Bugzilla is not a support forum. Please use the Tomcat users mailing list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52380] com.businessobjects.wp.om.OMReportElementContainer (Error: INF)
https://issues.apache.org/bugzilla/show_bug.cgi?id=52380 Mark Thomas ma...@apache.org changed: What|Removed |Added Resolution|FIXED |INVALID -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing process for JARs for Maven Central
There hasn't been any activity on this thread for a little while. I don't recall any significant arguments one way or the other for using Nexus or scp+rsync. Since Jean-Frederic has switched all the Maven artifact release scripts to use Nexus, I intend to do the following: - See what happens when I try and do the next Tomcat 7 release using Nexus - Fix anything that doesn't work - Review the ease of use of scp+rsync and Nexus and if there are issues, complexities etc with Nexus switch back to scp+rsync otherwise stick with Nexus Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-108) THe httpsPort flag starts another http thread not an https thread
[ https://issues.apache.org/jira/browse/MTOMCAT-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174289#comment-13174289 ] Brad Giaccio commented on MTOMCAT-108: -- @Keith what Repository are you looking in https://repository.apache.org/content/groups/snapshots-group/org/apache/tomcat/maven/tomcat7-war-runner/2.0-SNAPSHOT/ The files from Tue Dec 20 00:16:29 UTC 2011, the ones after that (i.e Today) appear to have fixes for MTOMCAT-110 and MTOMCAT-111 as well THe httpsPort flag starts another http thread not an https thread - Key: MTOMCAT-108 URL: https://issues.apache.org/jira/browse/MTOMCAT-108 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: MAc OSX 10.6.8 Reporter: Keith Corbin Assignee: Olivier Lamy Fix For: 2.0 Attachments: https.patch, https.patch WHen you run the executable war the httpsPort flag starts an http protocol listener thread on the port listed not an https protocol listener. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-108) THe httpsPort flag starts another http thread not an https thread
[ https://issues.apache.org/jira/browse/MTOMCAT-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174300#comment-13174300 ] Olivier Lamy commented on MTOMCAT-108: -- http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html says https://repository.apache.org/content/groups/snapshots-group THe httpsPort flag starts another http thread not an https thread - Key: MTOMCAT-108 URL: https://issues.apache.org/jira/browse/MTOMCAT-108 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: MAc OSX 10.6.8 Reporter: Keith Corbin Assignee: Olivier Lamy Fix For: 2.0 Attachments: https.patch, https.patch WHen you run the executable war the httpsPort flag starts an http protocol listener thread on the port listed not an https protocol listener. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1221841 - /tomcat/trunk/.gitignore
Author: markt Date: Wed Dec 21 19:25:03 2011 New Revision: 1221841 URL: http://svn.apache.org/viewvc?rev=1221841view=rev Log: Ignore a couple of plug-in config files Modified: tomcat/trunk/.gitignore Modified: tomcat/trunk/.gitignore URL: http://svn.apache.org/viewvc/tomcat/trunk/.gitignore?rev=1221841r1=1221840r2=1221841view=diff == --- tomcat/trunk/.gitignore (original) +++ tomcat/trunk/.gitignore Wed Dec 21 19:25:03 2011 @@ -19,7 +19,9 @@ logs work build.properties mvn.properties +.checkstyle .classpath +.fbprefs .project .settings *.iml - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1221842 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Wed Dec 21 19:25:43 2011
New Revision: 1221842
URL: http://svn.apache.org/viewvc?rev=1221842view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52293
Correctly handle Context.antiResourceLocking when HOst.unpackWARs=false
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1221842r1=1221841r2=1221842view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Wed Dec 21
19:25:43 2011
@@ -742,8 +742,7 @@ public class ContextConfig
docBase = cn.getBaseName();
File file = null;
-if (docBase.toLowerCase(Locale.ENGLISH).endsWith(.war)) {
-// TODO - This is never executed. Bug or code to delete?
+if (originalDocBase.toLowerCase(Locale.ENGLISH).endsWith(.war)) {
file = new File(System.getProperty(java.io.tmpdir),
deploymentCount++ + - + docBase + .war);
} else {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1221845 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/ContextConfig.java webapps/docs/changelog.xml
Author: markt Date: Wed Dec 21 19:29:08 2011 New Revision: 1221845 URL: http://svn.apache.org/viewvc?rev=1221845view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52293 Correctly handle the case when antiResourceLocking is enabled at the Context level when unpackWARs is disabled at the Host level. Based on a patch by Justin Miller. Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Dec 21 19:29:08 2011 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187381,1187 753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1201931,1 202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038
DO NOT REPLY [Bug 52293] antiResourceLocking and unpackWARs
https://issues.apache.org/bugzilla/show_bug.cgi?id=52293 --- Comment #6 from Mark Thomas ma...@apache.org 2011-12-21 19:29:10 UTC --- Fixed in trunk and will be included in 7.0.24 onwards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1221846 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Wed Dec 21 19:31:38 2011 New Revision: 1221846 URL: http://svn.apache.org/viewvc?rev=1221846view=rev Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1221846r1=1221845r2=1221846view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Dec 21 19:31:38 2011 @@ -128,6 +128,14 @@ PATCHES PROPOSED TO BACKPORT: +1: markt,funkman -1: +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52293 + Correctly handle antiResourceLocking=true when unpackWARs=false + Correctly handle multi-level contexts when antiResourceLocking=true + Patch by Justin Miller + https://issues.apache.org/bugzilla/attachment.cgi?id=28038action=diff + +1: markt + -1: + PATCHES/ISSUES THAT ARE STALLED - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52293] antiResourceLocking and unpackWARs
https://issues.apache.org/bugzilla/show_bug.cgi?id=52293 --- Comment #7 from Mark Thomas ma...@apache.org 2011-12-21 19:31:43 UTC --- Proposed for 6.0.x -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52365] tomcat cluster org.apache.catalina.tribes.ChannelException: Sender not connected
https://issues.apache.org/bugzilla/show_bug.cgi?id=52365 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Mark Thomas ma...@apache.org 2011-12-21 20:06:08 UTC --- This works for me and is such a basic part of the cluster support that if it were broken, I'd expect to see many more complaints. The most likely cause is a configuration error but without the full configuration from both nodes it is very difficult to tell. Please use the users mailing list to debug this issue further. If that identifies a bug (one that can be produced on a clean installation of the latest Tomcat 6 release) then please re-open this bug and provide the reproduction steps. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hello, I have started some stuff here: https://github.com/olamy/tomcat70. * sources have been to appropriate modules. * I'm now working on some test which fail (some tests need webapp examples) * distro not yet done. * repackaging of dbcp pool, commons-logging is done using shading technology * I will work with jbonofre (who is karaf committer) to add necessary stuff to osgiing. NOTE: It's really work in progress not finish (so pull requests will be accepted :-) ) 2011/12/20 Mark Thomas ma...@apache.org: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turk mt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. I would be very interested in seeing what a Mavenised build of trunk looks like. While I may come across as anti-Maven, that is not my position. I am anti *any* disruptive change that causes more disruption then benefit it brings and right now I see more disruption than I do benefit. I am also wary (from my experience of infrastructure at the ASF) of folks pushing strongly for a switch to something better, promising to help with the switch and promising to support things moving forwards and then melting away just as their support is really needed. A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x, 6.0.x or 5.5.x) at GitHub would help considerably: - we would be able to see how all the potential wrinkles (down-loading JDT, building a packages renamed DBCP, building a package renamed Commons logging, etc) were handled in Maven - we'd be able to judge how much simpler the build process was - Maven newbies like me could try building it, debugging with it and developing with it to see how easy we found it - the work required to create it would demonstrate a commitment to supporting this change I should stress that a working Mavenised build of a version of Tomcat is necessary but not sufficient to get my support for a switch from Ant to Maven for the build / release process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Hi all, I just discussed with Olivier about that. I will help OSGiing Tomcat. I would like to enhance Pax Web to be able to support both Jetty (as currently) and Tomcat using OSGi service selector. I plan to push the OSGi changes tomorrow on the Olivier's github. Regards JB On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. * sources have been to appropriate modules. * I'm now working on some test which fail (some tests need webapp examples) * distro not yet done. * repackaging of dbcp pool, commons-logging is done using shading technology * I will work with jbonofre (who is karaf committer) to add necessary stuff to osgiing. NOTE: It's really work in progress not finish (so pull requests will be accepted :-) ) 2011/12/20 Mark Thomasma...@apache.org: On 20/12/2011 08:17, Antonio Petrelli wrote: 2011/12/19 Mladen Turkmt...@apache.org On 12/19/2011 07:04 PM, Henri Gomez wrote: Exactly. Since any change would require a learning curve and it seems we don't have that many (read none) maven experts in the house, Gradle could be equally considered, given that it seems more advanced in customization. I know well Maven but Olivier (Lamy) is a Maven expert, so there is friend in the business. And there is a full Maven PMC not too far ready to provide advices and help. Not counting Tomcat consumers ASF projects like OpenEJB. All I have seen so far is talk and talk and more talk. There is trunk, branches, sandbox, so anyone is free to make a proposal and if things work, I'll be the first one supporting it. I already forked my own repository from GitHub. I hope to start it after the holidays. I would be very interested in seeing what a Mavenised build of trunk looks like. While I may come across as anti-Maven, that is not my position. I am anti *any* disruptive change that causes more disruption then benefit it brings and right now I see more disruption than I do benefit. I am also wary (from my experience of infrastructure at the ASF) of folks pushing strongly for a switch to something better, promising to help with the switch and promising to support things moving forwards and then melting away just as their support is really needed. A demonstration of a fully Mavenised build of Tomcat trunk (or 7.0.x, 6.0.x or 5.5.x) at GitHub would help considerably: - we would be able to see how all the potential wrinkles (down-loading JDT, building a packages renamed DBCP, building a package renamed Commons logging, etc) were handled in Maven - we'd be able to judge how much simpler the build process was - Maven newbies like me could try building it, debugging with it and developing with it to see how easy we found it - the work required to create it would demonstrate a commitment to supporting this change I should stress that a working Mavenised build of a version of Tomcat is necessary but not sufficient to get my support for a switch from Ant to Maven for the build / release process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. Otherwise no one will be able to apply custom patches to the exiting code base. BTW, Oliver, it looks really nice! Have couple of suggestion, but we need to solve #1 first. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 21/12/2011 21:21, Mladen Turk wrote: On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. I'm not sure we need a new branch if the end result is going to be the same. How we merge patches from trunk - 7.0.x - 6.0.x is something that is going to need to be addressed. I would have started with trunk rather than 7.0.x but they are close enough that what works for one should work for the other. Otherwise no one will be able to apply custom patches to the exiting code base. Yep, that is a problem we need to solve. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-108) THe httpsPort flag starts another http thread not an https thread
[ https://issues.apache.org/jira/browse/MTOMCAT-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13174425#comment-13174425 ] Keith Corbin commented on MTOMCAT-108: -- My bad, I was looking at the old repo location. --Keith On Wed, Dec 21, 2011 at 1:51 PM, Olivier Lamy (Commented) (JIRA) THe httpsPort flag starts another http thread not an https thread - Key: MTOMCAT-108 URL: https://issues.apache.org/jira/browse/MTOMCAT-108 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Environment: MAc OSX 10.6.8 Reporter: Keith Corbin Assignee: Olivier Lamy Fix For: 2.0 Attachments: https.patch, https.patch WHen you run the executable war the httpsPort flag starts an http protocol listener thread on the port listed not an https protocol listener. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 10:24 PM, Mark Thomas wrote: On 21/12/2011 21:21, Mladen Turk wrote: On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. I'm not sure we need a new branch if the end result is going to be the same. Well, we would screw anyone doing derivative work, that's for sure. Also any distribution packaging tomcat will have serious problems as well since almost all of them use package dependencies instead download or maven tasks. Eg, take a look at https://github.com/vanaf/tomcat7-fedora/blob/master/tomcat.spec OpenSuse is almost the same (they add some Geronimo dependencies however) In essence no packages will be able to change the version unless he rewrites the .spec or debian files from scratch thought. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 21/12/2011 21:57, Mladen Turk wrote: On 12/21/2011 10:24 PM, Mark Thomas wrote: On 21/12/2011 21:21, Mladen Turk wrote: On 12/21/2011 09:34 PM, Olivier Lamy wrote: Hello, I have started some stuff here: https://github.com/olamy/tomcat70. We must at least create 7.1.x branch for such a crucial change. I'm not sure we need a new branch if the end result is going to be the same. Well, we would screw anyone doing derivative work, that's for sure. Also any distribution packaging tomcat will have serious problems as well since almost all of them use package dependencies instead download or maven tasks. Eg, take a look at https://github.com/vanaf/tomcat7-fedora/blob/master/tomcat.spec OpenSuse is almost the same (they add some Geronimo dependencies however) In essence no packages will be able to change the version unless he rewrites the .spec or debian files from scratch thought. Ouch. That is argument for only doing this in trunk, if we do it at all. Still need to figure out how to merge patches if we go that way. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
On 12/21/2011 11:01 PM, Mark Thomas wrote: On 21/12/2011 21:57, Mladen Turk wrote: In essence no packages will be able to change the version unless he rewrites the .spec or debian files from scratch thought. Ouch. That is argument for only doing this in trunk, if we do it at all. Right. Up till now all linux distributions were using tomcatX, so yes, Tomcat8 (trunk) is the logical target. Still need to figure out how to merge patches if we go that way. If they do not span across new 'modules' it should be just making sure they are executed using 'patch -pX' so that correct number of directory entries is stripped from patch header. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52293] antiResourceLocking and unpackWARs
https://issues.apache.org/bugzilla/show_bug.cgi?id=52293 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Attachment #28037|1 |0 is patch|| -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52293] antiResourceLocking and unpackWARs
https://issues.apache.org/bugzilla/show_bug.cgi?id=52293 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Attachment #28034|1 |0 is patch|| -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
