Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta2

[Ted Husted]

Arron Bates wrote:
Couldn't agree more (hence my +1), new RC for JavaOne will be great.
Just saying, things seem to have shifted a little.
The paradox now is that by not shipping 1.1 in some form, we are 
starting to degrade the quality of our software.

We've been imposing a gag order on post-1.1 development for so long, 
that Struts is lagging behind the marketplace, and the needs of our 
community. A lot of us starting to move on to the next level of web 
application design, and, we need to bring Struts with us, lest it become 
irrelevant.

James' focus is admittedly different. But we're not shipping Struts for 
the sake of shipping Struts. We're shipping Struts so that we can 
continue to improve the quality of the product as a whole.

As a practical matter, the part we're talking about now, FileUpload, is 
a separate JAR, and a the final version could be swapped in at anytime. 
There's nothing to be gained by waiting, and much to be gained by moving 
forward.

In the past, when things like FileUpload were under our own CVS, this 
wouldn't even be an issue, since we could release FileUpload as part of 
the greater release. In the future, hopefully, it won't be an issue 
either, since we won't be holding back *23 months* new development for 
one small piece. (Not to mention the several months of development that 
haven't happened because we're feature-locked.)

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2

[James Turner]

The other issue here, and one I'm sure that a lot of other folks on the
list who interact with the public a lot can sympathize with, is that
there are a LOT of commercial entities still using 1.0 because they have
a policy of not using beta software.  I cringe when I think of all the
people suffering needlessly under the yoke of 1.0's limitations, and
thus have been increasingly frustrated at the delays in getting 1.1 out.

Oh yah, and I wanna get my new validations into the repository too
(truth in advertising...)

James



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Status check?

[Ted Husted]

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.

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.

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: VOTE (enough already!): Release Struts RC2 with FileUpload Beta2

[Ted Husted]

James Turner wrote:
The 72 hour voting cutoff is 3AM Eastern June 1
Just for the record, the 72-hour convention is how long we should wait 
before taking action. It doesn't mean that people couldn't continue to 
vote after 3 AM on June 1, if we haven't already cut the release.

Of course, this is also a majority vote so there would have to be more 
(binding) -1s than +1s for it to make a difference.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20385] New: - Attribute "id" support required for "html:text"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20385

Attribute "id" support required for "html:text"

   Summary: Attribute "id" support required for "html:text"
   Product: Struts
   Version: 1.1 RC1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tag "html:text" not support attribute "id".
But this attribute required for JavaScript and other HTML-features
(example: for tag tag "label", without "html:text id..." 
hotkey "label accesskey..." not worked ).
By default, IMHO, value of attribute "id" should be equals value "property".

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20385] - Attribute "id" support required for "html:text"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20385

Attribute "id" support required for "html:text"

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-31 18:33 ---
See the styleId attribute here:
http://jakarta.apache.org/struts/userGuide/struts-html.html#text

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20389] New: - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20389

Need mechanism that lets more than one forms points to the same form bean instance in 
a HTML page

   Summary: Need mechanism that lets more than one forms points to
the same form bean instance in a HTML page
   Product: Struts
   Version: 1.1 RC1
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Sometimes in a HTML page, we have more than one HTML forms, where the forms 
must have different name attribute value, otherwise our javascripts cannot 
work on those forms; On the other hand, we need to let those forms' form bean 
point to the same bean instance in seesion scope or request scope. Is there 
any way we can achieve that goal?

We tried to use name and "attribute" attribute in action tag of struts-
config.xml, but we get the HTML form name as the attribute value of action 
tag, so it make no sense.

Here is our version of FormTag, but I don't think that's a good way, and also 
it might affect validator funcation. Hope you guys have a good mechanism.

//
package com.aon.chor.org.apache.struts.taglib.html;

import java.io.IOException;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.PageContext;
import javax.servlet.jsp.tagext.TagSupport;

import org.apache.struts.Globals;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.action.ActionServlet;
import org.apache.struts.config.FormBeanConfig;
import org.apache.struts.config.ModuleConfig;
import org.apache.struts.util.MessageResources;
import org.apache.struts.util.RequestUtils;
import org.apache.struts.util.ResponseUtils;
import org.apache.struts.taglib.html.Constants;

/**
 * Custom tag that represents an input form, associated with a bean whose
 * properties correspond to the various fields of the form.
 *
 * @author Craig R. McClanahan
 * @author Martin Cooper
 * @author James Turner
 * @version $Revision: 1.43 $ $Date: 2003/01/28 05:18:03 $
 */

