DO NOT REPLY [Bug 16603] - controller forwardPattern should support different module roots.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603 controller forwardPattern should support different module roots. [EMAIL PROTECTED] changed: What|Removed |Added Severity|Enhancement |Normal --- Additional Comments From [EMAIL PROTECTED] 2003-02-06 08:57 --- I'm not sure to understand you well... It's not true that forwardPattern does'nt support arbitrary paths. The code of RequestUtils.forwardURL() do it very well and is used in RequestProcessor. So we actualy can (since 1.1b2 at least) define forwardPattern like /WEB- INF/my_modules/$M$P and *it works*. The problem is that ActionConfig.forward and ActionConfig.input paths are not processed the same way as ForwardConfig.path. I can't see how it can be an enancment as it's allready implemented and is documented in the user guide : http://jakarta.apache.org/struts/userGuide/configuration.html#controller_config This said, I agree that placing pages under /WEB-INF/ is not portable, and I thank you for your solution. But such a *bug* is not bound to the /WEB-INF/ dir, it will occure with a forwardPattern like $M/pages/$P or any else than $M$P. And if it's the only pattern we can define I don't see what it's made for... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16736] - html:form Focus-Script should check for disabled input field
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16736.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16736
html:form Focus-Script should check for disabled input field
--- Additional Comments From [EMAIL PROTECTED] 2003-02-06 10:08 ---
Actually I use the same jsp to edit and view data, and in view-mode I set all
fields disabled. There are 2 major advantages of this approach to using hidden-
fields and plain text output:
1. The Page looks exactly the same
2. Minimum effort to implement:
I define a variable readonly and in all elements add parameter
disabled=${readonly} to every input tag, that's it.
When using hidden-fields I'd have to add a c:choose-Tag around every input
field to choose between the hidden and the original tag. This is cumbersome and
I also dislike that much program logic in the jsp.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Migrate to Dependency on commons-resources
We'll be doing that for 1.2. David From: Steve Peterson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Proposal] Migrate to Dependency on commons-resources Date: Thu, 06 Feb 2003 01:54:48 -0600 I'm looking at taking on (2) below as my first contribution to Struts. Let me know if you have any specific suggestions or don't think it's something that should be worked on right now. S At 06:34 PM 1/12/2003 -0800, Craig R. McClanahan wrote: As we've discussed a couple of times, the last major functionality change we had discussed for Struts 1.1 was to migrate to dependence on commons-resources, rather than the proprietary message resource facilities inside og.apache.struts.util. As you might recall, Michael Schacter took a first crack at factoring out the Struts resources classes out to create this commons package, which is currently in the sandbox. I've recently gone through it, and did a major refactoring of commons-resources, to the point where I'm now ready to propose that we modify Struts to depend on it. I'd like the other committers to evaluate the current state of commons-resources, and my proposed integration plan below, to see what they think of this idea. The nightly build of commons-resources.jar included in recent Struts nightly builds is the code that I'm proposing. You can see the Javadocs for this code at: http://jakarta.apache.org/commons/resources/api/ and get the sources via either CVS (from jakarta-commons-sandbox) or nightly snapshots: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/ In terms of Struts integration, I propose: (1) Most Struts classes declare a static MessageResources instance for the messages unique to that Struts package. For example, org.apache.struts.taglib.bean.CookieTag has this: protected static MessageResources messages = MessageResources.getMessageResources (org.apache.struts.taglib.bean.LocalStrings); This would be migrated to the new Messages class from commons-resources: protected static Messages messages = Messages.getMessages(org.apache.struts.taglib.bean); The calls to actually retrieve message strings are compatible with the existing code, as well as the properties files used to acquire the message strings, so no other changes should be required. (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers around equivalent functionality from commons-resources (much like GenericDataSource now wraps commons-dbcp), and deprecate them. This protects existing apps that are customizing these APIs, but allows us to remove the o.a.s.u classes in a future version. (3) Modify the message-resources initialization element to allow the selection and configuration of an appropriate ResourcesFactory from commons-resources, wrapped by a Messages instance. This is primarily a change in the interpretation of the factory attribute, and should not affect anyone that uses the current default. (4) Modify all internal uses (including in tag libraries) of org.apache.struts.util.MessageResources to use org.apache.commons.resources.Messages instead. This will be transparent to users that use the standard implementations, but will require folks who have subclassed the MessageResources classes to migrate their code as well. What do you think? Should we go ahead and do this migration? Is the commons-resources package as it stands now as complete and functional as it needs to be (obviously, it'll need to be promoted to a standard Commons package and released so we can rely on it, which will require a couple of volunteers willing to help me maintain it). Should we do the entire migration outlined above, or maybe only part of it? Thoughts, please. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16603] - controller forwardPattern should support different module roots.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603 controller forwardPattern should support different module roots. --- Additional Comments From [EMAIL PROTECTED] 2003-02-06 15:41 --- Actually, I disagree that putting JSP pages under WEB-INF is not portable. If it doesn't work on a particular container, then I claim that is a bug in the container. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Migrate to Dependency on commons-resources
I'm wondering: a) is it something the project would accept as a patch for 1.2 b) whether now is a good time to be working on it (I assume it is since 1.1 is nearly complete and changes in that area look unlikely) If the answer to a) or b) is no, I'm open to suggestions of other things to work on. I have some time available now, have benefited from Struts, and would like to contribute. Steve At 08:16 AM 2/6/2003 -0700, David Graham wrote: We'll be doing that for 1.2. David From: Steve Peterson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Proposal] Migrate to Dependency on commons-resources Date: Thu, 06 Feb 2003 01:54:48 -0600 I'm looking at taking on (2) below as my first contribution to Struts. Let me know if you have any specific suggestions or don't think it's something that should be worked on right now. S At 06:34 PM 1/12/2003 -0800, Craig R. McClanahan wrote: As we've discussed a couple of times, the last major functionality change we had discussed for Struts 1.1 was to migrate to dependence on commons-resources, rather than the proprietary message resource facilities inside og.apache.struts.util. As you might recall, Michael Schacter took a first crack at factoring out the Struts resources classes out to create this commons package, which is currently in the sandbox. I've recently gone through it, and did a major refactoring of commons-resources, to the point where I'm now ready to propose that we modify Struts to depend on it. I'd like the other committers to evaluate the current state of commons-resources, and my proposed integration plan below, to see what they think of this idea. The nightly build of commons-resources.jar included in recent Struts nightly builds is the code that I'm proposing. You can see the Javadocs for this code at: http://jakarta.apache.org/commons/resources/api/ and get the sources via either CVS (from jakarta-commons-sandbox) or nightly snapshots: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/ In terms of Struts integration, I propose: (1) Most Struts classes declare a static MessageResources instance for the messages unique to that Struts package. For example, org.apache.struts.taglib.bean.CookieTag has this: protected static MessageResources messages = MessageResources.getMessageResources (org.apache.struts.taglib.bean.LocalStrings); This would be migrated to the new Messages class from commons-resources: protected static Messages messages = Messages.getMessages(org.apache.struts.taglib.bean); The calls to actually retrieve message strings are compatible with the existing code, as well as the properties files used to acquire the message strings, so no other changes should be required. (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers around equivalent functionality from commons-resources (much like GenericDataSource now wraps commons-dbcp), and deprecate them. This protects existing apps that are customizing these APIs, but allows us to remove the o.a.s.u classes in a future version. (3) Modify the message-resources initialization element to allow the selection and configuration of an appropriate ResourcesFactory from commons-resources, wrapped by a Messages instance. This is primarily a change in the interpretation of the factory attribute, and should not affect anyone that uses the current default. (4) Modify all internal uses (including in tag libraries) of org.apache.struts.util.MessageResources to use org.apache.commons.resources.Messages instead. This will be transparent to users that use the standard implementations, but will require folks who have subclassed the MessageResources classes to migrate their code as well. What do you think? Should we go ahead and do this migration? Is the commons-resources package as it stands now as complete and functional as it needs to be (obviously, it'll need to be promoted to a standard Commons package and released so we can rely on it, which will require a couple of volunteers willing to help me maintain it). Should we do the entire migration outlined above, or maybe only part of it? Thoughts, please. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16603] - controller forwardPattern should support different module roots.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603 controller forwardPattern should support different module roots. --- Additional Comments From [EMAIL PROTECTED] 2003-02-06 16:01 --- Weblogic does not support it and that is the number 1 or 2 container in the world. They interpret part of the spec more strictly than others when it says that files under WEB-INF can't be served outside the container. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Migrate to Dependency on commons-resources
Please post your patches (in diff -u format) to this ticket: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16792 Thanks! David From: Steve Peterson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: [Proposal] Migrate to Dependency on commons-resources Date: Thu, 06 Feb 2003 09:51:14 -0600 I'm wondering: a) is it something the project would accept as a patch for 1.2 b) whether now is a good time to be working on it (I assume it is since 1.1 is nearly complete and changes in that area look unlikely) If the answer to a) or b) is no, I'm open to suggestions of other things to work on. I have some time available now, have benefited from Struts, and would like to contribute. Steve At 08:16 AM 2/6/2003 -0700, David Graham wrote: We'll be doing that for 1.2. David From: Steve Peterson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Proposal] Migrate to Dependency on commons-resources Date: Thu, 06 Feb 2003 01:54:48 -0600 I'm looking at taking on (2) below as my first contribution to Struts. Let me know if you have any specific suggestions or don't think it's something that should be worked on right now. S At 06:34 PM 1/12/2003 -0800, Craig R. McClanahan wrote: As we've discussed a couple of times, the last major functionality change we had discussed for Struts 1.1 was to migrate to dependence on commons-resources, rather than the proprietary message resource facilities inside og.apache.struts.util. As you might recall, Michael Schacter took a first crack at factoring out the Struts resources classes out to create this commons package, which is currently in the sandbox. I've recently gone through it, and did a major refactoring of commons-resources, to the point where I'm now ready to propose that we modify Struts to depend on it. I'd like the other committers to evaluate the current state of commons-resources, and my proposed integration plan below, to see what they think of this idea. The nightly build of commons-resources.jar included in recent Struts nightly builds is the code that I'm proposing. You can see the Javadocs for this code at: http://jakarta.apache.org/commons/resources/api/ and get the sources via either CVS (from jakarta-commons-sandbox) or nightly snapshots: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-resources/ In terms of Struts integration, I propose: (1) Most Struts classes declare a static MessageResources instance for the messages unique to that Struts package. For example, org.apache.struts.taglib.bean.CookieTag has this: protected static MessageResources messages = MessageResources.getMessageResources (org.apache.struts.taglib.bean.LocalStrings); This would be migrated to the new Messages class from commons-resources: protected static Messages messages = Messages.getMessages(org.apache.struts.taglib.bean); The calls to actually retrieve message strings are compatible with the existing code, as well as the properties files used to acquire the message strings, so no other changes should be required. (2) Convert o.a.s.u.MessageResources (and its friends) to wrappers around equivalent functionality from commons-resources (much like GenericDataSource now wraps commons-dbcp), and deprecate them. This protects existing apps that are customizing these APIs, but allows us to remove the o.a.s.u classes in a future version. (3) Modify the message-resources initialization element to allow the selection and configuration of an appropriate ResourcesFactory from commons-resources, wrapped by a Messages instance. This is primarily a change in the interpretation of the factory attribute, and should not affect anyone that uses the current default. (4) Modify all internal uses (including in tag libraries) of org.apache.struts.util.MessageResources to use org.apache.commons.resources.Messages instead. This will be transparent to users that use the standard implementations, but will require folks who have subclassed the MessageResources classes to migrate their code as well. What do you think? Should we go ahead and do this migration? Is the commons-resources package as it stands now as complete and functional as it needs to be (obviously, it'll need to be promoted to a standard Commons package and released so we can rely on it, which will require a couple of volunteers willing to help me maintain it). Should we do the entire migration outlined above, or maybe only part of it? Thoughts, please. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16616] - SaveRegistrationAction does not cancel correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16616. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16616 SaveRegistrationAction does not cancel correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-02-06 18:24 --- I have to say that while I don't agree that hitting the cancel button from a create registration screen should take you to the login screen, I don't think this defect is worth additional consideration. I apologize for the incorrect posting of the second part of the defect. I did not realize that mapping.getInputForward took care of inputForward attribute, my mistake. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts-wml 1.1b3 available - now in synch with Struts v1.1b3
Struts-wml is now in synch with Struts v1.1b3 and is available from the project's webpage: https://sourceforge.net/projects/struts-wml Struts-wml is a set of Struts compliant taglibs useful for building dynamic WAP/WML applications. It's based on struts-html taglib. Please report bugs using SourceForge's Bug Tracker. Regards, Davor Cengija -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16856] New: - bean:write don't escape new line characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16856. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16856 bean:write don't escape new line characters Summary: bean:write don't escape new line characters Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] On tag bean:write is provided a useful filter attribute that escape characters that are sensistive in HTML. Why it don't escape \n\r character's with br\ tags? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16856] - bean:write don't escape new line characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16856. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16856 bean:write don't escape new line characters [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-02-06 20:40 --- It only filters characters that pose a security risk. It is not a general purpose filter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/test/org/apache/struts/action TestActionMessage.java
jmitchell2003/02/06 16:29:21
Modified:src/test/org/apache/struts/action TestActionMessage.java
Log:
Fix \r\n problem
Revision ChangesPath
1.3 +129 -129
jakarta-struts/src/test/org/apache/struts/action/TestActionMessage.java
Index: TestActionMessage.java
===
RCS file:
/home/cvs/jakarta-struts/src/test/org/apache/struts/action/TestActionMessage.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestActionMessage.java16 Nov 2002 04:58:47 - 1.2
+++ TestActionMessage.java7 Feb 2003 00:29:21 - 1.3
@@ -1,129 +1,129 @@
-/*
- * The Apache Software License, Version 1.1
- *
- * Copyright (c) 1999-2002 The Apache Software Foundation. All rights
- * reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in
- *the documentation and/or other materials provided with the
- *distribution.
- *
- * 3. The end-user documentation included with the redistribution, if
- *any, must include the following acknowlegement:
- * This product includes software developed by the
- *Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowlegement may appear in the software itself,
- *if and wherever such third-party acknowlegements normally appear.
- *
- * 4. The names The Jakarta Project, Struts, and Apache Software
- *Foundation must not be used to endorse or promote products derived
- *from this software without prior written permission. For written
- *permission, please contact [EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache
- *nor may Apache appear in their names without prior written
- *permission of the Apache Group.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
- * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
- * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- *
- * This software consists of voluntary contributions made by many
- * individuals on behalf of the Apache Software Foundation. For more
- * information on the Apache Software Foundation, please see
- * http://www.apache.org/.
- *
- */
-
-package org.apache.struts.action;
-
-import junit.framework.Test;
import junit.framework.TestCase;
import
junit.framework.TestSuite;
-
-/**
- * Unit tests for the codeorg.apache.struts.action.ActionMessage/code class.
- *
- * @author Dominique Plante
- * @version $Revision$ $Date$
- */
-
-public class TestActionMessage extends TestCase
-{
- protected ActionMessage amWithNoValue = null;
- protected ActionMessage amWithOneValue = null;
-/**
- * Defines the testcase name for JUnit.
- *
- * @param theName the testcase's name.
- */
- public TestActionMessage(String theName)
- {
- super(theName);
- }
-
-/**
- * Start the tests.
- *
- * @param theArgs the arguments. Not used
- */
-public static void main(String[] theArgs)
-{
-junit.awtui.TestRunner.main(new String[]
{TestActionMessage.class.getName()});
-}
-
-/**
- * @return a test suite (codeTestSuite/code) that includes all methods
- * starting with test
- */
-public static Test suite()
-{
-// All methods starting with test will be executed in the test suite.
-return new TestSuite(TestActionMessage.class);
-}
-
- public void setUp()
- {
- amWithNoValue = new ActionMessage(amWithNoValue);
- amWithOneValue = new
cvs commit: jakarta-struts/src/test/org/apache/struts/taglib/logic SimpleBeanForTesting.java TestEmptyTag.java TestGreaterEqualTag.java TestLessEqualTag.java TestLessThanTag.java TestGreaterThanTag.java
jmitchell2003/02/06 16:32:06
Modified:src/test/org/apache/struts/taglib/logic
TestGreaterThanTag.java
Added: src/test/org/apache/struts/taglib/logic
SimpleBeanForTesting.java TestEmptyTag.java
TestGreaterEqualTag.java TestLessEqualTag.java
TestLessThanTag.java
Log:
Adding more test cases. Almost finished with all the logic tags.
Revision ChangesPath
1.2 +159 -15
jakarta-struts/src/test/org/apache/struts/taglib/logic/TestGreaterThanTag.java
Index: TestGreaterThanTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/test/org/apache/struts/taglib/logic/TestGreaterThanTag.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestGreaterThanTag.java 6 Feb 2003 04:36:30 - 1.1
+++ TestGreaterThanTag.java 7 Feb 2003 00:32:06 - 1.2
@@ -70,12 +70,13 @@
* @author James Mitchell
*/
public class TestGreaterThanTag extends JspTestCase {
+
protected final static String COOKIE_KEY =
org.apache.struts.taglib.logic.COOKIE_KEY;
-protected final static String COOKIE_VAL = 5;
protected final static String HEADER_KEY =
org.apache.struts.taglib.logic.HEADER_KEY;
-protected final static String HEADER_VAL = 5;
protected final static String PARAMETER_KEY =
org.apache.struts.taglib.logic.PARAMETER_KEY;
-protected final static String PARAMETER_VAL = 5;
+protected final static String GREATER_VAL = 6;
+protected final static String LESSER_VAL = 4;
+
/**
* Defines the testcase name for JUnit.
@@ -110,21 +111,21 @@
* Create cookie for testCookiePresent method test.
*/
public void beginCookieGreaterThan(WebRequest testRequest) {
- testRequest.addCookie(COOKIE_KEY, COOKIE_VAL);
+ testRequest.addCookie(COOKIE_KEY, GREATER_VAL);
}
/**
* Create header for testHeaderGreaterThan method test.
*/
public void beginHeaderGreaterThan(WebRequest testRequest) {
- testRequest.addHeader(HEADER_KEY, HEADER_VAL);
+ testRequest.addHeader(HEADER_KEY, GREATER_VAL);
}
/**
* Create header for testParameterGreaterThan method test.
*/
public void beginParameterGreaterThan(WebRequest testRequest) {
- testRequest.addParameter(PARAMETER_KEY, PARAMETER_VAL);
+ testRequest.addParameter(PARAMETER_KEY, GREATER_VAL);
}
/**
@@ -132,13 +133,12 @@
*/
public void testCookieGreaterThan() throws ServletException, JspException {
GreaterThanTag gt = new GreaterThanTag();
-String testVal = 4;
gt.setPageContext(pageContext);
gt.setCookie(COOKIE_KEY);
-gt.setValue(testVal);
+gt.setValue(LESSER_VAL);
assertTrue(
- Cookie Value ( + COOKIE_VAL + ) is greater than test value ( +
testVal + ),
+ Cookie Value ( + GREATER_VAL + ) is greater than value ( +
LESSER_VAL + ),
gt.condition());
}
@@ -147,13 +147,12 @@
*/
public void testHeaderGreaterThan() throws ServletException, JspException {
GreaterThanTag gt = new GreaterThanTag();
-String testVal = 4;
gt.setPageContext(pageContext);
gt.setHeader(HEADER_KEY);
-gt.setValue(testVal);
+gt.setValue(LESSER_VAL);
assertTrue(
- Header Value ( + HEADER_VAL + ) is greater than test value ( +
testVal + ),
+ Header Value ( + GREATER_VAL + ) is greater than value ( +
LESSER_VAL + ),
gt.condition());
}
@@ -162,15 +161,160 @@
*/
public void testParameterGreaterThan() throws ServletException, JspException {
GreaterThanTag gt = new GreaterThanTag();
-String testVal = 4;
gt.setPageContext(pageContext);
gt.setParameter(PARAMETER_KEY);
-gt.setValue(testVal);
+gt.setValue(LESSER_VAL);
+
+assertTrue(
+ Parameter Value ( + GREATER_VAL + ) is greater than value ( +
LESSER_VAL + ),
+ gt.condition());
+}
+
+
+/**
+ * Testing codeGreaterThanTag/code using name attribute in
+ * the application scope.
+*/
+public void testApplicationScopeNameGreaterThan()
+ throws ServletException, JspException {
+
+GreaterThanTag gt = new GreaterThanTag();
+
+ String testKey = testApplicationScopeNameGreaterThan;
+ Integer itgr = new Integer(GREATER_VAL);
+
+ pageContext.setAttribute(testKey, itgr, PageContext.APPLICATION_SCOPE);
+ gt.setPageContext(pageContext);
+
Buglet related to Globals.MAPPING_KEY?
I just noticed something strange that I believe to be a minor bug, but I'm not sure which is intended to be the correct solution. RequestProcessor.processMapping() tries to find the ActionMapping for the current request. Once found, the mapping is stored in a request attribute, viz Globals.MAPPING_KEY. So far, so good. Now, further down the line, in RequestUtils.populate(), IFF the request is a multipart request, the mapping request attribute is removed from the request. This is the part that's odd. I believe the original reason for storing the mapping in a request attribute was so that it could be obtained in populate() when processing a multipart request, without having to pass it as a parameter all the way down. In fact, the only code that accesses the attribute is shortly above the only place that it's removed from the request. The catch is that it isn't removed for any other type of request. Now, obviously, we could fix this in one of two ways. We could either have populate() always remove it, or never remove it. Although the former is better matched with the original intent of the attribute, it's possible that people have assumed that it is always available, and written code with that in mind. In fact, the ConfigHelper class (not used, and marked as experimental) seems to make this assumption, even within the Struts code base. Therefore, to be on the safe side, I plan on removing the call to removeAttribute() from populate(), thus guaranteeing that the mapping is available regardless of the type of request being processed. Comments? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/conf/test/tomcat41 server.xml
craigmcc2003/02/06 17:20:14 Modified:.build-tests.xml conf/test/tomcat40 server.xml conf/test/tomcat41 server.xml Log: Change port numbers (8005-9005 and 8080-9090) on the Tomcat 4.0 and 4.1 tests, so that the existence of a running Tomcat on the default ports does not interfere with being able to run them. Revision ChangesPath 1.14 +2 -2 jakarta-struts/build-tests.xml Index: build-tests.xml === RCS file: /home/cvs/jakarta-struts/build-tests.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- build-tests.xml 27 Dec 2002 11:03:55 - 1.13 +++ build-tests.xml 7 Feb 2003 01:20:13 - 1.14 @@ -462,7 +462,7 @@ The servlet engine is automatically stopped if the tests fail for any reason.-- -runservertests testURL=http://localhost:8080/test; +runservertests testURL=http://localhost:9090/test; startTarget=start.tomcat.40 stopTarget=stop.tomcat.40 testTarget=run.test/ @@ -545,7 +545,7 @@ The servlet engine is automatically stopped if the tests fail for any reason.-- -runservertests testURL=http://localhost:8080/test; +runservertests testURL=http://localhost:9090/test; startTarget=start.tomcat.41 stopTarget=stop.tomcat.41 testTarget=run.test/ 1.3 +2 -2 jakarta-struts/conf/test/tomcat40/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-struts/conf/test/tomcat40/server.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- server.xml16 Jun 2002 04:02:38 - 1.2 +++ server.xml7 Feb 2003 01:20:14 - 1.3 @@ -1,9 +1,9 @@ -Server port=8005 shutdown=SHUTDOWN debug=0 +Server port=9005 shutdown=SHUTDOWN debug=0 Service name=Tomcat-Standalone Connector className=org.apache.catalina.connector.http.HttpConnector - port=8080 minProcessors=5 maxProcessors=75 + port=9090 minProcessors=5 maxProcessors=75 acceptCount=10 debug=0/ Engine name=Standalone defaultHost=localhost debug=0 1.2 +2 -2 jakarta-struts/conf/test/tomcat41/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-struts/conf/test/tomcat41/server.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- server.xml16 Jun 2002 04:02:38 - 1.1 +++ server.xml7 Feb 2003 01:20:14 - 1.2 @@ -1,4 +1,4 @@ -Server port=8005 shutdown=SHUTDOWN debug=0 +Server port=9005 shutdown=SHUTDOWN debug=0 Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ @@ -29,7 +29,7 @@ Service name=Tomcat-Standalone Connector className=org.apache.coyote.tomcat4.CoyoteConnector - port=8080 minProcessors=5 maxProcessors=75 + port=9090 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Buglet related to Globals.MAPPING_KEY?
On Thu, 6 Feb 2003, Martin Cooper wrote: Date: Thu, 6 Feb 2003 17:19:47 -0800 (PST) From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Buglet related to Globals.MAPPING_KEY? I just noticed something strange that I believe to be a minor bug, but I'm not sure which is intended to be the correct solution. RequestProcessor.processMapping() tries to find the ActionMapping for the current request. Once found, the mapping is stored in a request attribute, viz Globals.MAPPING_KEY. So far, so good. Now, further down the line, in RequestUtils.populate(), IFF the request is a multipart request, the mapping request attribute is removed from the request. This is the part that's odd. I believe the original reason for storing the mapping in a request attribute was so that it could be obtained in populate() when processing a multipart request, without having to pass it as a parameter all the way down. In fact, the only code that accesses the attribute is shortly above the only place that it's removed from the request. The catch is that it isn't removed for any other type of request. Now, obviously, we could fix this in one of two ways. We could either have populate() always remove it, or never remove it. Although the former is better matched with the original intent of the attribute, it's possible that people have assumed that it is always available, and written code with that in mind. In fact, the ConfigHelper class (not used, and marked as experimental) seems to make this assumption, even within the Struts code base. Therefore, to be on the safe side, I plan on removing the call to removeAttribute() from populate(), thus guaranteeing that the mapping is available regardless of the type of request being processed. Comments? +1. We've got a bunch of precedents in the module handling code for passing request attributes under well-known names. And, if we ever figure out how to suport multiple mappings for the controller servlet gracefully, we're going to want this as a request attribute in order to distinguish which of the (potentially several) mappings matched on this request. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cactus Test Failures?
Trying to run the test.tomcat.40 and test.tomcat.41 targets, I get a JUnit failure on the testInitDestroyInternal testcase. The logged message implies that this is because Tomcat is returning a 404 error for /test/ServletRedirector. Did something change in this test recently? Or maybe I need a different version of Cactus (1.4) or JUnit (3.8.1)? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cactus Test Failures?
I recently added a few tests under o.a.s.t.logic I've attached a test run I just did about 3 minutes ago. I'm using Cactus (1.4) or JUnit (3.8.1) -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 8:36 PM Subject: Cactus Test Failures? Trying to run the test.tomcat.40 and test.tomcat.41 targets, I get a JUnit failure on the testInitDestroyInternal testcase. The logged message implies that this is because Tomcat is returning a 404 error for /test/ServletRedirector. Did something change in this test recently? Or maybe I need a different version of Cactus (1.4) or JUnit (3.8.1)? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Buildfile: C:\home\jmitchell\projects\cvs\jakarta-struts\build.xml skip.tomcat.32: [echo] * [echo] WARNING : Property 'tomcat.home.32' has not been set. [echo] No test will be run on that servlet engine. [echo] * init: [echo] - jakarta-struts 1.1-b4-dev - [echo] java.class.path = C:\j2sdk1.4.1\lib\tools.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\xml-apis.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\xercesImpl.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\optional.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\mail_1_2.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\junit.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\commons-cactus-ant.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\catalina-ant.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\cactus-ant.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\antlr-runtime.jar;C:\Apache_Home\jakarta-ant-1.5.1\lib\ant.jar; [echo] java.home = C:\j2sdk1.4.1\jre [echo] user.home = C:\Documents and Settings\jmitchell prepare.library: compile.library: [style] Transforming into C:\home\jmitchell\projects\cvs\jakarta-struts\target\library test.tomcat.32: skip.tomcat.33: test.tomcat.33: [echo] tomcat.home.33 = /Apache_Home/jakarta-tomcat-3.3.1 init: prepare.test: compile.test: [javac] Compiling 1 source file to C:\home\jmitchell\projects\cvs\jakarta-struts\target\test\classes prepare.test.war: [war] Building war: C:\home\jmitchell\projects\cvs\jakarta-struts\target\test\test.war prepare.test.tomcat.33: [delete] Deleting directory C:\home\jmitchell\projects\cvs\jakarta-struts\target\test\servers\tomcat33\webapps\test [copy] Copying 1 file to C:\home\jmitchell\projects\cvs\jakarta-struts\target\test\servers\tomcat33\webapps test.tomcat.33: start.tomcat.33: [java] 2003-02-06 20:52:13 - AutoDeploy: Source or destination missing [java] 2003-02-06 20:52:13 - AutoDeploy: Expanding C:\home\jmitchell\projects\cvs\jakarta-struts\target\test\servers\tomcat33\webapps\test.war [java] 2003-02-06 20:52:15 - ServerXmlReader: Config=$TOMCAT_HOME\conf\server.xml [java] 2003-02-06 20:52:15 - PathSetter: install=C:\Apache_Home\jakarta-tomcat-3.3.1\lib [java] 2003-02-06 20:52:15 - PathSetter: home=C:\home\jmitchell\projects\cvs\jakarta-struts\target\test\servers\tomcat33 [java] 2003-02-06 20:52:15 - AutoWebApp: No autoconf directory C:\home\jmitchell\projects\cvs\jakarta-struts\target\test\servers\tomcat33\modules [java] 2003-02-06 20:52:15 - AutoWebApp: Auto-Adding DEFAULT:/test [java] 2003-02-06 20:52:15 - ContextManager: Tomcat configured and in stable state [java] 2003-02-06 20:52:15 - ContextManager: Adding DEFAULT:/test [java] 2003-02-06 20:52:15 - Ctx(/test) : Validating web.xml [java] EmbededTomcat: Init time 3045 [java] 2003-02-06 20:52:15 - Http10Interceptor: Starting on 8080 [java] 2003-02-06 20:52:15 - Ajp12Interceptor: Starting on 8007 [java] EmbededTomcat: Startup time 200 run.test: [junit] Running org.apache.struts.action.TestActionMessage [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.05 sec [junit] Testsuite: org.apache.struts.action.TestActionMessage [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.05 sec [junit] Testcase: testActionMessageWithNoValue took 0.03 sec [junit] Testcase: testActionMessageWithAStringValue took 0 sec [junit] Running org.apache.struts.action.TestActionMessages [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.09 sec [junit] Testsuite: org.apache.struts.action.TestActionMessages [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.09 sec [junit] Testcase: testEmpty took 0.04 sec [junit] Testcase: testNotEmpty took 0 sec [junit] Testcase: testSizeWithOneProperty took 0 sec [junit] Testcase: testSizeWithManyProperties took 0 sec [junit] Testcase: testSizeAndEmptyAfterClear took 0.01 sec [junit] Testcase: testGetWithNoProperty took
Re: Cactus Test Failures?
Wierd ... it doesn't appear to be related to testInitDestroyInternal in particular -- I tried commenting that out and replacing it with a trivially simple test, and got the same sort of error. Yet, the servlet mapping for /ServletRedirector looks right in the web.xml file. James, did you try this with the commit I just did that switched the port numbers? I want to make sure that *that* didn't mess anything up. Craig On Thu, 6 Feb 2003, James Mitchell wrote: Date: Thu, 6 Feb 2003 20:59:17 -0500 From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Cactus Test Failures? I recently added a few tests under o.a.s.t.logic I've attached a test run I just did about 3 minutes ago. I'm using Cactus (1.4) or JUnit (3.8.1) -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 8:36 PM Subject: Cactus Test Failures? Trying to run the test.tomcat.40 and test.tomcat.41 targets, I get a JUnit failure on the testInitDestroyInternal testcase. The logged message implies that this is because Tomcat is returning a 404 error for /test/ServletRedirector. Did something change in this test recently? Or maybe I need a different version of Cactus (1.4) or JUnit (3.8.1)? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cactus Test Failures?
No, I haven't updated since this morning. I'll try that. -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 9:11 PM Subject: Re: Cactus Test Failures? Wierd ... it doesn't appear to be related to testInitDestroyInternal in particular -- I tried commenting that out and replacing it with a trivially simple test, and got the same sort of error. Yet, the servlet mapping for /ServletRedirector looks right in the web.xml file. James, did you try this with the commit I just did that switched the port numbers? I want to make sure that *that* didn't mess anything up. Craig On Thu, 6 Feb 2003, James Mitchell wrote: Date: Thu, 6 Feb 2003 20:59:17 -0500 From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Cactus Test Failures? I recently added a few tests under o.a.s.t.logic I've attached a test run I just did about 3 minutes ago. I'm using Cactus (1.4) or JUnit (3.8.1) -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 8:36 PM Subject: Cactus Test Failures? Trying to run the test.tomcat.40 and test.tomcat.41 targets, I get a JUnit failure on the testInitDestroyInternal testcase. The logged message implies that this is because Tomcat is returning a 404 error for /test/ServletRedirector. Did something change in this test recently? Or maybe I need a different version of Cactus (1.4) or JUnit (3.8.1)? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cactus Test Failures?
On Thu, 6 Feb 2003, James Mitchell wrote: Date: Thu, 6 Feb 2003 21:21:55 -0500 From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Cactus Test Failures? ... ... [junit] Testcase: testGetForAProperty took 0 sec [junit] Testcase: testAddMessages took 0.03 sec [junit] Running org.apache.struts.action.TestActionServlet [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.264 sec [junit] Testsuite: org.apache.struts.action.TestActionServlet [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.264 sec [junit] Testcase: testInitDestroyInternal took 2.234 sec [junit] Caused an ERROR [junit] Connection refused: connect [junit] java.net.ConnectException: Connection refused: connect [junit] at java.net.PlainSocketImpl.socketConnect(Native Method) [junit] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) [junit] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) [junit] at java.net.Socket.connect(Socket.java:426) ... ... You thinking what I'm thinking? That is odd all right, but definitely not what I got -- see attached. In my case, it seems that the connection actually happened, because I get the Tomcat 404 error page back. ... well, that was last time. Grumble grumble ... now it says the testInitDestroyMethod does not exist, on both 4.0 and 4.1. -- James Mitchell Craig - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 9:13 PM Subject: Re: Cactus Test Failures? No, I haven't updated since this morning. I'll try that. -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 9:11 PM Subject: Re: Cactus Test Failures? Wierd ... it doesn't appear to be related to testInitDestroyInternal in particular -- I tried commenting that out and replacing it with a trivially simple test, and got the same sort of error. Yet, the servlet mapping for /ServletRedirector looks right in the web.xml file. James, did you try this with the commit I just did that switched the port numbers? I want to make sure that *that* didn't mess anything up. Craig On Thu, 6 Feb 2003, James Mitchell wrote: Date: Thu, 6 Feb 2003 20:59:17 -0500 From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Cactus Test Failures? I recently added a few tests under o.a.s.t.logic I've attached a test run I just did about 3 minutes ago. I'm using Cactus (1.4) or JUnit (3.8.1) -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 8:36 PM Subject: Cactus Test Failures? Trying to run the test.tomcat.40 and test.tomcat.41 targets, I get a JUnit failure on the testInitDestroyInternal testcase. The logged message implies that this is because Tomcat is returning a 404 error for /test/ServletRedirector. Did something change in this test recently? Or maybe I need a different version of Cactus (1.4) or JUnit (3.8.1)? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Buildfile: build.xml skip.tomcat.41: init: [echo] - jakarta-struts 1.1-b4-dev - [echo] java.class.path = /usr/local/ant/lib/xml-apis.jar:/usr/local/ant/lib/xercesImpl.jar:/usr/local/ant/lib/xalan.jar:/usr/local/ant/lib/stylebook-1.0-b3_xalan-2.jar:/usr/local/ant/lib/optional.jar:/usr/local/ant/lib/log4j.jar:/usr/local/ant/lib/junit.jar:/usr/local/ant/lib/jdom.jar:/usr/local/ant/lib/checkstyle.jar:/usr/local/ant/lib/catalina-ant.jar:/usr/local/ant/lib/cactus-ant-1.4.1.jar:/usr/local/ant/lib/aspectjrt-1.0.5.jar:/usr/local/ant/lib/ant.jar:/usr/local/java/lib/tools.jar
Re: Cactus Test Failures?
I just changed that last commit back (build-tests.xml, and both server.xml) and its running fine now. (see attached) -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 9:34 PM Subject: Re: Cactus Test Failures? On Thu, 6 Feb 2003, James Mitchell wrote: Date: Thu, 6 Feb 2003 21:21:55 -0500 From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Cactus Test Failures? ... ... [junit] Testcase: testGetForAProperty took 0 sec [junit] Testcase: testAddMessages took 0.03 sec [junit] Running org.apache.struts.action.TestActionServlet [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.264 sec [junit] Testsuite: org.apache.struts.action.TestActionServlet [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.264 sec [junit] Testcase: testInitDestroyInternal took 2.234 sec [junit] Caused an ERROR [junit] Connection refused: connect [junit] java.net.ConnectException: Connection refused: connect [junit] at java.net.PlainSocketImpl.socketConnect(Native Method) [junit] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) [junit] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) [junit] at java.net.Socket.connect(Socket.java:426) ... ... You thinking what I'm thinking? That is odd all right, but definitely not what I got -- see attached. In my case, it seems that the connection actually happened, because I get the Tomcat 404 error page back. ... well, that was last time. Grumble grumble ... now it says the testInitDestroyMethod does not exist, on both 4.0 and 4.1. -- James Mitchell Craig - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 9:13 PM Subject: Re: Cactus Test Failures? No, I haven't updated since this morning. I'll try that. -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 9:11 PM Subject: Re: Cactus Test Failures? Wierd ... it doesn't appear to be related to testInitDestroyInternal in particular -- I tried commenting that out and replacing it with a trivially simple test, and got the same sort of error. Yet, the servlet mapping for /ServletRedirector looks right in the web.xml file. James, did you try this with the commit I just did that switched the port numbers? I want to make sure that *that* didn't mess anything up. Craig On Thu, 6 Feb 2003, James Mitchell wrote: Date: Thu, 6 Feb 2003 20:59:17 -0500 From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Cactus Test Failures? I recently added a few tests under o.a.s.t.logic I've attached a test run I just did about 3 minutes ago. I'm using Cactus (1.4) or JUnit (3.8.1) -- James Mitchell - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 8:36 PM Subject: Cactus Test Failures? Trying to run the test.tomcat.40 and test.tomcat.41 targets, I get a JUnit failure on the testInitDestroyInternal testcase. The logged message implies that this is because Tomcat is returning a 404 error for /test/ServletRedirector. Did something change in this test recently? Or maybe I need a different version of Cactus (1.4) or JUnit (3.8.1)? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
source version for commons-beanutils.jar for struts1.1 b3
Hello, What version of source should be used for commons-beanutils.jar that shipped with struts. -Aswath _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: source version for commons-beanutils.jar for struts1.1 b3
On Thu, 6 Feb 2003, aswath satrasala wrote: Hello, What version of source should be used for commons-beanutils.jar that shipped with struts. The corresponding sources are tagged with the label STRUTS_1_1_B3 in the CVS repository. -- Martin Cooper -Aswath _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
martinc 2003/02/06 21:25:24
Modified:src/share/org/apache/struts/util RequestUtils.java
Log:
Do not remove the action mapping from the request for multipart requests.
This means that the action mapping will always be available under the
Globals.MAPPING_KEY request attribute, regardless of the type of request
being processed.
Revision ChangesPath
1.82 +4 -5
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
Index: RequestUtils.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- RequestUtils.java 6 Feb 2003 03:01:58 - 1.81
+++ RequestUtils.java 7 Feb 2003 05:25:23 - 1.82
@@ -1065,7 +1065,6 @@
request, multipartHandler);
names = Collections.enumeration(multipartParameters.keySet());
}
-request.removeAttribute(Globals.MAPPING_KEY);
}
if (!isMultipart) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java
martinc 2003/02/06 21:42:46
Modified:src/share/org/apache/struts/action ActionServlet.java
Log:
Add BigDecimal and BigInteger to the set of types for which default
converters are registered on startup.
PR: 16829
Submitted by: Brian Alexander Lee
Revision ChangesPath
1.143 +12 -4
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
Index: ActionServlet.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
retrieving revision 1.142
retrieving revision 1.143
diff -u -r1.142 -r1.143
--- ActionServlet.java28 Jan 2003 19:30:23 - 1.142
+++ ActionServlet.java7 Feb 2003 05:42:45 - 1.143
@@ -65,6 +65,8 @@
import java.io.IOException;
import java.io.InputStream;
+import java.math.BigDecimal;
+import java.math.BigInteger;
import java.net.URL;
import java.sql.SQLException;
import java.util.ArrayList;
@@ -82,6 +84,8 @@
import org.apache.commons.beanutils.BeanUtils;
import org.apache.commons.beanutils.PropertyUtils;
import org.apache.commons.beanutils.ConvertUtils;
+import org.apache.commons.beanutils.converters.BigDecimalConverter;
+import org.apache.commons.beanutils.converters.BigIntegerConverter;
import org.apache.commons.beanutils.converters.BooleanConverter;
import org.apache.commons.beanutils.converters.ByteConverter;
import org.apache.commons.beanutils.converters.CharacterConverter;
@@ -1315,6 +1319,10 @@
}
if (convertNull) {
ConvertUtils.deregister();
+ConvertUtils.register(new BigDecimalConverter(null),
+ BigDecimal.class);
+ConvertUtils.register(new BigIntegerConverter(null),
+ BigInteger.class);
ConvertUtils.register(new BooleanConverter(null), Boolean.class);
ConvertUtils.register(new ByteConverter(null), Byte.class);
ConvertUtils.register(new CharacterConverter(null),
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16829] - The convertNull param==true for ActionServlet does not default java.math.BigDecimal/BigInteger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16829. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16829 The convertNull param==true for ActionServlet does not default java.math.BigDecimal/BigInteger [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-02-07 05:44 --- Fixed in the 20030207 nightly build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/upload CommonsMultipartRequestHandler.java
martinc 2003/02/06 23:00:49
Modified:conf/share struts-config_1_1.dtd
src/share/org/apache/struts/config ControllerConfig.java
src/share/org/apache/struts/upload
CommonsMultipartRequestHandler.java
Log:
Allow configuration of the size threshold below which uploads will be saved
in memory, and above which they will be saved to some alternate storage
medium, typically disk.
Revision ChangesPath
1.36 +10 -1 jakarta-struts/conf/share/struts-config_1_1.dtd
Index: struts-config_1_1.dtd
===
RCS file: /home/cvs/jakarta-struts/conf/share/struts-config_1_1.dtd,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- struts-config_1_1.dtd 28 Jan 2003 19:30:23 - 1.35
+++ struts-config_1_1.dtd 7 Feb 2003 07:00:49 - 1.36
@@ -515,6 +515,14 @@
megabytes, or gigabytes, respectively.
[250M]
+ memFileSize The maximum size (in bytes) of a file whose contents will
+ be retained in memory after uploading. Files larger than
+ this threshold will be written to some alternative storage
+ medium, typically a hard disk. Can be expressed as a number
+ followed by a K, M, or G, which are interpreted to
+ mean kilobytes, megabytes, or gigabytes, respectively.
+ [256K]
+
multipartClass The fully qualified Java class name of the multipart
request handler class to be used with this module.
[org.apache.struts.upload.CommonsMultipartRequestHandler]
@@ -555,6 +563,7 @@
!ATTLIST controller inputForward %Boolean; #IMPLIED
!ATTLIST controller locale %Boolean; #IMPLIED
!ATTLIST controller maxFileSizeCDATA #IMPLIED
+!ATTLIST controller memFileSizeCDATA #IMPLIED
!ATTLIST controller multipartClass %ClassName; #IMPLIED
!ATTLIST controller nocache%Boolean; #IMPLIED
!ATTLIST controller pagePatternCDATA #IMPLIED
1.13 +26 -5
jakarta-struts/src/share/org/apache/struts/config/ControllerConfig.java
Index: ControllerConfig.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/config/ControllerConfig.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ControllerConfig.java 28 Jan 2003 19:30:24 - 1.12
+++ ControllerConfig.java 7 Feb 2003 07:00:49 - 1.13
@@ -231,6 +231,23 @@
/**
+ * The maximum file size to retain in memory.
+ */
+protected String memFileSize = 256K;
+
+public String getMemFileSize() {
+return (this.memFileSize);
+}
+
+public void setMemFileSize(String memFileSize) {
+if (configured) {
+throw new IllegalStateException(Configuration is frozen);
+}
+this.memFileSize = memFileSize;
+}
+
+
+/**
* The fully qualified Java class name of the MultipartRequestHandler
* class to be used.
*/
@@ -369,8 +386,12 @@
sb.append(,locale=);
sb.append(this.locale);
if (this.maxFileSize != null) {
-sb.append(,maxFileSzie=);
+sb.append(,maxFileSize=);
sb.append(this.maxFileSize);
+}
+if (this.memFileSize != null) {
+sb.append(,memFileSize=);
+sb.append(this.memFileSize);
}
sb.append(,multipartClass=);
sb.append(this.multipartClass);
1.7 +42 -23
jakarta-struts/src/share/org/apache/struts/upload/CommonsMultipartRequestHandler.java
Index: CommonsMultipartRequestHandler.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/CommonsMultipartRequestHandler.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- CommonsMultipartRequestHandler.java 9 Nov 2002 04:04:11 - 1.6
+++ CommonsMultipartRequestHandler.java 7 Feb 2003 07:00:49 - 1.7
@@ -218,7 +218,7 @@
// Set the maximum size before a FileUploadException will be thrown.
upload.setSizeMax((int) getSizeMax(ac));
// Set the maximum size that will be stored in memory.
-upload.setSizeThreshold(getSizeThreshold(ac));
+upload.setSizeThreshold((int) getSizeThreshold(ac));
// Set the the location for saving data on disk.
upload.setRepositoryPath(getRepositoryPath(ac));
@@ -324,8
