Re: [VOTE] David M. Karr as a Struts Committer
+1 Rob Craig R. McClanahan wrote: I'd like to propose David M. Karr [EMAIL PROTECTED] as a committer on -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to extend AppException
phpsurf wrote: Hi when looking at the default ExceptionHandler implementation, I saw that there was a special behaviour when handling org.apache.struts.util.AppException. ... But the problem is that its properties are private instead of protected, so it's quite difficult to add some features to the class ... That sounds reasonable, to make them protected. Go ahead and submit a bug request http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Struts -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] David M. Karr as a Struts Committer
+1 Craig R. McClanahan wrote: I'd like to propose David M. Karr [EMAIL PROTECTED] as a committer on Struts. It's clear from his work on the EL library that he would be a tremendous asset to the Struts development community (and not just for these tags :-). Here's my +1. Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY US co-author, Java Web Development with Struts Order it today: http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12819] New: - org.apache.struts.util.AppException should have protected properties instead of private properties
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=12819.
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=12819
org.apache.struts.util.AppException should have protected properties instead of
private properties
Summary: org.apache.struts.util.AppException should have
protected properties instead of private properties
Product: Struts
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
org.apache.struts.util.AppException should have protected properties instead of
private properties
this would allow any application to overide the AppException class and both:
- benefit from the default ExceptionHandler behaviour
- implement its own exception handling, inheriting from AppException
and by the way, maybe it could also implement the following constructor, to be
fully compliant with ActionError's constructors:
public AppException(String key, Object[] values) {
super(key);
error = new ActionError(key, values);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Core] Truly global globa-forwards
Just thought I would chime in as another developer that finds the idea of a hierarchy of modules most useful. Hopefully you don't find my comments to verbose. My company has decided to move forward with using Struts for one of our applications that is being migrated from a client-server app to a web-based app. It was obvious that we would benefit from using the Struts framework. We created some prototypes to prove its usefulness and see if it could handle some specific customer requirements. While creating some prototypes we wanted to leverage the sub-apps that Struts 1.1 provides. We found, however, that the default module did not behave as we expected. We assumed that if we used messages or errors (bean:message and html:errors) within a sub-app and the message was not found in the message resources for that sub-app, that Struts would look to the default app for the messages. We did not like the idea of duplicating messages across all sup-apps. For example, most all of our modules will be using messages for our buttons like Save, New, Cancel, Delete, etc. (we are using i18n so it's not feasible to hard-code these). We wanted to define these once in the message resources for the default app and override the message in the sub-app as necessary. We have since extended the framework to handle this scenario since we also needed to fulfill a customer requirement that allows the customer to switch between customer-defined labels and system-defined labels. We haven't extended the framework to deal with global forwards in the same fashion yet, but I'm sure we will need to do so as well. So, in short we would love to see the hierarchy of modules idea apply to sub-apps. Russ -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 14, 2002 4:53 PM To: 'Struts Developers List' Subject: RE: [Core] Truly global globa-forwards The issue here is the model for module usage. The current design came about primarily as a solution for the problem of development scalability. On a large project, having several people making frequent changes to struts-config.xml gets out of hand rather quickly. Breaking the application into modules allows multiple teams to develop their modules independently. The usage model is multiple independent modules that have little or no communication between them. All modules are treated the same, with the default module's *only* distinguishing characteristic being the lack of a prefix. The existence of a default module is primarily for backwards compatibility reasons. It has no special status in a Struts app. This is quite different from the usage model that I needed for my web app, and I think from what you are looking for too. What I needed is a hierarchy of modules. The root module is two things - a framework into which the remaining modules are plugged, and a set of shared behaviours useful to those other modules. To build this, I needed to extend Struts in several ways so that I have a comprehensive hierarchical model. The reason I referred to using the default module for truly global forwards, by itself, as hacky is because it confuses the usage model. The modules are no longer independent, per the current design, but they don't form a true hierarchy either, because all the other pieces needed for a fully hierarchical application are missing. Ultimately, what we want to do is collect information on how people are using modules, and how they want to be able to use them, and think through the design issues of the various usage models. Then we'll be able to take a more comprehensive look at how we might incorporate multiple models into the Struts code base. To respond to a couple of other points you made: * I can't put my code into contrib, sorry - it belongs to my employer, not to me individually. * Forward patterns were added for 1.1-b2. It's mentioned briefly in the release notes, but the only real description is currently here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10268 Note, however, that $A was subsequently changed to $M. -- Martin Cooper -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 14, 2002 12:04 PM To: Struts Developers List Subject: Re: [Core] Truly global globa-forwards (this started on struts-user -- see thread of same name there for background) Martin Cooper wrote: I can't say for sure whether this is likely to become part of the Struts core or not. However, what you are asking gives us another data point on the way modules are going to be used in Struts 1.1 apps. I think it's very logical that you would have the ability to make use of a global configuration (of most things) in addition to the sub-application configuration (data-sources, properties, you name it). Craig, for compatability reasons I'm sure (and to simplify things too, I'd wager), made the application root yet another sub-app -- and I
Re: [Forward-Looking] Struts and JavaServer Faces
On Wed, 18 Sep 2002, Jing Zhou wrote: [snip] * Transition one page at a time to use the new tag libraries, making an appropriate modification to the forward elements for your pages (the URL needs to change to meet Faces requirements). Could you provide a simple example to show how forward should be modified? Will it require to change ActionForward class itself, or just the path attribute need to be changed? No software change at all required -- only a change in the path attribute in struts-config.xml. For example, from: forward name=registration path=/registration.jsp/ to forward name=registration path=/faces/registration.jsp/ I noticed that some *actions* in faces are for component's state changes, so there will be no populating, validating, and action things for them. Are we going to use the ActionForward class to go to the same component with changed states, is that correct? (For example, a tab pane is changed from visible tab item 0 to visible tab item 1) The integration library will still offer full support for form beans and auto-population, with calls to reset() and validate() at the right times, and so on. This is primarily to support existing code. New apps will want to make a choice between using form beans (in the traditional Struts fashion) and just using Faces components (with their per-component pluggable validators) directly. [snip] One thing we had discussed sometime ago was about split name/property v.s. merged name/property. It is understandable to attempt to have a merged name/property so that we could map it to faces modelReference. I feel I need to do lobby works to reserve the split name/property version, if necessary. The split version of name/property provides a better mapping and more functions than merged modelReference: 1) name is mapped to JSP attribute name in the four JSP scopes; 2) property is mapped to JavaBean's property; 3) name + . + property is mapped to Faces modelReference; 4) name and property can be evaluated by an EL engine independently; 5) name and property completely hide HTML's name attribute; If one considers the RequestUtils.lookup() as a mini-evaluator, 4) give us a so called two-phase evaluations. While the merged modelReference can only give us one-phase evaluation and thus we lost the function 4) So, the name and property are well defined and well seperated in the mapping, they shouldn't be deprecated ... I saw David's struts-el contribution, he's done a good job, we still have the split version. But I am not sure if your Struts/JSF integration will keep it or not. I expect the integration will make Struts *stand on* JSF and bigger than JSF. For making JSF do something like this, I suspect this one is going to be a hard sell to the EG, but you can try by submitting the feedback to [EMAIL PROTECTED] The reasons I think this way are as follows: * The split syntax is totally incompatible with variable references in JSTL 1.0 and JSP 2.0, which don't support it. It would not be appropriate for JSF to be gratuitously incompatible with this standard. * The split syntax is too restrictive, because it assumes the shape of the graph of model beans matches the shape of the graph of user interface components. This has proven to be troublesome to many Struts users already. * The actual data that a model reference points at is ambiguous because it is sensitive to the location of a component in a page. This makes life much harder for tools, which will prefer to use absolute model reference expressions during development. For making Struts use supersets of the standard EL syntax (along the lines you are describing), that sounds like a bad strategy to me -- we really really want people already familiar with standard EL expression syntax to be able to use Struts and know what to expect. Thus, I think we need to make the struts-el library conform a little more closely, now that we know what the syntax requirements of model reference expressions are going to be. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12821] New: - Password fields are not validated against minLength on javascript side
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=12821.
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=12821
Password fields are not validated against minLength on javascript side
Summary: Password fields are not validated against minLength on
javascript side
Product: Struts
Version: Nightly Build
Platform: All
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Validator Framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
In the javascript function validateMinLength(form) forgets to apply its
validation control to form fields of type 'password' and only validates
against 'text' and 'textarea'.
here the patch:
validator name=minlength
classname=org.apache.struts.util.StrutsValidator
method=validateMinLength
methodParams=java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionErrors,
javax.servlet.http.HttpServletRequest
depends=required
msg=errors.minlength
javascript![CDATA[
function validateMinLength(form) {
var bValid = true;
var focusField = null;
var i = 0;
var fields = new Array();
oMinLength = new minlength();
for (x in oMinLength) {
if (form[oMinLength[x][0]].type == 'text' ||
form[oMinLength[x][0]].type == 'textarea' ||
form[oMinLength[x][0]].type == 'password') {
var iMin = parseInt(oMinLength[x][2](minlength));
if (!(form[oMinLength[x][0]].value.length = iMin)) {
if (i == 0) {
focusField = form[oMinLength[x][0]];
}
fields[i++] = oMinLength[x][1];
bValid = false;
}
}
}
if (fields.length 0) {
focusField.focus();
alert(fields.join('\n'));
}
return bValid;
}]]
/javascript
/validator
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12821] - Password fields are not validated against minLength on javascript side
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=12821. 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=12821 Password fields are not validated against minLength on javascript side [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-09-19 16:59 --- I wonder how often this one is gonna show up again.. *** This bug has been marked as a duplicate of 12683 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12683] - validator-rules.xml has a neglect
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=12683. 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=12683 validator-rules.xml has a neglect [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-09-19 16:59 --- *** Bug 12821 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10191] - Validator Range Checking Bug
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=10191. 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=10191 Validator Range Checking Bug --- Additional Comments From [EMAIL PROTECTED] 2002-09-19 17:28 --- I've added the following to GenericValidator: public static boolean isInRange(short value, short min, short max) public static boolean isInRange(double value, double min, double max) public static boolean isInRange(float value, float min, float max) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: VOTE: Behavior of Validator
+1 Good example, and I agree with your rationale. Under the new behavior following the example you gave for the second case: username=blank, password=god: one error generated on required Two errors should be generated: username is required password cannot be god Is the new behavior that you want to have happen? Dominique -Original Message- From: James Turner [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 10:41 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: VOTE: Behavior of Validator As currently written, the Validator has what I consider a quirk. Suppose you have two fields, username and password. Username has depends=required and password has depends=required.notgod (where notgod is a test that makes sure that the user didn't choose god as a password). The following behavior occurs: username=blank, password=blank: two errors generated on required username=blank, password=god: one error generated on required username=george, password=god: one error genereated on notgod This is because the Validator won't look at notgod until *all* fields pass the required test. I think this is a broken behavior. It leads to web forms where the user thinks that they've filled in all the fields correctly, but then get new error messages they've never seen before. I'd like to correct this before Validator freezes for a release, but I want to make sure no one really really thinks that the current behavior is somehow the right one. So please vote: +1 = Change Validator so that this doesn't occur 0 = I don't give a hoot -1 = I really like the way it works now (please give a reason) I'm sending this both to Commons and Struts because both communities are impacted by the change. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12825] New: - Action roles attribute incorrectly parsed for comma-seperated roles
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=12825. 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=12825 Action roles attribute incorrectly parsed for comma-seperated roles Summary: Action roles attribute incorrectly parsed for comma- seperated roles Product: Struts Version: 1.1 Beta 2 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the action node of the strugs-config, if you use a comma-seperated list of roles for the new roles attribute, the first letter of each role (except the last role) is dropped. The bug is in: org.apache.struts.config.ActionConfig method: setRoles(String roles) On line 328 of the source, it reads: list.add(roles.substring(1, comma).trim()); The 1 needs to be a 0 And why not use StringTokenizer instead? (not that it matters much) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: VOTE: Behavior of Validator
At 02:02 PM 9/19/2002, Dominique Plante wrote: +1 Good example, and I agree with your rationale. Under the new behavior following the example you gave for the second case: username=blank, password=god: one error generated on required Two errors should be generated: username is required password cannot be god Is the new behavior that you want to have happen? Precisely. Validation for a field should stop on the first error *for that field* James Dominique -Original Message- From: James Turner [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 10:41 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: VOTE: Behavior of Validator As currently written, the Validator has what I consider a quirk. Suppose you have two fields, username and password. Username has depends=required and password has depends=required.notgod (where notgod is a test that makes sure that the user didn't choose god as a password). The following behavior occurs: username=blank, password=blank: two errors generated on required username=blank, password=god: one error generated on required username=george, password=god: one error genereated on notgod This is because the Validator won't look at notgod until *all* fields pass the required test. I think this is a broken behavior. It leads to web forms where the user thinks that they've filled in all the fields correctly, but then get new error messages they've never seen before. I'd like to correct this before Validator freezes for a release, but I want to make sure no one really really thinks that the current behavior is somehow the right one. So please vote: +1 = Change Validator so that this doesn't occur 0 = I don't give a hoot -1 = I really like the way it works now (please give a reason) I'm sending this both to Commons and Struts because both communities are impacted by the change. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Behavior of Validator
- Original Message - From: James Turner [EMAIL PROTECTED] Precisely. Validation for a field should stop on the first error *for that field* James +1 I agree whole-heartedly with this. The way the Validator currently works is to iterate throught the validation rules, and for each rule iterate through the fields to locate those that depend on that rule. This seems wasteful to me. I think a better way would be to iterate through the list of fields, and for each field execute the validation methods for that field. This should accomplish what you state above. Dave D -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
VOTE: Behavior of Validator
As currently written, the Validator has what I consider a quirk. Suppose you have two fields, username and password. Username has depends=required and password has depends=required.notgod (where notgod is a test that makes sure that the user didn't choose god as a password). The following behavior occurs: username=blank, password=blank: two errors generated on required username=blank, password=god: one error generated on required username=george, password=god: one error genereated on notgod This is because the Validator won't look at notgod until *all* fields pass the required test. I think this is a broken behavior. It leads to web forms where the user thinks that they've filled in all the fields correctly, but then get new error messages they've never seen before. I'd like to correct this before Validator freezes for a release, but I want to make sure no one really really thinks that the current behavior is somehow the right one. So please vote: +1 = Change Validator so that this doesn't occur 0 = I don't give a hoot -1 = I really like the way it works now (please give a reason) I'm sending this both to Commons and Struts because both communities are impacted by the change. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: VOTE: Behavior of Validator
+1 and thanks V. James Turner wrote: As currently written, the Validator has what I consider a quirk. Suppose you have two fields, username and password. Username has depends=required and password has depends=required.notgod (where notgod is a test that makes sure that the user didn't choose god as a password). The following behavior occurs: username=blank, password=blank: two errors generated on required username=blank, password=god: one error generated on required username=george, password=god: one error genereated on notgod This is because the Validator won't look at notgod until *all* fields pass the required test. I think this is a broken behavior. It leads to web forms where the user thinks that they've filled in all the fields correctly, but then get new error messages they've never seen before. I'd like to correct this before Validator freezes for a release, but I want to make sure no one really really thinks that the current behavior is somehow the right one. So please vote: +1 = Change Validator so that this doesn't occur 0 = I don't give a hoot -1 = I really like the way it works now (please give a reason) I'm sending this both to Commons and Struts because both communities are impacted by the change. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Adding bundle Attr to optionsCollection
Is it possible to add a bundle attribute to optionsCollection so that if bundle is specified, the label attribute is used to retreive the corresponding bundle message from resource file? For example, optionsCollection bundle=MyMessage name=mybean value=myvalue label=messageKey/ the message key returns a key in MyMessage.properties. Similar method is already used in bean:message. I already modified my source to have this feature. It would be nice if I can contribute it to Struts. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 2017] - Text entered in forms using multi-part/formdata cannot be utf8
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=2017. 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=2017 Text entered in forms using multi-part/formdata cannot be utf8 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED]|struts- ||[EMAIL PROTECTED] Status|ASSIGNED|NEW -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12634] - Struts 1.0.2 download contains tld files for 1.1 beta features
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=12634. 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=12634 Struts 1.0.2 download contains tld files for 1.1 beta features [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-20 03:47 --- If there is really an issue here, please provide full details and reopen the bug report. As far as I have been able to determine, there are no problems in this area with the Struts 1.0.2 release available for download on the Jakarta web site. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12754] - html:image does not have a styleId attribute
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=12754. 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=12754 html:image does not have a styleId attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-09-20 04:20 --- *** This bug has been marked as a duplicate of 12014 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12825] - Action roles attribute incorrectly parsed for comma-seperated roles
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=12825. 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=12825 Action roles attribute incorrectly parsed for comma-seperated roles [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-09-20 05:12 --- *** This bug has been marked as a duplicate of 9523 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9523] - Action and multiple roles
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=9523. 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=9523 Action and multiple roles [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-09-20 05:12 --- *** Bug 12825 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12323] - Powered by Struts
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=12323. 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=12323 Powered by Struts [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-09-20 05:23 --- The specified web site does not meet the requirements for being listed as a Powered by Struts web site. Please read the requirements here: http://jakarta.apache.org/struts/resources/powered.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
