Re: struts-config and xslt
Steve Raeburn wrote: While messing with the struts-config_1_1.dtd, I was surprised not to find a way to name and describe the whole application. As you can have multiple config files for each module, display-name and description could really only describe the contents of each file rather than describing the application or module. (web.xml already has this info at application level). You're right it would be module level information. My thought is that while not read or used by struts it keeps a useful summary description with the struts-config.xml that could then be digested/processed by some other tool like maven when generating documentation. Would this still be meaningful? I think description probably would but I'm not sure about display-name. I was assuming display-name was the same as saying 'a short 1 to 5' word descriptive phrase. It certainly couldn't/shouldn't be the module name. -Rob Steve -Original Message- From: Rob Leland [mailto:[EMAIL PROTECTED] Sent: August 4, 2003 6:26 PM To: Struts Developers List Subject: Re: struts-config and xslt Jonas Björnerstedt wrote: Hello, Having to evaluate an xml editor (I won't say which), I decided to use struts-config.xml as an example. After some hours wrestling with the program, this is the result I got: http://bjornerstedt.org/struts-config.html It is the config file from the struts-example application. It was created using: http://bjornerstedt.org/struts-config_1_1.xslt It's not that pretty (especially not in Mozilla). I am sure others can do it better, but given that it is rather easy to create an xslt, I think it would be a good idea to include one in Struts. Not only does it make the file more readable for large applications, it can also be used to make the xml - editor a decent Struts editor. While messing with the struts-config_1_1.dtd, I was surprised not to find a way to name and describe the whole application. Specifically, I would like to see display-name and description added to the struts-config element in the dtd: !ELEMENT struts-config (display-name?, description?, data-sources?, form-beans?, global-exceptions?, global-forwards?, action-mappings?, controller?, message-resources*, plug-in*) This seems reasonable, if no others object I'll change the dtd to add this info. However, I see no reason for struts itself to read in this information. If you want this info in your application you can use the resource files. instead of: !ELEMENT struts-config (data-sources?, form-beans?, global-exceptions?, global-forwards?, action-mappings?, controller?, message-resources*, plug-in*) Descriptions should be available at all levels. Jonas - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius.
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/configActionConfig.java
[EMAIL PROTECTED] wrote: jmitchell2003/08/04 05:06:46 Modified:src/share/org/apache/struts/config ActionConfig.java Log: Fix comments. Submitted by Rob Leand ;) This is actually a bug from me. When I renamed everything from 'application' to 'module' I overlooked these. Thanks ! -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-config and xslt
Jonas Björnerstedt wrote: Hello, Having to evaluate an xml editor (I won't say which), I decided to use struts-config.xml as an example. After some hours wrestling with the program, this is the result I got: http://bjornerstedt.org/struts-config.html It is the config file from the struts-example application. It was created using: http://bjornerstedt.org/struts-config_1_1.xslt It's not that pretty (especially not in Mozilla). I am sure others can do it better, but given that it is rather easy to create an xslt, I think it would be a good idea to include one in Struts. Not only does it make the file more readable for large applications, it can also be used to make the xml - editor a decent Struts editor. While messing with the struts-config_1_1.dtd, I was surprised not to find a way to name and describe the whole application. Specifically, I would like to see display-name and description added to the struts-config element in the dtd: !ELEMENT struts-config (display-name?, description?, data-sources?, form-beans?, global-exceptions?, global-forwards?, action-mappings?, controller?, message-resources*, plug-in*) This seems reasonable, if no others object I'll change the dtd to add this info. However, I see no reason for struts itself to read in this information. If you want this info in your application you can use the resource files. instead of: !ELEMENT struts-config (data-sources?, form-beans?, global-exceptions?, global-forwards?, action-mappings?, controller?, message-resources*, plug-in*) Descriptions should be available at all levels. Jonas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/configActionConfig.java
[EMAIL PROTECTED] wrote:
jmitchell2003/08/03 07:18:03
Modified:src/share/org/apache/struts/config ActionConfig.java
Log:
Fix comments. Submitted by Michael Rimov.
Revision ChangesPath
1.13 +5 -5 jakarta-struts/src/share/org/apache/struts/config/ActionConfig.java
Index: ActionConfig.java
===
RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/config/ActionConfig.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ActionConfig.java 4 Jul 2003 21:25:23 - 1.12
+++ ActionConfig.java 3 Aug 2003 14:18:03 - 1.13
@@ -651,7 +651,7 @@
/**
- * Return the form bean configurations for this application. If there
+ * Return all forward configurations for this application. If there
Should this be 'module' instead of 'application' ?
* are none, a zero-length array is returned.
*/
public ForwardConfig[] findForwardConfigs() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-
Rob Leland (703-525-3580)
Choose a job you love, and you will never have to work a day of your life.
-Confucius.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
Ted Husted wrote: I use many utilities Actions like these, and the result is that fewer *custom* Actions are needed. I think increasing the number of standard Actions in the distribution is a very good idea. It makes Struts more accessible to newcomers, saves everyone from reimplementing the same design, and leverages the fact that Actions are singletons. -Ted. How about struts-tools distribution named after the velocity-tools. These would be classes that could be used stand-alone or in pairs. Tnen we could place those orphan RequestUtils absoluteURL, and other utilities there. It would have a package structure o.a.s.tools.(util, actions, ) -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
David Graham wrote: --- Rob Leland [EMAIL PROTECTED] wrote: Ted Husted wrote: I use many utilities Actions like these, and the result is that fewer *custom* Actions are needed. I think increasing the number of standard Actions in the distribution is a very good idea. It makes Struts more accessible to newcomers, saves everyone from reimplementing the same design, and leverages the fact that Actions are singletons. -Ted. How about struts-tools distribution named after the velocity-tools. These would be classes that could be used stand-alone or in pairs. Tnen we could place those orphan RequestUtils absoluteURL, and other utilities there. It would have a package structure o.a.s.tools.(util, actions, ) I think unused methods/classes should be deprecated and removed. We shouldn't be carrying around excess unused utility code just because a user *might* be using them. I agree they should be moved from the core package. And moved to an optional package. -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
David Graham wrote: --- Rob Leland [EMAIL PROTECTED] wrote: David Graham wrote: --- Rob Leland [EMAIL PROTECTED] wrote: Ted Husted wrote: I use many utilities Actions like these, and the result is that fewer *custom* Actions are needed. I think increasing the number of standard Actions in the distribution is a very good idea. It makes Struts more accessible to newcomers, saves everyone from reimplementing the same design, and leverages the fact that Actions are singletons. -Ted. How about struts-tools distribution named after the velocity-tools. These would be classes that could be used stand-alone or in pairs. Tnen we could place those orphan RequestUtils absoluteURL, and other utilities there. It would have a package structure o.a.s.tools.(util, actions, ) I think unused methods/classes should be deprecated and removed. We shouldn't be carrying around excess unused utility code just because a user *might* be using them. I agree they should be moved from the core package. And moved to an optional package. I have a few concerns with this. First, it's more work to maintain this new optional package with build files, tests, distribution, etc. Second, it's likely that the unused code would decay because Struts isn't using it. Since we don't currently have a struts-contrib or struts-tools distribution I would agree. Once that is in place I believe that would change. Also, it's confusing to have some actions in o.a.s.tools.actions and some in o.a.s.actions. I think *all* standard actions that are distributed with Struts should live in o.a.s.actions. or moved into the tools jar. I agree with what you said : I think unused methods/classes should be deprecated and removed. If the struts core doesn't use it then it doesn't belong in the core, and should be moved to a seperate jar. That includes any actions David -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius.
Re: Addition of two new actions
David Graham wrote: I have a few concerns with this. First, it's more work to maintain this new optional package with build files, tests, distribution, etc. Second, it's likely that the unused code would decay because Struts isn't using it. Since we don't currently have a struts-contrib or struts-tools distribution I would agree. Once that is in place I believe that would change. Also, it's confusing to have some actions in o.a.s.tools.actions and some in o.a.s.actions. I think *all* standard actions that are distributed with Struts should live in o.a.s.actions. or moved into the tools jar. I agree with what you said : I think unused methods/classes should be deprecated and removed. If the struts core doesn't use it then it doesn't belong in the core, and should be moved to a seperate jar. That includes any actions So you're proposing that all of the current actions be separated from the standard Struts distro jar? Yes, and if it is documented and deprecated over enough time, then by struts 1.4 they could be removed. It's one way to get a lean struts-core. How do we make a distinction between the 'actions' classes and come other methods()/classes say under the util package about which stays and which goes. Whats the reasoning ? I think that will be highly confusing. No more so than going from struts 1.0 - 1.1 where the import statements changed for BeanUtils had to change. And much less confusing than pulling out the TagUtil from RequestUtils, which requires changing imports and code, instead of just the import statements. Choose a job you love, and you will never have to work a day of your life. -Confucius. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius.
Re: Addition of two new actions
Steve Raeburn wrote: I would prefer going with simpler, specialised classes than a monolithic DispatchAction +1, I am infavor of the simpler classes. They are easier to understand, maintain and modify. but if there is a consensus to combine them then I accept your point. A combined action may perhaps offer more flexibility. A concrete subclass might be able to resolve the method in different ways depending on what was present at runtime. (request parameter, parameter, key). However, I'm not sure that flexibility justifies the increased complexity of the class or of understanding how to use it. Potential areas for user +1, I have see too many struts based programs heap the functionality into Action classes, and they are a bear to maintain. The same is true in any class, and having a simpler DispatchAction class is a cleaner way to go. confusion would be misunderstanding the order of preference for resolving the method names or not recognizing conflicts that could arise between them. Also, what happens if we need to resolve by other means? Add more weight to the super class or add another specialized sub class? To summarize: - I think we definitely need the functionality that ParameterDispatchAction offers. - If the actions are combined, the result needs to be just as extensible and easy to understand as keeping them separate. - I would rather not combine them, but I'm open to ideas that satisfy the previous two points. Steve Again, I am infavor of the simpler classes. - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Refactoring RequestUtils
David Graham wrote: The movement of JSP specific methods to TagUtils is nearly completed except for moving the externalized messages. I'd like to refactor RequestUtils even more to reduce its hefty size. There are 2 distinct groups of methods: URL related and Module related. 1. I suggest we move the module methods into a new ModuleUtils class. 2. I would suggest that there also be a UrlUtils class except that 4 of the URL methods aren't used in Struts and 2 of them should be moved into TagUtils. serverURL(), absoluteURL(), actionURL(), and printableURL() are not used. absoluteURL() is the original method in RequestUtils January 05 2001, and was originally used by the Include, Link, and Redirect tags in struts Beta 1. It was removed from these tags in May 2001, and replaced by inline stringBuffer appends. actionURL() was contributed by Chris Smith Jan 25 2001, as part of the FormTag but was migrated later to the ReuqestUtils. Two options come to mind, deprecation or place it in a 'user space' set of utilities. These would be convience methods not used by struts but available for a user. I am +1 on either route encodeURL() and pageURL() should go to TagUtils. What do we do with the 4 unused methods? Thoughts? David __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts build.xml
Steve: Be sure to fill out the doc/volunteers.xml when you have a chance. - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator - ValidWhen ] Bug or unneeded variable.
James Turner wrote:
It's auto-generated code, so you can talk to the ANTLR folks if you want
:-)
I was hoping for you would volunteer to take a look at the generated
code when you have the chance. :-D
This would be helpful since I haven't used validwhen, and
am less motovated than someone who has a *live* site using the code. ;-)
Then how do we handle *maintaining* generated code ?
a) manually fix any bugs.
b) wait for antlr bug fixes then recreate the files.
Rob
James
-Original Message-
From: Rob Leland [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 27, 2003 1:17 AM
To: Struts Developers List
Subject: [validator - ValidWhen ] Bug or unneeded variable.
James:
The variable 'theRetToken' is assigned but never used in
method nextToken() Instead _returnToken is always returned.
So it appears that theRetToken is unneeded, or this is a bug.
Also the method mWS()
on line 272:
_ttype = Token.SKIP;
if ( _createToken _token==null _ttype!=Token.SKIP ) {
}
so the if statement will never be executed.
--
Rob Leland
-
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]
--
Rob Leland
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/htmlJavascriptValidatorTag.java
David Graham wrote: I think we should only place @since tags on methods in the public API (public and protected). agreed, 1+ -- Rob Leland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts build.properties.sample
James Mitchell wrote: I'm the one to blame on that one. Sorry, it was on my todo list, somewhere between make more money and save marriage.I hope you understand. Are you kidding ? You've been pretty consistent in fixing and posting patches, and there is talk of scrapping the ant build anyway... I just happen to be in a rare spirt mode. -- Rob Leland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/htmlTestFrameTag1.jsp TestFrameTag3.jsp TestFrameTag5.jsp TestFrameTag7.jsp TestImgTag1a.jspTestImgTag3a.jsp TestImgTag5a.jsp TestImgTag7a.jsp TestLinkTag1.jsp TestLinkTag3.jspTestLinkTag4.jsp TestLinkTag5.jsp TestLinkTag6.jsp TestLinkTag7.jsp TestLinkTag8.jsp
FYI I updated the unit tests but the commit message was too large, here is an example of the change. rleland 2003/07/26 23:29:11 Modified:web/test/test/org/apache/struts/taglib/html TestFrameTag1.jsp TestFrameTag3.jsp TestFrameTag5.jsp TestFrameTag7.jsp TestImgTag1a.jsp TestImgTag3a.jsp TestImgTag5a.jsp TestImgTag7a.jsp TestLinkTag1.jsp TestLinkTag3.jsp TestLinkTag4.jsp TestLinkTag5.jsp TestLinkTag6.jsp TestLinkTag7.jsp TestLinkTag8.jsp Log: Update jsp tests to use TagUtils.computeURL methods. Revision ChangesPath 1.2 +8 -8 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag1.jsp Index: TestFrameTag1.jsp === RCS file: /home/cvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestFrameTag1.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- TestFrameTag1.jsp 7 Mar 2003 05:39:10 - 1.1 +++ TestFrameTag1.jsp 27 Jul 2003 06:29:11 - 1.2 @@ -87,7 +87,7 @@ /bean:define bean:define id=thisMap name=paramMap type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.util.RequestUtils.computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -98,7 +98,7 @@ /bean:define bean:define id=thisMap name=paramPropertyMap property=map type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.util.RequestUtils.computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -108,7 +108,7 @@ /bean:define bean:define id=thisMap name=paramMap type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.util.RequestUtils.computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -118,7 +118,7 @@ /bean:define bean:define id=thisMap name=paramPropertyMap property=map type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.util.RequestUtils.computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -128,7 +128,7 @@ /bean:define bean:define id=thisMap name=paramMap type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.util.RequestUtils.computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -138,7 +138,7 @@ /bean:define bean:define id=thisMap name=paramPropertyMap property=map type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.util.RequestUtils.computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -148,7 +148,7 @@ /bean:define bean:define id=thisMap name=paramMap type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.util.RequestUtils.computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% /bean:define /logic:equal @@ -158,7 +158,7 @@ /bean:define bean:define id=thisMap name=paramPropertyMap property=map type=java.util.Map/ bean:define id=EXPECTED_RESULTS toScope=page - frame src=%=org.apache.struts.util.RequestUtils.computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% + frame src=%=org.apache.struts.taglib.TagUtils.getInstance().computeURL(pageContext, simpleForward, null, null, null, thisMap, null, false)% /bean:define /logic:equal -- Rob Leland
Re: [validator - ValidWhen ] Bug or unneeded variable.
James Turner wrote:
It's auto-generated code, so you can talk to the ANTLR folks if you want
:-)
Did you check in the files to CVS that were used to generate the .java
files, or could you ?
-Rob
James
-Original Message-
From: Rob Leland [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 27, 2003 1:17 AM
To: Struts Developers List
Subject: [validator - ValidWhen ] Bug or unneeded variable.
James:
The variable 'theRetToken' is assigned but never used in
method nextToken() Instead _returnToken is always returned.
So it appears that theRetToken is unneeded, or this is a bug.
Also the method mWS()
on line 272:
_ttype = Token.SKIP;
if ( _createToken _token==null _ttype!=Token.SKIP ) {
}
so the if statement will never be executed.
--
Rob Leland
--
Rob Leland
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionServlet init parameters [WAS] Re: cvs commit: jakarta-struts/src/share/org/apache/struts/actionActionServlet.java
Craig R. McClanahan wrote: On Sat, 26 Jul 2003, David Graham wrote: Date: Sat, 26 Jul 2003 11:35:23 -0700 (PDT) From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: ActionServlet init parameters [WAS] Re: cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java What is the overall strategy for servlet parameters vs. struts-config controller attributes? We moved most of the init parameters to the controller element so I'm inclined to say that this should be defined there as well. Are there any reasons that it *must* be a servlet init parameter? The informal policy I applied on the initial migration was anything specific to a module goes into struts-config.xml, anything global to ActionServlet stays an init parameter. I think that rule still makes sense, but obviously it's worth reviewing. I am **assuming** the configFactory and the implementing ModuleConfig implementation class could add more info to the struts-config.xml. It seemed easier, to specify that in the ActionServlet parameters. If a parameters were changed/added then a new DTD would need to be registered with the digester, this seems like something you would want to do before processing of the struts-config.xml. Thus the factory would need to be know before hand, or the struts-config.xml would need to be processed twice. Once non validating, to pull off the struts-config className=org.apache.struts.config.impl.NewModuleConfigFactory /struts-config class info. That class would then register any new DTD and ConfigRuleSet() items. Right now the ModuleConfig is just a container populated by the rules setup in ConfigRuleSet(). Long term it might be useful to work towards a set of api's, so the ModuleConfigImpl or some other class under impl class registered the DTD for the struts-config.xml it needs. -Rob David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rob Leland
Re: [Vote] Don Brown as committer
James Mitchell wrote: Don has been involved with Struts for quite some time and has submitted [X] +1 - I agree. [ ] +0 - I agree, but think we should wait until he can recite the servlet spec verbatim. [ ] -0 - I disagree, but not enough to stop the train. [ ] -1 - I disagree and my reason(s) are/is .. Don, I wasn't familar with your name but after searching Google, I see that you developed stxx, Struts Cocoon adaptor, BFS scripting for struts, Action pattern matching, it also looks like you are familar with JetSpeed (Not sure) ... -- Rob Leland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nightly build is generating empty binary distribution file
Craig R. McClanahan wrote: On Sun, 20 Jul 2003, Steve Raeburn wrote: Date: Sun, 20 Jul 2003 22:21:16 -0700 From: Steve Raeburn [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Nightly build is generating empty binary distribution file I've noticed that the nightly build is not generating the binary distribution. There is an archive created but it's only 45 bytes. http://cvs.apache.org/builds/jakarta-struts/nightly/ As the gump build is working it looks like a configuration problem is preventing the files being copied/archived. Could this be to due to the build version number change from 1.1 to 1.2? I couldn't find any documentation on configuring the nightly build process so I can't confirm or fix the problem. Can someone please take a look and/or point me in the direction of some info on the nightly build config? It's running on my personal desktop (which recently went through a hard disk failure and replacement). Unfortunately, I've only got JDK 1.4.2 installed right now, and compiling struts-legacy requires 1.3 or before to compile :-(. In the top level build.properties file set jdk.version=1.4 and you'll be able to build. -Rob Thanks Steve Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rob Leland
Re: Error with release-notes-1.0.xml in build
David M. Karr wrote: I was working on updating Struts-EL with the recent changes to the base tag library. I haven't updated in a while. After I fixed some other minor setup issues, I got to the following: - Processing C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\doc\userGuide\release-notes-1.0.xml to C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\target\documentation\userGuide\release-notes-1.0.html : Fatal Error! java.lang.ArrayIndexOutOfBoundsException Cause: java.lang.ArrayIndexOutOfBoundsException Failed to process C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\doc\userGuide\release-notes-1.0.xml BUILD FAILED file:C:/cygwin/home/dmkarr/work/jakartacvs/jakarta-struts/build-webapps.xml:207: Fatal error during transformation - With the latest CVS update, It works for me... [style] Processing D:\Projects\Apache\jakarta-struts-current\doc\userGuide\release-notes-1.0.xml to D:\Projects\Apache\jakarta-struts-current\target\documen tation\userGuide\printer\release-notes-1.0.html [style] Processing D:\Projects\Apache\jakarta-struts-current\doc\userGuide\installation-oas.xml to D:\Projects\Apache\jakarta-struts-current\target\document ation\userGuide\printer\installation-oas.html I am useing Xerces 1.4.4 and Xalan 2.5 -Rob I didn't find anything like this in the archives. Any idea what this might be? -- Rob Leland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm.getMap() change
David Graham wrote: DynaActionForm.getMap() returns the Map that the properties are stored in without copying it to a new Map instance or wrapping it in an unmodifiable Map. IMO, we should treat that method with much more care and return an unmodifiable view of the Map considering it's mainly to be used in JSTL tags. Does this solve a problem that you or others have encountered in practice ? -Rob Is anyone opposed to this idea? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/actionActionServlet.java
I wanted to pull this over to the 1_1_BRANCH but can't find what
property file
'configWebXml' is defined in. Shouldn't it be in the
LocalString.properties file
or ActionResource.properties file ?
[EMAIL PROTECTED] wrote:
dgraham 2003/07/02 21:44:13
Modified:src/share/org/apache/struts/action ActionServlet.java
Log:
Throw more descriptive exception if web.xml isn't found. PR# 21203.
Revision ChangesPath
1.158 +9 -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.157
retrieving revision 1.158
diff -u -r1.157 -r1.158
--- ActionServlet.java 3 Jul 2003 03:43:37 - 1.157
+++ ActionServlet.java 3 Jul 2003 04:44:13 - 1.158
@@ -1082,6 +1082,11 @@
InputStream input =
getServletContext().getResourceAsStream(/WEB-INF/web.xml);
+
+if (input == null) {
+log.error(internal.getMessage(configWebXml));
+throw new ServletException(internal.getMessage(configWebXml));
+}
try {
digester.parse(input);
-
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: [VOTE-RESULT] Steve Raeburn as a Struts Committer
Steve Raeburn wrote: I'm getting the long delay just using Putty interactively. But as you've mentioned Eclipse seems to authenticate at least twice during a checkout. Also, I've never had problems using anonymous CVS so it does seem to be SSH related. I'll try Craig's suggestion and take a look at MindTerm tomorrow. Steve I used MindTerm 1.X which worked well, but they made version 2.X commercial and you need to use a web page applet to start it, yech ! I have been useing WinCVS with CYGWIN ssh together under W2K for 2 years now. Here is my shell script I start for ssh tunneling : echo on ssh -L 2401:localhost:2401 -l rleland -N cvs.apache.org pause Then start up either WinCVS or the command line cvs client with Root=:pserver:[EMAIL PROTECTED]:/home/cvs then you'll be good to go. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts 1.1 branch
Were we going to maintain a struts 1.1 branch, or just go forward like ant and other projects. I know we had talked about doing away with beta's/RC's and just releasing 1.1.x, 1.2.x Thoughts? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validwhen returns, need some pixie dust on the nightly buildmachine
James Turner wrote: Ummm, ok... Where does it live? James -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Tuesday, July 01, 2003 3:31 PM To: [EMAIL PROTECTED] Subject: Re: Validwhen returns, need some pixie dust on the nightly build machine James, you'll need to update the Gump descriptor too, otherwise we're going to start seeing Gump failure messages again. ;-( -- Martin Cooper Check out gump from cvs.apache.org and add a dependancy to the jakarta-struts.xml. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Modular Struts Examples
Ted Husted wrote: I'd like to propose that we gather together the struts-documentation, struts-example (MailReader), struts-exercise-taglib, struts-upload, struts-validator, and tiles-documentation I am curretly -0 on this. I don't like smashing --all-- the examples into one example simply because it would be too much of a bite for new users to swallow. Tiles already uses modules as part of it's documentation. Having the : struts-example (MailReader), struts-upload, struts-validator as a single application seem reasonable. Perhaps we can structure them so they are both standalond and modules ? -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - jakarta-struts
The Gump build is going to fail again, tomorrow morning, I have been babysitting the different gump machines. I'd appreciate it if someone that has the time could see what I am missing. I have been tweaking the struts build.xml and it looks like it should really work. The only funny thing is that the target is for the struts-legacy.jar is under struts/target/class instead of contrib/struts-legacy/target/class but the jar produced is correct. When the main build starts it copies the right number of jars to the dist directory, I am assuming that includes the struts-legacy.jar. It's got to be something simple ! An alternate approach is to revert the gump/project/jakarta-struts.xml back to version 1.35 and use that as a base for the gump build with two projects. -Rob Christopher Lenz wrote: Martin Cooper wrote: On Mon, 23 Jun 2003, James Mitchell wrote: On Monday 23 June 2003 11:18, Christopher Lenz wrote: I don't think the Gump builds have anything todo with the nightly builds of Struts. The Gump descriptors are in the jakarta-gump directory on cvs.apache.org, and every Apache committer has commit access to that directory. http://jakarta.apache.org/gump/ Yes, that sounds like what I was vaguely remembering. So, at this point, noone can fix this but Craig? No, any Jakarta committer can fix it. The issue is one of figuring out how to modify the Struts Gump descriptor to build struts-legacy first, and then have the main build refer to that. Any committer can check in the change, we just need to figure out what that change looks like. ;-) Revision 1.35 of the Gump descriptor looked a lot better than the current one IMHO. Basically, there need to be two projects: - jakarta-struts-legacy, which builds the struts-legacy JAR - jakarta-struts, which depends on the jakarta-struts-legacy project A glue project as in Revision 1.35 should not be needed. The important thing is that the 'dist' target of the main Struts build-file should not try to build struts-legacy. And without having looked at the Struts build file, I suspect there's some kind of chicken egg problem lurking ;-) - chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Final Release
-- Vote: Struts 1.1 Final Release Plan [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts build.xml
James Mitchell wrote: On Tuesday 24 June 2003 01:45, [EMAIL PROTECTED] wrote: rleland 2003/06/23 22:45:13 Modified:.build.xml Log: Change version by adding '-post' to verify that gump is indeed using an old struts build.xml file not the current one. Revision ChangesPath 1.109 +1 -1 jakarta-struts/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-struts/build.xml,v retrieving revision 1.108 retrieving revision 1.109 diff -u -r1.108 -r1.109 --- build.xml 19 Jun 2003 03:30:46 - 1.108 +++ build.xml 24 Jun 2003 05:45:13 - 1.109 @@ -137,7 +137,7 @@ property name=project.name value=jakarta-struts/ !-- Version of the project -- -property name=project.version value=1.1-rc2/ +property name=project.version value=1.1-rc2-post/ Should that be 1.1-dev? That's would be ok. The main thing is look at the [GUMP] failed build. You'll see that the version echoed out was 1.1-rc2, and not 1.1-rc2-post which it should have been if it was using the most recient CVS version of build.xml !! -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - jakarta-struts
James Mitchell wrote: On Monday 23 June 2003 11:43, Martin Cooper wrote: On Mon, 23 Jun 2003, James Mitchell wrote: On Monday 23 June 2003 11:18, Christopher Lenz wrote: I don't think the Gump builds have anything todo with the nightly builds of Struts. The Gump descriptors are in the jakarta-gump directory on cvs.apache.org, and every Apache committer has commit access to that directory. http://jakarta.apache.org/gump/ Yes, that sounds like what I was vaguely remembering. So, at this point, noone can fix this but Craig? No, any Jakarta committer can fix it. The issue is one of figuring out how to modify the Struts Gump descriptor to build struts-legacy first, and then have the main build refer to that. Any committer can check in the change, we just need to figure out what that change looks like. ;-) Ok ok!! So I'm lazy ;) I finally got around to reading this: http://jakarta.apache.org/gump/faq.html So, unless anyone else gets to it first, I'll try to fix this tonight. I had tried creating a second project in Gump. Use CVS to look at the previos versions of the jakarta-struts.xml file. From the GUMP output it appears that the struts-legacy project worked. I used that as a dependancy for the 'struts-core' project and that is where it couldn't find the struts-legacy.jar. James, Let me give it --one-- more shot tonight. I believe what I need to do is not copy the struts-legacy.jar with the other jars at first but delay it's copying until after it is built. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - jakarta-struts
James Mitchell wrote: On Monday 23 June 2003 11:43, Martin Cooper wrote: On Mon, 23 Jun 2003, James Mitchell wrote: On Monday 23 June 2003 11:18, Christopher Lenz wrote: I don't think the Gump builds have anything todo with the nightly builds of Struts. The Gump descriptors are in the jakarta-gump directory on cvs.apache.org, and every Apache committer has commit access to that directory. http://jakarta.apache.org/gump/ Yes, that sounds like what I was vaguely remembering. So, at this point, noone can fix this but Craig? No, any Jakarta committer can fix it. The issue is one of figuring out how to modify the Struts Gump descriptor to build struts-legacy first, and then have the main build refer to that. Any committer can check in the change, we just need to figure out what that change looks like. ;-) Ok ok!! So I'm lazy ;) I finally got around to reading this: http://jakarta.apache.org/gump/faq.html So, unless anyone else gets to it first, I'll try to fix this tonight. Also looking at the gump output at : http://cvs.apache.org/builds/gump/latest/jakarta-struts.html It looks like it is building with an old version of the struts build.xml file. Notice the targets: When gump executes the 'dist' target we get: init: [echo] - jakarta-struts 1.1-rc2 - prepare.dist prepare.library: is printed out. when I do a 'ant dist' from a clean state I get, and should get : dist.legacy: init: [echo] -- Struts Legacy Distribution 1.1-rc2 -- prepare: resources: compile: docs: init: [echo] - jakarta-struts 1.1-rc2 - Let me post this on the gump list to get some feedback. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - jakarta-struts
I am sure this is occuring because the target is set to the base struts directory, and so there are no *.class files to generate a struts-legacy.jar though the .class files are probably still in the main struts.jar. I'll try creating two seperate projects under gump to see if this solves the problem. I've have gump in CVS but I'll try the first iteration w/o trying to install and run gump locally. If I botched it I'll bite the bullet and install gump locally. -Rob Craig McClanahan wrote: This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-06-18/jakarta-struts.html Buildfile: build.xml dist.legacy: init: [echo] -- Struts Legacy Distribution 1.1-rc2 -- prepare: [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/target [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/target/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/target/classes/META-INF [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/target/conf [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/contrib/struts-legacy/dist [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/contrib/struts-legacy/dist/docs [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/contrib/struts-legacy/dist/docs/api resources: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/classes [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/classes/META-INF [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/conf [copy] Replacing: @name@ - Struts Legacy Distribution [copy] Replacing: @version@ - 1.1-rc2 compile: [javac] Compiling 1 source file to /home/rubys/jakarta/jakarta-struts/target/classes docs: [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.struts.legacy... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.4.1 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /home/rubys/jakarta/jakarta-struts/contrib/struts-legacy/dist/docs/api/stylesheet.css... dist: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/contrib/struts-legacy/dist [jar] Building jar: /home/rubys/jakarta/jakarta-struts/contrib/struts-legacy/dist/struts-legacy.jar init: [echo] - jakarta-struts 1.1-rc2 - [echo] java.class.path = /home/rubys/jakarta/xml-commons/java/external/build/xml-apis.jar:/home/rubys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-xerces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build/xalan-unbundled.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/java/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/home/rubys/jakarta/ant/dist/lib/ant.jar:/home/rubys/jakarta/ant/dist/lib/ant-jmf.jar:/home/rubys/jakarta/ant/dist/lib/ant-junit.jar:/home/rubys/jakarta/ant/dist/lib/ant-stylebook.jar:/home/rubys/jakarta/ant/dist/lib/ant-swing.jar:/home/rubys/jakarta/ant/dist/lib/ant-trax.jar:/home/rubys/jakarta/ant/dist/lib/ant-xalan2.jar:/home/rubys/jakarta/ant/dist/lib/nodeps.jar:/opt/jdbc2_0/jdbc2_0-stdext.jar:/home/rubys/jakarta/jakarta-servletapi-4/lib/servlet.jar:/home/rubys/jakarta/jakarta-commons/beanutils/dist/commons-beanutils.jar:/home/rubys/jakarta/jakarta-commons/collections/dist/commons-collections.jar:/home/rubys/jakarta/jakarta-commons/digester/dist/commons-digester.jar:/home/rubys/jakarta/jakarta-commons/fileupload/target/commons-fileupload-20030618.jar:/home/rubys/jakarta/jakarta-commons/lang/dist/commons-lang-20030618.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/commons-logging.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/commons-logging-api.jar:/home/rubys/jakarta/jakarta-commons/validator/dist/commons-validator.jar:/home/rubys/jakarta/jakarta-oro/jakarta-oro-20030618.jar:/home/rubys/jakarta/jakarta-struts/target/library/classes:/home/rubys/jakarta/jakarta-struts/target/tiles/library/classes [echo] java.home = /usr/java/j2sdk1.4.1_02/jre [echo] user.home = /home/rubys prepare.dist: [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/dist/webapps prepare.library: [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF/tlds [mkdir] Created dir: /home/rubys/jakarta/jakarta-struts/target/library/classes/org/apache/struts/resources [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF [copy] Copying 8 files
Re: cvs commit: jakarta-struts build.xml
James Mitchell wrote:
On Wednesday 18 June 2003 23:30, [EMAIL PROTECTED] wrote:
rleland 2003/06/18 20:30:46
Modified:.build.xml
Log:
Roll back changes so that inorder to build struts,
a user must first go to the contrib.struts-legacy
directory and do a seperate build. This was done because
when a recursive build was performed the target was set to the
top, level of struts instead of contrib/struts-legacy/target which
resulted in the struts-legacy.jar file not being created.
This may have absolutely nothing to do with the gump build, and forgive me for
mentioning this late, but I am able to build to build the entire distribution
by changing only 2 things from the build.properties.sample.
- add the key jdk.version={specify your jdk version}
- change the key
from:
../struts-legacy.jar=contrib/struts-legacy/dist/struts-legacy.jar
to:
struts-legacy.jar=contrib/struts-legacy/dist/struts-legacy.jar
Your right, I looked at the gump build and in the previous version I had
defined
the jdk.version but not the struts-legacy.jar path ! I'll rollback that
version tomorrow,
and change the struts build file to again to do an integrated build,
which I like better
which is the reason I made the change in the first place. I am going to
let the gump
build attempt to build tonight just to see if I got the definition of
building two projects
in a module right. I also have 0 experience with gump.
Thanks,
Rob
After making those changes, ant dist works fine.
Sorry, but I'm not schooled in the ways of gump.
Gump now builds struts-legacy as a seperate target.
Revision ChangesPath
1.108 +2 -20 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.107
retrieving revision 1.108
diff -u -r1.107 -r1.108
--- build.xml 11 Jun 2003 18:19:35 - 1.107
+++ build.xml 19 Jun 2003 03:30:46 - 1.108
@@ -395,15 +395,6 @@
/target
!--
-Construct distributable struts legacy support for datasources
---
-target name=dist.legacy
-ant antfile=build.xml dir=contrib/struts-legacy
- target=dist/
-/target
-
-
-!--
Build the contrib modules that are packaged with the binary
--
target name=dist.contrib depends=dist.source if=jstl.jar
@@ -427,7 +418,7 @@
Construct complete binary distribution
--
target name=dist
-
depends=dist.legacy,dist.library,dist.webapps,dist.source,dist.contrib +
depends=dist.library,dist.webapps,dist.source,dist.contrib
description=Construct binary distribution/
!--
@@ -727,20 +718,11 @@
/copy
/target
-
-!--
- Clean struts legacy distribution
---
-target name=clean.legacy
-ant antfile=build.xml dir=contrib/struts-legacy
-inheritall=false target=clean/
-/target
-
!--
Clean up build and distribution directories
--
-target name=clean depends=clean.legacy
+target name=clean
description=Clean build and distribution directories
delete dir=${build.home}/
delete dir=${dist.home}/
-
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: VOTE (enough already!): Release Struts RC2 with FileUpload Beta2
James Turner wrote: From: David Graham [mailto:[EMAIL PROTECTED] +1 I agree that deprecating methods does not require a new beta. We don't guarantee backwards compatibility between betas. James, can you act as release manager for RC2? Sounds like Martin won't have time to do it. David I'd be happy to, if A) someone will grant me karma on the Jakarta web site and B) someone can walk me through the basic steps involved, as I've deferred to Martin Release Addict Cooper on these matters in previous releases I've managed. James I don't know if there is a guide for 'release-managers' . I believe commons has one. What is publicly done is to create a release proposal, comitters look over it and agree those are the criteria. I beleive the struts 1.1 beta 3, release plan is a good template. http://jakarta.apache.org/site/decisions.html http://jakarta.apache.org/struts/proposals/release-plan-1.1b3.html http://jakarta.apache.org/struts/proposals/release-plan-1.1rc1.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's RC1?
After fixing the DTD reference in the struts-config.xml it appears that all tests passed, unlike the earlier email I sent you. Though I am not sure about the last test since it doesn't seem to report any failure count. [junit] Testcase: testMultiFactory took 2.003 sec [junit] Testcase: testSingleSharedFactory took 0.1 sec [junit] Testcase: testUtilBaseEnvironment took 0 sec stop.tomcat.40: [java] Stopping service Tomcat-Standalone [runservertests] Server stopped ! BUILD SUCCESSFUL Is it supposed to report the Failures like the other tests [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.113 sec ^ -Rob Martin Cooper wrote: I know this is the question on the tip of all struts-dev folks' tongues. First of all, I do apologise for taking so long to get this puppy out. The tag happened on time, but this has been an insane week at my day job, and I've had little time to validate the build. (My employer announced an acquisition on Wednesday, which added some extra hooplah to the week too...) In any case, running the Cactus tests tonight, I have a problem. On all of the Tomcat versions I've tried so far (4.1.18, 4.0.6, 3.3.1), I get a test failure in the Tiles tests. The relevant part of the output follows: - cut here - [junit] Testcase: testMultiFactory took 2.544 sec [junit] Caused an ERROR [junit] junit.framework.Assert.assertNotSame(Ljava/lang/String;Ljava/lang/Ob ject;Ljava/lang/Object;)V [junit] at org.apache.struts.tiles.TestTilesPlugin.testMultiFactory(Test TilesPlugin.java:236) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces sorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet hodAccessorImpl.java:25) [junit] Testcase: testMultiFactory - cut here - There was a flurry of messages on the Cactus tests on this list recently, but this does not appear to be related to the problems described therein. Obviously, I need to determine whether this is a bug that we need to fix prior to RC1, or if I somehow messed up my system. (I have been able to run the Cactus tests in the past.) Therefore, I'd appreciate it if someone else could take the tests for a spin, and let me know the results. Thanks! -- Martin Cooper - 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: IncludeTag
James Mitchell wrote: Hmmm...no takers on this one eh? Here is a guess... It looks like to name an anchor point for items that are included when a hyperlink is generated, possably using JavaScript.. It was added May 09 2001 By Craig, In version 1.13 of the Tag. In that version the RequestUtils.computeURL() method was created and a bunch of code removed, that I assume became computeURL() The log reads as follows: Refactor the hyperlink-generation code used in the bean:include, html:link, html:rewrite, and logic:redirect tags to use common utility methods based on URLs rather than Strings.This will ensure consistency in implementation, and make it easy to provide full URL-processing functionality to other tags as necessary. pOptional anchor tag (#xxx) to be added to the generated + hyperlink. Specify this value strongwithout/strong any + # character./p Here is Buzilla request that caused the addition http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1644 That's all I have. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Release Candidate 1 Release Plan
Martin Cooper wrote: -- Vote: Struts 1.1-rc1 Release Plan [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: It's Valentine's Day, where are we?
Craig R. McClanahan wrote: The ModuleConfig context attributes are all set up at startup time, under a key of Globals.APPLICATION_KEY plus the module prefix. The ModuleConfig for the currently executing module is stored as a request attribute (under Globals.APPLICATION_KEY). FYI the APPLICATION_KEY is deprecated in favor of the MODULE_KEY which use the same string value for compatability. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla #16603] Discussion Please
Craig R. McClanahan wrote: However, at this point in time, I'm going to suggest that we resolve this one as LATER and put it into the 1.2 Family camp. +1, We have a good product and have uncovered some inconsistent behaviour. The 1.2 relase time seems appropiate. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
David Graham wrote: +1 Didn't David add the cdata/comments to the Javascript Tag that he and Martin were talking about on Thursday. It seemed that there was still disagreement that was a good thing ? Would those end up in the RC1 from the head of the CVS tree or are we voting on the STRUTS_1_1_B3 tag to become directly RC1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
On 23 Dec 2002, Martin Cooper wrote: Vote: Struts 1.1b3 Release Plan [X ] +0 I am in favor of the release, but am unable tohelp support it( On Vacation) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan
Martin Cooper wrote: So, where are we on this exactly? I believe people are OK with this Saturday for the freeze / tag date. But if we're going for that, then I need to get a revised plan out soon, and I'd rather take everything into account at once than have a second version vetoed. If I change only the date (and the bug list), is that enough? I'll be working on Struts tonight, and will check in changes later tonight. After that I'll be out on Vacation for a week. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/userGuide installation.xml
Craig R. McClanahan wrote: On 18 Dec 2002 [EMAIL PROTECTED] wrote: - Commons Services isn't yet released. AFAIK, we don't have any code in Struts 1.1 that uses this, and we've sort of replaced the original concept with plugins. Is anyone actually using it *because* it's included in the current nightly builds? Do we really need to ship (and support) this library in 1.1 final? Craig The contrib project, that Oleg originally checked in, used it. It still has some interesting JDBC code that I would like to salvage. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Short Term] Rob Leland
FYI: I am finishing up the ModuleConfig renaming by putting in factory Methods in and changing over the tests to use the Factories and ModuleConfig interfaces. I to find time to get other more important items like bugs later this week. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/userGuide installation.xml
Martin Cooper wrote: I guess we could remove the commons-services.jar from the builds, +1 Do you have any thoughts on how best to salvage the code you're interested in? Need to give it some thought. I just discovered it when I was removing unused imports and cleaning up JavaDoc, for contrib projects last week. Maybe create a contrib/utils directory ? Unofficial but gererally usefull classes. I'll have to make a list, if they aren't too many classes then see if they fit somewhere in commons, or maybe punt them over to SourceForge, before deleting them outright. SPEAKING of which After 1.1 The o.a.s.u.IteratorAdapter should probably be deprecated and punted over to commons-collections ?, or if there is already an equalivent in commons use that internally instead. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Avoid code reformating !
David Graham wrote: 3. I disagree that we should stop formatting code. We have a standard that we should be following. If we need to change that standard then we can debate that. One thing the automatic code formatters do that isn't nice is to reorder methods. I believe this was one big gripe Cedric had, and I agree. This falls --outside-- the current code guidelines. Also now that Cedric has made changes to Tiles that effectively undoes the formatting changes, will you feel obligated to reformat it again ? Dave -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan
Martin Cooper wrote: Just to let folks know, I would then suggest December 21 as the new Code Freeze / Tag Date. +1 I just realized that what I suggested went contrary to what Craig and other said that they wanted to do for new releases, go to an Ant style release numbering., which doesn't implies quality. Which I am for ! Instead of a Code freeze I guess I was referring to a feature freeze, though we were supposed to be in one for several months now. 8 if you count beta 1 release date. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: b3 minus 27? (or so)
Martin Cooper wrote: Although I'm a committer on Validator, I'm kinda just the infrastructure guy, and don't feel qualified to vouch for the patch. -- Martin Cooper Ok, Thanks and I know the feeling. I need to learn JavaScript for some other work I doing and I am taking a little extra time so I will be able to expand the Validator JS a bit more. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Removing the Consultants Page
+1, I get tired just watching you update it !!! David Graham wrote: I think Ted is in favor of dropping the Consultants page. I am as well and if you all agree then I think we should remove it. I'm personally tired of handling the requests for new links and policing the rules. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PlugIn, ApplicationConfig and Deprecated
Craig R. McClanahan wrote: Since we went to all the effort to change ApplicationConfig to ModuleConfig in the first place, we should complete the task and banish it from any non-deprecated APIs that we have. This whole change did make me pretty squeamish :-), but a half-completed change is much worse than a fully completed one. Ok, I removed the compatability PlugInPatch so developers will have to make a few changes inorder to use the 20021126 build. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc status.xml
[EMAIL PROTECTED] wrote: -pfont size=-2Website updated from CVS: 2002 NOV 17 by husted./font/p +pfont size=-2Website and Javadocs updated from CVS: 2002 NOV 21 by husted./font/p Thanks !!! -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc status.xml
[EMAIL PROTECTED] wrote: Website updated from CVS: 2002 NOV 11 by husted. + Website updated from CVS: 2002 NOV 17 by husted. The Struts Websites JavaDocs aren't been updated. I recreated the UML diagrams back in October, however the dates on the UML are from June. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: javadoc Weird state of org/apache/struts/util/AppException.java
David M. Karr wrote: When I view the file src/share/org/apache/struts/util/AppException.java in Cygwin/XEmacs (binmode), it shows up as a SINGLE line (the entire file), with linefeeds (\r in od) instead of newlines. I see just about the same in vi. I noticed David G. made some formatting changes in this file a couple of weeks ago. Apparently every other line was a blank line, for some reason? The blank lines appeared when Rob Leland made some minor changes about 7 weeks ago. In my copy, if I just replace the ^Ms (what shows in XEmacs) with a newline, the file looks fine, and the od output shows normal newlines (just like other files). I also notice that in src/share/org/apache/struts/validator, ValidatorForm.java and DynaValidatorForm.java are in the same state. I can verify that using vim under cygwin. It looks Ok using IntelliJ. I'll see if I can figure out which program is doing that and STOP using it! -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Action.java Globals.java questions.
I know that the Globals were pulled out of Action.Java to prevent direct dependencies on Action.java Right now Action.java has duplicates KEYS fields from Globals.java. Some were for compatibility with 1.0, BUT some were added for Struts 1.1. Continuing to add new constants to BOTH creates duplication which is not good... Could we 1) Remove the keys added for Struts 1.1 from Action.java AND/OR 2) Have Action extend the Globals so the duplicate variables and JavaDoc can be deleted ? -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Action.java Globals.java questions.
Ted Husted wrote: Do we have many more constants to add right now? How about if we stay the course though the 1.1 release, for consistency, +1 We should probably go ahead deprecate the Action statics that pass through references to Globals, so we can change it all over on the next run. About an hour ago I marked a few of these as deprecated then thought it better to ask the list before. There are still a few that need to be marked deprecated. If you think about it really the ResponseUtils RequestUtils Globals could be combined into a more appropiate class. Then the constants wouldn't need to be used externally except by developers extending the basic Struts classes. Maybe for 1.2 ?! -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application componentsto Module
The 3 methods are
A) superclassing
B) superclassing modified
B) delegation.
In thinking over superclassing vs delegation, I realized
superclassing, if used in a modified form isn't so bad.
However straight superclassing presents real design problems with
inconsistent states between ModuleConfig ApplicationConfig objects.
I still prefer delegation a bit more, but will help out regardless of
the consensus.
Here were my thoughts
Use cases, using C++ type syntax for brevity
Need to support:
1) ApplicationConfig as arguments to methods
void ClassY.methodA(ApplicationConfig)
2) ApplicationConfig as return values
ApplicationConfig ClassX.methodB()
3) Operations on ApplicationConfig protected fields
protected ApplicationConfig.formBeans.field1
4) Operations on ApplicationConfig public methods
public ApplicationConfig.formBeans.methodZ()
DESIGN GOALS:
A) Use ModuleConfig internally in Struts exclusively.
B) Create ApplicationConfig objects for external consumption only,
avoid storing/persisting ApplicationConfig
C) operations on the methods and properties manipulate
the same underlying objects
1) ApplicationConfig as arguments to methods
void ClassY.methodA(ApplicationConfig)
extract Superclass method
A Method signature of
void ClassY.methodA(ModuleConfig)
Works for both ModuleConfig objects and Application Config
objects.
This is a strength of superclassing.
Delegation
A Method signature of
void ClassY.methodA(ApplicationConfig)
and
void ClassY.methodA(ModuleConfig)
would need to be supplied.
What does that mean ?
void ClassY.methodB(ApplicationConfig ac) {
ClassY.methodB(ac.methodConfig);
}
Superclassing is more elegant. Delegation required the
definition of a 2nd method. For each and every method that
takes a ModuleConfig.
2) ApplicationConfig as return values
ApplicationConfig ClassX.methodA()
extract Superclass method with mods
A Method signature of
ApplicationConfig ClassX.methodA()
There are two choices to support this use case
1) superclassing pure The other alternative is
to construct a separate
object entirely that i.e. declare
class ApplicationConfig extends ModuleConfig {
}
While possible however this violates the design goal C:
operations on the methods and properties manipulate
the same underlying objects
Does it matter if a ApplicationConfig.plugIn object points to a
different copy of an ArrayList than the internal ModuleConfig ?
It very well could. At the very minimum it opens up the
possibility of ending up with ModuleConfig and ApplicationConfig
for a given module containing different plugIn items if a .add()
is performed.
It also changes the behavior from Struts 1.1B2.
2) The second choice superclassing modified
A ApplicationConfig object can be created from a
ModuleConfig object:
class ApplicationConfig {
ApplicationConfig(ModuleConfig mc) {
super(mc.prefix);
this.field1 = mc.field1
this.field2 = mc.field2
}
}
Currently the Constructor for ApplicationConfig and thus
the new ModuleConfig would look like :
class ModuleConfig {
static field1 = new Map();
ModuleConfig(String prefix) {
this.prefix = prefix
}
}
During the super() call the fields are initialized
such as field1 = new Map(), then they would be reinitialized
again with this.field1 = mc.field1
This can be optimized a by rewriting a 2nd constructor
for ModuleConfig
class ModuleConfig {
ModuleConfig(String prefix) {
this();
this.prefix = prefix;
this.field1 = new Map();
this.field2 = new Map();
}
ModuleConfig(String prefix,boolean dummy) {
this.prefix = prefix;
}
}
Delegation
A Method signature of
ApplicationConfig ClassX.methodA()
A ApplicationConfig object can be created from a
ModuleConfig object:
ApplicationConfig {
ApplicationConfig(ModuleConfig mc) {
this.mc = mc;
this.field1 = mc.field1
this.field2 = mc.field2
}
}
With Superclassing 2 constructors needed to be invoked, an
ApplicationConfig and a ModuleConfig to return a
ApplicationConfig object. Also an additional
constructors needs to be added to ModuleConfig especially for
ApplicationConfig to prevent unnecessary creation of objects
that are later thrown away. This constructor
Re: Powered By Page
David Graham wrote: I understand the criteria to be included on the powered by page to be that you either: 1. Put the powered by struts logo on a page or 2. include item 3 from the apache license on the page. I believe the criteria was not Struts specific. Just that they mention the Apache Foundation. I am not sure there was a mention of how accessable the credit had to be, but it would seem that somewhere within one click of the main page would be nice. You could always search the archives. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application components
Ted Husted wrote: 10/30/2002 1:29:38 PM, Robert Leland wrote: So, this is a long-winded case of asking why can't we do this? The method public ApplicationConfig ActionConfig.getApplicationConfig() though this is only used 4 times in struts itself, it is public. Which means we assume that others extending struts may rely on it. It may be worthwhile to note that none of this has appeared in an action Release, only the beta. The number of people affected may be vanishingly small, or even non-existant. I agree I would rather just do a global replace and be done with it, using IntelliJ of course. We could always put it up a notice on the USERS/DEVELOPERS LIST and evaluate any negative reactions. Sort of a JCP process. If we do deprecate, then Composition is still the cleanest way to go for struts internally. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 14054] - Rename Application componentsto Module
Craig R. McClanahan wrote: So, this is a long-winded case of asking why can't we do this? * Move all the functionality of ApplicationConfig to ModuleConfig. * Make ApplicaitonConfig a subclass of ModuleConfig with no extra methods of its own. * Deprecate the ApplicationConfig class itself. * Modify all source references from ApplicationConfig to ModuleConfig (which is a fairly large, but fairly mechanical, exercise) -- and don't forget the unit tests :-). Craig I should also mention that last night when I was looking over the code I told IntelliJ to do the refactoring for just the above actions, 'extract super class'. I then reviewed what it intended to do, in about 30 instances. I told it not to change the return signatures on the methods. Based on that I realized that composition offered a clearer solution. Composition is more work because there isn't a refactoring button for 'replace object with facade'. I don't want to repeat myself but at the same time I feel like there is some key piece of information I am leaving out that would help you see that composition is the way to go. I'll wait until others have the chance to look it over more. You can always download a 30 trial of IntelliJ at www.intelliJ.net. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Modules vs. Sub-Applications
Ted Husted wrote: As these methods are really not part of the public API, could we not just change them now and be done with it? Some are Public, however I would also vote +1 to rename them now. I agree with David and say lets go one intermediate step and deprecate them for struts 1.1B3 but to remove them before the next beta or Release candidate. That is what I propose to do with the StrutsValidator StrutsValidatorUtil methods. This would not effect compatability between 1.0 1.1 and would give a grace period to people using the Beta3 or Nightly builds. If a user tries to upgrade to the final struts 1.1 build, we could always suggest first going to the 1.1B3 removing the deprecation warnings then going to 1.1 final. -Rob -Ted. 10/28/2002 1:21:40 PM, Craig R. McClanahan wrote: On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: I thought it was application module, therefore the current names are still consistent with that. That's certainly my excuse for thinking we should not change them now :-). Although I agree with David that ModuleConfig and selectModule () would have made more sense had we known this was going to be the conclusion. Craig Did I miss some threads :( Wait, stop the printer... Ah, the perils of writing about beta software :-) :-) chuck Craig -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-struts/doc/userGuide dev_validator.xml
James Mitchell wrote: Speaking of David, I haven't heard from him in a while. What gives? Don't Know, last Email he sent to the list was in July, Sometimes life gets in the way. :-/ I emailed him today to ask if he wanted to donate the documentation from his web site to struts directly. We'll see. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [struts-el] HTML taglib
Eddie Bush wrote: Ok - this nearly *has* to be an issue with either Ant 1.4.1 or NB. Just for Reference to properly build Jakarta-Commons you'll need to use Ant 1.5.1. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] James Mitchell as Struts Committer
James, +1 Use the force wisely ! -Rob Ted Husted wrote: James Mitchell has been a long-time contributor of good ideas as well as patches on the developer list. He is also generous with his help on the user list. I believe it's time that we nominated James as a Committer. After all, we can always use another Evangelist. Here's my +1 -Ted. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Now available: Validator 1.0 RC1
Erik Hatcher wrote: Can this be dropped onto Struts 1.1b2 or do I need to use a nightly Struts build? There have been public methods added to some classes, but that is about it. I don't believe this causes a problem as it does with C++, but I could be wrong. Also, there have been a few Validator bug fixes, module fixes, in the last week. If you are allowed to use a nightly build of Struts I would highly recommend it ! I do. -Rob -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: DO NOT REPLY [Bug 11950] - Missing script in generatedjavascipt
James Holmes wrote: Are you sure this is all fixed now?? If you run the example app there is some spurious output from the JavaScript stuff I believe you are working on. // End -- shows up on the bottom of the page. Yes, It and the !-- Begin are a trick to prevent older browsers from reading the JavaScript. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util PropertyMessageResources.java
James Mitchell wrote: Hi Rob, I dont think those lines were doing what you thought. Without them, there is no support for inherited messages. Since doIt was a local variable I don't see how that impacts inherited messages. When the code below the while loop is executed doIt is always true, hence there is no need for it. -ROb -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: TODO sections
Ted Husted wrote: James Mitchell wrote: Can anyone tell me who's doing which? For myself I am concentrating on the Validator code. Luckly James Turner a commons committer has been actively working towards a release. Any problems/questions I have with the commons-validator get addressed pretty quickly. So I want to strike while the he has time to work on it. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[SHORT TERM PLAN]
Validator - Rob Leland, JavaDoc - Any incorrect JavaDoc IntelliJ catches. Refactoring - When it makes sense, currently Integrating the ApplicationConfig access a little more into the framework. I.E. code for access the ApplicationConfig object stored in the session is spread out. Some classes have a common access method, some don't. Yesterday I placed a central static access method in RequestUtils, but now that I am thinking about that, it might not have been the best place for it. For now it will stay there. Once all the access is centralized, moving the method to another class will take only 2 seconds with IntelliJ. -Rob aka [EMAIL PROTECTED] [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Need help figuring out how I broke Struts-EL unit tests
David M. Karr wrote: Ted == Ted Husted [EMAIL PROTECTED] writes: Ted Are you using Ant 1.5? I know to build Commons I needed Ant 1.5.1 -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/validator ValidatorPlugIn.java
I can get to it some time this weekend, though if Martin wishes to fix it that is great also... Which bring up another question...see [Policy on depreciation vs deleting] -Rob Eddie Bush wrote: Yes. My goal was to not create a session just to get at the ServletContext though. That's why I wrote it that way. I suppose it would be better your way though. In all liklihood, the more I think about it (and think about logger output), Struts is going to create a session anyway - for a number of other reasons. So, that's probably not good justification for doing things the way I did. Sorry about that. Should I submit a patch, or does someone else want to fix it? Martin Cooper wrote: The new version of getValidatorResources() added here takes a ServletContext and an HttpServletRequest. It seems to me that it should only take the request, since the servlet context can be obtained from that. It would be a little less error-prone this way, too. My 2 cents. -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Struts Committer: Eddie Bush
Craig R. McClanahan wrote: I'd like to propose Eddie Bush [EMAIL PROTECTED] as a committer on the Struts project. +1 [Vote/Patches/Granularity/Linux how do they do it/Alternate Release] [Vote] I believe this project can benefit from a more timely application of patches. (I am currently waiting for come commons patches to be applied and know how frustrating it is to wait.) Eddie is an individual that at this point in his life, has demonstrated a willingness to devote a --good-- chunk of his time to helping others, and creating patches. [Granularity and the Gauntlet] Building: There are bricks and mortar, each are needed to build a building. Struts: We need timely thoughtful patches and major contributions. [Linux how do they do it ?] Maybe this was already answered. Struts has a Monolithic distribution ruled by a Meritocracy(Small group who hae won right on Merit). Linux has a hierarchy ruled by Monarchy approach. The lead branch which is watched over by Linus Torvalds, he has the ultimate say so about what goes in. Then there are the Maintenance release 2.5, 2.4, 2.2 etc. Each has a release manager(Appointed by Linus) who is independent to make decisions about their branch. The recent case where the 2.5 Kernel people (Linus) went with an alternate VM system, and the 2.4 people didn't (Alan Cox of Red Hat) decided the new VM wasn't stable enough. http://www.byte.com/documents/s=1436/byt20011024s0002/1029_moshe.html Ultimately, each patch needs to prove it's merit. Then each branch like 2.4 has multiple branches 2.4.x-ac 2.4-dj etc... Each gets a chance to be tried out on a wide basis. And yes it is can be chaotic when merging branches. http://users.edpnet.be/moritz/gpl/gpl.html [Alternate Releases] Yes maybe there should be an experimental release branch of struts, on source forge or other web site. I am not volunteering. It would give a wide number of people a chance to experiment on a wide basis to see what works and what doesn't. There would be no guarantee that any or all changes would be incorportaed. Then users could lobby to have it included into Jakarta struts on merit. After all that is the original charter struts was founded on, as to why there should been another MVC engine besides Turbine at Jakarta. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] David M. Karr as a Struts Committer
+1 Rob Craig R. McClanahan wrote: I'd like to propose David M. Karr [EMAIL PROTECTED] as a committer on -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to extend AppException
phpsurf wrote: Hi when looking at the default ExceptionHandler implementation, I saw that there was a special behaviour when handling org.apache.struts.util.AppException. ... But the problem is that its properties are private instead of protected, so it's quite difficult to add some features to the class ... That sounds reasonable, to make them protected. Go ahead and submit a bug request http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Struts -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/utilStrutsValidator.java
Craig R. McClanahan wrote: On Sat, 24 Aug 2002, James Turner wrote: Thanks for the commit. One minor request? I've done significant amounts of hackage on that file now, and it's probably appropriate for me to be in the authors list at the top. +1. James sorry, I wasn't aware that you had made other patches to this file. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Planning for 1.1 beta 2
Craig R. McClanahan wrote: Are the other committers interested in working towards such a goal? +1, I'll try to finish up the UML for classes. and put in place holders for the added package descriptions. Plus pitch in else where. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
multipart requests + forwarding = bug
I haven't experienced this bug but my office mate mentioned he experienced it, he is not here today. There also seems to been some discussion, and several different patches floating around to fix this. If this is still a problem could someone who has experienced this file a BUG report at http://nagoya.apache.org/bugzilla/ I'll see that it gets fixed. -Rob Matt Raible wrote: You might try matching up your form names in your validation.xml file: form-validation formset form name=LogonForm field property=user depends=required arg0 key=error.user.required/ /field /form /formset /form-validation Should be logonForm according to struts-config.xml. HTH, Matt --- Struts-dev Newsgroup [EMAIL PROTECTED] wrote: Subject: Validation on DynamicForm problem From: Tomas [EMAIL PROTECTED] === Hello, how, to make verification (validation) of dynamic forms ? in struts-config.xml is: struts-config . . . form-bean name=logonForm dynamic=true type=org.apache.struts.validator.DynaValidatorActionForm form-property name=user type=java.lang.String / form-property name=password type=java.lang.String / /form-bean action-mappings action path=/logon type=simple.LogonAction name=logonForm validate=true scope=session input=/index.jsp /action /action-mappings !-- == Message Resources Definitions === -- message-resources parameter=org.apache.struts.webapp.validator.ApplicationResources/ !-- == Plug-in Definitions == -- plug-in className=org.apache.struts.validator.ValidatorPlugIn set-property property=pathnames value=/WEB-INF/validator-rules.xml,/WEB-INF/validator.xml/ /plug-in . . . /struts-config in file validator.xml is: form-validation formset form name=LogonForm field property=user depends=required arg0 key=error.user.required/ /field /form /formset /form-validation in web.xml is: web-app servlet servlet-nameaction/servlet-name servlet-classorg.apache.struts.action.ActionServlet/servlet-class init-param param-nameapplication/param-name param-valueApplicationResources/param-value /init-param init-param param-nameconfig/param-name param-value/WEB-INF/struts-config.xml/param-value /init-param init-param param-namedebug/param-name param-value3/param-value /init-param init-param param-namedetail/param-name param-value3/param-value /init-param init-param param-namevalidate/param-name param-valuetrue/param-value /init-param load-on-startup2/load-on-startup /servlet /web-app no efect in edit form, always (but still) error messages: 747375 [HttpProcessor[80][4]] DEBUG org.apache.struts.action.RequestProcessor - Validating input form properties 747375 [HttpProcessor[80][4]] DEBUG org.apache.struts.action.RequestProcessor - No errors detected, accepting input Can you help? Second question is, how to used text fields (width indexed=true) on dynamic forms? [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MessageResources
James Mitchell wrote: Struts gurus, this was in response to someone (I doubt that I'm the only one) asking about having the resource bundle loaded from xml file(s). I know this is a commons question, but ... About a year ago March 2001 ? the same request was made. I am pretty sure the creation of Message Resources was changed to uses a Factory to make this possible so I am pretty sure there are people out there reading Message Resources from an XML file. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
NestedNotEqualsTag doesn't implement NestedPropertySupport
In doing the UML for the nested Logic tags I noticed
that the NestedNotLogicEqual doesn't implement
NestedPropertySupport
public class NestedEqualTag extends EqualTag implements
NestedPropertySupport, NestedNameSupport {
public class NestedNotEqualTag extends NotEqualTag implements
NestedNameSupport {
Is this an oversite, and if not why ?
--
Robert Leland ([EMAIL PROTECTED])
804 N. Kenmore Street
Arlington, VA 22201-2225
Voice: 703-525-3580
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NestedFormTag in cvs head
David Winterfeldt wrote: v1.3 of src/share/org/apache/struts/taglib/nested/html/NestedFormTag.java won't compile for me. David I bet you are using Tomcat 3.X, JSP 1.1 ? I believe it uses a JSP 1.2 construct. -Rob -- Robert Leland ([EMAIL PROTECTED]) 804 N. Kenmore Street Arlington, VA 22201-2225 Voice: 703-525-3580 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Unnecessary multiple URLEncoder.encode() in RequestUtils
Patches are always welcome, follow the directions here: http://jakarta.apache.org/site/bugs.html To submit a bug report. I would recommend filling the bug report as opposed to posting a patch to the mailing list. Johannes Carlén wrote: Hi, I was running our application with JProbe and discovered that some pages with many html:links consumed a whole lot of memory. I did some research and found the computeURL() method in org.apache.struts.util.RequestUtils. In computeURL() *every* single key and value is url encoded by itself and then appended to the url string. When trying a very simple test page with only one html:link tag on it and only one parameter (key/value) this increased the memory consumption by nearly 200kb's, and this consumption is linear by the number of parameters added!!! When changing the code, suddenly the memory consumed by some of our pages went down from 7-8MB's to 1.5MB. A real gain there... When the url encoding takes place, some memory is used every time and I think this method should be used with care and only when needed. In this case, on the whole url string at the end of the method. Will any of you guys take care of this or would you like some help? I have the modified source code by hand if you'd like it (however this should be a quick fix anyhow). Best regards /Johannes _ Hitta snörapporter... från 500 olika skidorter i Europa på http://se.snow.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] . -- Robert Leland ([EMAIL PROTECTED]) 804 N. Kenmore Street Arlington, VA 22201-2225 Voice: 703-525-3580 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 1 Release Plan
-- Vote:Struts 1.1b1 Release Plan [X] +1I am in favor of the release, and will help support it [ ] +0I am in favor of the release, but am unable to help support it [ ] -0I am not in favor of the release [ ] -1I am against this proposal (must include a reason). -- Let me know how I can give a hand. -Rob Robert Leland ([EMAIL PROTECTED]) 804 N. Kenmore Street Arlington, VA 22201-2225 Voice: 703-525-3580 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/bean CookieTag.java DefineTag.java HeaderTag.java PageTag.java ParameterTag.java SizeTag.java StrutsTag.java
[EMAIL PROTECTED] wrote: craigmcc01/04/23 15:52:22 Modified:src/share/org/apache/struts/taglib/bean CookieTag.java DefineTag.java HeaderTag.java PageTag.java ParameterTag.java SizeTag.java StrutsTag.java Log: Remove unused imports. Was Jikes used to determine unused imports ?
Re: FOLLOWUP: struts-config_1_0.dtd location when not connected to internet
That was the same fix that was made to struts about a month ago, it now has a copy of the DTD in the jar file. I am also using JBuilder4 and since this change it works ok for me. -Rob "Young, Wayne" wrote: I finally got back to working this issue. Recall, I was having the trouble running a struts application using Tomcat 3.2 JBuilder 4 in debug mode while disconnected from the internet. I resolved this issue by extracting the DTDs from the struts.jar to the WEB-INF\classes\org\apache\struts\resources directory. These DTD's were in the struts.jar in my WEB-INF\lib directory, but they weren't found at runtime. Thanks. Wayne [EMAIL PROTECTED] -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, March 30, 2001 11:38 AM To: '[EMAIL PROTECTED]' Subject: RE: struts-config_1_0.dtd location when not connected to internet On Fri, 30 Mar 2001, Cook, Levi wrote: Does using the local DTD require the DOCTYPE declaration to be modified?? Thanks in advance, Levi Cook No. The XML parser looks at the public identifier (the part that starts "-//Apache ..." to see if it has a local copy. If so, the system identifier (the URL) is totally ignored. By the way, servlet containers do this for the web.xml DTD as well, which is why (for example) you can run Tomcat disconnected from the Internet without modifying any of your web.xml files. Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, March 30, 2001 11:19 AM To: Struts-Dev@Jakarta. Apache. Org (E-mail) Subject: Re: struts-config_1_0.dtd location when not connected to internet On Fri, 30 Mar 2001, Young, Wayne wrote: I'm trying to run my struts application disconnected from the internet. When I try to start Tomcat 3.2 in JBuilder4, it is unable to find the struts-config_1_0.dtd in the location below and won't load the action servlet. (as expected) !DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd" Struts registers a local copy of the DTD for this (and for the web.xml DTDs as well) at a path that should be in the struts.jar file: /org/apache/struts/resources/struts-config_1_0.dtd which is then accessed via this.getClass().getResource(). If there is something wierd about the classloader inside JBuilder4, it might have problems with this -- I've successfully run Struts in detached mode on Tomcat 3.2 stand alone. Craig
Re: struts-config_1_0.dtd location when not connected to internet
About 3 weeks ago, the DTD was included in the struts.jar to fix this problem. Try a recient nightly build. -Rob [EMAIL PROTECTED] wrote: I believe that if you place the dtd in a resources folder inside the org.apache.struts folder and compile it should work correctly. "Young, Wayne" To: "Struts-Dev@Jakarta. Apache. Org (E-mail)" [EMAIL PROTECTED] WYoung@metascc: olv.com Subject: struts-config_1_0.dtd location when not connected to internet 03/30/01 08:51 AM Please respond to struts-dev I'm trying to run my struts application disconnected from the internet. When I try to start Tomcat 3.2 in JBuilder4, it is unable to find the struts-config_1_0.dtd in the location below and won't load the action servlet. (as expected) !DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd" I tried the following without success. !DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN" "struts-config_1_0.dtd" I receive this error. Parse Fatal Error at line 5 column -1: Relative URI "struts-config_1_0.dtd"; can not be resolved without a document URI. org.xml.sax.SAXParseException: Relative URI "struts-config_1_0.dtd"; can not be resolved without a document URI. Any ideas? Wayne [EMAIL PROTECTED]
Re: package.html for action
I have a sequence diagram that someone created for the login, last January. It was very nice showing the effects of flow of control. I have been saving all such e-mails and could send several that users have sent. Where should I put it ? -Rob "Craig R. McClanahan" wrote: On Thu, 29 Mar 2001, Ted Husted wrote: If you just want to do the token stuff now, we could work something into the User Guide about it. It really should have been in the tour (mea culpa), but it was added after I wrote the first draft, and I haven't gone back. As you probably know, we've using the package files to create the "Developer Guides" for the Taglibs. Extending the "guides" to the rest of the frameworks sounds like a good idea. I agree. For example, the User's Guide for the o.a.s.action package could also talk about things like subclassing ActionServlet to specialize its behavior. On a slightly separate note, a piece of doc that would be incredibly helpful here is a UML Sequence Diagram of the basic request flow through the controller and related objects. Anyone have a nice tool and some time to build such a thing? Rob Leland wrote: Does org.apache.struts.action need a package.html. I would like to make a drop of documentation for the Token stuff. Craig
Re: package.html for action
"Craig R. McClanahan" wrote: will become the User Guide for the controller framework. Sound OK? Sounds good, I'll do it this weekend. Along with a Credits.txt or some such to acknowledge the original authors. -Rob
Re: id attribute again
Only one comment if for html: it should directly map into a standard html tag. Otherwise, you might want to place it in the bean: taglib. I am sure we'll have a user supplied section up soon. Ted Husted might have a user contributed site, or atleast a link to user contributed items. Michael Hackett Developer, Pictorius Inc.
package.html for action
Does org.apache.struts.action need a package.html. I would like to make a drop of documentation for the Token stuff.
Re: dropdown values gone after validation error
"Young, Wayne" wrote: I have the following struts/JSP fragment that creates a dropdown with values from the networkTypes attribute. html:select styleClass="Field" property="networkType" size="1" html:options property="networkTypes"/ /html:select/td The networkTypes attribute is created in the "getNetworkTypes" action that Is getNetworkTypes an Iterator, Vector, ArrayList. I have noticed that for java.util.Enumerate, and java.util.Iterator you can go through the list only once if you obtained a --reference-- to the list. I have started to copy the objects to an array, see the RegistrationForm.java and look at subscriptions in the example program, on how to do this. -Rob
Are we in Beta ?
I am not sure we are in Beta mode with a feature freeze, at least with the set of criteria that was put forth in Feburary. For instance, it seems like DispatchAction(), while a good idea, is a new feature as opposed to a bug fix, and it didn't compile when it was checked in. Also the proposed multiple action servlets per web app is also a new feature, that I am not sure which version 1.0 / 1.1 it will be in. Is there any reason these items couldn't make it into version 1.1 is it ? I just don't want us to get in a prolonged cycle where we start adding new features that can wait, until after we branch the CVS tree for version 1.0 beta 2/ and 1.1 . Once we do that the development of new features can begin again. Note I am not asking when the final version will be ready. We are all volunteer, with full time jobs. -Rob
Re: development issues
Tahir Awan wrote: What's the process of submitting those tags to be part of the struts framework. I am sure there are many ways to do this. Here are my thoughts: Like you said you want to get users comments so you can refine the implementation so: 1) Post the changes on a Web site describing the changes to be made. Then ask for users comments and suggestions for improvements. 2) Post them to the struts-dev list. Then ask for users comments and suggestions for improvements. 3) You could post the patches in a bug report either as the entire file or a series of diffs. 4) Lobby one of the comitter and convince them that those changes are good. Then make a proposal on the struts-dev list after users have had a chance to look at the work and ask them to vote on your proposal. So probably try method #1 #2 then once you get feedback document those changes and submit them as a bug/enhancement request which is #3.
Re: Ted Husted: An entry for the FAQ(Re: building struts)
I left out one important point. That is to copy the ant/dist/lib files to your ant/lib dir so the revised FAQ entry would look like: This should go in the FAQ: Question: I cannot building struts, I keep getting either a java.lang.ClassNotFoundException: org.apache.tools.ant.taskdefs.optional.TraXLiaison or a java.lang.SecurityException: sealing violation I played with my adjusted my class paths for 5 hours, Help ... what can I do ? Answer: I would recommend ALWAYS building 'ant' before trying to build 'struts' for the first time. Why? It seems that ant customizes itself for each environment, and determines which XML parser you are using. Once I did that struts builds without a hitch. 1) Read the Build instructions for ANT, creating the ANT_HOME, and other needed enviromental variables. 2) Then run build.bat - to perform the bootstrap build of ant and build the final version of Ant. 3) Copy the ANT_HOME/dist/lib jar files to ANT_HOME/lib . 4) Make sure you read the 'struts' build guide, and have installed all required packages. 5) Change to the struts directory. 5) Then type 'build' If this doesn't work then make sure that your CLASSPATH references only one jaxp.jar and that parser.jar isn't in your CLASSPATH
Re: PROPOSAL - Testing Framework
"Craig R. McClanahan" wrote: Rob Leland has volunteered to take the lead on this, but I don't know if anything specific has happened yet. Not only am I willing to Lead but to follow, since Vince obviously has MUCH more experience with J2EEUnit testing than me. I have a handle on JUnit, but not J2EEUnit , ... Yet :). Nothing has been put in place, I have started looking at the action classes had hoped to get a few tests in by version 1.0, with the bulk of the tests for version 1.1. So Vince what would you propose for directory structures, organizing tests ? It looked like you had some good suggestions yesterday. -Rob
Re: PROPOSAL - Testing Framework
On the contact info for testing could you change the contact email address from: [EMAIL PROTECTED] to : [EMAIL PROTECTED] That way I can sort out email easier. -Rob
PROPOSAL - Testing Framework
I would like to add some additional Unit tests to the struts framework. These would be tests for struts itself, not end user code. My thoughts are that as struts evolves and new functionality is added we want to verify that other functionality is not broken, as code is changed and refactored. I am proposing using JUnit 3.5 (http://junit.sourceforge.net/) and J2EEUnit (J2eeunit.sourceforge.org). I am going to force myself to do this in an upcoming project at work, and believe it makes sense to do it in struts also. I am targeting the 1.1 release time period. If Unit testing is approved, some small set of tests may make it into the struts 1.0 release, again assuming people here vote for its inclusion. My initial thoughts for providing testing is to start with the private methods of struts starting with the struts.action package, then later develop tests for the public methods of struts.action. I didn't want to start another package until I finished the majority of the private methods, only because I would need to debug my unit tests, and only by developing tests for some of the private methods the public could I do this. Then other packages would follow : struts.upload, struts.util, struts.digester, struts.actions, struts.taglib.X In about that order, only because that would be a usefull order for me in the project I am working on. Infact, I only have plans to do struts.upload, and struts.util, and doubt I would have the time to produce tests for the other packages. Thoughts ? -Rob
Breaking Interface (was:Re: cvs commit: jakarta-struts/web/upload/WEB-INF/classes/org/apache/struts/example/upload UploadAction.java)
This commit will break any code that implements the
org.apache.struts.upload.FormFile interface, because a new method was
added.
Is there a way to not break this for people ?
One of the things Struts/Craig has always stressed
is good backward compatability ?
[EMAIL PROTECTED] wrote:
mschachter01/02/14 13:43:10
Modified:src/share/org/apache/struts/upload DiskFile.java
DiskMultipartRequestHandler.java FormFile.java
MultipartElement.java MultipartIterator.java
web/upload/WEB-INF/classes/org/apache/struts/example/upload
UploadAction.java
Added: src/share/org/apache/struts/upload MultipartValueStream.java
Log:
Made changes to classes in upload package to address problems with storing
files in memory. This commit will break any code that implements the
org.apache.struts.upload.FormFile interface, because a new method was
added. Changed MultipartIterator to use the new MultipartValueStream class
from Jimmy Larsson for
going through multipart elements. This will fix a bug with null content types
for files. Also updated the upload example to use the new recommended method
for retrieving file content.
Submitted By: Jimmy Larsson
Revision ChangesPath
1.2 +14 -5
jakarta-struts/src/share/org/apache/struts/upload/DiskFile.java
Index: DiskFile.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/DiskFile.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DiskFile.java 2000/11/09 20:08:56 1.1
+++ DiskFile.java 2001/02/14 21:43:05 1.2
@@ -1,6 +1,7 @@
package org.apache.struts.upload;
import java.io.File;
+import java.io.InputStream;
import java.io.IOException;
import java.io.FileInputStream;
import java.io.ByteArrayOutputStream;
@@ -26,10 +27,8 @@
/**
* The name of the file
*/
-protected String fileName;
+protected String fileName;
-
-
public DiskFile(String filePath) {
this.filePath = filePath;
}
@@ -39,6 +38,9 @@
* array form. Tries to read the entire file (using a byte array
* the size of getFileSize()) at once, in one call to
FileInputStream.read(byte[]).
* For buffered reading, see {@link #getFileData(int) getFileData(int)}.
+ * Note that this method can be dangerous, and that the size of a file
+ * can cause an OutOfMemoryError quite easily. You should use
+ * {@link #getInputStream() getInputStream} and do your own thing.
*
* @exception ServletException If the temp file no longer exists, or if there
is
*some sort of IOException
@@ -56,6 +58,9 @@
/**
* Attempts to read a file n bytes at a time, n being equal to "bufferSize".
+ * Note that this method can be dangerous, and that the size of a file
+ * can cause an OutOfMemoryError quite easily. You should use
+ * {@link #getInputStream() getInputStream} and do your own thing.
*
* @param bufferSize The size in bytes that are read from the file at a time
* @exception FileNotFoundException If the temp file no longer exists
@@ -150,7 +155,11 @@
public int getFileSize() {
return fileSize;
}
-
-
+/**
+ * Returns a FileInputStream to the file
+ */
+public InputStream getInputStream() throws FileNotFoundException, IOException
{
+return new FileInputStream(filePath);
+}
}
1.7 +55 -97
jakarta-struts/src/share/org/apache/struts/upload/DiskMultipartRequestHandler.java
Index: DiskMultipartRequestHandler.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/DiskMultipartRequestHandler.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- DiskMultipartRequestHandler.java 2000/11/28 07:17:17 1.6
+++ DiskMultipartRequestHandler.java 2001/02/14 21:43:05 1.7
@@ -47,11 +47,19 @@
*/
protected Hashtable allElements;
+/**
+ * The temporary directory
+ */
+protected String tempDir;
+
public void handleRequest(HttpServletRequest request) throws ServletException
{
+retrieveTempDir();
+
MultipartIterator iterator = new MultipartIterator(request,
servlet.getBufferSize(),
-
getMaxSizeFromServlet());
+
getMaxSizeFromServlet(),
+
Current thoughts on Turbine and struts ?
Craig: Back in June 2000 you were quoted as saying about turbine and struts Finally, longer term, I would not be at all surprised to see the two approaches merged. What is you current thinking on this.
