Re: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Steve Peterson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] While you are talking about updating the build, another small item for the todo list would be to sync the version number assignment up with the now-project-standard a.b.c style release numbering. I have personally seen some (small) confusion related to release 1.1.0 being stored in jakarta-struts-1.1.zip. The problem here, I think, is that we should not be referring to it as 1.1.0 at all. The decision we made, unless I'm mistaken, is that we would start to use the 3-part numbering *after* Struts 1.1, not *with* Struts 1.1. So there is no 1.1.0 release. -- Martin Cooper S At 08:14 AM 7/22/2003 -0400, Ted Husted wrote: Craig R. McClanahan wrote: Do we really want to wait that long? CAN we wait that long? How long is a piece of String. =:0) We can do a 1.2 release candidate this month, and then figure on doing 1.3 by the end of August. As long as week keep 1.x.x in evolutionary mode, I don't think we need to worry too much about maintaining branch for 1.#.x versus 1.#.x. In practice, the 1.1 branch has been out-there for over a year, and it seems unlikely that any serious problems could be cured with a trivial point-release fix. We just have to be careful to keep the HEAD release-ready and whiteboard anything radical before merging it in. I have family coming in this week and can't volunteer to roll 1.2 myself this weekend. But if no one beats me to it, I'd like to roll a 1.2 release candidate the first weekend in August. -Ted. - 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: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] --- Martin Cooper [EMAIL PROTECTED] wrote: Steve Peterson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] While you are talking about updating the build, another small item for the todo list would be to sync the version number assignment up with the now-project-standard a.b.c style release numbering. I have personally seen some (small) confusion related to release 1.1.0 being stored in jakarta-struts-1.1.zip. The problem here, I think, is that we should not be referring to it as 1.1.0 at all. The decision we made, unless I'm mistaken, is that we would start to use the 3-part numbering *after* Struts 1.1, not *with* Struts 1.1. So there is no 1.1.0 release. I'm a bit confused by this. Didn't we already have a 3 part numbering system with 1.0.1 and 1.0.2? 1.1.1 would be a bugfix release only; however, we decided to not do that and roll up any bug fixes + enhancements into 1.2.0. We had three-part numbering, yes, but only for bug fix releases. But we had 1.0 and 1.1 for the regular releases, not 1.0.0 and 1.1.0. Going forward from now, the plan is to always have three parts to the release number, even for non-bug-fix-only releases, in a similar manner to Tomcat. -- Martin Cooper David -- Martin Cooper S At 08:14 AM 7/22/2003 -0400, Ted Husted wrote: Craig R. McClanahan wrote: Do we really want to wait that long? CAN we wait that long? How long is a piece of String. =:0) We can do a 1.2 release candidate this month, and then figure on doing 1.3 by the end of August. As long as week keep 1.x.x in evolutionary mode, I don't think we need to worry too much about maintaining branch for 1.#.x versus 1.#.x. In practice, the 1.1 branch has been out-there for over a year, and it seems unlikely that any serious problems could be cured with a trivial point-release fix. We just have to be careful to keep the HEAD release-ready and whiteboard anything radical before merging it in. I have family coming in this week and can't volunteer to roll 1.2 myself this weekend. But if no one beats me to it, I'd like to roll a 1.2 release candidate the first weekend in August. -Ted. - 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] __ 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]
Re: DO NOT REPLY [Bug 21821] - taglibs requesting certain RequestUtil methods fail if page access not through ActionServlet
Steve Raeburn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-07-23 16:28 --- Frankly, I think requiring this goes too far. Suggesting best practices for real applications is one thing, but generating unexpected exceptions for simple example applications makes this harder to use. Note that I have no problem requiring use of the controller in order for modules to work. Most applications don't use modules, including the exercise application, which now doesn't work. I entirely agree this comment. Directly accessing JSPs has been permitted up until 1.1 and most of the included webapps work this way. I think if we are going to require that *all* requests go through the controller that's a bigger functional change than a 1.1 - 1.2 upgrade should contain. I don't see that it should be necessary to require that restriction for modules to work properly. What is the point of having a front controller if you then have to have code all over the place that checks to see if it was invoked, and if not, do its job for it? This issue is much bigger than just getting taglibs and modules to work together. The implication is that tags should continue to work correctly in the absence of *any* per-request processing the controller does. Think about that for a minute. You'll also bypass the Tiles request processor, and then expect Tiles to work correctly in your JSP pages. Who knows what else? Any directly accessed JSP would be assumed to be part of the default module and the message resources obtained accordingly. If you try to access a JSP directly *and* expect it to work as part of a module *then* you deserve all that's coming to you ;-) The problem is that this behaviour will cause even *more* confusion when people try to use modules. We specifically tell people that their existing apps should just work when dropped in as a non-default module. But if they are accessing JSP pages without going through the controller, they will suddenly find that the wrong message resources are being picked up. Wouldn't it be better for them to see an error message, rather than having to figure out what happened by themselves? -- Martin Cooper I don't claim to have any great knowledge of the internal workings of modules (yet) which is why I was tentative in posting a patch rather than committing a fix because I thought there might be a better way to solve the problem. I will to investigate further to see if that's the case. In the meantime, I will commit the patch later today and, yes, we should be looking at updating the webapps :-0 Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Don Brown as committer
James Mitchell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Don has been involved with Struts for quite some time and has submitted numerous patches and enhancements. I believe that as we move forward with development, having Don on our team would be a tremendous asset. I would like to nominate Don Brown as a Committer. Here's my +1!!! [ ] +1 - I agree. [X] +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 .. In addition, I think we should wait until he can recite the JSP spec verbatim, as well, before we allow him to make changes to the taglibs... More seriously, though, my reasoning for a +0 rather than a +1 is that, although I respect the opinions of other committers, I have not personally had the opportunity to examine any of Don's code. -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 678-910-8017 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Craig R. McClanahan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 :-(. Given that we have struts-legacy on its own release cycle, I think we need to decouple the struts-legacy build from the main Struts build. They were coupled shortly before the 1.1 final release, and that was a big pain when I was creating the release. I should be able to do 'ant clean dist' at the top level and point to an existing struts-legacy release, but I can't do that the way the builds are coupled right now. I could have just gone in and undone the coupling that was done (and I still could ;), but I'd like to understand why they are so tightly coupled before I do that. It seems not only unnecessary, but also highly undesirable, especially when struts-legacy is independently released. -- Martin Cooper Thanks Steve Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building struts-legacy (was: Re: Nightly build is generating empty binary distribution file)
Craig R. McClanahan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Mon, 21 Jul 2003, Martin Cooper wrote: Given that we have struts-legacy on its own release cycle, I think we need to decouple the struts-legacy build from the main Struts build. They were coupled shortly before the 1.1 final release, and that was a big pain when I was creating the release. I should be able to do 'ant clean dist' at the top level and point to an existing struts-legacy release, but I can't do that the way the builds are coupled right now. I could have just gone in and undone the coupling that was done (and I still could ;), but I'd like to understand why they are so tightly coupled before I do that. It seems not only unnecessary, but also highly undesirable, especially when struts-legacy is independently released. Decoupling this would probably be nice, but I don't think we're done if we just fix that. I never thought I'd see a build environment more complex than the one for Tomcat 4.1, but I think we've grown ourselves one :-(. I agree that we're not done by just decoupling legacy from the rest. However, that's what I would recommend for 1.2 and the 1.1 branch. Beyond that, we've also talked about moving to a Maven based build. If we're going to make changes on the scale you suggest below, then I would far rather do that as part of a migration to Maven than do it independently, assuming we do decide to move to Maven. Otherwise, we run the risk of making life difficult for ourselves under Maven, and I, for one, don't relish the prospect of reorganising the code base more than once. ;-) While we're at it, this would also be a good time to reorganise the docs. If we move to Maven, then we should be able to take advantage of its site:generate and site:deploy targets, which would be very nice. Hmm. I'm beginning to think that perhaps 1.3 should be just an internal reorg release... -- Martin Cooper Isn't it time to start splitting chunks of this into inddependently buildable subdirectories, and then create a top-level build.xml that only does the appropriate things in the appropriate order? An example might be to create a core subdirectory for the things we think would go into struts-core.jar (informally, it's probably what we have now minus the tag libraries but that's a detail). The directory structure might look like: core/ build.xml Build for this chunk src/java/ Java sources dist/ Output directory for dist of this target/ Output directory for main of this and we can start splitting things up one chunk at a time. The most important concern is to minimize cross dependencies between the builds for each subdirectory. The next consideration is that they should all default up to a developer's own build.properties in the top-level directory, instead of having a build.properties for each subdirectory. From this line of thinking, packaging releases becomes a function of grabbing the dist output from the relevant top-level directories like core/dist. We could also dispense with contrib as an artificial distinction, and just have all the individual components at the top level, then decide what goes into a standard Struts release in each release plan. It wouldn't bother me to break the overall build for a while in order to get this sorted out -- IMHO it's pretty broken already :-). But we might also want to do a 1.2.0 first. Comments? -- Martin Cooper Craig (jdk.version=1.4 solved one problem, but I'm still struggling to tweak all the individual build.properties files to work in my environment) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: When is the next release?
On Mon, 14 Jul 2003, James Turner wrote: David Graham wrote: The plan all along was that 1.2.0 would include a move to commons-resources and no other major changes. However, commons-resources is still in the sandbox so I suggest we postpone that move to the next release. I've committed all of my interesting changes for 1.2.0 so I'd like to hear the status on the nested and tiles bugs plus the one Martin has assigned to himself. Also, is the validwhen vaildation working? Well, validWhen is checked into the release, and it's the same code I'm using on a live customer site, so my belief is that it is. We won't know how well it works until more users try it out and find bugs, but that's the nice thing about more frequent release cycles, right? I assume you mean that 'validWhen' is checked in to CVS, and that it's in the nightlies. It certainly isn't in a release at this point. One thing I would like to be absolutely clear on. More frequent releases absolutely does *not* mean lower quality releases, and does *not* mean moving the burden of quality assurance from the committers to the user base. The above statement regarding the nice thing about more frequent releases could be construed otherwise, so I felt a need to clearly state my own position. :-} -- Martin Cooper James - 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
On Tue, 8 Jul 2003, Rob Leland wrote: 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. MindTerm must have switched to commercial after 2.0, because I'm using 2.0 (right now, in fact, to send this message), and it comes up with: MindTerm 2.0 (non-commercial) This copy of MindTerm is for non-commercial and personal use only. Steve, let me know off-list if you want me to send you a copy of MindTerm 2.0. -- Martin Cooper 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Powered By Struts Logos
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Saturday, July 05, 2003 11:33 AM To: Struts Developers List Subject: Re: Powered By Struts Logos On Sat, 5 Jul 2003, Hookom, Jacob John wrote: Date: Sat, 5 Jul 2003 13:23:58 -0500 From: Hookom, Jacob John [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Powered By Struts Logos As per Craig's comment on the user forum, I've attached some powered by struts logos for use The background of this was a query on the user list for a Powered By Struts logo. Our current one doesn't really do much for me (and I'm sure not for anyone else either). How about if we have a logo contest, with the goal of making the new logo one of the features of the first 1.2.0 release? +1. Sounds like fun! -- Martin Cooper Regards, Jacob Hookom Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 1.1 final to bugzilla
David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bug reports coming in against 1.1 final don't have any way of selecting that in the version drop down. Can somebody add that to the list? I don't think I have the karma for that but if I do, just point me in the right direction. I believe Craig is the only Struts committer who has the karma to do that. I offered to help Pier with Bugzilla maintenance a while ago, but the offer wasn't taken up (probably because I'm not enough of a *nix hacker to do the whole job ;). -- Martin Cooper Thanks, David __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 James Turner [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ok, now that the dust is settling on 1.1, I've re-checked-in the validwhen validator, but in order for the nightlies not to break, the antlr.jar file (available from http://www.antlr.org/download/) needs to be put on the build machine and the antlr.jar property in build.properties needs to point to it. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/utilL abelValueBean.java
Just curious - what's the reason for explicitly initialising members to
null, given that that's what happens anyway?
--
Martin Cooper
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 7:20 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/util
LabelValueBean.java
dgraham 2003/07/01 19:20:28
Modified:src/share/org/apache/struts/util LabelValueBean.java
Log:
Added default constructor for PR# 18142.
Revision ChangesPath
1.3 +14 -11
jakarta-struts/src/share/org/apache/struts/util/LabelValueBean.java
Index: LabelValueBean.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/Labe
lValueBean.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LabelValueBean.java 12 Mar 2002 06:30:56 - 1.2
+++ LabelValueBean.java 2 Jul 2003 02:20:28 - 1.3
@@ -7,7 +7,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2001 The Apache Software Foundation.
All rights
+ * Copyright (c) 1999-2003 The Apache Software Foundation.
All rights
* reserved.
*
* Redistribution and use in source and binary forms, with
or without
@@ -59,13 +59,10 @@
*
*/
-
package org.apache.struts.util;
-
import java.io.Serializable;
-
/**
* A simple JavaBean to represent label-value pairs. This
is most commonly used
* when constructing user interface elements which have a
label to be displayed
@@ -76,7 +73,6 @@
* @author Martin F N Cooper
* @version $Revision$ $Date$
*/
-
public class LabelValueBean implements Serializable {
@@ -84,6 +80,13 @@
/**
+ * Default constructor.
+ */
+public LabelValueBean() {
+this(null, null);
+}
+
+/**
* Construct an instance with the supplied property values.
*
* @param label The label to be displayed to the user.
@@ -101,7 +104,7 @@
/**
* The property which supplies the option label
visible to the end user.
*/
-private String label;
+private String label = null;
public String getLabel() {
return this.label;
@@ -115,7 +118,7 @@
/**
* The property which supplies the value returned to
the server.
*/
-private String value;
+private String value = null;
public String getValue() {
return this.value;
-
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: cvs commit: jakarta-struts/src/share/org/apache/struts/utilL abelValueBean.java
Erm, actually, I was referring to the new:
private String label = null;
versus the original (and exactly equivalent, AFAIK):
private String label;
--
Martin Cooper
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 9:34 PM
To: Struts Developers List
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/util
L abelValueBean.java
--- Martin Cooper [EMAIL PROTECTED] wrote:
Just curious - what's the reason for explicitly
initialising members to
null, given that that's what happens anyway?
I was just in the mode of calling one constructor from every other
constructor and didn't even think about it. I could have
just as easily
called super();. In fact, I think I'll go change that now.
David
--
Martin Cooper
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 7:20 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-struts/src/share/org/apache/struts/util
LabelValueBean.java
dgraham 2003/07/01 19:20:28
Modified:src/share/org/apache/struts/util
LabelValueBean.java
Log:
Added default constructor for PR# 18142.
Revision ChangesPath
1.3 +14 -11
jakarta-struts/src/share/org/apache/struts/util/LabelValueBean.java
Index: LabelValueBean.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/Labe
lValueBean.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LabelValueBean.java 12 Mar 2002 06:30:56 - 1.2
+++ LabelValueBean.java 2 Jul 2003 02:20:28 - 1.3
@@ -7,7 +7,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 1999-2001 The Apache Software Foundation.
All rights
+ * Copyright (c) 1999-2003 The Apache Software Foundation.
All rights
* reserved.
*
* Redistribution and use in source and binary forms, with
or without
@@ -59,13 +59,10 @@
*
*/
-
package org.apache.struts.util;
-
import java.io.Serializable;
-
/**
* A simple JavaBean to represent label-value pairs. This
is most commonly used
* when constructing user interface elements which have a
label to be displayed
@@ -76,7 +73,6 @@
* @author Martin F N Cooper
* @version $Revision$ $Date$
*/
-
public class LabelValueBean implements Serializable {
@@ -84,6 +80,13 @@
/**
+ * Default constructor.
+ */
+public LabelValueBean() {
+this(null, null);
+}
+
+/**
* Construct an instance with the supplied property values.
*
* @param label The label to be displayed to the user.
@@ -101,7 +104,7 @@
/**
* The property which supplies the option label
visible to the end user.
*/
-private String label;
+private String label = null;
public String getLabel() {
return this.label;
@@ -115,7 +118,7 @@
/**
* The property which supplies the value returned to
the server.
*/
-private String value;
+private String value = null;
public String getValue() {
return this.value;
-
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]
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
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]
[ANNOUNCEMENT] Struts 1.1 Final released
The Struts team is proud, and extremely pleased, to announce the Final release of Struts 1.1. This release includes significant new functionality, as well as numerous fixes for bugs which were reported against the previous release, and supersedes the earlier 1.0.2 version as the latest official release of Struts from the Apache Software Foundation. The binary distribution is available at: http://www.apache.org/dist/jakarta/struts/binaries/ and the source distribution is available at: http://www.apache.org/dist/jakarta/struts/source/ In addition, the library distribution, which contains updated binaries without the sample applications, is available at: http://www.apache.org/dist/jakarta/struts/library/ Details of the changes in this release are available in the Release Notes, which can be found here: http://jakarta.apache.org/struts/userGuide/release-notes-1.1.html -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Vote: Struts-Faces Integration Library 0.4
On Fri, 27 Jun 2003, Craig R. McClanahan wrote: This is a formal vote to release version 0.4 of the integration library as an official distribution from the Struts Project: --- [VOTING SLIP: Struts-Faces Integration Library 0.4] - [X] +1 - I am in favor of this release, and can help [ ] +0 - I am in favor of this release, but cannot help [ ] -0 - I am not in favor of this release [ ] -1 - I am against this proposal (must include a reason) --- -- Martin Cooper Here's my +1. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Final Release
On Thu, 26 Jun 2003, Ted Husted wrote: -- 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). - Yippee! -- Martin Cooper I am +1 on the Struts 1.1 Final release plan. -Ted. - 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: [ANNOUNCEMENT] Struts 1.1 Release Candidate 2 released
On Thu, 26 Jun 2003, Ted Husted wrote: Martin, Since you're still engaged with FileUpload (bless you!), I cobbled up a release plan (with you as Release Manager) and will post a vote, so that this can be ready and waiting for you =:0) Thanks for doing this, Ted, that's great. FileUpload went out last night (or rather early this morning ;), so now we have all of our Commons ducks in a row. Yahoo! (Can I say that, or is it trademarked? :) -- Martin Cooper -Ted. Martin Cooper wrote: On Wed, 25 Jun 2003, Ted Husted wrote: I've got a release of my own shipping Monday, so if you want to finish this up Martin, please do =:0) Just want to be clear, so that nothing falls on the floor by accident. ;-) I'll do the Release Manager thing. Do you want me to do the plan and vote, or are you going to finish that up? I don't mind doing it, but I haven't started on it yet, and likely won't until I've finished with getting the FileUpload release out the door. Just let me know which way you'd like to go. -- Martin Cooper -Ted. Martin Cooper wrote: On Wed, 25 Jun 2003, Ted Husted wrote: Just a note on the RC2 status. Martin posted the release vote for FileUpload on Monday, and there are already 3 binding +1s. yeah!/ Yep. The release itself is built, I just need to get it out. That should happen this evening. We've one outstanding Bugzilla ticket against RC2, which we should be able to either resolve or postpone. Given the imminent release of FU 1.0, I plan to post the Struts 1.1 Final Release vote tomorrow, so that we can roll it out on June 29. double-yeah!/ I think we might have just a few happy customers at that time. ;-) I was just thinking about pushing out the release plan myself, but if you're already on it, great! It looks like I'll have time to do the release itself this weekend, assuming we're ready. -- 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: struts-lagacy.jar on ibiblio/maven (fwd)
On Thu, 26 Jun 2003, Craig R. McClanahan wrote: Tomsk, I don't know how to make this happen myself, but I'll forward this to the Struts Developer list and one of those folks will be able to help. I can make that happen. Since it often takes a few days, I'd prefer to hold off until Struts 1.1 Final is out (which should be this weekend) and push the final jars up to ibiblio, rather than pushing up RC2. Which jars need to go up there? I would assume struts-legacy.jar and struts.jar, although you only mentioned struts-legacy. Please let me know, and I'll get them all done at once. -- Martin Cooper Craig -- Forwarded message -- Date: Thu, 26 Jun 2003 21:54:10 +0200 From: Thomas Diesler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: struts-lagacy.jar on ibiblio/maven Hi craig, I would like to use the latest rc2 with maven. Could you put the struts-lagacy-1.1-rc2.jar onto ibiblio, or is it in another repo? cheers -tomsk - 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: [GUMP] Build Failure - jakarta-struts
On Thu, 26 Jun 2003, Stefan Bodewig wrote: [RESEND as I used the wrong sender address the first time and the mail is now stuck in the moderation queue.] On 26 Jun 2003, Stefan Bodewig [EMAIL PROTECTED] wrote: I'll see what I can do to fix the struts build on my personal Gump installation and will commit an updated Gump descriptor (and tell you after the fact 8-). OK, I've committed an altered Gump descriptor that successfully builds Struts. I've also removed the ant task from Struts' build.xml that invokes the legacy build locally and it still works. Awesome! Thanks SO much, Stefan! -- Martin Cooper Oh, and ... On Thu, 26 Jun 2003, Rob Leland [EMAIL PROTECTED] wrote: 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. happens because the definition of build.home in your top level build file overrides the definition in contrib/struts-legacy/build.xml when you use ant - which in turn has the effect you observe on legacy's javac's destdir attribute. Stefan - 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: [ANNOUNCEMENT] Struts 1.1 Release Candidate 2 released
On Wed, 25 Jun 2003, Ted Husted wrote: Just a note on the RC2 status. Martin posted the release vote for FileUpload on Monday, and there are already 3 binding +1s. yeah!/ Yep. The release itself is built, I just need to get it out. That should happen this evening. We've one outstanding Bugzilla ticket against RC2, which we should be able to either resolve or postpone. Given the imminent release of FU 1.0, I plan to post the Struts 1.1 Final Release vote tomorrow, so that we can roll it out on June 29. double-yeah!/ I think we might have just a few happy customers at that time. ;-) I was just thinking about pushing out the release plan myself, but if you're already on it, great! It looks like I'll have time to do the release itself this weekend, assuming we're ready. -- Martin Cooper -Ted. - 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: [ANNOUNCEMENT] Struts 1.1 Release Candidate 2 released
On Wed, 25 Jun 2003, Ted Husted wrote: I've got a release of my own shipping Monday, so if you want to finish this up Martin, please do =:0) Just want to be clear, so that nothing falls on the floor by accident. ;-) I'll do the Release Manager thing. Do you want me to do the plan and vote, or are you going to finish that up? I don't mind doing it, but I haven't started on it yet, and likely won't until I've finished with getting the FileUpload release out the door. Just let me know which way you'd like to go. -- Martin Cooper -Ted. Martin Cooper wrote: On Wed, 25 Jun 2003, Ted Husted wrote: Just a note on the RC2 status. Martin posted the release vote for FileUpload on Monday, and there are already 3 binding +1s. yeah!/ Yep. The release itself is built, I just need to get it out. That should happen this evening. We've one outstanding Bugzilla ticket against RC2, which we should be able to either resolve or postpone. Given the imminent release of FU 1.0, I plan to post the Struts 1.1 Final Release vote tomorrow, so that we can roll it out on June 29. double-yeah!/ I think we might have just a few happy customers at that time. ;-) I was just thinking about pushing out the release plan myself, but if you're already on it, great! It looks like I'll have time to do the release itself this weekend, assuming we're ready. -- Martin Cooper -Ted. - 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] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - 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: [GUMP] Build Failure - jakarta-struts
On Mon, 23 Jun 2003, David Graham wrote: On Monday 23 June 2003 09:40, James Mitchell wrote: I thought we had this fixed. Is there a document that explains a) how to fix this and b) how has access to it? ^^^ how == who Craig, because the builds run on his home machine. The *nightly* builds are run on Craig's machine, but the Gump builds are not. They are run on several different machines, and I believe one runs every 6 hours. The one that sends the nag mail is run on Sam Ruby's machine, I think. Every Jakarta committer has commit access to Gump: http://jakarta.apache.org/gump/ and the Struts Gump descriptor is in the Gump CVS repository. I posted a question to the Gump list on how to fix the Struts build, and Sam Ruby replied, but I haven't had a chance to follow up on that. You should be able to find the message in the archives, if you're interested. Rob Leland has taken a crack at fixing the Gump descriptor, but it appears he hasn't hit quite the right recipe yet. ;-) -- Martin Cooper David On Monday 23 June 2003 07:59, Craig McClanahan wrote: This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-06-23/jakarta-struts.html Buildfile: build.xml init: [echo] - jakarta-struts 1.1-rc2 - [echo] java.class.path = /home/rubys/jakarta/xml-commons/java/external/build/xml-apis.jar:/home/ru by s/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xm l-x erces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build /xa lan-unbundled.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/java/j2sdk 1.4 .1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/home/rubys/ja kar ta/ant/dist/lib/ant.jar:/home/rubys/jakarta/ant/dist/lib/ant-jmf.jar:/hom e/r ubys/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 /ja karta/ant/dist/lib/ant-trax.jar:/home/rubys/jakarta/ant/dist/lib/ant-xala n2. jar:/home/rubys/jakarta/ant/dist/lib/nodeps.jar:/opt/jdbc2_0/jdbc2_0-stde xt. jar:/home/rubys/jakarta/jakarta-servletapi-4/lib/servlet.jar:/home/rubys/ jak arta/jakarta-commons/beanutils/dist/commons-beanutils.jar:/home/rubys/jak art a/jakarta-commons/collections/dist/commons-collections.jar:/home/rubys/ja kar ta/jakarta-commons/digester/dist/commons-digester.jar:/home/rubys/jakarta /ja karta-commons/fileupload/target/commons-fileupload-20030623.jar:/home/rub ys/ jakarta/jakarta-commons/lang/dist/commons-lang-20030623.jar:/home/rubys/j aka rta/jakarta-commons/logging/dist/commons-logging.jar:/home/rubys/jakarta/ jak arta-commons/logging/dist/commons-logging-api.jar:/home/rubys/jakarta/jak art a-commons/validator/dist/commons-validator.jar:/home/rubys/jakarta/jakart a-o ro/jakarta-oro-20030623.jar:/home/rubys/jakarta/jakarta-struts/target/lib rar y/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/stru ts /resources [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/library/classes/META-INF [copy] Copying 8 files to /home/rubys/jakarta/jakarta-struts/target/library/classes/org/apache/stru ts /resources [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/library [copy] Copying 1 file to /home/rubys/jakarta/jakarta-struts/target/library BUILD FAILED /home/rubys/jakarta/jakarta-struts/build.xml:251: Warning: Could not find file /home/rubys/jakarta/jakarta-struts/contrib/struts-legacy/dist/struts-lega cy .jar to copy. Total time: 2 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - To unsubscribe, e-mail
Re: [GUMP] Build Failure - jakarta-struts
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. ;-) -- Martin Cooper -chris David Graham wrote: Yes. I knew that, but I seem to remember him saying a few times that any committer can modify the process (??gump descriptors??), but I can't seem to find that in the archives. Sorry, but using words like this and it aren't too descriptive ;-). I don't know how to access the gump descriptors. David [snip] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - 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: Tiles Use In A Disconnected PC
On Tue, 17 Jun 2003, Craig R. McClanahan wrote: On Tue, 17 Jun 2003, Martin Cooper wrote: Date: Tue, 17 Jun 2003 10:39:08 -0700 (PDT) From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles Use In A Disconnected PC I just checked, and sure enough, the path that's being registered for the local DTDs does not match the location of the DTDs within the jar. Phew ... it wasn't just me :-). I'm not sure which one is wrong, but I'll fix this tonight, unless someone else beats me to it. (Oh, the perils of an always-on connection! ;) I got the value I'm using from Ted's book: !DOCTYPE tiles-definitions PUBLIC -//Apache Software Foundation//DTD Ties COnfiguration 1.1//EN http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd; and I'd vote to go with that. Sorry, I wasn't clear in my message. The mismatch is between where the code is looking in the jar, and where the DTD actually is in the jar. In fact, the problem turns out to be even more strange. The code is registering each public ID twice, with different entity URLs. It would appear that the second one registered is the one it's trying to use. In any case, we shouldn't be registering more than once for the same public ID! By the way, Craig, I notice you have Ties instead of Tiles in the doctype above. I assume that's a typo in the message, and not in your code? ;-) -- Martin Cooper Regarding Validator, there was a similar issue with versions prior to Validator 1.0.2, but I'm pretty sure there is no problem with 1.0.2, which is what's bundled with Struts 1.1 RC2. If I'm wrong, someone please correct me ASAP so that we can fix that too. Validator worked fine for me offline. -- Martin Cooper Craig On Tue, 17 Jun 2003, Craig R. McClanahan wrote: One of my the demos for my JavaOne sessions (using Struts and JDO together) used Tiles -- but I ran into problems trying to parse the tiles-definitions.xml file when disconnected from the Internet. The only way I could fix this was to remove the DOCTYPE declaration (which is bad); this made the app work, but fired off a bunch of wierd parse errors in the Tomcat logs. The Struts code I used was very near (but not identical) what we shipped in RC2. I've seen a variety of comments on STRUTS-USER implying that this is still an issue. Can you guys please confirm that using the standard DOCTYPE declaration, when disconnected from the Internet, actually works? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page layout: Please forward (fwd)
Forwarding a report of web site problems. -- Martin Cooper -- Forwarded message -- Date: Mon, 09 Jun 2003 12:13:21 -0400 From: Apache Software Foundation [EMAIL PROTECTED] Reply-To: Jakarta Project Management Committee List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Page layout: Please forward not acked. -- The Apache Software Foundation If you have not looked at http://www.apache.org/foundation/preFAQ.html PLEASE DO SO NOW. There's an excellent chance your question/concern is addressed therein. If your question concerns licensing, please see http://www.apache.org/foundation/licence-FAQ.html---BeginMessage--- Hello, please do me a favour and forward the following remark to the webmaster or to whoever is involved with page layout. I do not expect any reply. Thank you. MS Internet Explorer 5.5 prints the following page badly in portrait format, even the so-called printer friendly version: http://jakarta.apache.org/struts/userGuide/preface.html The body text is truncated on the right. I expect, this applies to a lot more pages, since they are all layouted in the same way. Reason: The page uses a nested TABLE layout with with two images in the first outer row. Their combined width, unfortunately, exceeds the width of a normal printing page. Since both the width of the outer and of the inner table is set to 100%, the result is poor. After I stored the page on my disk and removed the outer table structure like this, the result was ok. body text=#00 vlink=#023264 alink=#023264 link=#023264 bgcolor=#ff !-- JAKARTA LOGO -- a href=http://jakarta.apache.org/; img alt=... src=.../jakarta-logo.gif align=left border=0/a !-- STRUTS LOGO -- a href=http://jakarta.apache.org/struts/; img alt=... src=.../struts.gif align=right border=0/a br clear=all hr !-- Here begins the former inner table -- table cellspacing=5 cellpadding=5 width=100% border=0 tbody tr td bgcolor=#023264 font face=arial,helvetica,sanserif color=#ff size=+1 strong0. Preface: Core Technologies/strong /font /td /tr ... and so on. Regards Hubert Kauker travel-BA.Sys GmbH Co. KG Backoffice- AdministrationsSysteme Alexanderstrasse 38 D-45472 Mülheim an der Ruhr, Germany www.travelbasys.de Telefon: +49 208 4947360. Fax: +49 208 491587. mailto:[EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles Use In A Disconnected PC
I just checked, and sure enough, the path that's being registered for the local DTDs does not match the location of the DTDs within the jar. I'm not sure which one is wrong, but I'll fix this tonight, unless someone else beats me to it. (Oh, the perils of an always-on connection! ;) Regarding Validator, there was a similar issue with versions prior to Validator 1.0.2, but I'm pretty sure there is no problem with 1.0.2, which is what's bundled with Struts 1.1 RC2. If I'm wrong, someone please correct me ASAP so that we can fix that too. -- Martin Cooper On Tue, 17 Jun 2003, Craig R. McClanahan wrote: One of my the demos for my JavaOne sessions (using Struts and JDO together) used Tiles -- but I ran into problems trying to parse the tiles-definitions.xml file when disconnected from the Internet. The only way I could fix this was to remove the DOCTYPE declaration (which is bad); this made the app work, but fired off a bunch of wierd parse errors in the Tomcat logs. The Struts code I used was very near (but not identical) what we shipped in RC2. I've seen a variety of comments on STRUTS-USER implying that this is still an issue. Can you guys please confirm that using the standard DOCTYPE declaration, when disconnected from the Internet, actually works? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: li'l help on contributing
This should help you understand the process: http://jakarta.apache.org/struts/faqs/helping.html -- Martin Cooper Ben Sion [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This is prolly, blaringly obvious to those that have done this before, but, after I have created a patch and attached it to the ticket, what is the process for fixes? btw, thanx for the heads up David. cheers Ben - Original Message - From: David Graham [EMAIL PROTECTED] Date: Thursday, June 12, 2003 1:00 pm Subject: Re: li'l help on contributing Create a patch in cvs diff -u format and attach it to the bugzilla ticket. David Hey guys, This is my first (small) foray into the world of open source contributions, so bear with me. I have fixed the code for the enhancement raised in Bugzilla (item 19944). I was wondering what the procedure is for checking these changes in? Does it first need approval(a vote) from the committers? are there any ant targets I need to run/show to prove that these changes don't break the existing code. Any help would be greatly appreciated. cheers Ben -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail --- -- 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: [GUMP] Build Failure - jakarta-struts
On Sun, 8 Jun 2003, Martin Cooper wrote: snip/ We're responsible for our own Gump descriptor. ;-) So, I guess we need to create a new descriptor for struts-legacy, since it needs to be listed as a dependency for the regular Struts build. I'm not sure how this works when they're both out of the same repo, but I can take this up with Sam et al if nobody else has any ideas in the meantime. I received some feedback from Sam, but I won't have a chance to follow up on that until after JavaOne (i.e. until after this week), so I'm afraid we'll have to endure a few more broken Gump builds yet. ;-( -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Final steps for RC2
I believe all that's left is the last of the testing, and then pushing the release itself out the door. Ted, I know you're heading out on Monday morning. In case you don't have time to finish up, it looks like I'll have some time to do that, just in time for JavaOne. Just in case, I've built a release and created signatures and digests, and even have a site2 update ready to go. If you'd like me to pick this up, I think all I need to know is which testing still needs to happen. (I'd like to avoid doing all of it, if possible, for time reasons. ;) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - jakarta-struts
On Sun, 8 Jun 2003, Ted Husted wrote: I popped the release up in that directory, so it's available there at least. I'm not sure where you mean by that directory. Gump always starts from scratch, based on what's at the HEAD of CVS, and builds everything. Actually, the only place I've seen struts-legacy is in the nightlies directory. Don't we need that to be in a released location, so that people can pick it up and build Struts with it? The buildfile follows the same format as Struts and Struts-Faces, so it may just be matter of telling Sam, or whoever is managing Gump these days, to start building it. We're responsible for our own Gump descriptor. ;-) So, I guess we need to create a new descriptor for struts-legacy, since it needs to be listed as a dependency for the regular Struts build. I'm not sure how this works when they're both out of the same repo, but I can take this up with Sam et al if nobody else has any ideas in the meantime. What do we do when a Commons package is added to the mix? That's easy - we just add a dependency on that Commons package in the Struts Gump descriptor. In this case, we need to create the descriptor for struts-legacy, though. However, this gives me an idea - perhaps I can look to the Commons descriptor for ideas on how to add struts-legacy to the regular Struts descriptor. -- Martin Cooper -T. Martin Cooper wrote: We're going to have to find a way to get Gump to build struts-legacy. It would be nice to get this working, given that the nightlies will be down for a while. If anyone has any ideas, please speak up! ;-) Otherwise I'll try to find some time to take a look, but it probably won't be today. -- Martin Cooper -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 2:34 AM To: [EMAIL PROTECTED] Subject: [GUMP] Build Failure - jakarta-struts This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-06-08/jakarta-struts.html Buildfile: build.xml init: [echo] - jakarta-struts 1.1-rc2 - [echo] java.class.path = /home/rubys/jakarta/xml-commons/java/external/build/xml-apis.j ar:/home/rubys/jakarta/xml- xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-x erces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build/xa lan- unbundled.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/jav a/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/too ls.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:/ho me/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/servle t.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-commo ns/dbcp/dist/commons-dbcp.jar:/home/rubys/jakarta/jakarta- commons/digester/dist/commons-digester.jar:/home/rubys/jakarta /jakarta-commons/fileupload/target/commons-fileupload-20030608 .jar:/home/rubys/jakarta/jakarta-commons/lang/dist/commons-lang- 20030608.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/ commons-logging.jar:/home/rubys/jakarta/jakarta-commons/loggin g/dist/commons-logging-api.jar:/home/rubys/jakarta/jakarta-com mons/pool/dist/commons-pool.jar:/home/rubys/jakarta/jakarta- commons/validator/dist/commons-validator.jar:/home/rubys/jakar ta/jakarta-oro/jakarta-oro-20030608.jar:/home/rubys/jakarta/ja karta-struts/target/library/classes:/home/rubys/jakarta/jakart a-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 to /home/rubys/jakarta/jakarta-struts/target/library/classes/org/ apache/struts/resources [copy] Copying 1 file to /home/rubys
[ANNOUNCEMENT] Struts 1.1 Release Candidate 2 released
The Struts team is proud to announce the release of Struts 1.1 Release Candidate 2. This release includes some new functionality, but mostly just fixes for a number of bugs which were reported against earlier versions. The Struts Team believes that this release is ready for prime time, hence its designation as a release candidate. The binary distribution is available at: http://www.apache.org/dist/jakarta/struts/binaries/ and the source distribution is available at: http://www.apache.org/dist/jakarta/struts/source/ In addition, the library distribution, which contains updated binaries without the sample applications, is available at: http://www.apache.org/dist/jakarta/struts/library/ Details of the changes in this release are available in the Release Notes, which can be found here: http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc2.html Special thanks to Ted Husted for his help in preparing this release. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging problem in 1.1 RC2
My apologies. Commons Logging now comes as two separate jars, and I bundled the wrong one. I've fixed the problem on the main Apache site. It'll take a little while to propagate to the mirrors, so if you want to download it right away, you probably want to go to the main site. -- Martin Cooper On Mon, 9 Jun 2003, Raible, Matt wrote: I found that this release candidate has a (seemingly) bad commons-logging.jar. I have a nightly build of Struts (20030326) and it's commons-logging.jar is 31K. The one shipped with 1.1 RC2 is only 22K and none of my JUnit tests emit any log messages. If I replace 1.1 RC2's commons-logging.jar with the one that's 31K, everything works as expected. Looks like the following files are missing: Log4jCategoryLog.class Log4jFactory.class Log4JLogger.class LogKitLogger.class package.html Here's a screenshot of the diff between the two: http://tinyurl.com/dvtw Is this as designed? Thanks, Matt -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2003 1:29 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [ANNOUNCEMENT] Struts 1.1 Release Candidate 2 released The Struts team is proud to announce the release of Struts 1.1 Release Candidate 2. This release includes some new functionality, but mostly just fixes for a number of bugs which were reported against earlier versions. The Struts Team believes that this release is ready for prime time, hence its designation as a release candidate. The binary distribution is available at: http://www.apache.org/dist/jakarta/struts/binaries/ and the source distribution is available at: http://www.apache.org/dist/jakarta/struts/source/ In addition, the library distribution, which contains updated binaries without the sample applications, is available at: http://www.apache.org/dist/jakarta/struts/library/ Details of the changes in this release are available in the Release Notes, which can be found here: http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc2.html Special thanks to Ted Husted for his help in preparing this release. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status check? - Houston we have a problem
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 4:37 AM To: Struts Developers List Subject: Re: Status check? - Houston we have a problem I'm still play-testing the web apps against all three, but here's an early warning: Running the exercise app under Tomcat 3.3.1a The logic-compare test kills container - nothing in log to indicate why. This is a big test, so it may be rendering problem. (TC41 is OK) Urk. It doesn't just kill the container, it kills the JVM (on Sun JDK 1.4.1_01). I didn't see that before, but maybe I was using an earlier JVM. If I have time, I'll try that. Same result under NN and IE for Windows XP. The Tomcat test memory usage is under 50%. Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal), http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp Error: 500 Location: /struts-exercise-taglib/bean-cookie.jsp Internal Servlet Error: org.apache.jasper.JasperException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public The part of the test that is failing is: jsp:getProperty name=sess property=name/ The jsp:getProperty tags earlier on the page succeeded. The only difference I can see is that the earlier ones all have setters as well as getters in the Tomcat CookieFacade class, whereas there is only a getter for 'name'. So this actually looks like some kind of JSP/reflection bug, not related to Struts. (The bean:cookie tag must have worked, because we know the jsp:getProperty tag is trying to access a cookie!) -- Martin Cooper at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty( JspRuntimeLibrary.java:430) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandl er.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler .java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConn ection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi nt.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) Root cause: java.lang.IllegalAccessException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57) at java.lang.reflect.Method.invoke(Method.java:317) at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty( JspRuntimeLibrary.java:428) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandl er.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler .java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConn ection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi nt.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) - 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: [GUMP] Build Failure - jakarta-struts
We're going to have to find a way to get Gump to build struts-legacy. It
would be nice to get this working, given that the nightlies will be down for
a while. If anyone has any ideas, please speak up! ;-) Otherwise I'll try to
find some time to take a look, but it probably won't be today.
--
Martin Cooper
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 08, 2003 2:34 AM
To: [EMAIL PROTECTED]
Subject: [GUMP] Build Failure - jakarta-struts
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-08/jakarta-struts.html
Buildfile: build.xml
init:
[echo] - jakarta-struts 1.1-rc2 -
[echo] java.class.path =
/home/rubys/jakarta/xml-commons/java/external/build/xml-apis.j
ar:/home/rubys/jakarta/xml-
xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-x
erces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build/xa
lan- unbundled.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/jav
a/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/too
ls.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:/ho
me/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/servle
t.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-commo
ns/dbcp/dist/commons-dbcp.jar:/home/rubys/jakarta/jakarta-
commons/digester/dist/commons-digester.jar:/home/rubys/jakarta
/jakarta-commons/fileupload/target/commons-fileupload-20030608
.jar:/home/rubys/jakarta/jakarta-commons/lang/dist/commons-lang-
20030608.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/
commons-logging.jar:/home/rubys/jakarta/jakarta-commons/loggin
g/dist/commons-logging-api.jar:/home/rubys/jakarta/jakarta-com
mons/pool/dist/commons-pool.jar:/home/rubys/jakarta/jakarta-
commons/validator/dist/commons-validator.jar:/home/rubys/jakar
ta/jakarta-oro/jakarta-oro-20030608.jar:/home/rubys/jakarta/ja
karta-struts/target/library/classes:/home/rubys/jakarta/jakart
a-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 to
/home/rubys/jakarta/jakarta-struts/target/library/classes/org/
apache/struts/resources
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-struts/target/library
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-struts/target/library
BUILD FAILED
/home/rubys/jakarta/jakarta-struts/build.xml:251: Warning:
Could not find file
/home/rubys/jakarta/jakarta-struts/${struts-legacy.jar} to copy.
Total time: 2 seconds
-
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: Status check? - Houston we have a problem
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 10:24 AM To: 'Struts Developers List' Subject: RE: Status check? - Houston we have a problem -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 4:37 AM To: Struts Developers List Subject: Re: Status check? - Houston we have a problem I'm still play-testing the web apps against all three, but here's an early warning: Running the exercise app under Tomcat 3.3.1a The logic-compare test kills container - nothing in log to indicate why. This is a big test, so it may be rendering problem. (TC41 is OK) Urk. It doesn't just kill the container, it kills the JVM (on Sun JDK 1.4.1_01). I didn't see that before, but maybe I was using an earlier JVM. If I have time, I'll try that. I just tried Sun JDK 1.4.0, and it kills that too. ;-( Don't know if I have any others lying around. I'll see... -- Martin Cooper Same result under NN and IE for Windows XP. The Tomcat test memory usage is under 50%. Also (Same result NN/IE; TC41 is OK; Tomcat cookie test nominal), http://localhost:8080/struts-exercise-taglib/bean-cookie.jsp Error: 500 Location: /struts-exercise-taglib/bean-cookie.jsp Internal Servlet Error: org.apache.jasper.JasperException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public The part of the test that is failing is: jsp:getProperty name=sess property=name/ The jsp:getProperty tags earlier on the page succeeded. The only difference I can see is that the earlier ones all have setters as well as getters in the Tomcat CookieFacade class, whereas there is only a getter for 'name'. So this actually looks like some kind of JSP/reflection bug, not related to Struts. (The bean:cookie tag must have worked, because we know the jsp:getProperty tag is trying to access a cookie!) -- Martin Cooper at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty( JspRuntimeLibrary.java:430) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandl er.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler .java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConn ection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi nt.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) Root cause: java.lang.IllegalAccessException: Class org.apache.jasper.runtime.JspRuntimeLibrary can not access a member of class org.apache.tomcat.facade.CookieFacade with modifiers public at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:57) at java.lang.reflect.Method.invoke(Method.java:317) at org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty( JspRuntimeLibrary.java:428) at bean_0002dcookie_1._jspService(bean_0002dcookie_1.java:284) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandl er.java:574) at org.apache.tomcat.core.Handler.invoke(Handler.java:322) at org.apache.tomcat.core.Handler.service(Handler.java:235) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler .java:485) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:917) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833) at org.apache.tomcat.modules.server.Http10Interceptor.processConn ection(Http10Interceptor.java:176) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoi nt.java:494) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:516) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: [VOTE] Convert RC2 to Beta 5
I'm not going to vote right now, because I'm trying to work through the problems and see if I can get them fixed. Ted, how long do we have to find fixes and still allow you enough time to get a release out? If we take the 'name' row out of the bean-cookie.jsp test, then the remainder of that test works fine on Tomcat 3.3.1. I propose to go ahead and check that in unless I hear any objection. Now I'm looking at the logic-compare.jsp problem. If anyone else has some time to look into the problems, might I suggest looking at the Tiles-related ones that Ted mentioned? -- Martin Cooper -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 3:14 PM To: Struts Developers List Subject: [VOTE] Convert RC2 to Beta 5 In final testing of RC2, some compatibility issues have been found between Tomcat 3.3.1 and the struts-exercise-taglib application as well as the tiles-documentation application. Martin Cooper has been looking into the problems and has found that for the struts-exercise-taglibs cookie test, it is the jsp:getProperty name=sess property=name/ expression that is failing. The jsp:getProperty tags earlier on the page succeeded. The only difference seems to be that the earlier ones all have setters as well as getters in the Tomcat CookieFacade class, whereas there is only a getter for 'name'. So this actually looks like some kind of JSP/reflection bug, not related to Struts. (The bean:cookie tag must have worked, because we know the jsp:getProperty tag is trying to access a cookie!) Also, the (rather complex) comparison test is killing the JVM when run under TC3. In the Tiles application, servlet exceptions are being noted. One example is the extendedDefinitionTag page, but there may be others. Unless fixes to these problems are immediately forthcoming, I propose that we document the issues and release Stuts 1.1 beta 5. By getting this milestone out to the community, we would have a better chance of resolving the remaining issues so that we can go to Struts 1.1. final as soon as possible This proposal has my +1. -Ted. - 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] Convert RC2 to Beta 5
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 4:56 PM To: 'Struts Developers List' Subject: RE: [VOTE] Convert RC2 to Beta 5 I'm not going to vote right now, because I'm trying to work through the problems and see if I can get them fixed. Ted, how long do we have to find fixes and still allow you enough time to get a release out? If we take the 'name' row out of the bean-cookie.jsp test, then the remainder of that test works fine on Tomcat 3.3.1. I propose to go ahead and check that in unless I hear any objection. Now I'm looking at the logic-compare.jsp problem. OK, I have this one nailed. It has to do with the size of the page being too big for Tomcat 3.3.1 to handle. I've split the page into two by pulling out the numeric tests into a separate page, and both pages now work. Again, I propose to check this in unless I hear any objection. Now for the Tiles problems... -- Martin Cooper If anyone else has some time to look into the problems, might I suggest looking at the Tiles-related ones that Ted mentioned? -- Martin Cooper -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 3:14 PM To: Struts Developers List Subject: [VOTE] Convert RC2 to Beta 5 In final testing of RC2, some compatibility issues have been found between Tomcat 3.3.1 and the struts-exercise-taglib application as well as the tiles-documentation application. Martin Cooper has been looking into the problems and has found that for the struts-exercise-taglibs cookie test, it is the jsp:getProperty name=sess property=name/ expression that is failing. The jsp:getProperty tags earlier on the page succeeded. The only difference seems to be that the earlier ones all have setters as well as getters in the Tomcat CookieFacade class, whereas there is only a getter for 'name'. So this actually looks like some kind of JSP/reflection bug, not related to Struts. (The bean:cookie tag must have worked, because we know the jsp:getProperty tag is trying to access a cookie!) Also, the (rather complex) comparison test is killing the JVM when run under TC3. In the Tiles application, servlet exceptions are being noted. One example is the extendedDefinitionTag page, but there may be others. Unless fixes to these problems are immediately forthcoming, I propose that we document the issues and release Stuts 1.1 beta 5. By getting this milestone out to the community, we would have a better chance of resolving the remaining issues so that we can go to Struts 1.1. final as soon as possible This proposal has my +1. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Convert RC2 to Beta 5
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 5:26 PM To: 'Struts Developers List' Subject: RE: [VOTE] Convert RC2 to Beta 5 -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 4:56 PM To: 'Struts Developers List' Subject: RE: [VOTE] Convert RC2 to Beta 5 I'm not going to vote right now, because I'm trying to work through the problems and see if I can get them fixed. Ted, how long do we have to find fixes and still allow you enough time to get a release out? If we take the 'name' row out of the bean-cookie.jsp test, then the remainder of that test works fine on Tomcat 3.3.1. I propose to go ahead and check that in unless I hear any objection. Now I'm looking at the logic-compare.jsp problem. OK, I have this one nailed. It has to do with the size of the page being too big for Tomcat 3.3.1 to handle. I've split the page into two by pulling out the numeric tests into a separate page, and both pages now work. Again, I propose to check this in unless I hear any objection. Now for the Tiles problems... Fixed. Time to release RC2! :-) -- Martin Cooper -- Martin Cooper If anyone else has some time to look into the problems, might I suggest looking at the Tiles-related ones that Ted mentioned? -- Martin Cooper -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 3:14 PM To: Struts Developers List Subject: [VOTE] Convert RC2 to Beta 5 In final testing of RC2, some compatibility issues have been found between Tomcat 3.3.1 and the struts-exercise-taglib application as well as the tiles-documentation application. Martin Cooper has been looking into the problems and has found that for the struts-exercise-taglibs cookie test, it is the jsp:getProperty name=sess property=name/ expression that is failing. The jsp:getProperty tags earlier on the page succeeded. The only difference seems to be that the earlier ones all have setters as well as getters in the Tomcat CookieFacade class, whereas there is only a getter for 'name'. So this actually looks like some kind of JSP/reflection bug, not related to Struts. (The bean:cookie tag must have worked, because we know the jsp:getProperty tag is trying to access a cookie!) Also, the (rather complex) comparison test is killing the JVM when run under TC3. In the Tiles application, servlet exceptions are being noted. One example is the extendedDefinitionTag page, but there may be others. Unless fixes to these problems are immediately forthcoming, I propose that we document the issues and release Stuts 1.1 beta 5. By getting this milestone out to the community, we would have a better chance of resolving the remaining issues so that we can go to Struts 1.1. final as soon as possible This proposal has my +1. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
I'm doing a cleanup pass over the release notes right now, fixing some things and cleaning up the text in some places. Is it OK for me to go ahead and check that in when I'm done, Ted? -- Martin Cooper On Sat, 7 Jun 2003, Ted Husted wrote: OK, the release-notes are updated. ]My, we have been busy little beavers:-)]. There were a good number of refactoring and fixes, but no new major changes aside from those stated. (Though, I'll need to add the new deprecations to the What's Different list. If there's anything else we've done recently that should be added to the What's New and What's Different sections, please let me know. I need to run some errands. If anyone is around and is up for starting on some of the Tomcat tests for me, that would be great. We need to run the Cactus tests and playtest the examples apps for the supported containers. Otherwise, I'll get to it this afternoon. -Ted. - 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: Status check?
On Sat, 7 Jun 2003, Craig R. McClanahan wrote: On Sat, 7 Jun 2003, Ted Husted wrote: Date: Sat, 07 Jun 2003 14:25:23 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Status check? Yes, go ahead, Martin. I made a couple of very minor changes to my local copy, but nothing that won't reconcile after you chedck in yours. A very popular FAQ after each release has been what version of the commons libraries was included. Can we be explicit about this, perhaps in the what's included section? I'm actually in the middle of adding that now. ;-) I remember you asked me a while ago to make sure we list the explicit versions we use. The What's Included section seems like the logical place. My only concern is that, because of the length of the RC/Beta Fixes section, it's quite far down the page. But I don't know where else I would put it... -- Martin Cooper By the way, I uploaded the new Struts-Faces integration library stuff (and copied over the old one for legacy purposes) to a new directory: http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/ I left a web server redirect in place so to that the old URL comes here. Martin Cooper wrote: I'm doing a cleanup pass over the release notes right now, fixing some things and cleaning up the text in some places. Is it OK for me to go ahead and check that in when I'm done, Ted? One more status note ... it doesn't look like I'm going to be able to resurrect my nightly build process (for Commons packages and Struts) before getting on a plane tomorrow for JavaOne, so nightly builds will probably not be available until I can get back and clean that up. I hate disk hardware problems :-(. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Sat, 7 Jun 2003, Ted Husted wrote: Martin Cooper wrote: I'm actually in the middle of adding that now. ;-) I remember you asked me a while ago to make sure we list the explicit versions we use. The What's Included section seems like the logical place. My only concern is that, because of the length of the RC/Beta Fixes section, it's quite far down the page. But I don't know where else I would put it... It would be best to carry the explicit list on the installation page installation.html as we always have, and then add a cross-reference from the Release Notes, to remind people where to find it. =;) The list on the installation page refers to what you need if you want to build Struts from source, rather than what is bundled with Struts itself. They're similar, but not identical, since in the former, we refer to version 123 or later, whereas in the latter, we need to specify an exact version. I'd actually prefer to put the list in the What's Included and then change the installation page to say that you need to build against what's included with Struts, or a later version, and have the link point the other way. Since I'm already done adding the list to the release notes, I'll go ahead and check that in, but feel free to move it if you'd prefer. Incidentally, I noticed that the installation page still references DBCP and Pool, and the build file is still including those jars in the build. We obviously need to fix those before the release. Let me know if you'd like me to take care of either of those. -- Martin Cooper We might also mention that the packages are also cited in the build.properties.sample file. But, we should avoid keeping the actual list in a third place =:) -Ted. - 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: Status check?
On Sat, 7 Jun 2003, Ted Husted wrote: Martin Cooper wrote: http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases I added the section on PGP 8.0 Freeware, since that's what I use, but you can also use GPG, which I think is installed on daedalus. The MD5 tool is definitely installed on daedalus, since that's where I create the digests for Struts releases. If you're still having trouble, you could put the zip and tar.gz bundles in your home directory on cvs and give me access, and I can create the sigs and upload them, if you want. OK, I admittedly haven't even tried signing these, but I still need to pack. =:) I uploaded struts-legacy to my home directory on cvs.apache.org. Could you could sign these for me, Martin? You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o. I've created the .asc signature files, and the .md5 digest files, but only for the .tar.gz and .zip files, since we don't usually release the .tar files. (They're only needed to produce the .tar.gz files.) -- Martin Cooper There aren't any lib files, since this distribution is nothing but lib :) (Really loving that release target!) -Ted. - 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: Status check?
On Sat, 7 Jun 2003, Ted Husted wrote: Martin Cooper wrote: You'll find everything ready to go at ~martinc/struts-legacy on cvs.a.o. I've created the .asc signature files, and the .md5 digest files, but only for the .tar.gz and .zip files, since we don't usually release the .tar files. (They're only needed to produce the .tar.gz files.) OK, I've made the changes regarding the DBPC/Pool dependencies, and play tested the new build in an application that exercises the datasource, along with the Tiles and the Validator -- all systems nominal! I can do the stock Tomcat testing in the morning, and, should everything pass, we can tag this puppy and ship it! (If anyone wants to be the Release Test Manager, jump in now! There's a working candidate at http://cvs.apache.org/~husted/ - This is a preview only - it is *not* the final RC! but it's what we want to test.) Assuming the rest is done, Martin, old friend, will you be around tomorrow at mid-day to sign the Struts jar for me? If you mean mid-day EDT, yes, I should be around then. By mid-day PDT, though, I'll be out at a lunch appointment. So the earlier you're ready, the better. ;-) -- Martin Cooper (I promise to get setup to do signing for next time.) -Ted. - 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: Status check?
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Our installation page says our dependency is J2SE 1.2 or later. Does that mean I should compile the binary distribution under the latest J2SE 1.2, or should I use the latest J2SE 1.4? I have been building the releases using J2SE 1.4 for some time now, and I would recommend sticking with that. Going with 1.4 ensures we get the benefits of the latest compiler improvements. The compatibility issue is with the JVM rather than the compiler - we want to be able to run on J2SE 1.2, but we don't need to build the releases with that. -- Martin Cooper I'm installing 1.2 now, to at least be sure it still builds (as I remember, the nightlies are building on Craig's machine under 1.4). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: The tagging for the main Struts release will actually be a bit more painful for RC2 since you can't just blanket-tag the Commons packages - they'll have to be tagged individually to match the specific versions we're bundling. I can understand why we tagged the Commons packages when we were building betas against the nightly builds, but now that we are basing our RCs on Final Releases or other Release Candidates, tagging the Commons CVS seems futile and dangerous. Don't they already have tags for the versions upon which we have declared our dependency? And, I'd have to be sure I had the release version checked-out (some of which are months old now) rather than the current trunk. I disagree that it is either futile or dangerous. It is useful because you can, at some point in time, just do a CVS checkout using the appropriate Struts tag and get everything you need to build that version of Struts. That way, you don't have to refer to a (possibly erroneous) document to look up which versions you need to get. It isn't dangerous, because you can simply ask CVS to tag the code for a specific version of a Commons component with the relevant Struts tag. It could be dangerous if it was done off a local code base rather than tagging CVS against CVS itself, but that's not necessary. I'll take care of tagging our dependencies once RC2 is out. -- Martin Cooper -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Sat, 31 May 2003, Martin Cooper wrote: Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2 this weekend, I can then cut RC2 with that, if you like. The bugs are all resolved now. (1 fixed, 1 remind, 3 later (enhancements).) So it's just a matter of what release this will be, and what to do about the deprecated methods. Then I can send out the vote. OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or updated the web site, but it's there. The Tomcat build did indeed break, and interested parties can see the resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe for their support. -- Martin Cooper I'm going to release the struts-generic package first thing in the morning, and move the nightly build dependencies over to that, so we can then just plug in the latest FileUpload. IMHO, you might consider taking FileUpload straight to RC1. It's unreleased software and API changes are to be expected. If this were FU 2.0, and you were removing something that was in FU 1.0's established API, it would be different. But greater latitude as to API changes should be given to unreleased, pre-1.0 packages. So you're suggesting that I rip out the deprecated methods now, go for RC1, and damn the torpedoes that the API is incompatible between Beta 1 and RC1, and there was no warning (other than nightly builds)? You really think that's OK? Gump builds for Tomcat and Turbine will start failing as soon as I remove the deprecated methods. Tapestry won't be affected, since Mr. Tapestry doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts already has the necessary changes. -- Martin Cooper If you were to go to FileUpload RC1, then perhaps Struts and FileUpload can then go to final together. -Ted. - 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: Status check?
On Tue, 3 Jun 2003, Ted Husted wrote: If anyone had a mind to, it would be really great to have the Struts News and Resources pages updated this week, before the next RC. There's been a bunch of stuff announced on the list lately. (If not, I'll try to do it before we go to final release.) I'm still getting my head around the release procedures [never signed a JAR before, except with a marker =:)], but do hope to have it sorted out by Friday or Saturday. You shouldn't have to sign any jars - we haven't done that for Struts before. The only things I sign for the releases are the zip and tar.gz bundles. There's a page on the Wiki that might help you with that: http://nagoya.apache.org/wiki/apachewiki.cgi?SigningReleases I added the section on PGP 8.0 Freeware, since that's what I use, but you can also use GPG, which I think is installed on daedalus. The MD5 tool is definitely installed on daedalus, since that's where I create the digests for Struts releases. If you're still having trouble, you could put the zip and tar.gz bundles in your home directory on cvs and give me access, and I can create the sigs and upload them, if you want. -- Martin Cooper -Ted. - 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: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2
David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'm fairly certain I voted +1 on this. Yup. http://marc.theaimsgroup.com/?l=struts-devm=105421605003516w=2 -- Martin Cooper David From: James Turner [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2 Date: Tue, 3 Jun 2003 23:47:12 -0400 +1 James Holmes [EMAIL PROTECTED] James Turner [EMAIL PROTECTED] James Mitchell [EMAIL PROTECTED] Arron Bates [EMAIL PROTECTED] No other votes (unless Ted and David Graham want to +1 retroactively, since they seemed to be supportive but didn't explicitly +1) Therefore, the vote passes. James Turner Director of Software Development Benefit Systems, Inc. [EMAIL PROTECTED] Track Chair, Strategic Open Source 2003 Fall COMDEX Author: MySQL JSP Web Applications Struts Kick Start JavaServer Faces Kick Start - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Sun, 1 Jun 2003, Ted Husted wrote: Martin, I'm trying to release the struts-legacy package with our GenericDataSource implementation. I'm working from the Commons instructions (but substituting jakarta-struts where appropriate). http://jakarta.apache.org/commons/releases.html The instructions here are more up to date and more comprehensive: http://jakarta.apache.org/commons/releases/ I proposed switching the link to that not too long ago, but Robert wanted to do some cleanup first. IMHO, they're still better, though. At step 5, it looks like I should log into cvs.apache.org first, tag the live files there, and create the binary distribution on that machine, as is done with the source distribution at step 9. When you tag something in CVS, you're tagging the repository rather than the files per se. So yes, you need to be connected to cvs.apache.org. Basically, you need to make sure what you have on your local disk is what you want to tag, and then run the CVS 'tag' command. That will tag the repository. The reason your local files need to be up to date is because the version tagged in the repo is whatever you have locally. You can also use 'cvs rtag' if you want to tag the repo regardless of what you have, but I think most people, myself included, stick with 'cvs tag'. The binary and source distributions come from your local machine. You won't be able to build them on cvs.a.o or www.a.o, since they don't have the JDK available. As far as building and packaging go, you might want to take a look at the 'release' target I added to the main Struts build file. That really helps with putting the binary and source uploads together. For the main Struts release, the most time-consuming part is just testing that everything works with all the supported containers (including all the web apps). I don't know how much you'll need to do for the legacy stuff. Another time-consuming step is signing everything and creating digests. The tagging for the main Struts release will actually be a bit more painful for RC2 since you can't just blanket-tag the Commons packages - they'll have to be tagged individually to match the specific versions we're bundling. Hope this helps. -- Martin Cooper Is that correct? Otherwise, do I check the files in (again) between #8 and #9, so the tag propagates. I've haven't had to set CVS tags myself before, and so I'm a bit nervous about that part. -Ted. -- Ted Hustled, Struts in Action http://husted.com/struts/book.html - 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: Status check?
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2 this weekend, I can then cut RC2 with that, if you like. The bugs are all resolved now. (1 fixed, 1 remind, 3 later (enhancements).) So it's just a matter of what release this will be, and what to do about the deprecated methods. Then I can send out the vote. I'm going to release the struts-generic package first thing in the morning, and move the nightly build dependencies over to that, so we can then just plug in the latest FileUpload. IMHO, you might consider taking FileUpload straight to RC1. It's unreleased software and API changes are to be expected. If this were FU 2.0, and you were removing something that was in FU 1.0's established API, it would be different. But greater latitude as to API changes should be given to unreleased, pre-1.0 packages. So you're suggesting that I rip out the deprecated methods now, go for RC1, and damn the torpedoes that the API is incompatible between Beta 1 and RC1, and there was no warning (other than nightly builds)? You really think that's OK? Gump builds for Tomcat and Turbine will start failing as soon as I remove the deprecated methods. Tapestry won't be affected, since Mr. Tapestry doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts already has the necessary changes. -- Martin Cooper If you were to go to FileUpload RC1, then perhaps Struts and FileUpload can then go to final together. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
On Wed, 28 May 2003, James Turner wrote: Ok folks, things have been mighty quiet lately here. So I'm going to summerize where I think things are right now: 1) Struts core is basically ready to go, and the dependency on the latest version of DBCP has been removed 2) What we're waiting on is the final release of FileUpload, which Martin is working on. Can we get a status check on FileUpload? It would be mighty nice to get RC2 out before JavaOne. First, the FileUpload status. I have had some e-mail exchanges off-list with the reporters of the two outstanding bugs. A partial solution exists for one of them, and, when completed, should actually solve both of them. Unfortunately, those solutions won't work for Struts users, since they involve passing new information to FileUpload, which Struts obviously doesn't do right now. However, that could potentially be deferred to a Struts 1.2 release, as long as we promise ourselves that we'll be better about getting releases out more frequently. My problem right now with getting this finished up is that I am really swamped at my day job. With the hours I'm having to devote to that at the moment, there aren't many left for anything else. (Somebody told me last weekend was a holiday weekend. What weekend? ;) I promise I'll try to find some time this coming weekend to get a fix in that will hopefully resolve both issues. Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. Much as I would like to see Struts 1.1 RC2 happen before JavaOne, I just don't see how that can happen, given the steps that FileUpload has to go through before a final release. I almost felt like finishing up the following paragraph with Sorry, folks. But I decided to rant instead. |- rant For a long time now, not one other committer to FileUpload has put in any effort to finish it up and/or get it released. This is despite the fact that FileUpload is used by Tomcat, Turbine and Tapestry, as well as by Struts. I feel like I'm running a one-man show, which is exactly what Jakarta (and Apache) projects are not supposed to be. Running such a one-man show makes me feel guilty when I don't have the time to put in to help get Struts 1.1 RC2 out the door. It makes me feel like it's my fault. But it shouldn't be up to just me. /rant (Can you tell that I'm really stressed out right now? ;) Important note: The above rant should *not* be read as a complaint that other Struts developers are not getting involved with FileUpload. I don't expect you guys to do that at all. Rant over. Now back to my day job. (A day job at 11pm? What's wrong with this picture?) -- Martin Cooper James Turner Director of Software Development Benefit Systems, Inc. [EMAIL PROTECTED] Track Chair, Strategic Open Source 2003 Fall COMDEX Author: MySQL JSP Web Applications Struts Kick Start JavaServer Faces Kick Start - 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: Bugzilla status for bugs with patches
There is a standard Bugzilla way of marking bugs so that those with (or without) patches can be easily identified. That is the use of PatchAvailable in the Keywords field. Ted has started using this field, and I think this is great. Unfortunately, I suspect there are plenty of unresolved bug reports that have patches but do not have this keyword set. A very useful exercise, therefore, would be to query for unresolved bug reports that do not have PatchAvailable set, and then go through the results and add the keyword for those that do have patches. Personally, I find the use of [PATCH] in the subject of a bug report annoying, and I'd rather see that removed and replaced with the use of the PatchAvailable keyword. -- Martin Cooper Mohan Kishore [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I am sorry - i guess i was not very clear. i am just concerned about how to query Bugzilla in order to only get bugs with no available patches. If we had a standard (say, keyword 'PATCH' or 'HAS_PATCH') for bugs with an available patch, then we can do more focussed queries. Would be especially nice if there were a small document which establishes the steps in picking up bugs from Bugzilla, [assigning to oneself], uploading patch, updating status etc. (with focus on Bugzilla status at every point). Would allow easier participation from part-time/new participants... regards, Mohan. --- David Graham [EMAIL PROTECTED] wrote: The patches are listed in each bug report as links to the attachments. I personally don't use the [PATCH] marker in the name because you can just add that to the keywords field. David Hi, Is it a standard (at least within jakarta) to prefix the bugs with patches available with a [PATCH]? Any ideas w.r.t creating a status called Has Patch? I ask because there are quite a few bugs in the commons which have no indication about available patches. I guess the commiters can finish up (or reject) the ones with patches, while the rest of us can try our hands at the ones which do not have any fix yet... regards, Mohan. __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've always wanted to move them to the HTML taglib, since they are tied to the Struts controller (where the other taglibs are not). This would put, I believe, all the Struts-dependant tags in one place. Nope. I'd say bean:struts is Struts-specific. ;-) -- Martin Cooper I don't think we need to pull them, but I would be in favor of deprecating them as logic tags and placing them in the html taglib (next time around). David Graham wrote: IMHO, the logic:forward and logic:redirect tags implement a business logic function in the view layer rather than in an Action. The rest of the tags in the logic taglib provide view layer functionality. I think we should deprecate logic:forward and logic:redirect to enforce a cleaner MVC implementation. Thoughts? David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
A few comments: 1) All of the tags in the logic taglib relate to flow control. There are two sets - conditionals and 'goto's - but they are all flow control. I find it strange to want to claim that some flow control tags break the MVC model while others don't. 2) If we removed these tags, we wouldn't be enforcing anything. People who use them today would just switch to using jsp:forward and c:redirect, but would lose the convenience of using logical names, as with other Struts tags, and have to hard code them instead. 3) Many people, including myself, have been using these tags since the earliest days of Struts. (They were created in September 2000.) To my knowledge, this is the first time that anyone has suggested that they break the MVC model. If other people really believed that, I would have expected it to come up before now. 4) Just for fun: I find it interesting that David is so impassioned about cleaning up the logic taglib when he's usually the first person to suggest that people forget that taglib and use JSTL instead. ;-) ;-) -- Martin Cooper David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] IMHO, the logic:forward and logic:redirect tags implement a business logic function in the view layer rather than in an Action. The rest of the tags in the logic taglib provide view layer functionality. I think we should deprecate logic:forward and logic:redirect to enforce a cleaner MVC implementation. Thoughts? David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
Mohan Kishore [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] --- Martin Cooper [EMAIL PROTECTED] wrote: 1) All of the tags in the logic taglib relate to flow control. There are two sets - conditionals and 'goto's Not true - conditionals relate to layout and display (i.e. View) Conditionals relate to whatever the developer wants them to relate to. They are in no way limited to layout and display. I can just as easily use a conditional tag to control (sic) a SQL update as I can to determine whether or not to show someone's credit card number. - gotos send control out of the current file (i.e. Control) In my view (!), you are splitting hairs here. You are saying that if a tag exerts control over the flow that takes that flow out of the page, that is Control. But if a tag exerts control over the flow such that the flow remains within the page, that is View. 2) If we removed these tags, we wouldn't be enforcing anything. But, we will be making a statement about the MVC pattern. e.g. People can still put in java code in scriptlets in JSP pages, we are not stopping them. We just have a stand and promote better practices... I agree with promoting best practices, of course. And I claim that using logical names in preference to hard coded URLs is a best practice, and that logic:forward and logic:redirect promote this practice. -- Martin Cooper imho __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Updating bug reports (was Re: DO NOT REPLY [Bug 18094] - validate method on ValidatorForm should use mapping.getName as key to validator)
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've been tagging the resolved laters for the unknown build and then indicating a milestone. The problem with this is that we don't know what version it was reported against, and therefore don't know what version to attempt to reproduce the problem with. If someone goes to try to reproduce it with the latest code base, and it doesn't happen, then we don't know if that's because the code changed since the version it was reported against, or whether there's some other factor involved that needs to be investigated. Knowing what version the problem was reported against is important, and I don't agree with zapping it out just so that we don't have to reopen LATER bugs. If we're going to continue to do this, then we should be going back and reinstating the original value later. That being the case, we might as well use LATER for what it's meant for, and leave Version for what it's meant for. And yes, I know that I can look at the Bug Activity to see the original version, but unless I'm mistaken, there's no way to run a report against past values of a field. -- Martin Cooper This gets them off the list of things we need to handle for the current iteration, but does not force us to go through the red tape of reopening it later. -T. [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18094. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18094 validate method on ValidatorForm should use mapping.getName as key to validator [EMAIL PROTECTED] changed: What|Removed |Added -- -- Status|NEW |RESOLVED Resolution||LATER -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STP] RC1 Release Plan
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] snip/ If we can swat these two, we might be able to roll out RC2. I've been somewhat absent from here for a while, primarily because I'm working on getting FileUpload into shape. In the process of addressing a couple of issues over there, I stumbled across a couple more that have required some larger changes, and I'm trying to get those polished off. I mention this here because the changes to FileUpload involve deprecating some methods that Struts calls in the very short term, and eliminating them from the FileUpload 1.0 Final release. My plan is to complete the FileUpload changes within a few days, update Struts to not use the deprecated methods, and submit equivalent patches against Tomcat 5 and Turbine, which also use FileUpload. At that point, I intend to go for FileUpload 1.0 Beta 2, then remove the deprecated methods, go for RC1 and then Final, all in as short a period as I can push it through. Comments welcome. -- Martin Cooper -T. Ted Husted wrote: I'll update the plan and website later, but for now, the outstanding RC1-RC2 list stands at five tickets [NOT RESOLVED, NOT CLOSED, STRUTS, NOT UNKNOWN]. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_sta tus=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1= emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailr eporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldt o=Nowchfieldvalue=product=Strutsversion=0.5+Finalversion=1.0+Beta+1vers ion=1.0+Beta+2version=1.0+Beta+3version=1.0+Finalversion=1.0.1+Finalvers ion=1.0.2+Finalversion=1.1+Beta+1version=1.1+Beta+2version=1.1+Beta+3ver sion=1.1+RC1version=Nightly+Buildshort_desc=short_desc_type=allwordssubst rlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=a llwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noo pvalue0-0-0=cmdtype=doitnewqueryname=order=Bug+Number -T. Ted Husted wrote: I'm going to make run at the bug list and update the Release Plan, as we did for b3. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STP] RC1 Release Plan
David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Why not just go to RC1 instead of beta 2? The problem is that some methods need to be removed before 1.0 Final. If the next milestone is RC1, then the methods need to be removed immediately, otherwise it's not a true release candidate. That, in turn, implies that there is no milestone in which they are deprecated. Since most, if not all, current users of the package will use at least one of these methods, it seems rather rude to just zap them without warning, so the idea is to deprecate them in Beta 2 and remove them in RC1. On a related topic, it looks like Validator has cleared all the bugs for a 1.0.2 release. I think we could release Struts 1.1 RC2 before any final releases of FileUpload and Validator just to see what bugs (if any) get reported on those components. Then, we can release FileUpload and Validator final before Struts 1.1 final. I agree that we can release Struts RC2 before all our dependencies are final. I do, however, want to make sure that RC2 includes the changes to account for the FileUpload methods that are going away. Otherwise Struts RC2 wouldn't be a true release candidate either. -- Martin Cooper Is anyone working on Commons DBCP, Pool, or Logging? David I've been somewhat absent from here for a while, primarily because I'm working on getting FileUpload into shape. In the process of addressing a couple of issues over there, I stumbled across a couple more that have required some larger changes, and I'm trying to get those polished off. I mention this here because the changes to FileUpload involve deprecating some methods that Struts calls in the very short term, and eliminating them from the FileUpload 1.0 Final release. My plan is to complete the FileUpload changes within a few days, update Struts to not use the deprecated methods, and submit equivalent patches against Tomcat 5 and Turbine, which also use FileUpload. At that point, I intend to go for FileUpload 1.0 Beta 2, then remove the deprecated methods, go for RC1 and then Final, all in as short a period as I can push it through. Comments welcome. -- Martin Cooper -T. Ted Husted wrote: I'll update the plan and website later, but for now, the outstanding RC1-RC2 list stands at five tickets [NOT RESOLVED, NOT CLOSED, STRUTS, NOT UNKNOWN]. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_st a tus=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1= emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemail r eporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfield t o=Nowchfieldvalue=product=Strutsversion=0.5+Finalversion=1.0+Beta+1ver s ion=1.0+Beta+2version=1.0+Beta+3version=1.0+Finalversion=1.0.1+Finalver s ion=1.0.2+Finalversion=1.1+Beta+1version=1.1+Beta+2version=1.1+Beta+3ve r sion=1.1+RC1version=Nightly+Buildshort_desc=short_desc_type=allwordssubs t rlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type= a llwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=no o pvalue0-0-0=cmdtype=doitnewqueryname=order=Bug+Number -T. Ted Husted wrote: I'm going to make run at the bug list and update the Release Plan, as we did for b3. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build broken?
I've made the change, but I don't have a handy JSP 1.1 to build against, so could you try it, please, and make sure it's OK? It still builds fine against JSP 1.2. -- Martin Cooper On Wed, 5 Mar 2003, David Graham wrote: When I try to build Struts I get this error: [javac] C:\eclipse\workspace\jakarta-struts\src\share\org\apache\struts\taglib\nested\NestedPropertyTag.java:121: cannot resolve symbol [javac] symbol : variable EVAL_BODY_AGAIN [javac] location: class org.apache.struts.taglib.nested.NestedPropertyTag [javac] return (EVAL_BODY_AGAIN); I think EVAL_BODY_AGAIN is a JSP 1.2 feature and I'm building with the Servlet 2.2 jar. Is anyone else having this problem? David _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - 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: Correct procedure for reporting bugs?
On Thu, 6 Mar 2003, Mark wrote: I was looking for a Get involved or Report bugs link on the struts website, and could not find any. I guess you missed this page: http://jakarta.apache.org/struts/using.html -- Martin Cooper I would like to participate in the Improvement Process but would like to know what is the best avenue for doing so? Regards, Mark Williamson - 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: cvs commit: jakarta-struts build.properties.sample build.xml
On Wed, 6 Mar 2003 [EMAIL PROTECTED] wrote:
craigmcc2003/03/05 20:20:49
Modified:.build.properties.sample build.xml
Log:
Make it possible to build Struts against the Servlet 2.4 and JSP 2.0 APIs,
where the JSP classes have been pulled out into their own JAR file (jsp.jar).
On an earlier platform, you can leave the jsp.jar property unset and things
will continue to operate as they have before.
Is this split into two jar files a Tomcat 5 thing? I haven't found a
jakarta-servletapi download for 2.4/2.0, so I'm guessing it is. It's worth
noting that (unless the spec dictates it somewhere) other containers may
not do the same thing. For example, Resin 3.0 still has both in a single
jar file.
--
Martin Cooper
Revision ChangesPath
1.32 +6 -1 jakarta-struts/build.properties.sample
Index: build.properties.sample
===
RCS file: /home/cvs/jakarta-struts/build.properties.sample,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- build.properties.sample 28 Feb 2003 06:42:20 - 1.31
+++ build.properties.sample 6 Mar 2003 04:20:49 - 1.32
@@ -78,6 +78,11 @@
# http://java.sun.com/products/jdbc/download.html
jdbc20ext.jar=../../../Java/Programs/sun/jdbc2_0-stdext.jar
+# The JAR file containing the JSP API classes to compile against if you are
+# using JSP 2.0 or later (where these classes are separated from servlet.jar).
+# If you are using JSP 1.1 or 1.2, leave this property unset
+#jsp.jar=${apache.home}/jakarta-servletapi/lib/jsp.jar
+
# The JAR file containing the Servlet API classes to compile against (either
# version 2.2 or 2.3)
servlet.jar=${apache.home}/jakarta-servletapi/lib/servlet.jar
1.102 +9 -1 jakarta-struts/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-struts/build.xml,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -r1.101 -r1.102
--- build.xml 28 Feb 2003 06:42:20 - 1.101
+++ build.xml 6 Mar 2003 04:20:49 - 1.102
@@ -75,6 +75,13 @@
jdbc20ext.jar (required). The path to the JAR file
for the JDBC 2.0 Optional Package APIs.
+jsp.jar (optional). the path to the JSP API
+ classes to compile against, if you are
+ using JSP 2.0 where these classes have
+ been separated from servlet.jar. If you
+ are using JSP 1.1 or 1.2, leave this
+ property unset.
+
servlet.jar (required). The path to the Servlet API
classes to compile against (currently,
either version 2.2 or 2.3 supported).
@@ -195,6 +202,7 @@
pathelement location=${commons-validator.jar}/
pathelement location=${jakarta-oro.jar}/
pathelement location=${jdbc20ext.jar}/
+ pathelement location=${jsp.jar}/
pathelement location=${servlet.jar}/
pathelement location=${xerces.jar}/
/path
@@ -319,7 +327,7 @@
mkdir dir=${build.home}/documentation/api/
javadoc sourcepath=${src.share.dir}
destdir=${build.home}/documentation/api
-classpath=${servlet.jar}:${jdbc20ext.jar}
+classpath=${servlet.jar}:${jsp.jar}:${jdbc20ext.jar}
packagenames=org.apache.struts.*
author=true
private=true
-
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: Some taglibs are missing a few common attributes.
James Mitchell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] We allow titleKey for the html:frame, altKey and titleKey for html:button, and a few others, but do not allow a way to specify the bundle or args. Besides the obvious... bean:define id=myMessage bean:message key=my.title/ bean:define html:sometag title=%=myMessage%/ ...work-around, I'm wondering if we should add this. I think we shouldn't. I think the work-around is a much more flexible and generally better solution given the options available with bean:message. Your thoughts? I believe we should add support for specifying a bundle, but I don't think support for arguments is necessary, given the nature of these attributes. I agree with David K that the alternatives, such as the one you presented above, reduce the maintainability of the JSP pages. -- Martin Cooper -- James Mitchell Web Developer/Struts Evangelist http://jakarta.apache.org/struts/ People demand freedom of speech to make up for the freedom of thought which they avoid. - Soren Aabye Kierkegaard (1813-1855) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build broken?
David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] When I try to build Struts I get this error: [javac] C:\eclipse\workspace\jakarta-struts\src\share\org\apache\struts\taglib\neste d\NestedPropertyTag.java:121: cannot resolve symbol [javac] symbol : variable EVAL_BODY_AGAIN [javac] location: class org.apache.struts.taglib.nested.NestedPropertyTag [javac] return (EVAL_BODY_AGAIN); I think EVAL_BODY_AGAIN is a JSP 1.2 feature and I'm building with the Servlet 2.2 jar. Is anyone else having this problem? I'm not seeing the problem, but then I'm currently building against JSP 1.2. You are correct that EVAL_BODY_AGAIN is a JSP 1.2 constant. The JSP 1.1 equivalent is EVAL_BODY_TAG, so that's what we need to be using. Looking back at the recent commit messages, it looks like this was one of Arron's changes on 2/27. -- Martin Cooper David _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons Validator
On Sun, 2 Mar 2003, James Turner wrote: I don't have any problem with you fixing it, but I don't have the mojo/knowledge to rebuild the 1.0.1 release files and put them in the Apache hierarchy, Mr. Cooper, Esq. has been handling it. First off, I just reassigned the bug to Commons Validator, since it's not Struts-specific. I also added my own perspective on a possible fix. I don't think we're at the point of worrying about getting the fix into a distribution yet. It will go into a nightly build as soon as it's done, but there are a number of other open issues against Validator that will need to be addressed before we release a 1.0.2. There are 10 open bug reports (including #17470), only 3 of which are enhancement requests. -- Martin Cooper -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Sunday, March 02, 2003 7:18 PM To: [EMAIL PROTECTED] Subject: RE: Commons Validator http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17470 - 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: Dependent Packages in Struts 1.1
Mark Abbott [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is it usual in Struts for a release candidate to come out with the final dependency versions for community testing, or will these be put in place for the final release only? There isn't a usual way. ;-) With the Struts 1.0.x releases, there wasn't a dependency on the Commons packages, as we have now, because everything was in the Struts code base. It was only after 1.0 that things like BeanUtils, Digester, etc. were split out from Struts to create new Commons packages. That said, we haven't discussed the question you are asking for Struts 1.1. My take on it would be that an RC2 build would include released versions of those packages that have all of the functionality we need, but nightlies of those that we still need updates for. It's not clear whether or not we would have an additional RC build beyond that, just to pick up released versions of all of our dependencies. -- Martin Cooper Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should html:file tag have a value attribute?
Antoni Reus [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A Divendres 28 Febrer 2003 20:21, James Mitchell va escriure: Does it submit the file if you just hit submit? It shows a warning message saying that the file input was filled without any action of the user, and lets you choose to submit it or not. ... which, FYI, is exactly what the spec says it should do. See section 8 in: http://www.ietf.org/rfc/rfc1867.txt -- Martin Cooper -- Antoni - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/userGuide struts-html.xml
Does this actually build properly? I see this structure: info p Some text here. /p Some more text here. /info The second piece of text is not within a paragraph... -- Martin Cooper [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] jmitchell2003/02/28 16:45:00 Modified:doc/userGuide struts-html.xml Log: Fix docs Revision ChangesPath 1.52 +15 -5 jakarta-struts/doc/userGuide/struts-html.xml Index: struts-html.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- struts-html.xml 27 Feb 2003 03:55:06 - 1.51 +++ struts-html.xml 1 Mar 2003 00:44:59 - 1.52 @@ -1105,7 +1105,8 @@ requiredfalse/required rtexprvaluetrue/rtexprvalue info -Maximum number of input characters to accept. [No limit] +Maximum number of input characters to accept. This is ignored +by most browsers. [No limit] /info /attribute @@ -1333,9 +1334,18 @@ requiredfalse/required rtexprvaluetrue/rtexprvalue info -Value of the label to be placed on this button. This value will -also be submitted as the value of the specified request parameter. -[Body of this tag (if any), or Cancel] +p +strongNOTE/strong: When setting this to some value, whether +intentional or as the result (for example) of validation errors +forcing the user back to the original jsp, this value is ignored +by most browsers (for security reasons). +This means that your users will have to re-select any previously +selected files when submitting the form. Opera web browser will +prompt the user so they have a chance to abort the submit. +/p +Value to which this field should be initialized. [Use the +corresponding bean property value or body content (if any) if +property is not specified] /info /attribute /tag @@ -4987,7 +4997,7 @@ info Value of the label to be placed on this button. This value will also be submitted as the value of the specified request parameter. -[Body of this tag (if any), or Cancel] +[Body of this tag (if any)] /info /attribute /tag - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [patch] tiles-documentation import statement cleanup
-Original Message- From: Andrew Freeman [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 9:29 PM To: Struts Developers List Subject: RE: [patch] tiles-documentation import statement cleanup Hi David, The following links state that I can submit patches directly to the mailing list as long as I prefix the patches with a [PATCH] prefix in the subject: http://jakarta.apache.org/site/bugs.html and http://jakarta.apache.org/site/source.html Does the Struts community have stricter guidelines? Yes. See Reporting Bugs and Feature Requests here: http://jakarta.apache.org/struts/using.html Perhaps we should make it more obvious that the mailing list shouldn't be used for that. BTW, I'm horrified that we had unused imports! ;-) The last time I ran a PMD report, we were completely clean. -- Martin Cooper thanks, Andy -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 11:45 PM To: [EMAIL PROTECTED] Subject: Re: [patch] tiles-documentation import statement cleanup Patches should be posted to a bugzilla ticket. Cleaning up imports is not high on my list of todos for getting 1.1 released. David From: Andrew Freeman [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts-Dev [EMAIL PROTECTED] Subject: [patch] tiles-documentation import statement cleanup Date: Wed, 26 Feb 2003 23:32:20 -0500 I have removed the unused imports if anyone is interested. HTH, Andy struts-tiles-documentation-imports.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Investigating adding custom ant task to valid TLDattributes bean mappings
-Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 10:53 AM To: Struts Developers List Subject: Re: Investigating adding custom ant task to valid TLD attributes bean mappings First of all... why not use XDoclet to generate TLD files in the first place? They you are guaranteed to have valid accurate TLD files. I don't think this would work as we need it to. Many of the standard attributes are implemented in base classes, rather than on the tag classes themselves. That in itself may not be a problem, but not all of the attributes should be exposed for every tag that extends the base class (since they're not all valid for all HTML tags, for example). Would it be possible to control something like that with XDoclet? -- Martin Cooper But, more below... Where should I put the Ant task class? Obviously, it would go in the struts-el tree, but I'm not sure of the logistics of this. The task can only be performed after the library is built, but I guess the task class has to be available when ant starts. No, it doesn't. You just taskdef it after its compiled, not before. I'd be glad to avoid writing an Ant task and just execute java in the build, but I can't figure out how I can make what happens in the execution of my class to cause the build to fail. Just throw an exception from main and it should fail the build. If you are sure you are doing a fork=true you could call System.exit(), but if you don't fork then you'll kill Ant without a warning. Note that I'm only referring to the Struts-EL build, although it's conceivable we could also do this in the main build. It's still possible to mess up the property name-setter mapping, even if you just use the standard mapping. Catching the error at build time might save someone a few minutes. Again, XDoclet to the rescue! Erik - 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: Investigating adding custom ant task to valid TLD attributes bean mappings
There's already a precedent for this kind of thing at Jakarta Taglibs. On the front page of the web site: http://jakarta.apache.org/taglibs/index.html there's even a section for Tool Extensions, currently with only one occupant (an UltraDev plugin). I think this would be a great place for what you are describing. -- Martin Cooper Karr, David [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] On Thu, 27 Feb 2003, Karr, David wrote: From: Karr, David [EMAIL PROTECTED] I don't like the fact that it's so easy to mess up my BeanInfo mapping in Struts-EL, as it's all validated at runtime through introspection. After 1.1 is released, I plan to do some minor rearrangement inside the BeanInfo classes and add a custom task to the build which uses a class I just wrote which parses a TLD (using Digester) and tries to verify that all the tag attributes have valid setter methods in the tag class. Is this tool specific in any way to struts-el? It sounds like a generally useful tool that would work on any TLD. One possible distribution channel would be to propose it as an add-on utility to Tomcat (or even something that could be enabled at context startup time -- from bug reports it seems that WebLogic does this sort of checking). Another avenue would be to package it as a commons library that could be used by apps relying on custom tag libraries (like we do), so that anyone could integrate it into their build process. No, it's not specific to Struts-EL. It's just easier to mess up the mapping in a library that uses BeanInfo. The introspection mechanics of this class are relatively straightforward, but really putting this into the build presents some questions in my mind, mostly Ant-related: Where should I put the Ant task class? Obviously, it would go in the struts-el tree, but I'm not sure of the logistics of this. The task can only be performed after the library is built, but I guess the task class has to be available when ant starts. There's a similar chicken-and-egg issue with the custom Ant tasks for Tomcat integration. What I do is just copy catalina-ant.jar from my most recent Tomcat build and stick it in $ANT_HOME/lib. I don't try to build the Ant tasks and immediately use them. (This would be another argument for releasing this kind of library separately, even if it was struts or struts-el specific.) I'm convinced that this has wider applicability than Struts-EL, but I don't think the Struts build should be directly dependent on Tomcat (even though I hardly use anything else). This points to a separate commons-jspantsupport library, but the scope of that is awfully small. I would guess there are no other tools at this scope. It would look pretty silly to just have the one task in the library. One implementation detail I'm wondering about: When I use the Digester, I apparently need to register a local copy of the taglib DTD (my firewall here is brutal). I guess one of the optional task parameters would be the path to the TLD DTD. Then, there's the question of whether I use the 1.1 or 1.2 DTDs. For the elements this tool is looking at, it doesn't matter, but my register call has to match the DTD with the public identifier. Now that I'm thinking about this, perhaps the best place for a tool like this (and others like it) would be in the JSTL implementation? That would muddle the issue for the people still hanging on to Servlet 2.2, but it might be the most appropriate place for it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependent Packages in Struts 1.1
I've removed Commons Resources from the build, and also from the Gump descriptor, and updated the docs so that they no longer refer to this component. Struts no longer has any Commons Sandbox dependencies. :-) -- Martin Cooper Martin Cooper [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Craig R. McClanahan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] As the topic comes up regularly, it strikes me that we haven't had any formal discussions or decisions on what versions of our dependent packages to include in Struts 1.1 final. Most of them are probably non-controversial, but there are a couple of interesting cases. Let's talk about the whole list on this mail thread. Martin, could you make sure that the release notes include the final version list we come up with? Thanks in advance. Sure. commons-beanutils -- Version 1.6.1 was just posted, and contains a critical bugfix for BeanUtils.setProperty(). commons-collections -- The framework's dependency on this library is pretty lightweight -- I suggest we go with the latest public release (2.1) commons-dbcp -- There have been some bugfixes since the original 1.0 release; let's work on getting an update release of this out the door. commons-digester -- A bugfix release (1.4.1) is just in the final stages of being released. That's the one we want. commons-fileupload -- Martin just published a beta of this. By our standard rules, we'll need a final release before we can really use it. Yes. Since announcing the Beta, there has been an uptick in user activity, so there are a number of bugs that need to be addressed. Unfortunately, FileUpload seems to be a one man show (me) at the moment, with the original contributors being conspicuously absent. In addition, there has been some discussion about merging with another (non-Jakarta) file upload project. I need to get back in there and catch up. commons-lang -- We inherit dependencies on this one -- the latest public release (1.0.1) seems fine. commons-pool -- Same situation as commons-dbcp. commons-resources -- Since we decided to defer our conversion, I suggest we omit this library from Struts 1.1 final. That avoids the hassles related to the fact that resources is still in the sandbox. Check. I'll take it out of the build and also the Gump descriptor. I assume you'll pull it out of the nightly builds? commons-validator -- As far as I can tell, the current public release (1.0.1) is fine. Are there any bugfixes we need to pick up in a 1.0.2? I believe so, yes. There are several outstanding bug reports, and most of them have been submitted by Struts users. ;-) jakarta-oro -- The latest public release (2.0.7) is stable and seems to fit the bill. Everything else comes from within our own workspace, and I'm assuming we're going to use essentially the current HEAD branch plus critical bug fixes, and continue our plan to package struts-el in the contrib directory as we do today. That's my working assumption too. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependent Packages in Struts 1.1
David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Sorry I got off topic there. Why do we have a dependency on ORO? Does one of the commons-* libraries use it? Yes, Commons Validator uses it. -- Martin Cooper Re nested: Arron has released a fixed jar for people to download separately from Struts. This may be confusing to people who expect nested to work out of the 1.1 box. I don't use nested so I have no vested interest in whether it's fixed in 1.1 or 1.2. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Dependent Packages in Struts 1.1 Date: Tue, 25 Feb 2003 10:17:21 -0800 (PST) On Tue, 25 Feb 2003, David Graham wrote: Date: Tue, 25 Feb 2003 11:09:10 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Dependent Packages in Struts 1.1 So dbcp, pool, and fileupload still need work. Arron fixed an important bug with the nested taglib but he recommended that we not include the fix in 1.1 because it touched a lot of the nested tags. Are we sure we don't want to include that fix in 1.1? The nested tags are badly broken in Tomcat 4.1.18 if we don't include the fix. I think that's definitely worth considering, but separately from the scope of deciding on external dependencies. The same can be said for any nontrivial bug fix between now and final release. On the topic of the nested tags, do they work if you disable tag pooling in 4.1.18? If not, then I think we definitely have to fix this. If they do, then it's still worth thinking about, but not quite as urgent. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependent Packages in Struts 1.1
No. Jakarta ORO is a text processing package that Validator uses for its regular expression functionality. Commons Net is an internet protocol suite. Both packages did originate at ORO, Inc., though. ;-) -- Martin Cooper Byrne, Steven [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think that the just released commons-net 1.0 has taken over from jakarta-oro. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 10:00 AM To: [EMAIL PROTECTED] Subject: Dependent Packages in Struts 1.1 snip/ jakarta-oro -- The latest public release (2.0.7) is stable and seems to fit the bill. Everything else comes from within our own workspace, and I'm assuming we're going to use essentially the current HEAD branch plus critical bug fixes, and continue our plan to package struts-el in the contrib directory as we do today. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RC1 release and Commons Logging 1.0.2
As others have mentioned, Struts 1.1 Final will include only released versions of its dependencies, while the beta and release candidate builds include intermediate versions. One thing I'd like to add, though, is that, while the versions of dependencies included in RC1 are not released, they also do not fall into the category of we have no confidence in them. (In fact, I take issue with that statement, and will therefore change it!) The most laborious part of getting any Struts release out the door isn't tagging the tree and building the distributions - that's the easiest part. The laborious part is testing it. Prior to uploading the RC1 distributions, I ran the JUnit unit tests and the Cactus unit tests against Tomcat 4.1.18, 4.0.6 and 3.3.1. I also ran each of the 8 webapps that come with Struts on Tomcat 4.1.18 and Resin 2.1.6, and some of them on Tomcat 4.0.6 and 3.3.1. So I, at least, have a much greater degree of confidence in the builds of Commons components that are included in the Struts RC1 release. Now it's up to the rest of the Struts community to tell us where the problems are. ;-) -- Martin Cooper Gary Ashley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] If I understand the issue correctly, I believe that both Struts beta3 and RC1 are dependent upon a non release version of the Commons Logging API (something later than 1.0.2). If I am incorrect, I sincerely apologize and ask that you ignore the rest of my email. Otherwise, I'd ask that an important criteria in posting future releases be considered. There should not be any dependencies upon nightly builds. Two of my customers will not allow me to use nightly builds for fear of bugs, and this prevents me from using either beta3 or RC1. This comment on the struts website does not help my dilemma any: Nightly Builds are those that are very unstable (a.k.a. dynamite!). We have no confidence in them. They are for developers who are helping to develop the technology and want the latest bits. Use at your own risk! Please take these kinds of issues into consideration in the future. Another consideration to help those who are not in the loop, would be to post the versions of dependent APis that were used to run the tests in the release notes. Thank you for the consideration! Sincerely, A fan. Gary D Ashley Jr. Chief Technology Officer, 3rd Millennium Visions, Inc. I find that the harder I work, the more luck I seem to have. - Thomas Jefferson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Where's RC1?
On Sat, 22 Feb 2003, James Mitchell wrote: Did I check those in too soon? If so, sorry about that. No problem. There was only one file affected in this case, and it was easy enough to resolve. In the future, though, it might be a good idea for us to put a freeze on checkins between the tag date and the actual release date. The problem this time around was exacerbated by the long delay between these two points, which is entirely my fault. But freezing the tree would help us avoid potentially messy solutions in the future. By the way, in answer to the question in the subject line, the release is up, and I'm about to send the announcement. Hurrah! -- Martin Cooper -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org/ Beer is the reason we get up each afternoon. -- Ray McNeill -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Saturday, February 22, 2003 10:36 AM To: Struts Developers List Subject: Re: Where's RC1? Thanks, Rob. It seems there were a lot of changes to that file when James checked in his tests, and I didn't want to include those in the RC1 version. So I checked in a version that had just your change applied to the original RC1 version, and then re-checked in the HEAD version so that we're back to where we were. I've re-tagged the file for RC1, rebuilt, the tests are passing, so keep your fingers crossed! -- Martin Cooper On Sat, 22 Feb 2003, Rob Leland wrote: 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] - 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
[ANNOUNCEMENT] Struts 1.1 Release Candidate 1 released
The Struts team is proud to announce the release of Struts 1.1 Release Candidate 1. This release includes some new functionality, as well as fixes for a number of bugs which were reported against earlier versions. The Struts Team believes that this release is ready for prime time, hence its designation as a release candidate. The binary distribution is available at: http://www.apache.org/dist/jakarta/struts/binaries/ and the source distribution is available at: http://www.apache.org/dist/jakarta/struts/source/ In addition, the library distribution, which contains updated binaries without the sample applications, is available at: http://www.apache.org/dist/jakarta/struts/library/ Details of the changes in this release are available in the Release Notes, which can be found here: http://jakarta.apache.org/struts/userGuide/release-notes-1.1-rc1.html -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where's RC1?
Thanks, Rob. It seems there were a lot of changes to that file when James checked in his tests, and I didn't want to include those in the RC1 version. So I checked in a version that had just your change applied to the original RC1 version, and then re-checked in the HEAD version so that we're back to where we were. I've re-tagged the file for RC1, rebuilt, the tests are passing, so keep your fingers crossed! -- Martin Cooper On Sat, 22 Feb 2003, Rob Leland wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where's RC1?
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]
Re: 1.1b3 Release Build?
Good guess, but no cigar. ;-) The Beta 3 build is listed under both Release and Milestone builds. The reason I listed it under Release is that Struts gets a large number of downloads, and the download is itself quite large, so I wanted to make sure that we take maximum advantage of the Apache mirror system. Only the Release section of the download page references mirror sites at this time. -- Martin Cooper James Mitchell [EMAIL PROTECTED] wrote in message 006401c2d82b$5fcd5240$1f64f80a@atlanta">news:006401c2d82b$5fcd5240$1f64f80a@atlanta... Because our betas are as good as a release??? ;) -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org/ The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain (1835-1910) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 10:11 AM To: [EMAIL PROTECTED] Subject: 1.1b3 Release Build? Why is Struts 1.1b3 listed under release builds on the jakarta binary download page? Betas are not releases so this concerns me. David _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - 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: 1.1b3 Release Build?
James Mitchell [EMAIL PROTECTED] wrote in message 006601c2d82f$e997fdf0$1f64f80a@atlanta">news:006601c2d82f$e997fdf0$1f64f80a@atlanta... N, I still think its because our betas ROCK!!! ;) Betas, nothin'. Wait 'til you see our release candidate, coming soon to a mirror site near you! -- Martin Cooper -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org/ The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain (1835-1910) -Original Message- From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Martin Cooper Sent: Wednesday, February 19, 2003 10:54 AM To: [EMAIL PROTECTED] Subject: Re: 1.1b3 Release Build? Good guess, but no cigar. ;-) The Beta 3 build is listed under both Release and Milestone builds. The reason I listed it under Release is that Struts gets a large number of downloads, and the download is itself quite large, so I wanted to make sure that we take maximum advantage of the Apache mirror system. Only the Release section of the download page references mirror sites at this time. -- Martin Cooper James Mitchell [EMAIL PROTECTED] wrote in message 006401c2d82b$5fcd5240$1f64f80a@atlanta">news:006401c2d82b$5fcd5240$1f64f80a@atlanta... Because our betas are as good as a release??? ;) -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org/ The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain (1835-1910) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 10:11 AM To: [EMAIL PROTECTED] Subject: 1.1b3 Release Build? Why is Struts 1.1b3 listed under release builds on the jakarta binary download page? Betas are not releases so this concerns me. David _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.1b3 Release Build?
David Graham [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... From the download page, Release Builds are those that are ready for Prime Time. This build is as good as it gets!. IMHO, we shouldn't be listing betas under the release section. This is misleading and confusing to new users. Being that this is open source and all, you're welcome to submit a patch to make milestone builds available via mirror sites as well (binary and source). -- Martin Cooper David From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 1.1b3 Release Build? Date: Wed, 19 Feb 2003 07:54:24 -0800 Good guess, but no cigar. ;-) The Beta 3 build is listed under both Release and Milestone builds. The reason I listed it under Release is that Struts gets a large number of downloads, and the download is itself quite large, so I wanted to make sure that we take maximum advantage of the Apache mirror system. Only the Release section of the download page references mirror sites at this time. -- Martin Cooper James Mitchell [EMAIL PROTECTED] wrote in message 006401c2d82b$5fcd5240$1f64f80a@atlanta">news:006401c2d82b$5fcd5240$1f64f80a@atlanta... Because our betas are as good as a release??? ;) -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org/ The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain (1835-1910) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 10:11 AM To: [EMAIL PROTECTED] Subject: 1.1b3 Release Build? Why is Struts 1.1b3 listed under release builds on the jakarta binary download page? Betas are not releases so this concerns me. David _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - 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] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug #17113
I'd like at least one more pair of eyes - preferably including Craig's - to take a look at this bug, because if my analysis is correct, we need to make the change before we cut RC1 tonight. Here's the URL to make it easier to get to: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17113 Thanks! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FMT tag and form bean
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2t728$t7c$[EMAIL PROTECTED]">news:b2t728$t7c$[EMAIL PROTECTED]...
I have been nudging people toiwards JSTL.
A nice feature is FMT tag that formats the number, date, etc. in the
JSP. FMT tag needs the formBeans to return int!
No, it does not. If you provide a string to the format tags, such as
fmt:formatNumber, it will convert it to the appropriate numeric type. Try
the following:
- cut here -
%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
%
request.setAttribute(foo, 1234567890);
%
fmt:formatNumber value=${foo} type=currency/
- cut here -
To avoid any question of what other JSTL tags might be doing, I've
explicitly stored a string in a request attribute. The output from the above
page is:
$1,234,567,890.00
The fmt:formatNumber tag did its job just fine when passed a string
instead of an integer.
--
Martin Cooper
So if one does a FORM for updates you create formbean with String
getAge(), and number formated in Java before returning the String.
If then you just want to display the # (no update) you need to create a
bean with int getAge(), and FMT it in JSP.
So return int for JSTL and String for formBean.
A prefered solution is that HTML tag is able to do formating like FMT tag.
.V
Also, it be nice if tiles was able to do some EL, or have a nicer way of
FORWARDING to diferent JSP from the tile action one day.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FMT tag and form bean
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2u5oq$p8b$[EMAIL PROTECTED]">news:b2u5oq$p8b$[EMAIL PROTECTED]...
Thanks as always Ted and Martin.
I would still have to format the number in the bean for Form, and
localize dates (for the Candian dates), etc in the bean class. If the
page is read only, I would format in JSP.
I guess I don't understand. Why do you need to do formatting in the bean,
and why is it different if the page is read-only? You should be able to use
JSTL to do this in either case.
--
Martin Cooper
So far getAge() and
getAgeInt() look ok. I wonder which way the faces tag will work.
(yes, if know, if I copied data for the form bean but if I have
nested and multi row and many to many, it's kind of a pain; one day I
will write reflection with dynaRowSet to clone nesting, localize, format
and put in basicPortal)
.V
Martin Cooper wrote:
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2t728$t7c$[EMAIL PROTECTED]">news:b2t728$t7c$[EMAIL PROTECTED]...
I have been nudging people toiwards JSTL.
A nice feature is FMT tag that formats the number, date, etc. in the
JSP. FMT tag needs the formBeans to return int!
No, it does not. If you provide a string to the format tags, such as
fmt:formatNumber, it will convert it to the appropriate numeric type.
Try
the following:
- cut here -
%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
%
request.setAttribute(foo, 1234567890);
%
fmt:formatNumber value=${foo} type=currency/
- cut here -
To avoid any question of what other JSTL tags might be doing, I've
explicitly stored a string in a request attribute. The output from the
above
page is:
$1,234,567,890.00
The fmt:formatNumber tag did its job just fine when passed a string
instead of an integer.
--
Martin Cooper
So if one does a FORM for updates you create formbean with String
getAge(), and number formated in Java before returning the String.
If then you just want to display the # (no update) you need to create a
bean with int getAge(), and FMT it in JSP.
So return int for JSTL and String for formBean.
A prefered solution is that HTML tag is able to do formating like FMT
tag.
.V
Also, it be nice if tiles was able to do some EL, or have a nicer way of
FORWARDING to diferent JSP from the tile action one day.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FMT tag and form bean
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2uf0d$5gb$[EMAIL PROTECTED]">news:b2uf0d$5gb$[EMAIL PROTECTED]...
I would like to format in the JSP if possible (for both).
Let me just restate what I think you are saying:
Since JSTL can format strings, allways format and localize in the
formBean.
No, that doesn't make any sense. I'm saying Since JSTL can format strings,
always format and localise in the JSP page. I don't understand why you need
to do any of it in the bean, hence my last message.
So as you point out, I can format and localize both in the bean. (Ex:
formBean.setLocale(x) )
Um, I didn't point that out at all.
--
Martin Cooper
So probably a better choice.
But... since I like how the FMT tag works not sure what best
approach is. I almost want to cross post to JSPTag-user, see if Geary is
around. but it's really not that big a deal.
A student in a class asked why this was and I was stuttering, so I
posted to get it of my chest and maybe as a wish list for HTML-EL tag.
You and Ted pointed out some things however.
.V
Martin Cooper wrote:
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2u5oq$p8b$[EMAIL PROTECTED]">news:b2u5oq$p8b$[EMAIL PROTECTED]...
Thanks as always Ted and Martin.
I would still have to format the number in the bean for Form, and
localize dates (for the Candian dates), etc in the bean class. If the
page is read only, I would format in JSP.
I guess I don't understand. Why do you need to do formatting in the
bean,
and why is it different if the page is read-only? You should be able to
use
JSTL to do this in either case.
--
Martin Cooper
So far getAge() and
getAgeInt() look ok. I wonder which way the faces tag will work.
(yes, if know, if I copied data for the form bean but if I have
nested and multi row and many to many, it's kind of a pain; one day I
will write reflection with dynaRowSet to clone nesting, localize, format
and put in basicPortal)
.V
Martin Cooper wrote:
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2t728$t7c$[EMAIL PROTECTED]">news:b2t728$t7c$[EMAIL PROTECTED]...
I have been nudging people toiwards JSTL.
A nice feature is FMT tag that formats the number, date, etc. in the
JSP. FMT tag needs the formBeans to return int!
No, it does not. If you provide a string to the format tags, such as
fmt:formatNumber, it will convert it to the appropriate numeric type.
Try
the following:
- cut here -
%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
%
request.setAttribute(foo, 1234567890);
%
fmt:formatNumber value=${foo} type=currency/
- cut here -
To avoid any question of what other JSTL tags might be doing, I've
explicitly stored a string in a request attribute. The output from the
above
page is:
$1,234,567,890.00
The fmt:formatNumber tag did its job just fine when passed a string
instead of an integer.
--
Martin Cooper
So if one does a FORM for updates you create formbean with String
getAge(), and number formated in Java before returning the String.
If then you just want to display the # (no update) you need to create
a
bean with int getAge(), and FMT it in JSP.
So return int for JSTL and String for formBean.
A prefered solution is that HTML tag is able to do formating like FMT
tag.
.V
Also, it be nice if tiles was able to do some EL, or have a nicer way
of
FORWARDING to diferent JSP from the tile action one day.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FMT tag and form bean
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2uiqk$kce$[EMAIL PROTECTED]">news:b2uiqk$kce$[EMAIL PROTECTED]...
Let's try again:
:-)
http://jakarta.apache.org/struts/userGuide/struts-html.html#text
This does not let me localize or format.
Lets say I have a bean that has a #, String getStartDate().
If I sometimes use this bean on a read only page, I could do JSP FMT to
format and localize.
I sometime want to use the same bean on a R/W form submit page.
String getStartDate(), hut html:text does not format or localize. The
traditional approach I used was to format to native types inside the
setters/getters.
Point is I can't format a localize in html:text, but can in JSTL.
OK, now I see what you're saying. I was also assuming html:text had a
feature it turns out not to have
(yet ;). Still, you could do it like this, although it's a bit ugly:
fmt:formatDate var=temp value=${yourFormBean.startDate} ... /
html-el:text value=${temp} ... /
--
Martin Cooper
So the only place is in the bean, inside the getStartDate() {}.
The other alternative is to copy.
And I must have misunderstood what you were saying, but I think I now
understand the issues surouding it enough.
.V
Martin Cooper wrote:
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2uf0d$5gb$[EMAIL PROTECTED]">news:b2uf0d$5gb$[EMAIL PROTECTED]...
I would like to format in the JSP if possible (for both).
Let me just restate what I think you are saying:
Since JSTL can format strings, allways format and localize in the
formBean.
No, that doesn't make any sense. I'm saying Since JSTL can format
strings,
always format and localise in the JSP page. I don't understand why you
need
to do any of it in the bean, hence my last message.
So as you point out, I can format and localize both in the bean. (Ex:
formBean.setLocale(x) )
Um, I didn't point that out at all.
--
Martin Cooper
So probably a better choice.
But... since I like how the FMT tag works not sure what best
approach is. I almost want to cross post to JSPTag-user, see if Geary is
around. but it's really not that big a deal.
A student in a class asked why this was and I was stuttering, so I
posted to get it of my chest and maybe as a wish list for HTML-EL tag.
You and Ted pointed out some things however.
.V
Martin Cooper wrote:
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2u5oq$p8b$[EMAIL PROTECTED]">news:b2u5oq$p8b$[EMAIL PROTECTED]...
Thanks as always Ted and Martin.
I would still have to format the number in the bean for Form, and
localize dates (for the Candian dates), etc in the bean class. If the
page is read only, I would format in JSP.
I guess I don't understand. Why do you need to do formatting in the
bean,
and why is it different if the page is read-only? You should be able to
use
JSTL to do this in either case.
--
Martin Cooper
So far getAge() and
getAgeInt() look ok. I wonder which way the faces tag will work.
(yes, if know, if I copied data for the form bean but if I have
nested and multi row and many to many, it's kind of a pain; one day I
will write reflection with dynaRowSet to clone nesting, localize,
format
and put in basicPortal)
.V
Martin Cooper wrote:
Vic Cekvenich [EMAIL PROTECTED] wrote in message
b2t728$t7c$[EMAIL PROTECTED]">news:b2t728$t7c$[EMAIL PROTECTED]...
I have been nudging people toiwards JSTL.
A nice feature is FMT tag that formats the number, date, etc. in the
JSP. FMT tag needs the formBeans to return int!
No, it does not. If you provide a string to the format tags, such as
fmt:formatNumber, it will convert it to the appropriate numeric
type.
Try
the following:
- cut here -
%@ taglib prefix=fmt uri=http://java.sun.com/jstl/fmt; %
%
request.setAttribute(foo, 1234567890);
%
fmt:formatNumber value=${foo} type=currency/
- cut here -
To avoid any question of what other JSTL tags might be doing, I've
explicitly stored a string in a request attribute. The output from
the
above
page is:
$1,234,567,890.00
The fmt:formatNumber tag did its job just fine when passed a string
instead of an integer.
--
Martin Cooper
So if one does a FORM for updates you create formbean with String
getAge(), and number formated in Java before returning the String.
If then you just want to display the # (no update) you need to
create
a
bean with int getAge(), and FMT it in JSP.
So return int for JSTL and String for formBean.
A prefered solution is that HTML tag is able to do formating like
FMT
tag.
.V
Also, it be nice if tiles was able to do some EL, or have a nicer
way
of
FORWARDING to diferent JSP from the tile action one day.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: It's Valentine's Day, where are we?
On Sat, 15 Feb 2003, Ted Husted wrote: snip/ As soon as someone deals with 16603, we could see if Martin is available to cut the release candidate (or if someone else wants to step up to bat if he's busy). Craig has now dealt with 16603, and Bugzilla now shows that happy phrase Zarro Boogs found. I've just finished getting FileUpload 1.0 Beta 1 out the door, so I can now tackle Struts 1.1 RC1. I believe we still need to vote, so I'll post an RC1 release plan and call it, and we can go from there. -- Martin Cooper -Ted. James Turner wrote: The initial plan of action was to have an RC1 today. We currently have 6 outstanding bugs: 12573 Handling of HTML-Checkboxes and (dynamic) FormBeans result i 16603 controller forwardPattern should support different module 16916 nested:write using incorrect bean 16946 SwitchAction not setting context properly for tiles 17018 Constant usage example inconsistant with the DTD and Validat 17031 Validation of required html:file elments passes when no file I don't think we're every going to be in a zero bugs found state for more than a couple of hours, because Struts is becoming so widely used that there are always going to be new bug reports (even if they're erroneous) Does anyone consider any of the above bugs severe enough to constitute a blocker on an RC1? If not, we should designate the 2/14 nightly build as RC1 so we can push toward an end-of-the-month release. If so, we need to push to close them. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - 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]
[VOTE] Struts 1.1 Release Candidate 1 Release Plan
All outstanding bugs against Struts 1.1 have either been fixed or been categorized for fixing in a release subsequent to Struts 1.1 Final. Therefore, I propose that we release the tip of the main trunk in CVS as Release Candidate 1 for a Struts 1.1 release. I have checked in a proposed release plan, which is available for review on the Struts web site: http://jakarta.apache.org/struts/proposals/release-plan-1.1rc1.html Release plans must pass by a majority vote of committers on the project, but all other interested parties are welcome to cast their votes (and/or make comments or suggestions on the plan) as well. -- Vote: Struts 1.1-rc1 Release Plan [ ] +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). -- I am +1 on the Struts 1.1-rc1 release plan. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forcing or replacing a request processor version 1.1 beta3 -
Craig R. McClanahan [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Fri, 14 Feb 2003, PILGRIM, Peter, FM wrote: Am I missing something, or can't you just say: controller processorClass=com.mycompany.MyRequestProcessor/ and be done with it? Craig I certainly could do that and I am doing that, but I want to force the custom request processor, because I am package Struts as part of Expresso? How about defining an ExpressoPlugIn that configures everything you need at startup time? PlugIns run after the struts-config.xml file has been digested, but before the configuration information is frozen, so they can do things like: ModuleConfig modConfig = servlet.getServletContext().getAttribute(Globals.APPLICATION_KEY); ControllerConfig contConfig = modConfig.getControllerConfig(); contConfig.setProcessorClass(com.mycompany.MyRequestProcessor); This technique can be used for pretty much any sort of modifications to the configured information. However, it doesn't solve Peter's problem, it just moves it. Instead of the customer having to set a custom request processor in their struts-config.xml, now they have to set a plugin. Another alternative (recently added in the 1.1 tree) is to add some Digester rules that are included in the set used to parse struts-config.xml (see the rulesets init parameter on ActionServlet). If you couple that with turning validation off, you can even add additional configuration elements and attributes into the standard config file -- I think the STXX folks are planning to take advantage of this to define their processing pipelines inside an action element. This option also moves the problem, but this time it's moved to web.xml instead of struts-config.xml. ;-) I really don't see a way of doing what Peter wants without modifying the code. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TLD and class mismatch in struts-nested.
Right. Neither html:form not nested:form have 'title' or 'titleKey' attributes. Perhaps you have the wrong TLD in place? -- Martin Cooper David Graham [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I couldn't find those 2 attributes in the nested tld for the form tag. David From: Bernard GRANDJEAN [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: Bruno POMMEREL [EMAIL PROTECTED] Subject: TLD and class mismatch in struts-nested. Date: Tue, 11 Feb 2003 17:15:27 +0100 Hello, Using struts 1.1 b1 to b3 we encounter the following (fatal) problem on weblogic 7 : weblogic.servlet.jsp.JspException: (line 5): Error in using tag library uri='/WEB-INF/classes/struts-nested.tld' prefix='nested': The Tag class 'org.apache.struts.taglib. nested.html.NestedFormTag' has no setter method corresponding to TLD declared attribute 'titleKey', (JSP 1.1 spec, 5.4.1) The same error also occured for the attribute title. Taking a look at the implementation class we discovered that indeed there are no such methods. Weblogic seems to abide by the spec quite strictly. To get rid of these, I simply removed the attributes declaration in struts-nested.tld. Could this be taken into account in the next releases ? Thanks a lot guys ! Bernard. -- Bernard GRANDJEAN CNAMTS / DSI / CNQD Seyssins-Grenoble Tél 04 38 12 16 85 8, Rue Jean Moulin SEYSSINS 38176 SEYSSINET Cedex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Bugzilla #16603] Discussion Please
On Sat, 8 Feb 2003, Craig R. McClanahan wrote: big-snip/ Recommendation: -- If we were not imminently trying to release a 1.1 final, I would be tempted to design and work out a strategy for dealing with this ambiguity problem, and hash out what the right behavior should be in each case. 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. We're going to need to deal with it in a 1.2 time frame anyway, especially if we try to implement any sort of module configuration inheritance mechanisms, which are only going to make the problem worse. In a 2.0 time frame, the lesson I draw from this is that we will want to be very specific in defining how mapping of logical paths to physical paths is performed, including a way to distinguish what kind of logical path you're talking about (so that you can apply different rules for view components and for action components, for example). Does this sound like a plan that we (committers) can agree to? +1 I'm not particularly concerned about case (b), and don't believe we should go out of our way to provide a nice solution for it. I realise that some people will want to continue to use action chaining, so we will need to allow for it in some shape or form. However, I have a scheme that allows me to achieve the same effect without chaining actions, and I'm hoping to be able to contribute that at some point. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAR Licenses in Apache Software Distributions
+1 for Struts as 100% Apache Code. :-) -- Martin Cooper On Mon, 10 Feb 2003, Craig R. McClanahan wrote: If you're subscribed to the [EMAIL PROTECTED] mailing list, you'll be aware that there have been some recent policty decisions with the goal of tightening down on the licenses of packages that are shipped inside Apache software products. When looking at our Struts distributions, the only software that is *not* originally Apache code is the JDBC 2.0 optional package, which defines things like javax.sql.DataSource. The Sun license under which jdbc2_0-stdext.jar was downloaded allows redistribution when packaged in the manner we are doing so -- but, it seems to me, that we don't really need to supply it. Any servlet container that supports data sources is going to have it available already (as will anyone running a 1.4 or later JDK, which incorporates these APIs already). Therefore, I propose to remove it from the binary distributions of Struts that we create. This package will continue to be a compile-time dependency for building Struts itself, so anyone who builds Struts from source (and isn't running on 1.4) will need to provide this. That's fine -- the developer will have had to accept the license terms to acquire this JAR file, and it's not our issue any longer. If we make this change, Struts will become a 100% Apache Code distribution, which will be fun to crow about a little, too :-). Comments? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Buglet related to Globals.MAPPING_KEY?
I just noticed something strange that I believe to be a minor bug, but I'm not sure which is intended to be the correct solution. RequestProcessor.processMapping() tries to find the ActionMapping for the current request. Once found, the mapping is stored in a request attribute, viz Globals.MAPPING_KEY. So far, so good. Now, further down the line, in RequestUtils.populate(), IFF the request is a multipart request, the mapping request attribute is removed from the request. This is the part that's odd. I believe the original reason for storing the mapping in a request attribute was so that it could be obtained in populate() when processing a multipart request, without having to pass it as a parameter all the way down. In fact, the only code that accesses the attribute is shortly above the only place that it's removed from the request. The catch is that it isn't removed for any other type of request. Now, obviously, we could fix this in one of two ways. We could either have populate() always remove it, or never remove it. Although the former is better matched with the original intent of the attribute, it's possible that people have assumed that it is always available, and written code with that in mind. In fact, the ConfigHelper class (not used, and marked as experimental) seems to make this assumption, even within the Struts code base. Therefore, to be on the safe side, I plan on removing the call to removeAttribute() from populate(), thus guaranteeing that the mapping is available regardless of the type of request being processed. Comments? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: source version for commons-beanutils.jar for struts1.1 b3
On Thu, 6 Feb 2003, aswath satrasala wrote: Hello, What version of source should be used for commons-beanutils.jar that shipped with struts. The corresponding sources are tagged with the label STRUTS_1_1_B3 in the CVS repository. -- Martin Cooper -Aswath _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help deciphering screw-case for PR 15799
I looked at this one too, and came out with similar feelings. I think this needs the eyes of our resident Keyboard Monkey, if he's around. Calling all Keyboard Monkeys... We need your help... -- Martin Cooper On Wed, 5 Feb 2003, James Turner wrote: I've taken a look at the code for 15799, but I'm still not exactly sure what problem was being reported. I don't feel comfortable applying a patch for a problem that isn't properly documented. Anyone got a clue? James Turner Owner Manager, Black Bear Software, LLC [EMAIL PROTECTED] Author: MySQL JSP Web Applications: Data Driven Programming Using Tomcat and MySQL ISBN 0672323095; Sams, 2002 Co-Author: Struts Kick Start ISBN 0672324725; Sams, 2002 Forthcoming: JavaServer Faces Kick Start Sams, Fall 2003 - 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: Plans for the upcoming 2/14 soft deadline?
On Mon, 3 Feb 2003, Karr, David wrote: What are anyone's intentions for the deadline I heard about for 2/14, for some step in the release cycle? I only ask this because I will be out of town from 2/9-2/14. I probably won't even be able to get to email, much less do any last minute changes for the release. I hope no tag attribute changes are made just before the release like they were for 1.1b3. Any changes in that area should also be made in Struts-EL at the same time. Ted had suggested that we resolve the outstanding items first, and then put together a release plan, complete with tag date. See: http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=612913 However, I don't believe that's working. In fact, as I believe Ted himself said of the 1.1-b3 drive, having a date to aim for is a better motivator. Unfortunately, as I mentioned before, I don't have much time to help kill outstanding bug reports for RC1, due to current day job pressures. It'd be great to see an RC1 on or around Feb 14th, and I can do the RM thing, but I'm going to have to rely on others of you to get us ready for that. Also, what is the status of the idea of separating the contrib libraries out of the release? I'm not certain what the result was of any vote on this, but I had the impression there wasn't enough response to make a decision. IMO, Struts-EL should stay put until we get Struts 1.1 out the door. After that, we can discuss how to incorporate contrib code into the release as part of a broader discussion of how to factor distributions. -- 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: Cracking the whip
On Mon, 27 Jan 2003, James Turner wrote: Hey folks, if we're going to go for the Valentine's Day Release Massacre, we need to get the last 5 bugs closed. Any progress to report by anyone? Dear Mr. Validator, Bugzilla #16272 looks like a Commons Validator bug, and #16337 may be a problem with Struts/Validator integration. Any progress to report? ;-) -- Martin Cooper James Turner Owner Manager, Black Bear Software, LLC [EMAIL PROTECTED] Author: MySQL JSP Web Applications: Data Driven Programming Using Tomcat and MySQL ISBN 0672323095; Sams, 2002 Co-Author: Struts Kick Start ISBN 0672324725; Sams, 2002 Forthcoming: JavaServer Faces Kick Start Sams, Fall 2003 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts joins the zero bad imports list
Struts has now joined the (rather small) list of Jakarta projects which have *zero* bad imports (i.e. unused or unnecessary) in their code base: http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm Cool! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cracking the whip
On Wed, 29 Jan 2003, James Turner wrote: Dear Mr. Validator, Bugzilla #16272 looks like a Commons Validator bug, and #16337 may be a problem with Struts/Validator integration. Any progress to report? ;-) -- Martin Cooper Whoops, they weren't showing up on my bug query, I'll jump right on 'em. Boy, I get called Mr. Validator and LISP Boy in the same day. What's a guy gotta do around here to get a little respect? :-) Hey, what's wrong with Mr. Validator? Better than Validator dude, no? ;-) -- Martin Cooper James Turner Owner Manager, Black Bear Software, LLC [EMAIL PROTECTED] Author: MySQL JSP Web Applications: Data Driven Programming Using Tomcat and MySQL ISBN 0672323095; Sams, 2002 Co-Author: Struts Kick Start ISBN 0672324725; Sams, 2002 Forthcoming: JavaServer Faces Kick Start Sams, Fall 2003 - 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]
Tiles XmlParser - cut paste error?
Running PMD over the latest code, I think I've found a bug in the Tiles XmlParser class. Lines 255 - 256 of this class look like this: String menuItemDefaultClass = org.apache.struts.tiles.beans.SimpleMenuItem; digester.addObjectCreate( ADD_WILDCARD, menuItemDefaultClass, classtype); But then lines 262 - 263 look like this: String beanDefaultClass = org.apache.struts.tiles.beans.SimpleMenuItem; digester.addObjectCreate( BEAN_TAG, menuItemDefaultClass, classtype); Note that in the first case, menuItemDefaultClass is defined, and then used on the next line. In the second case, beanDefaultClass is defined, but on the next line, menuItemDefaultClass is used again. My guess is that this is a cut paste error, and that line 263 should be using beanDefaultClass instead of menuItemDefaultClass. However, this is a guess, since I don't use this functionality. Hence this message instead of just changing the code base. If someone who knows this area could take a look and confirm/deny, that would be great. -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