public class FormTag extends org.apache.struts.taglib.html.FormTag {

// - Instance Variables
/**
 * The message resources for this package.
 */
protected static MessageResources messages =
MessageResources.getMessageResources(Constants.Package 
+ ".LocalStrings");

// - Public Methods

/**
 * Render the beginning of this form.
 *
 * @exception JspException if a JSP exception has occurred
 */
public int doStartTag() throws JspException {

// Look up the form bean name, scope, and type if necessary
lookup();

// Create an appropriate "form" element based on our parameters
HttpServletResponse response = (HttpServletResponse) 
pageContext.getResponse();
StringBuffer results = new StringBuffer("");

// Add a transaction token (if present in our session)
HttpSession session = pageContext.getSession();
if (session != null) {
String token = (String) session.getAttribute
(Globals.TRANSACTION_TOKEN_KEY);
if (token != null) {
results.append("");
} else {
results.append("\">");
}
}
}

// Print this field to our output writer
ResponseUtils.write(pageContext, results.toString());

// Store this tag itself as a page attribute
pageContext.setAttribute(Constants.FORM_KEY, this, 
PageContext.REQUEST_SCOPE);

// Locate or create the bean associated with our form
int scope = PageContext.SESSION_SCOPE;
if ("request".equals(beanScope)) {
scope = PageContext.REQUEST_SCOPE;
}
Object bean = pageContext.getAttribute(beanName, scope);
if (bean == null) {
if (type != null) {
// Backwards compatibility - use explicitly specified values
try {
bean = RequestUtils.applicationInstance(beanType);
if (bean != null) {
((ActionForm) bean).setServlet(servlet);
}
} catch (Exception e) {
throw new JspException

DO NOT REPLY [Bug 20389] - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20389

Need mechanism that lets more than one forms points to the same form bean instance in 
a HTML page





--- Additional Comments From [EMAIL PROTECTED]  2003-06-01 00:37 ---
Created an attachment (id=6581)
Our version of FormTag

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20389] - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20389

Need mechanism that lets more than one forms points to the same form bean instance in 
a HTML page

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Custom Tags |Controller

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20389] - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20389

Need mechanism that lets more than one forms points to the same form bean instance in 
a HTML page





--- Additional Comments From [EMAIL PROTECTED]  2003-06-01 00:43 ---
By the way, we can not use only one Form in a HTML page under that 
circumstatnce because we tried to divide one HTML page to three sections and 
use tiles to render those section. And at the same we might reuse those 
sections some else.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20389] - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=20389

Need mechanism that lets more than one forms points to the same form bean instance in 
a HTML page





--- Additional Comments From [EMAIL PROTECTED]  2003-06-01 00:46 ---
Why not just use document.forms[0], document.forms[1], etc. to reference your 
forms from JavaScript? You shouldn't need to use the form names themselves. 
This would also insulate you from later changes to the names, as well.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Status check?

[Martin Cooper]

"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?

[David Graham]

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?
On one hand, it seems rude to break the builds with not much notice.  On the 
other, you're setting a dangerous precedent of maintaining backward 
compatibility between betas.  If the changes can be fixed in a reasonably 
short amount of time, I think you can just rip out the methods.  If not, can 
you leave them there and remove them in 1.1?

Gump builds for Tomcat and Turbine will start failing as soon as I remove
the deprecated methods.
What if you sent a note to the mailing lists with a warning?

David

--
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]
_
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: Status check?

[Ted Husted]

Martin Cooper wrote:
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.
The question is what's best for the community. From what you say, these 
methods are already doomed. It's just a matter of whether they fix the 
dependency now or a fortnight from now. (Or just stick with whatever JAR 
they are already using.)

Yes, Gump may break. That's why we have Gump. =:) Sam did not create 
Gump to chain us, but to free us to make changes. When Gump breaks 
people get the heads-up that they need to make changes themselves. 
(Before they *voluntarily* elect to use the new version.)

And, I agree with David. We've been taking backward compatibility 
between betas way too seriously. In the case of Struts, our betas have 
languished so long that it did become prudent for us to take that into 
account. They became de-facto releases. But I don't agree that as a rule 
we have to maintain full backward compatibility between betas *and* 
between final releases. Otherwise, why even have betas?

When the software is released, you have established an API contract. But 
a beta is not a contract, it is a *proposed* contract, and subject to 
change until we "sign on the dotted line" and cut a final release.

Personally, I don't think anyone will be astonished that things change 
in an unreleased product between betas. If they are, then maybe they 
should step up to bat and give you a hand with what is supposed to be a 
community-supported product.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]