date:20030814

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=22447

When using multiple modules the plugins are initialized double

   Summary: When using multiple modules the plugins are initialized
double
   Product: Struts
   Version: 1.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have switched from a single module impl. (default) to a multiple module 
implementation. When looking at the log files in the Tomcat window I see that 
the plugins a initialized double. This happens with the Tiles pluging (Tiles 
definitions for /reflection are initialized twice; see log), but also with the 
plugin I'm writing myself.

I'm wondering if this is a bug; when if so it has no advantage of using 
multiple modules.

Starting service Tomcat-Standalone
Apache Tomcat/4.0.3
15-aug-2003 8:49:45 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='org.apache.struts.util.LocalStrings', 
returnNull=true
15-aug-2003 8:49:45 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='org.apache.struts.action.ActionResources', 
returnNull=true
15-aug-2003 8:49:48 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='ApplicationResources', returnNull=true
15-aug-2003 8:49:48 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='resources.application', returnNull=true
15-aug-2003 8:49:49 org.apache.struts.tiles.TilesPlugin init
INFO: Tiles definition factory loaded for module '/reflection'.
15-aug-2003 8:49:49 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='resources.application', returnNull=true
15-aug-2003 8:49:49 org.overdijk.xcontent4struts.XContentPlugIn init
INFO: XContent factory loaded for module '/xcontent4struts-0.3'.
15-aug-2003 8:49:50 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='org.apache.struts.util.LocalStrings', 
returnNull=true
15-aug-2003 8:49:50 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='org.apache.struts.action.ActionResources', 
returnNull=true
15-aug-2003 8:49:51 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='ApplicationResources', returnNull=true
15-aug-2003 8:49:51 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='resources.application', returnNull=true
15-aug-2003 8:49:51 org.apache.struts.tiles.TilesPlugin init
INFO: Tiles definition factory loaded for module '/reflection'.
15-aug-2003 8:49:52 org.apache.struts.util.PropertyMessageResources 
INFO: Initializing, config='resources.application', returnNull=true
15-aug-2003 8:49:52 org.overdijk.xcontent4struts.XContentPlugIn init
INFO: XContent factory loaded for module '/xcontent4struts-0.3'.
Starting service Tomcat-Apache
Apache Tomcat/4.0.3

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

[OT] Is there a NYC area Struts User Group?

2003-08-14 Thread Davidson, Glenn

Does anyone know of a NYC area Struts user group?

Thanks

Glenn

DO NOT REPLY [Bug 22144] New: - Problem with

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=22144

Problem with 

   Summary: Problem with 
   Product: Struts
   Version: 1.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Validator Framework
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We are trying to put all the static JavaScript at the bottom of our Tiles 
layout so that we do not have to include it with every tile but the 
 tag does not create the static JavaScript correctly.

Here ia how we are trying to add the static JavaScript:


Since the form comes out null, the tag does not add the

RE: [OT] Is there a NYC area Struts User Group?

2003-08-14 Thread Paananen, Tero

> Does anyone know of a NYC area Struts user group?

http://groups.yahoo.com/group/struts_NYC/

-TPP

-
This email may contain confidential and privileged material for the sole use of the 
intended recipient(s). Any review, use, retention, distribution or disclosure by 
others is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete all 
copies of this message.  Also, email is susceptible to data corruption, interception, 
tampering, unauthorized amendment and viruses. We only send and receive emails on the 
basis that we are not liable for any such corruption, interception, tampering, 
amendment or viruses or any consequence thereof.


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

DO NOT REPLY [Bug 21254] - nested:messagePresent tag does not append parent name to indexed property

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=21254

nested:messagePresent tag does not append parent name to indexed property





--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 00:02 ---
This problem seems to be caused by NestedMessagesPresent implementing
NestedNameSupport rather than NestedPropertySupport.  The logic:MessagesPresent
tag uses the name attribute to specify the name of the action error set, rather
than the root object of the property tag like most of the other struts tags. 
Making NestedMessagesPresent implement NestedNameSupport causes this tag to
modify the name attribute of the MessagesPresent superclass with the nested root
object, which then causes it to fail to find the appropriate message set in the
page context.  This problem affects NestedMessagesPresent,
NestedMessagesNotPresent, and NestedMessages.  I've attached proposed patches.

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

DO NOT REPLY [Bug 22208] - bean:write with Integer property exception

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=22208

bean:write with Integer property exception

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 12:16 ---
I added format="" to the tag and now it works ok.

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

RE: When is the next release?

I think we could release 1.2 now if there was a release manager.  I don't
have the time to learn and perform the release process right now.

David

--- Nick Lesincki <[EMAIL PROTECTED]> wrote:
> It has been at least 1 month since question was asked
> When is the next release?
> Last msg said 1 month after 1.1 and a release manager
> was required and some bug fixes would be out.
> 
> Nicolas
> 
> 
> __
> 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]
> 


__
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]

DO NOT REPLY [Bug 22191] - Map-backed form property and multiselect.

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=22191

Map-backed form property and multiselect.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 00:14 ---


*** This bug has been marked as a duplicate of 21679 ***

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

DO NOT REPLY [Bug 21569] - ExceptionHandler modification to provide access to the stack trace

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=21569

ExceptionHandler modification to provide access to the stack trace

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 00:42 ---
Now it logs the exception with a message.

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

DO NOT REPLY [Bug 22207] - serialization and deserialization

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=22207

serialization and deserialization





--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 12:02 ---
Link to mailinglist archive for referance. 

http://www.mail-archive.com/[EMAIL PROTECTED]/msg17106.html

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

javadoc patches

2003-08-14 Thread Travis Stevens

I use javadoc a lot, as with most java developers.  When I use the 
struts javadocs, I don't feel that I get all the information I need.  A 
lot of times I need to look at the source.  In short: will you accept 
patches to improve that javadoc?

-Trav

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

DO NOT REPLY [Bug 17698] - The value(key) form name pattern doesn't work with

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=17698

The value(key) form name pattern doesn't work with 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 19:06 ---
With th nwst versin d struts it works !

stanowisko1 
stanowisko2 

private Map values = new HashMap() ;
public void setValue( String key, String[] val ) {
.
}
public String[] getValue(String key) {
..
}

BUT ONLY, when there is not other setter 
When I add :
public void setValue( String key, String val ) {
.
}
public String getValue(String key) {
..
}

no method is called ...

So I have 2 kinds of getters/setters - one for multiselect/checkbox and second
for others.
For me it is OK, but it shoould be in the documentation.

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

Re: RE: SuccessAction (was RE: Addition of two new actions)

2003-08-14 Thread 苗启广

hi ,all: 
   how can I send my questions to all of you ? Could you tell me ? Thanks~~ 
 mqg 

- SOUVENIR --- .
| Souvenir of China |
| A Good Place for You  |
`--> http://www.souvenirchina.com -'
mailto:[EMAIL PROTECTED]




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

cvs commit: jakarta-struts/src/share/org/apache/struts/plugins DigestingPlugIn.java

2003-08-14 Thread dgraham

dgraham 2003/08/06 21:02:42

  Modified:src/share/org/apache/struts/plugins DigestingPlugIn.java
  Log:
  Added @since tag.
  
  Revision  ChangesPath
  1.3   +1 -0  
jakarta-struts/src/share/org/apache/struts/plugins/DigestingPlugIn.java
  
  Index: DigestingPlugIn.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/plugins/DigestingPlugIn.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- DigestingPlugIn.java  7 Aug 2003 04:02:21 -   1.2
  +++ DigestingPlugIn.java  7 Aug 2003 04:02:42 -   1.3
  @@ -88,6 +88,7 @@
* @author David Graham
* @version $Revision$
* @see PlugIn
  + * @since Struts 1.2
*/
   public class DigestingPlugIn implements PlugIn {
   
  
  
  

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

RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)

2003-08-14 Thread James Mitchell

Is this a vote?  If so, shouldn't we have [VOTE] on the subject line?


--
James Mitchell
Software Engineer / Struts Evangelist
http://www.struts-atlanta.org
678.910.8017
AIM:jmitchtx




> -Original Message-
> From: Steve Raeburn [mailto:[EMAIL PROTECTED] 
> Sent: Friday, August 08, 2003 5:38 PM
> To: Struts Developers List
> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: 
> Addition of two new actions)
> 
> 
> I *think* we agreed to add this action. Pick a name.
> 
> [ ] ParameterDispatchAction
> [ ] MappingDispatchAction
> [ ] ConfigDispatchAction
> 
> Steve
> 
> > -Original Message-
> > From: Steve Raeburn [mailto:[EMAIL PROTECTED]
> > Sent: August 4, 2003 1:25 PM
> > To: Struts Developers List
> > Subject: RE: Addition of two new actions
> >
> >
> > In an ideal world, DispatchAction should probably become
> > ParameterDispatchAction and this could be plain old DispatchAction.
> >
> > Is Anthony's original suggestion of ConfigDispatchAction any better?
> >
> > I can't think of a name that I *really* like so I'm +0 on Mapping
> > or Config.
> >
> > Steve
> >
> > > -Original Message-
> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper
> > > Sent: August 4, 2003 10:15 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Addition of two new actions
> > >
> > > I'm +1 on this, other than on naming. I think 
> ParameterDispatchAction is
> > > definitely the wrong name for the last of these. People 
> are *far* more
> > > likely to think of the "Parameter" in the name as meaning 
> a request
> > > parameter than they are to think of the "parameter" action mapping
> > > attribute. Perhaps MappingDispatchAction instead?
> > >
> > > I am -0 on combining all of this into one action.
> > >
> > > --
> > > 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: cvs commit: jakarta-struts/doc volunteers.xml

2003-08-14 Thread Steve Raeburn

Got it. Thanks. People keep adding stuff when I'm not looking :-)

Steve

> 
> Also edit the maven project.xml for developer entries.
> 
> -Rob
> 



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

Re: cvs commit: jakarta-struts/web/example/WEB-INF struts-config-registration.xmlstruts-config.xml

On Sat, 9 Aug 2003, Robert Leland wrote:

> Date: Sat, 09 Aug 2003 22:38:44 -0400
> From: Robert Leland <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: cvs commit: jakarta-struts/web/example/WEB-INF
> struts-config-registration.xml struts-config.xml
>
> David Graham wrote:
>
> >--- [EMAIL PROTECTED] wrote:
> >
> >
> >>rleland 2003/08/09 01:50:52
> >>
> >>  Modified:conf/share struts-config_1_2.dtd
> >>   doc/userGuide release-notes.xml
> >>   web/example/WEB-INF struts-config-registration.xml
> >>struts-config.xml
> >>  Log:
> >>  Add two new elements   and  for
> >>use
> >>  by struts config file tools and document generation.
> >>  Suggested by Jonas Björnerstedt
> >>
> >>
> >
> >The only suggestion I could find in the archives was to add 
> >and  elements.  I'm confused by the two description fields.
> >Is there a need for two different descriptions of the same
> >struts-config.xml file?  web.xml uses  and  so
> >I think it would be better to match that.
> >

A web.xml file also includes provisions for icons -- we might want to go
ahead and do those at the same time.

> >David

Craig

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

Re: cvs commit: jakarta-struts/contrib/struts-el build.xml

On Sat, 9 Aug 2003, David M. Karr wrote:

> Date: 09 Aug 2003 19:28:39 -0700
> From: David M. Karr <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-struts/contrib/struts-el build.xml
>
> > "craigmcc" == craigmcc  <[EMAIL PROTECTED]> writes:
>
> craigmcc> craigmcc2003/08/09 18:21:43
> craigmcc>   Modified:contrib/struts-el build.xml
> craigmcc>   Log:
> craigmcc>   Modify the build.xml for struts-el to have a hard-coded reference to 
> the
> craigmcc>   struts.jar in the parent Struts source tree (i.e. output of "ant 
> dist").
> craigmcc>   This makes it possible to compile struts-el even when the user has a
> craigmcc>   "${user.home}/build.properties" file that defines a struts.jar 
> property
> craigmcc>   (as I do, because I *use* Struts in lots of different packages).
>
> I assume this is to address the issue with compile errors?
>
>

Yes ... you were right on the money about my build using the wrong JAR
file.  It's because I have the following settings in my
${user.home}/build.properties file so I can use 1.1 final in all my
regular projects that use Struts:

  struts.home=/usr/local/jakarta-struts-1.1
  struts.jar=${struts.home}/lib/struts.jar

Since there's no way to tell Ant to undefine a property, I changed the
struts-el build to use a relative path to find struts.jar instead of the
property.

It works now, so we should see a nightly build succeed tonight.

Craig


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

cvs commit: jakarta-struts/doc/userGuide release-notes.xml

rleland 2003/08/09 19:53:09

  Modified:doc/userGuide release-notes.xml
  Log:
  Use standard prexisting ELEMENTS description and display-name,
  instead of description-short & description-long.
  
  -Rob
  
  Revision  ChangesPath
  1.28  +5 -4  jakarta-struts/doc/userGuide/release-notes.xml
  
  Index: release-notes.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/release-notes.xml,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- release-notes.xml 9 Aug 2003 08:50:52 -   1.27
  +++ release-notes.xml 10 Aug 2003 02:53:09 -  1.28
  @@ -131,12 +131,13 @@
The Struts Configuration 1.1 DTD has been deprecated in favor of the
   http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd";>struts-config_1_2.dtd.
   In the Struts 1.2 release, existing Struts configuration files can be
  -loaded using either DTD version. The new DTD adds two new elements 

  -and  for use by struts config file tools and document 
generation. 
  +loaded using either DTD version. The new DTD adds two new elements 

  +and  to the struts-config element.
  +There are for use by struts config file tools and document generation. 
   
   
   New Dependencies on Commons packages
  -The resource components of Struts 1.1 has been found to be useful in
  +The resource component of Struts 1.1 has been found to be useful in
   general Java development (and not just useful for building Struts-based
   web applications), and have been migrated into the
   http://jakarta.apache.org/commons/";>Jakarta Commons Project.
  @@ -149,7 +150,7 @@
   The following Commons packages contain the replacements for the
   corresponding Struts 1.1 classes:
   
  -BeanUtils Package
  +Resources Package
   [http://jakarta.apache.org/commons/resources.html";>org.apache.commons.resources]
 -
   org.apache.struts.utils.MessageResources
   
  
  
  

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

Re: Building contrib packages WAS Re: cvs commit: jakarta-struts/contrib/tag-docbuild.xml

David Graham wrote:

--- Steve Raeburn <[EMAIL PROTECTED]> wrote:
 

o.a.s.util.GenericDataSource is in the core and extends the legacy
GenericDataSource so legacy needs to be built first.
   

That's a good point.

 

It is deprecated since 1.1. Can we get rid of all legacy / DataSource
stuff
for 1.2?
   

I believe that was the plan all along but I've been waiting for Ted to
remove it because he (thankfully :-) took the lead in adding it.  I
haven't looked into it but hopefully it will be a simple build.xml change
and removal from cvs.
The cleaning up the DTD, docs and then maybe example app ?

Rob

David

 

Steve

   

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: August 9, 2003 4:03 PM
To: Struts Developers List
Subject: Building contrib packages WAS Re: cvs commit:
jakarta-struts/contrib/tag-doc build.xml
While we're somewhat on this topic I'd like to get some clarification
 

on
   

the build process.  Why do struts-el and struts-legacy get built with
 

the
   

standard Struts build file?  Struts-EL has *never* built on my machine
 

and
   

I have just taken it on faith the rest of Struts built properly. 
 

Also,
   

after struts-legacy was added I've had to run my builds twice.  The
 

first
   

one always fails and the second succeeds (well, not really succeeds
because struts-el fails).
In general, I don't see a reason for contrib packages to be built with
 

the
   

rest of Struts.  Am I missing something?

David

--- [EMAIL PROTECTED] wrote:
 

craigmcc2003/08/09 12:29:30

 Modified:.build.xml
  contrib/struts-el build.xml
contrib/struts-el/src/share/org/apache/strutsel/taglib/html
   ELFormTag.java ELHtmlTag.java
   ELJavascriptValidatorTag.java
  contrib/struts-faces build.xml
  contrib/struts-legacy build.xml
  contrib/tag-doc build.xml
 Log:
 Correct loading order of properties files to go from most local
(current
 directory) to most global (${user.home}/build.properties).  Since
   

Ant
   

 follows a "first definition wins" strategy, this makes the most
   

sense
   

 for our convention of allowing local overrides of global values. 
   

It
   

also
 means that I can now do an "ant dist" in the top level directory
   

with
   

only
 one thing in my build.properties file (jdk.version=1.4), so this
should fix
 the nightly builds as well (verifying that is my next step).
 Also fixed some compile errors in struts-el -- I don't know how
   

that
   

code
 could have compiled for anyone.  Could someone more familiar with
   

that
   

 library make sure I did the changes correctly?

 Revision  ChangesPath
 1.118 +5 -2  jakarta-struts/build.xml
 Index: build.xml

   

===
   

 RCS file: /home/cvs/jakarta-struts/build.xml,v
 retrieving revision 1.117
 retrieving revision 1.118
 diff -u -r1.117 -r1.118
 --- build.xml  8 Aug 2003 06:00:55 -   1.117
 +++ build.xml  9 Aug 2003 19:29:30 -   1.118
 @@ -113,9 +113,9 @@
  -->
  
 -
 -
  
 +
 +
  
  
 @@ -204,6 +204,9 @@
  
  
 +
 +
 +
  
  


 1.17  +4 -4  jakarta-struts/contrib/struts-el/build.xml

 Index: build.xml

   

===
   

 RCS file: /home/cvs/jakarta-struts/contrib/struts-el/build.xml,v
 retrieving revision 1.16
 retrieving revision 1.17
 diff -u -r1.16 -r1.17
 --- build.xml  13 Jun 2003 03:22:14 -  1.16
 +++ build.xml  9 Aug 2003 19:29:30 -   1.17
 @@ -51,10 +51,10 @@
   -->
   
 - 
 - 
 - 
   
 + 
 + 
 + 
   
   
 @@ -219,7 +219,7 @@
  -->

 
 -   
 +   

   


 1.9   +7 -7

   

jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/tag
lib/html/ELFormTag.java
 

 Index: ELFormTag.java

   

===
   

 RCS file:

   

/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/st
rutsel/taglib/html/ELFormTag.java,v
 

 retrieving revision 1.8
 retrieving revision 1.9
 diff -u -r1.8 -r1.9
 --- ELFormTag.java	26 Jul 2003 05:48:02 -	1.8
 +++ ELFormTag.java	9 Aug 2003 19:29:30 -	1.9
 @@ -386,9 +386,9 @@
  this, pageContext))
   

!=
   

null)
  setScope(string);
 -if ((bool = EvalHelper.evalBoolean("scriptLanguage",
getScriptLanguageExpr(),
 -   this, pageContext)) !=
null)
 -setScriptLanguage(bool.booleanValue());
 +if ((string = EvalHelper.evalString("scriptLanguage",
getScriptLanguageExpr(),
 +this, pageContext))
   

!=
   

null)
 +setScriptLanguageExpr(string);
  if ((string = EvalHelper

Re: When is the next release?

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Just a head's up. I'd like to draw up a Release Plan tomorrow for Struts
> 
> 1.2 beta 1. I'd like to get this out so people can start migrating to 
> the "non-deprecated Struts 1.1+" (for lack of a better term) *before* we
> 
> get into the Commons Resources thing.

I think this is a great time to release 1.2.  Aside from getting the
massive amount of deprecated code out of Struts, we're also releasing bug
fixes and quite a few minor enhancements.  It will also be nice to get out
of the dreaded 1.1 series :-).  Thanks for handling the release Ted!

David

> 
> Since we did so much backward-compatiblity work on Struts 1.1, getting 
> the deprecations out of some of the older code will be no small task for
> 
> some people, but the sooner we get the community started on this, the 
> better.
> 
> If anyone else would like to be the Release Manager, please feel free to
> 
> chime in. I'd be happy to pass the baton once the plan is in place.
> 
> -Ted.
> 
> 
> 
> -
> 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]

DO NOT REPLY [Bug 22284] - html:form is not HTML 4.01 compliant

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=22284

html:form is not HTML 4.01 compliant





--- Additional Comments From [EMAIL PROTECTED]  2003-08-10 18:05 ---
Created an attachment (id=7728)
Patch to FormTag.java

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

Re: When is the next release?

2003-08-14 Thread Erik Hatcher

On Sunday, August 10, 2003, at 06:25  PM, Robert Leland wrote:
Maven generates a change log and so does the perl script cvs2cl.pl 
(www.red-bean.com/~kfogel/cvs2cl.shtml,
And so does Ant:

	http://ant.apache.org/manual/CoreTasks/changelog.html



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

DO NOT REPLY [Bug 22283] - document how to use html:html xhtml=true

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=22283

document how to use html:html xhtml=true

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-10 16:28 ---
I added a note to the docs about rendering the xmlns attribute.  The docs don't
need to specify what the tag doesn't render, only what it does.  Also, the
Struts taglib docs aren't meant to be an XHTML tutorial.

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

RE: SuccessAction (was RE: Addition of two new actions)

--- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> > I thought the whole point was that there would be only one forward
> > and the action would always forward to that forward?  In that case,
> > you could count on using the first one.
> 
> Just thinking that if an anonymous/default ActionForward were allowed,
> then
> it could also be useful for other actions. In any case, it's better not
> to
> allow a situation where the behaviour is unspecified.
> 
> >> You'd probably need to add a method such as getDefaultForward()
> >> to retrieve it.
> >
> > This part seems to be adding complexity to something which was meant
> > to be very simple.
> 
> I think it might actually be possible to reduce the visible complexity
> by
> doing that. e.g.
> 
>  type="org.apache.struts.actions.SuccessAction">
>   
>   
> 
> SuccessAction may not now be best name, but let's stick with it for the
> moment.
> 
> To be really radical, we could absorb the behaviour into Action, and
> have it
> check for a default ActionForward and use that, if found. That way
> there's
> no need for a SuccessAction at all. Then you could just do:
> 
>  type="org.apache.struts.action.Action">
>   
>   
> 
> If Action actually does something useful, could we go crazy and default
> the
> type as well?
> 
>   
>   
>   

There is a simpler way of doing that:


The only benefit of SuccessAction was that it allowed you to use the more
configurable  element to describe the forward so I think
SuccessAction examples should include  attributes that couldn't
be done any other way.

Having said all that, I do like that we're trying to get a simpler
action/forward declaration syntax :-).

> 
> Now that's simple. Especially if you allow a global default forward...
> 
>   

All we know from this is that there is an action mapped to /myAction but
we don't know what handles it.  Taken by itself, it looks nonsensical and
would likely cause confusion.  This may be a case where it's *too* simple.

David

> 
> Probably not quite so useful, but nicely minimal!
> 
> Steve
> 
> 
> 
> -
> 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: Building contrib packages WAS Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml

--- Robert Leland <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> 
> >--- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> >  
> >
> >>o.a.s.util.GenericDataSource is in the core and extends the legacy
> >>GenericDataSource so legacy needs to be built first.
> >>
> >>
> >
> >That's a good point.
> >
> >  
> >
> >>It is deprecated since 1.1. Can we get rid of all legacy / DataSource
> >>stuff
> >>for 1.2?
> >>
> >>
> >
> >I believe that was the plan all along but I've been waiting for Ted to
> >remove it because he (thankfully :-) took the lead in adding it.  I
> >haven't looked into it but hopefully it will be a simple build.xml
> change
> >and removal from cvs.
> >
> The cleaning up the DTD, docs and then maybe example app ?

I don't think we're removing/changing anything in the DTD.  I did make the
 attribute REQUIRED for 1.2 so we don't default to
GenericDataSource but AFAIK we're still supporting the 
element.

David

> 
> Rob
> 
> >
> >David
> >
> >  
> >
> >>Steve
> >>
> >>
> >>
> >>>-Original Message-
> >>>From: David Graham [mailto:[EMAIL PROTECTED]
> >>>Sent: August 9, 2003 4:03 PM
> >>>To: Struts Developers List
> >>>Subject: Building contrib packages WAS Re: cvs commit:
> >>>jakarta-struts/contrib/tag-doc build.xml
> >>>
> >>>
> >>>While we're somewhat on this topic I'd like to get some clarification
> >>>  
> >>>
> >>on
> >>
> >>
> >>>the build process.  Why do struts-el and struts-legacy get built with
> >>>  
> >>>
> >>the
> >>
> >>
> >>>standard Struts build file?  Struts-EL has *never* built on my
> machine
> >>>  
> >>>
> >>and
> >>
> >>
> >>>I have just taken it on faith the rest of Struts built properly. 
> >>>  
> >>>
> >>Also,
> >>
> >>
> >>>after struts-legacy was added I've had to run my builds twice.  The
> >>>  
> >>>
> >>first
> >>
> >>
> >>>one always fails and the second succeeds (well, not really succeeds
> >>>because struts-el fails).
> >>>
> >>>In general, I don't see a reason for contrib packages to be built
> with
> >>>  
> >>>
> >>the
> >>
> >>
> >>>rest of Struts.  Am I missing something?
> >>>
> >>>David
> >>>
> >>>--- [EMAIL PROTECTED] wrote:
> >>>  
> >>>
> craigmcc2003/08/09 12:29:30
> 
>   Modified:.build.xml
>    contrib/struts-el build.xml
> 
> contrib/struts-el/src/share/org/apache/strutsel/taglib/html
> ELFormTag.java ELHtmlTag.java
> ELJavascriptValidatorTag.java
>    contrib/struts-faces build.xml
>    contrib/struts-legacy build.xml
>    contrib/tag-doc build.xml
>   Log:
>   Correct loading order of properties files to go from most local
> (current
>   directory) to most global (${user.home}/build.properties).  Since
> 
> 
> >>Ant
> >>
> >>
>   follows a "first definition wins" strategy, this makes the most
> 
> 
> >>sense
> >>
> >>
>   for our convention of allowing local overrides of global values. 
> 
> 
> >>It
> >>
> >>
> also
>   means that I can now do an "ant dist" in the top level directory
> 
> 
> >>with
> >>
> >>
> only
>   one thing in my build.properties file (jdk.version=1.4), so this
> should fix
>   the nightly builds as well (verifying that is my next step).
> 
>   Also fixed some compile errors in struts-el -- I don't know how
> 
> 
> >>that
> >>
> >>
> code
>   could have compiled for anyone.  Could someone more familiar with
> 
> 
> >>that
> >>
> >>
>   library make sure I did the changes correctly?
> 
>   Revision  ChangesPath
>   1.118 +5 -2  jakarta-struts/build.xml
> 
>   Index: build.xml
>  
> 
> 
> >>===
> >>
> >>
>   RCS file: /home/cvs/jakarta-struts/build.xml,v
>   retrieving revision 1.117
>   retrieving revision 1.118
>   diff -u -r1.117 -r1.118
>   --- build.xml   8 Aug 2003 06:00:55 -   1.117
>   +++ build.xml   9 Aug 2003 19:29:30 -   1.118
>   @@ -113,9 +113,9 @@
>    -->
> 
>    
>   -
>   -
>    
>   +
>   +
> 
>    
> value="../jakarta-tomcat-4.0/build"/>
>   @@ -204,6 +204,9 @@
> 
>    
>    
>   +
>   +
>   + value="${basedir}/contrib/struts-legacy/dist/struts-legacy.jar"/>
> 
>    
>    
> 
> 
> 
>   1.17  +4 -4  jakarta-struts/contrib/struts-el/build.xml
> 
>   Index: build.xml
>  
> 
=== message truncated ===


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---

Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)

2003-08-14 Thread 苗启广



ÔÚ 2003-08-09 03:01:00 ÄúÐ´µÀ£º
>Is this a vote?  If so, shouldn't we have [VOTE] on the subject line?of you ? Could 
>you tell me ? Thanks~~
>
>
>--
>James Mitchell
>Software Engineer / Struts Evangelist
>http://www.struts-atlanta.org
>678.910.8017
>AIM:jmitchtx
>
>
>
>
>> -Original Message-
>> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
>> Sent: Friday, August 08, 2003 5:38 PM
>> To: Struts Developers List
>> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE:
>> Addition of two new actions)
>>
>>
>> I *think* we agreed to add this action. Pick a name.
>>
>> [ ] ParameterDispatchAction
>> [ ] MappingDispatchAction
>> [ ] ConfigDispatchAction
>>
>> Steve
>>
>> > -Original Message-
>> > From: Steve Raeburn [mailto:[EMAIL PROTECTED]
>> > Sent: August 4, 2003 1:25 PM
>> > To: Struts Developers List
>> > Subject: RE: Addition of two new actions
>> >
>> >
>> > In an ideal world, DispatchAction should probably become
>> > ParameterDispatchAction and this could be plain old DispatchAction.
>> >
>> > Is Anthony's original suggestion of ConfigDispatchAction any better?
>> >
>> > I can't think of a name that I *really* like so I'm +0 on Mapping
>> > or Config.
>> >
>> > Steve
>> >
>> > > -Original Message-
>> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper
>> > > Sent: August 4, 2003 10:15 AM
>> > > To: [EMAIL PROTECTED]
>> > > Subject: Re: Addition of two new actions
>> > >
>> > > I'm +1 on this, other than on naming. I think
>> ParameterDispatchAction is
>> > > definitely the wrong name for the last of these. People
>> are *far* more
>> > > likely to think of the "Parameter" in the name as meaning
>> a request
>> > > parameter than they are to think of the "parameter" action mapping
>> > > attribute. Perhaps MappingDispatchAction instead?
>> > >
>> > > I am -0 on combining all of this into one action.
>> > >
>> > > --
>> > > 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]
>
>
 mqg

- SOUVENIR --- .
| Souvenir of China |
| A Good Place for You  |
`--> http://www.souvenirchina.com -'
mailto:[EMAIL PROTECTED]




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

cvs commit: jakarta-struts/src/share/org/apache/struts/action PlugIn.java

rleland 2003/08/09 21:58:54

  Modified:src/share/org/apache/struts/action PlugIn.java
  Log:
  By definition an interface has only public methods so remove
  keyword 'public'
  
  Revision  ChangesPath
  1.11  +6 -6  jakarta-struts/src/share/org/apache/struts/action/PlugIn.java
  
  Index: PlugIn.java
  ===
  RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/action/PlugIn.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- PlugIn.java   15 Apr 2003 00:18:45 -  1.10
  +++ PlugIn.java   10 Aug 2003 04:58:53 -  1.11
  @@ -94,7 +94,7 @@
* Receive notification that our owning module is being
* shut down.
*/
  -public void destroy();
  +void destroy();
   
   
   /**
  @@ -109,7 +109,7 @@
* @exception ServletException if this PlugIn cannot
*  be successfully initialized
*/
  -public void init(ActionServlet servlet, ModuleConfig config)
  +void init(ActionServlet servlet, ModuleConfig config)
   throws ServletException;
   
   
  
  
  

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

DO NOT REPLY [Bug 22307] New: - org.struts.bean.IncludeTag encoding

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=22307

org.struts.bean.IncludeTag encoding

   Summary: org.struts.bean.IncludeTag encoding
   Product: Struts
   Version: 1.0.2 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The source contains the following statement which poses a problem with including
l18n jsps.  

InputStreamReader in = new InputStreamReader(is); // FIXME - encoding

I would suggest changing this to:

InputStreamReader in = new InputStreamReader(is, _encoding);

and adding a member variable at the top:

protected String _encoding = "UTF-8";

as well as a setter:

protected void setEncoding(String encoding) {
_encoding = encoding;
}

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

Re: Re: Resource Bundle Prototyping

2003-08-14 Thread 苗启广



ÔÚ 2003-08-09 09:04:00 ÄúÐ´µÀ£º
>adam kramer wrote:of you ? Could you tell me ? Thanks~~
>> On Wed, 6 Aug 2003, Sgarlata Matt wrote:
>>
>>>Has there been any discussion of allowing resource bundles to inherit
>>>properties from other resource bundles?  For the project I am working
>>>on, it would be nice if we had one resource bundle with
>>>application-level properties and also module-specific resource bundles
>>>which had all the properties of the application-level resource bundle
>>>plus additional ones specific to that module.  I know you can specify
>>>multiple resource bundles per module in Struts, but the problem is that
>>>certain components (e.g. - the validator) always look for the default
>>>resource bundle.
>>
>>
>>  In some of my projects I have run into the same problem as well, and I'm
>> sure others have. It would be nice to have either a core module that
>> provided resources to all modules or atleast a way of specifying a way for
>> a the default resource bundle in modules to inherit values from a core
>> resource bundle as to avoid having to repeat values throughout an
>> application and introduce chances for inconsistency and error. This might
>> be done by specifying an application-wide resource bundle in struts
>> configuration and then have those values within all other module resource
>> bundles (inclding the default module). You could obviously overwrite the
>> values in your module's def. bundle. This would seem an
>> appropriate feature, unless there were other core resources that needed to
>> be shared throughout modules. Then it would seem a module-type enhance
>> would be appropriate. ahh, oh so vague. :)
>>
>
>Hmmm
>
>I have just read a message from the Expresso opensource mailing list
>asking us to review the common-resources package as well, since we
>integrate Struts 1.1
>
>I remember reading way back that ResourceBundle supported delegation
>about of the box. In other words ResourceBundle can have a parent
>ResourceBundle. Is this what you want?
>
>The common resources should support what ever `java.util.ResourceBundle'
>does. Is this not true?
>
>The other issue I can see that crosses with this post is
>`module inheritance' , but my experience with this one is pretty low.
>
>--
>Peter Pilgrim
>__ _ _ _
>   / //__  // ___// ___/   +  Serverside Java
>  / /___/ // /__ / /__ +  Struts
> / // ___// ___// ___/ +  Expresso Committer
>  __/ // /__ / /__ / /__   +  Independent Contractor
> /___///////   +  Intrinsic Motivation
>On Line Resume
>||
>\\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
 mqg

- SOUVENIR --- .
| Souvenir of China |
| A Good Place for You  |
`--> http://www.souvenirchina.com -'
mailto:[EMAIL PROTECTED]




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

Testing Dispatch Action Classes with Cactus

2003-08-14 Thread Gupta, Sahil

Can some one point to how to do this?

-Original Message-
From: Mike Jasnowski [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2003 9:57 AM
To: Struts Developers List
Subject: RE: ActionForwards, et al (was SuccessAction)


>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.

Not sure if this comment belongs in the context of here, but I'll throw it
out. We use Tiles and Tiles Controllers heavily, and one thing I dislike
about forwarding to a TileDefinition is that I cannot then easily figure out
which Action I'm forwarding to ( The path names a definition which is the
same for each view in my case).

I'm currently appending information via an extension to the ActionForward,
this extra info is then used in my controller to prepare the appropriate
data for that view.  If there was some more transparent way to do this that
would be good.

I currently have one controller per definition, which may encompass several
related views.

> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thing.




-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2003 9:47 AM
To: Struts Developers List
Subject: Re: ActionForwards, et al (was SuccessAction)


--- Ted Husted <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> > What I think we're seeing here
> > is that we've outgrown our ActionForward declarations and need some
> new
> > ones.  I'm fine with adding a SuccessAction but would really like to
> see
> > us discuss future possibilities in this area.
>
> This may not be what you meant, but I've been thinking that
> ActionForward could use a class extension point, same as ActionMapping.
>
> The idea would be to give ActionForward a type property for a Java
> class. If the property is specified, instead of just taking the path as
> it stands, the Controller would call a "prepare" method on the class,
> passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse.

This may be a good time to add an ActionContext interface instead of
passing all these individual pieces.  This would also slightly remove the
dependence on Servlet to allow us more flexibility when we look at the
Portlet API.

>
> The prepare method would return a String that the Controller would use
> for the path.
>
> This allows the ActionForward to act as a Page Controller for the path.
> If the particular page referenced by the path needs any special "chrome"
>
> the Page Controller can set that up. Or, if the path needs to be
> adjusted for Locale or device (PDA, browser, et al), then the Page
> Controller could adjust the path before returning it.
>
> If it were a virtual page, like an dynamic image, merge file, or PDF,
> the Page class could also render the Response, rather than have the
> Action do it.
>
> Right now, the Action is doing double duty. It first acts as a
> Dispatcher that acquires business resources and selects the logical
> view. But, in real life, many pages often need special runtime resources
>
> of their own. So, the Action also serves as a Page Controller for the
> page it selects. Many of us consider that a mixing of concerns, and so
> we start to use some Actions as Dispatchers and others as Page
> Controllers. Tiles also fills this gap and is essentially a hybrid of a
> Compositive View and a Page Controller framework.
>
> I'm thinking that, architecturally, the ActionForward represents some
> resource available to the application, of any type, that can be reached
> by the application's protocol. In an http environment, it's the job of a
>
> Resource object to provide a URI that the Controller can use the reach
> the actual resource. (And, in  another environment, perhaps the path
> would not be a URI.)
>
> The Action, in its purest form, represents a Dispatcher. It's the job of
>
> a Dispatcher to select which (logical) Resource will handle the
> response. When we talk about selecting between "success", "failure", or
> "glockenspiel", we're talking about dispatching.
>
> But, in real life, we often can't just dispatch to a page. The page
> needs certain resources to render, often to fill UI controls like select
>
> lists.
>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.
>
> What would start to happen here, I think, is that people will put into
> the new

DO NOT REPLY [Bug 22261] - html:rewrite tag functionality and documentation mismatch

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=22261

html:rewrite tag functionality and documentation mismatch

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-10 10:10 ---
There wasn't actually an 'action' attribute listed for the rewrite tag, although
it was implied by the description in other attributes. I've added it now.

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

cvs commit: jakarta-struts/contrib/struts-chain build.xml

rleland 2003/08/10 23:13:07

  Modified:contrib/struts-chain build.xml
  Log:
  Remove extra LF\CR in build.xml other imported files
  don't seem to have this.
  
  Revision  ChangesPath
  1.2   +308 -308  jakarta-struts/contrib/struts-chain/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-chain/build.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.xml 11 Aug 2003 04:55:34 -  1.1
  +++ build.xml 11 Aug 2003 06:13:07 -  1.2
  @@ -1,308 +1,308 @@
  -
  -
  -
  -  
  -
  -
  -  
  -  
  -  
  -  
  -  
  -
  -
  -  
  -  
  -  
  -
  -  
  -  
  -
  -  
  -  
  -  
  -
  -
  -  
  -  
  -  
  -  
  -  
  -  
  -
  -
  -  
  -  
  -  
  -  
  -
  -
  -  
  -  
  -
  -  
  -
  -
  -
  -
  -  
  -
  -
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  http://localhost:8080/manager"/>
  -  
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -
  -  
  -
  -  
  -
  -
  -  
  -
  -
  -
  -
  -
  -
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -  
  -
  -
  -
  -
  -
  -  
  -
  -
  -  
  -
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -
  -  
  -
  -
  -  
  -
  -  
  -
  -
  -
  -
  -
  -
  -
  -
  -  
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -  
  -
  -
  -  
  -
  -  
  -
  -
  -  
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -
  -
  -
  -  
  -
  -  
  -  
  -
  -  
  -
  -
  -  
  -
  -
  -
  +
  +
  +
  +  
  +
  +
  +  
  +  
  +  
  +  
  +  
  +
  +
  +  
  +  
  +  
  +
  +  
  +  
  +
  +  
  +  
  +  
  +
  +
  +  
  +  
  +  
  +  
  +  
  +  
  +
  +
  +  
  +  
  +  
  +  
  +
  +
  +  
  +  
  +
  +  
  +
  +
  +
  +
  +  
  +
  +
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  http://localhost:8080/manager"/>
  +  
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +  
  +
  +
  +
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +  
  +
  +
  +  
  +
  +  
  +
  +
  +
  +
  +
  +
  +
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +  
  +
  +
  +  
  +
  +
  +  
  +
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +
  +
  +
  +  
  +
  +  
  +  
  +
  +  
  +
  +
  +  
  +
  +
  +
  
  
  

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

Re: When is the next release?

Craig R. McClanahan wrote:
Tomcat's 4.1 experience was that only every sixth release or so was voted
GA, at least for the first several. 
I think if you look at the various Betas and RCs most Jakarta products 
go through, six would be the mode. So, this seems pretty typical.


I think it's unlikely to pass a GA vote, simply because ripping out all
the deprecated stuff is a fairly major amount of surgery, and we might
have missed something.  But we'll see.
Which is the beauty of this system. If it turns out to be GA after-all, 
we just need to update the links. CVS remains the same.


Absolutely.  One missing detail in the plan, though, is whether we branch
on each 1.2.x release.  Tomcat doesn't and I don't see a reason to since
we would probably never go back and try a 1.2.5.1 release to fix something
in 1.2.5.
Agreed. The release scheme implies that you wouldn't reissue a release. 
At most, you'd issue a patch based on the CVS tag. But more likely, 
you'd fix 1.2.5 with 1.2.6, and demote 1.2.5 if there was a serious issue.


Another thing Remy does for Tomcat (which I *really* appreciate) is keeps
a running change log (summary, not detailed) in the release notes for each
version.  That way, everyone can get a quick summary of what's changed.
I'd like this kind of thing to be part of the release manager's
responsibilities.
Once upon a time, I did a lot of this when we were ramping up for a 
milestone, but burned out during the 1.1 campaign. I agree that this is 
important, and so will bring us current for 1.x -> 1.2.x.

I'm also thinking we should make a concerted effort to apply or discount 
any outstanding patches developers have submitted. There's at least 21 
of these now.

http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=PatchAvailable&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number

We may not have a fix for an outstanding issue yet, but we really should 
honor any outstanding contributions.

I'm a zero-relative guy at heart :-).  My only concern is that people will
assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
1.2.1.
I think we should assume that people will make wrong assumptions no 
matter what we do, so let's just start with zero, as Cantor intended. =:0)

-Ted.



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

cvs commit: jakarta-struts/contrib/struts-el build.xml

2003-08-14 Thread craigmcc

craigmcc2003/08/09 18:21:43

  Modified:contrib/struts-el build.xml
  Log:
  Modify the build.xml for struts-el to have a hard-coded reference to the
  struts.jar in the parent Struts source tree (i.e. output of "ant dist").
  This makes it possible to compile struts-el even when the user has a
  "${user.home}/build.properties" file that defines a struts.jar property
  (as I do, because I *use* Struts in lots of different packages).
  
  Revision  ChangesPath
  1.18  +3 -3  jakarta-struts/contrib/struts-el/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-el/build.xml,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- build.xml 9 Aug 2003 19:29:30 -   1.17
  +++ build.xml 10 Aug 2003 01:21:43 -  1.18
  @@ -158,7 +158,7 @@
 
 
 
  -  
  +  
 
 
 
  @@ -193,7 +193,7 @@

 
 
  -  
  +  
 
 
  @@ -277,7 +277,7 @@

Re: cvs commit: jakarta-struts/doc/resources extensions.xml

I'm assuming this commit was prompted by a corresponding enhancement
ticket.  If so, it would be helpful if you included the ticket number in
the commit message so we can reference it later for more info if needed. 
I think the typical notation is PR# .

David

--- [EMAIL PROTECTED] wrote:
> mrdon   2003/08/11 16:51:03
> 
>   Modified:doc/resources extensions.xml
>   Log:
>   Added Struts BSF project link and description
>   
>   Revision  ChangesPath
>   1.11  +1 -0  jakarta-struts/doc/resources/extensions.xml
>   
>   Index: extensions.xml
>   ===
>   RCS file: /home/cvs/jakarta-struts/doc/resources/extensions.xml,v
>   retrieving revision 1.10
>   retrieving revision 1.11
>   diff -u -r1.10 -r1.11
>   --- extensions.xml  15 Feb 2003 20:55:24 -  1.10
>   +++ extensions.xml  11 Aug 2003 23:51:03 -  1.11
>   @@ -38,6 +38,7 @@
>http://husted.com/struts/resources/mapper.htm";>Mapper
> Framework by Capco - The Mapper framework can be used for
> automating the process of validating/converting/transferring data
> fields. (See README to get started. Updated
> 18-JUL-2001.)
>http://www.sura.ru/~gonza/bean-factory/";>Bean
> factory by Oleg V Alexeev - Adds the ability to easily link data
> bean creation to any Struts Action. All information about databeans and
> actions mappings stored in the standard Struts configuraton file. 
>http://home.earthlink.net/~dwinterfeldt/";>Struts
> Validator [Now bundled with Struts 1.1] by David Winterfeldt -
> Perform basic validations to check if a field is required, matches a
> regular expression, and some basic type checking. Different validation
> rules can be defined for different locales. The framework has basic
> support for user defined constants which can be used in some field
> attributes. The validation routines are modifiable in the validation.xml
> file so custom validation routines can be created and added to the
> framework.
>   +http://struts.sf.net";>Scriptable Actions by
> Don Brown - Allows Struts Actions to be written in the scripting
> language of one's choice rather than as Java classes. It uses the  href="http://jakarta.apache.org/bsf";>Beans Scripting Framework to
> allow scripts to be written in any language BSF supports like Python
> (using http://www.jython.org/";>Jython), Ruby (using  href="http://jruby.sourceforge.net/";>JRuby), JavaScript (using  href="http://www.mozilla.org/rhino/";>Rhino), or  href="http://www.beanshell.org";>BeanShell.
>
>
>
>   
>   
>   
> 
> -
> 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: [Vote ?] deprecate ActionErrors

--- Robert Leland <[EMAIL PROTECTED]> wrote:
> I believe at one time we were going to deprecate ActionErrors since it
> is really a shell over ActionMessages. We could still keep the
> error tag, just make it use ActionMessages directly.
> 

It would be nice to get rid of it but I don't think we can until 2.0. 
ActionForm.validate() (and other methods) return an ActionErrors object. 
There is no way to deprecate those methods with a new version that returns
ActionMessages because return types aren't part of method signatures.  I
think this would break backwards compatibility but I would love to be
wrong on this one :-).

Also, ActionError should be deprecated with ActionErrors because it's just
a useless subclass of ActionMessage.

David

> [ ] +1 Yes deprecate ActionErrors
> [ ]  0  Yes, but you'll have to face the angry crowds yourself.
> [ ] -1 No, and here is why.
> 
> -Rob
> 
> 
> -- 
> Robert Leland [EMAIL PROTECTED]
> --
> Java, J2EE, Struts, Web Application Development
> 
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
> 
> 
> 
> -
> 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: When is the next release?

2003-08-14 Thread Steve Raeburn



> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: August 10, 2003 12:37 PM
> To: Struts Developers List
> Subject: Re: When is the next release?
>
>
> I'm a zero-relative guy at heart :-).  My only concern is that people will
> assume 1.2.0 really means 1.2, but I'd be happy with either 1.2.0 or
> 1.2.1.
>

Craig, could you clarify what you mean by 1.2?

I would assume 1.2 == 1.2.x, i.e. 1.2 represents the series of 1.2.x
releases.
So 1.2 would represent the 1.2 interface, but 1.2.x would be a particular
implementation.

Steve

>
> 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: Wildcard-matched actions (again)

Don Brown wrote:

Heh, thankfully no. :)  In fact, that's one of the reasons I'd like to
incorporate this into Struts itself to remove that alternate processor
requirement.
The patch adds a couple of lines to RequestProcessor.processMapping() to,
in the case of no direct mapping found, try to match any wildcards.  All
of the logic of wildcard mapping is stored in a helper class to keep
RequestProcessor as clean as possible.
Don

How about an option to turn it off ? Having something infinitely 
configurable is good right ;-) !
But seriously, if there will be noticeable overhead the ability should 
be able to be turned off.
In fact once struts configuration is frozen then it should be able to 
detect whether it needs
to search for wild card matches or not.

-Rob

--
Robert Leland   [EMAIL PROTECTED]
--
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street   +01-703-525-3580
Arlington VA 22201


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

Re: ActionForwards, et al (was SuccessAction)

My only concern would be using the term "context" to imply more than one 
object.

IMHO, there should be a functional non-httpd framework below Struts, 
that would provide things like a Context Object, which would be a 
generic version of the HttpRequest. At the Stuts level, you could then 
have available to you signatures that used a Context or a HttpContext.

In the future, we should be able to write pure business Actions that 
don't use http semantics, and only use the http version when we 
absolutely need to. In practice, most of us rarely use the http services 
of the HttpRequest, and the same Actions could be coded using a generic 
Context (that might be chained to the HttpRequest, as is done with the 
Velocity Tools).

[We started along this way with duel Action classes, but I've never even 
tried to use the non-http one.]

So, if we're talking about the ActionContext interface being an 
abstraction of the Action class, I'd like to search for another name. My 
suggestion for an Action class interface would be

Action <- HttpDispatcher.

As for the other core classes, I would suggest

ActionForward <- HttpResource

ActionMapping <- HttpCommand

or, if you prefer,

Action <- WebDispatcher

ActionForward <- WebResource

ActionMapping <- WebCommand

Since, I'm lead to understand Craig finds "http" hard to say when he 
gives talks =:)

-Ted.

David Graham wrote:

--- Joe Germuska <[EMAIL PROTECTED]> wrote:

Just a little "me-too" here, but I think both Ted and David have good 
points.  Ted's approach to adding a controller to the ActionForward 
is a relatively small change to the infrastructure that can offer a 
lot of gain.   And I've been interested in seeing some kind of 
ActionContext class for quite a while now.


I chose my words carefully when I said "ActionContext interface".  I
*think* we can all agree that if we added this it should be an interface
:-).
David


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

Re: ActionForwards, et al (was SuccessAction)

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> My only concern would be using the term "context" to imply more than one
> 
> object.
> 
> IMHO, there should be a functional non-httpd framework below Struts, 
> that would provide things like a Context Object, which would be a 
> generic version of the HttpRequest. At the Stuts level, you could then 
> have available to you signatures that used a Context or a HttpContext.
> 
> In the future, we should be able to write pure business Actions that 
> don't use http semantics, and only use the http version when we 
> absolutely need to. In practice, most of us rarely use the http services
> 
> of the HttpRequest, and the same Actions could be coded using a generic 
> Context (that might be chained to the HttpRequest, as is done with the 
> Velocity Tools).
> 
> [We started along this way with duel Action classes, but I've never even
> 
> tried to use the non-http one.]
> 
> So, if we're talking about the ActionContext interface being an 
> abstraction of the Action class, I'd like to search for another name. 

No, I was thinking Actions would be passed an ActionContext in their
execute() method similar to how Servlets know about a ServletContext.  The
ActionContext would contain the HttpServletRequest, form bean, etc. and
would serve to keep the API stable while allowing flexibility in what the
ActionContext actually contained.

David

> My
> 
> suggestion for an Action class interface would be
> 
> Action <- HttpDispatcher.
> 
> As for the other core classes, I would suggest
> 
> ActionForward <- HttpResource
> 
> ActionMapping <- HttpCommand
> 
> or, if you prefer,
> 
> Action <- WebDispatcher
> 
> ActionForward <- WebResource
> 
> ActionMapping <- WebCommand
> 
> Since, I'm lead to understand Craig finds "http" hard to say when he 
> gives talks =:)
> 
> -Ted.
> 
> 
> David Graham wrote:
> 
> > --- Joe Germuska <[EMAIL PROTECTED]> wrote:
> > 
> >>Just a little "me-too" here, but I think both Ted and David have good 
> >>points.  Ted's approach to adding a controller to the ActionForward 
> >>is a relatively small change to the infrastructure that can offer a 
> >>lot of gain.   And I've been interested in seeing some kind of 
> >>ActionContext class for quite a while now.
> > 
> > 
> > I chose my words carefully when I said "ActionContext interface".  I
> > *think* we can all agree that if we added this it should be an
> interface
> > :-).
> > 
> > David
> 
> 
> 
> -
> 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]

DO NOT REPLY [Bug 21913] - Reloading a Struts app doesn't update form bean definitions

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=21913

Reloading a Struts app doesn't update form bean definitions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-10 11:51 ---
I do get the same problem on Tomcat 4.1.24 with DynaActionForms. It happens even
after a shutdown and restart of the container (not just the application).
No problem with regular ActionForm classes. 

I agree with David though, that this is a Tomcat problem and not Struts. so I'm
closing this as a Struts issue, but you should consider opening a ticket for
Tomcat. In the meantime, the work-around would be to use ActionForm classes (Not
ideal, I know).

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

Re: When is the next release?

Steve Raeburn wrote:
I'm for removing it. I can do this if no one else is on it already.
David said he thought I was going to do it, and I thought David was 
going to do it, so let's split the difference and let Steve do it =:)

-Ted.



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

DO NOT REPLY [Bug 22228] - Action.saveErrors() should save empty ActionErrors objects

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=8

Action.saveErrors() should save empty ActionErrors objects





--- Additional Comments From [EMAIL PROTECTED]  2003-08-11 21:36 ---
Created an attachment (id=7758)
Removes empty ActionErrors object check in the Action.saveErrors(HttpServletRequest) 
method.

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

Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html RewriteTag.java

Do we also need to add a TLD entry for this attribute?

David

--- [EMAIL PROTECTED] wrote:
> sraeburn2003/08/10 03:05:51
> 
>   Modified:doc/userGuide struts-html.xml
>src/share/org/apache/struts/taglib/html RewriteTag.java
>   Log:
>   Added action attribute to rewrite tag. 
>   PR: 22261
>   
>   Revision  ChangesPath
>   1.58  +17 -0 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.57
>   retrieving revision 1.58
>   diff -u -r1.57 -r1.58
>   --- struts-html.xml 10 Aug 2003 09:14:04 -  1.57
>   +++ struts-html.xml 10 Aug 2003 10:05:51 -  1.58
>   @@ -5550,6 +5550,23 @@
>a JavaScript procedure.
>
>
>   + 
>   +  action
>   +  false
>   +  true
>   +  
>   +  Logical name of a Action that
>   +  contains the actual content-relative URI of the
> destination
>   +  of this transfer.  This hyperlink may be
> dynamically
>   +  modified by the inclusion of query parameters, as
> described
>   +  in the tag description. You must
> specify
>   +  exactly one of the action attribute,
> the
>   +  forward attribute, the
>   +  href attribute, or the
> page
>   +  attribute.
>   +  
>   +
>   +
>
>  anchor
>  false
>   
>   
>   
>   1.15  +5 -5 
> jakarta-struts/src/share/org/apache/struts/taglib/html/RewriteTag.java
>   
>   Index: RewriteTag.java
>   ===
>   RCS file:
>
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/RewriteTag.java,v
>   retrieving revision 1.14
>   retrieving revision 1.15
>   diff -u -r1.14 -r1.15
>   --- RewriteTag.java 31 Jul 2003 00:25:39 -  1.14
>   +++ RewriteTag.java 10 Aug 2003 10:05:51 -  1.15
>   @@ -102,7 +102,7 @@
>   forward,
>   href,
>   page,
>   -   null,
>   +   action,
>   params,
>   anchor,
>   false,
>   
>   
>   
> 
> -
> 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]

cvs commit: jakarta-struts/doc/resources sigs.xml

2003-08-14 Thread jmitchell

jmitchell2003/08/11 20:10:02

  Modified:doc/resources sigs.xml
  Log:
  Added Silicon Valley User Group
  
  as requested by:
  Van Riper, Mike <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.3   +5 -0  jakarta-struts/doc/resources/sigs.xml
  
  Index: sigs.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/resources/sigs.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- sigs.xml  20 May 2003 03:18:18 -  1.2
  +++ sigs.xml  12 Aug 2003 03:10:02 -  1.3
  @@ -17,6 +17,11 @@
   enthusiasts, professionals and zealots who keep each other informed about 
   issues and innovations in the Struts Framework. Come to the meetings and 
   contribute!
  +http://www.baychi.org/bof/struts";>
  +Silicon Valley Struts User Group - The Silicon Valley Struts User
  +Group (SVSUG) meets on the first Wednesday of the month at various locations
  +in the south bay. All levels of Struts user experience are welcome. Meetings
  +are free and open to all.
   Online
   http://groups.yahoo.com/group/model_struts/";>Model Layer in MVC 
(Struts). 
   http://www.basebeans.com:8081/mailman/listinfo/mvc-programmers";>MVC 
Programmers. 
  
  
  

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

Re: ActionForwards, et al (was SuccessAction)

--- Joe Germuska <[EMAIL PROTECTED]> wrote:
> Just a little "me-too" here, but I think both Ted and David have good 
> points.  Ted's approach to adding a controller to the ActionForward 
> is a relatively small change to the infrastructure that can offer a 
> lot of gain.   And I've been interested in seeing some kind of 
> ActionContext class for quite a while now.

I chose my words carefully when I said "ActionContext interface".  I
*think* we can all agree that if we added this it should be an interface
:-).

David

> 
> Joe
> 
> 
> At 6:47 -0700 8/11/03, David Graham wrote:
> >--- Ted Husted <[EMAIL PROTECTED]> wrote:
> >>  David Graham wrote:
> >>  > What I think we're seeing here
> >>  > is that we've outgrown our ActionForward declarations and need
> some
> >>  new
> >>  > ones.  I'm fine with adding a SuccessAction but would really like
> to
> >>  see
> >>  > us discuss future possibilities in this area.
> >>
> >>  This may not be what you meant, but I've been thinking that
> >>  ActionForward could use a class extension point, same as
> ActionMapping.
> >>
> >>  The idea would be to give ActionForward a type property for a Java
> >>  class. If the property is specified, instead of just taking the path
> as
> >>  it stands, the Controller would call a "prepare" method on the
> class,
> >>  passing it the ActionForward, ActionForm, HttpRequest, and
> HttpResponse.
> >
> >This may be a good time to add an ActionContext interface instead of
> >passing all these individual pieces.  This would also slightly remove
> the
> >dependence on Servlet to allow us more flexibility when we look at the
> >Portlet API.
> >
> >>
> >>  The prepare method would return a String that the Controller would
> use
> >>  for the path.
> >>
> >>  This allows the ActionForward to act as a Page Controller for the
> path.
> >>  If the particular page referenced by the path needs any special
> "chrome"
> >>
> >>  the Page Controller can set that up. Or, if the path needs to be
> >>  adjusted for Locale or device (PDA, browser, et al), then the Page
> >>  Controller could adjust the path before returning it.
> >>
> >>  If it were a virtual page, like an dynamic image, merge file, or
> PDF,
> >>  the Page class could also render the Response, rather than have the
> >>  Action do it.
> >>
> >>  Right now, the Action is doing double duty. It first acts as a
> >>  Dispatcher that acquires business resources and selects the logical
> >>  view. But, in real life, many pages often need special runtime
> resources
> >>
> >>  of their own. So, the Action also serves as a Page Controller for
> the
> >>  page it selects. Many of us consider that a mixing of concerns, and
> so
> >>  we start to use some Actions as Dispatchers and others as Page
> >>  Controllers. Tiles also fills this gap and is essentially a hybrid
> of a
> >>  Compositive View and a Page Controller framework.
> >>
> >>  I'm thinking that, architecturally, the ActionForward represents
> some
> >>  resource available to the application, of any type, that can be
> reached
> >>  by the application's protocol. In an http environment, it's the job
> of a
> >>
> >>  Resource object to provide a URI that the Controller can use the
> reach
> >>  the actual resource. (And, in  another environment, perhaps the path
> >>  would not be a URI.)
> >>
> >>  The Action, in its purest form, represents a Dispatcher. It's the
> job of
> >>
> >>  a Dispatcher to select which (logical) Resource will handle the
> >>  response. When we talk about selecting between "success", "failure",
> or
> >>  "glockenspiel", we're talking about dispatching.
> >>
> >>  But, in real life, we often can't just dispatch to a page. The page
> >>  needs certain resources to render, often to fill UI controls like
> select
> >>
> >>  lists.
> >>
> >>  Ideally, I believe another class, specified by the ActionForward,
> should
> >>
> >>  be responsible for setting up any "chrome" a particular page may
> need.
> >>  It's the one that knows where the page is (via the path property),
> and
> >>  so it's the one that should be privy to these details.
> >>
> >>  What would start to happen here, I think, is that people will put
> into
> >>  the new class the code that now encourages them to "chain"
> >>  some Actions. By providing a separation of concern between "choosing
> the
> >>  Resource" and "preparing the context for the Resource", it becomes
> >>  easier for people to Do The Right Thing.
> >
> >I've had similar composition problems and agree that a separation makes
> >sense.  Tiles Controllers can be used to setup page data but that
> doesn't
> >always work (especially if you're not using Tiles :-) so I end up
> chaining
> >actions.  None of the action chaining is due to bus. logic as that's
> >properly factored into a Service layer; it has to do purely with
> setting
> >up page data.
> >
> >Tiles Controllers are one of the major reasons I use Tiles and I think
> >it's appropriate to move that concept into the Struts

Decomposing RequestProcessor -- Some Code To Play With

During the "Decomposing RequestProcessor" thread a while back, I hinted
that I'd been working on some code to propose for this purpose, but had
never had time to polish it enough to check in.  Well, I actually took a
bunch of time this weekend for precisely that purpose, and have checked in
two chunks of code for your viewing and toying pleasure:

* A new jakarta-commons/sandbox package called "chain" that implements
  the GoF Chain of Responsibility pattern, in a way that lets you compose
  arbitrarily complex processing chains out of very simple classes,
  in a variety of different contexts.  If you're familiar with Cocoon,
  think of the "site map" pattern but without the requirement that every
  dynamic step be an XSLT transformation.  If you're familiar with Axis,
  think of the way you can compose Handler chains, but without the
  restriction that it is only useful in implementing a web service.
  Nightly builds of this package should start showing up tonight at:

  http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-chain/

* A new contrib package in the Struts workspace called "struts-chain"
  that is the beginnings of a decomposition of the RequestProcessor
  processing pipeline, but allows the overall chain to be customzied in
  much more powerful manners than the way that subclassing
  RequestProcessor supports.  You'll need to grab the CVS source to
  play with this one.  None of the code actually works yet -- it is very
  definitely a work in progress -- but I *think* we'll be able to end up
  with something that can be added on to a Struts 1.1 distro.

I won't personally have huge amounts of time to work on this over the next
few months, but I will definitely participate in discussions and
improvements to this code.  If it all works out, I'm going to propose
something like this as a foundational architecture for a Struts 2.x series
that will leverage this design pattern to support extreme customization.

Craig



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

DO NOT REPLY [Bug 22356] New: - org.apache.struts.util.PropertyMessageResources fails to report errors when reading prop files.

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=22356

org.apache.struts.util.PropertyMessageResources fails to report errors when reading 
prop files.

   Summary: org.apache.struts.util.PropertyMessageResources fails to
report errors when reading prop files.
   Product: Struts
   Version: 1.0.2 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The following piece of code loads properties files.  In my case one of the prop
files had an invalid unicode entry /u except for one of the x was not in the
range of [a-f0-9A-F].  This causes the prop files to be partially loaded so when
access the web application in this locale some strings were localized and some
strings were not.  

An error must be reported in this case.  It was quite hard to track down why
this problem was occuring.




// Load the specified property resource
try {
is = this.getClass().getClassLoader().getResourceAsStream(name);
if (is != null) {
props.load(is);
is.close();
}
} catch (Throwable t) {
if (is != null) {
try {
is.close();
} catch (Throwable u) {
;
}
}
}

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

DO NOT REPLY [Bug 22309] - extending for sticky cluster node

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=22309

 extending for sticky cluster node

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
Summary|org.struts.bean.IncludeTag  | extending for
   |extending for sticky cluster|sticky cluster node
   |node|

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

cvs commit: jakarta-struts/web/tiles-documentation/doc/portal documentation.jsp

2003-08-14 Thread sraeburn

sraeburn2003/08/12 00:31:11

  Modified:src/test/org/apache/struts/tiles/config tiles-defs.xml
   web/tiles-documentation/WEB-INF tiles-doc-defs.xml
   web/tiles-documentation/doc/portal documentation.jsp
  Log:
  Remove links to missing resources. This is a quick fix, tiles-documentation looks 
like it needs an overhaul.
  
  PR: 21090
  See also PR: 12159
  
  Revision  ChangesPath
  1.2   +2 -0  
jakarta-struts/src/test/org/apache/struts/tiles/config/tiles-defs.xml
  
  Index: tiles-defs.xml
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/test/org/apache/struts/tiles/config/tiles-defs.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- tiles-defs.xml27 Dec 2002 11:02:54 -  1.1
  +++ tiles-defs.xml12 Aug 2003 07:31:11 -  1.2
  @@ -70,7 +70,9 @@
  
  -->
 
  +  
 
 
 
  
  
  
  1.2   +2 -0  
jakarta-struts/web/tiles-documentation/WEB-INF/tiles-doc-defs.xml
  
  Index: tiles-doc-defs.xml
  ===
  RCS file: 
/home/cvs/jakarta-struts/web/tiles-documentation/WEB-INF/tiles-doc-defs.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- tiles-doc-defs.xml5 Nov 2002 14:18:58 -   1.1
  +++ tiles-doc-defs.xml12 Aug 2003 07:31:11 -  1.2
  @@ -70,7 +70,9 @@
  
  -->
 
  +  
 
 
 
  
  
  
  1.3   +0 -7  
jakarta-struts/web/tiles-documentation/doc/portal/documentation.jsp
  
  Index: documentation.jsp
  ===
  RCS file: 
/home/cvs/jakarta-struts/web/tiles-documentation/doc/portal/documentation.jsp,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- documentation.jsp 5 Nov 2002 14:18:58 -   1.2
  +++ documentation.jsp 12 Aug 2003 07:31:11 -  1.3
  @@ -3,15 +3,8 @@
   Documentation
   
 
  -Installation / Requirements  
  -  
  -  
   http://www.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf";>tilesAdvancedFeatures.pdf (draft)
  -  
  -Tutorial
 
   API
  
  
  

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

DO NOT REPLY [Bug 22356] - org.apache.struts.util.PropertyMessageResources fails to report errors when reading prop files.

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=22356

org.apache.struts.util.PropertyMessageResources fails to report errors when reading 
prop files.





--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 20:18 ---
This particular piece of code should also be re-written to properly use
try/catch/finally.

Like this:

try {
is = this.getClass().getClassLoader().getResourceAsStream(name);
if (is != null) {
props.load(is);
}
} catch (Throwable t) {
//print the stack trace for the prop file that failed to be loaded.
t.printStackTrace();
} finally {
if (is!=null) try { is.close(); is=null; } catch (Exception ignore) {}
}

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

DO NOT REPLY [Bug 22343] New: - In J2SDK 1.5.0 (Tiger) enum is a keyword

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=22343

In J2SDK 1.5.0 (Tiger) enum is a keyword

   Summary: In J2SDK 1.5.0 (Tiger) enum is a keyword
   Product: Struts
   Version: Unknown
  Platform: All
   URL: http://jcp.org/en/jsr/detail?id=201
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi!

Tiger adds extensions to the Java Programming Language (JSR201). One is
"Enumerations", which required to add the new keyword enum.

I just made a grep (grep -lrw) over some sources and found some Apache projects
using enum as a word.

To be compliant with the new specification, please check that enum is not used
as a variable, field or method name.

Regards,
Robert

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

Re: [Vote ?] deprecate ActionErrors

David Graham wrote:

--- Robert Leland <[EMAIL PROTECTED]> wrote:
 

David Graham wrote:

   

--- Robert Leland <[EMAIL PROTECTED]> wrote:

 

I believe at one time we were going to deprecate ActionErrors since it
is really a shell over ActionMessages. We could still keep the
error tag, just make it use ActionMessages directly.
  

   

It would be nice to get rid of it but I don't think we can until 2.0. 
ActionForm.validate() (and other methods) return an ActionErrors
 

object. 
   

There is no way to deprecate those methods with a new version that
 

returns
   

ActionMessages because return types aren't part of method signatures. 
 

I
   

think this would break backwards compatibility but I would love to be
wrong on this one :-).
 

You're right. We could provide a stop gap ActionForm.validateToMsg() or 
whatever that returns a
list of ActionMessages objects. We could then get rid of ActionError 
internally by making it a facade
of ActionMessage instead of extending ActionMessage. The same goes for 
ActionErrors, it would only be a facade.
and only created when needed.
   

This seems overly complicated.  Why not just wait for 2.0 to remove this
and replace it with commons-resources classes?  At least, that's what I
think we were planning.
I think deprecating ActionError is ok because ActionErrors can hold
ActionMessage objects instead.
David

validateToMsg() doesn't have anything to do with resources. 
validateToMsg() would return an ActionMessages
object instead of an ActionErrors object. I know validateToMsg isn't a 
good name.
Maybe we just call it something else, maybe verify() or check(). This is 
similar to what we did for perform() vs
execute(), we gave the users a transition path so they could gradually 
as needed remove deprecated methods.

-Rob

--
Robert Leland   [EMAIL PROTECTED]
--
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street   +01-703-525-3580
Arlington VA 22201

DO NOT REPLY [Bug 22309] New: - org.struts.bean.IncludeTag extending for sticky cluster node

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=22309

org.struts.bean.IncludeTag extending for sticky cluster node

   Summary: org.struts.bean.IncludeTag extending for sticky cluster
node
   Product: Struts
   Version: 1.1RC2
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The include tag has the following inside the doStartTag method:

if ((conn instanceof HttpURLConnection)
&& urlString.startsWith(request.getContextPath())
&& (request.getRequestedSessionId() != null)
&& request.isRequestedSessionIdFromCookie()) {
StringBuffer sb = new StringBuffer("JSESSIONID=");
sb.append(request.getRequestedSessionId());
conn.setRequestProperty("Cookie", sb.toString());
}

I would like to request that this is moved to a protected method to allow for it
to be overriden.

protected void setCookie(URLConnection conn, HttpServletRequest request,
String urlString, URL url)  {

if ((conn instanceof HttpURLConnection) && 
urlString.startsWith(request.getContextPath()) && 
(request.getRequestedSessionId() != null) && 
request.isRequestedSessionIdFromCookie()) {

StringBuffer sb = new StringBuffer("JSESSIONID=");
sb.append(request.getRequestedSessionId());
conn.setRequestProperty("Cookie", sb.toString());
}

}

The reason I need to overload this method when extending this class is to
support a cluster.  The problem with the include tag in a cluster is as follows:

Client - ip=10.10.10.1 - requests to LoadBalancer, LB sends request for
10.10.10.1 to Node A, Node A - ip=10.10.10.2 - then uses the include tag for a
request, request goes out to LB - since include tag uses host of incoming
request -, LB says 10.2 is a new client and sends request to Node B.  

The hardware loadbalancer that I use will actually just stop at this point
instead of sending the request on to Node B, not sure why.  In any case the
requests should be sticky and say on the same node so what I did is I extended
the include tag and I have some logic that detects if I am running in a cluster
mode and if so I grab the ip address of the current node and use the setHref
method.  

This works for the most part except that the logic used to check if a JSESSION
should be appended onto the http request fails since the url doesn't startWith
/application it now startsWith http://ipaddress/application.   The way I'd like
to solve this is to overload the setCookie method and instead of using the
urlString I use the URL and check the URL's contextPath against the startsWith.
 So my overloaded method looks like:

protected void setCookie(URLConnection conn, HttpServletRequest request,
String urlString, URL url)  {
if ((conn instanceof HttpURLConnection) && 
url.getPath().startsWith(request.getContextPath()) && 
(request.getRequestedSessionId() != null) && 
request.isRequestedSessionIdFromCookie()) {
StringBuffer sb = new StringBuffer("JSESSIONID=");
sb.append(request.getRequestedSessionId());
conn.setRequestProperty("Cookie", sb.toString());
}

}

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

cvs commit: jakarta-struts/contrib/struts-chain build.properties.sample

rleland 2003/08/10 23:28:38

  Modified:contrib/struts-chain build.properties.sample
  Log:
  Place note about catalina-ant.jar
  
  Revision  ChangesPath
  1.2   +4 -2  jakarta-struts/contrib/struts-chain/build.properties.sample
  
  Index: build.properties.sample
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-chain/build.properties.sample,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.properties.sample   11 Aug 2003 04:55:33 -  1.1
  +++ build.properties.sample   11 Aug 2003 06:28:38 -  1.2
  @@ -7,7 +7,9 @@
   # customize the values as required.
   #
   # $Id$
  -
  +#
  +### Inorder to build you must have the catalina-ant.jar in your CLASSPATH
  +### this is located under the jakarta-tomcat/server/lib directory
   
   # The absolute or relative pathname of the directory containing your
   # Servlet API classes JAR file (servlet.jar)
  
  
  

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

RE: ActionForwards, et al (was SuccessAction)

On Mon, 11 Aug 2003, Mike Jasnowski wrote:

> Date: Mon, 11 Aug 2003 09:50:29 -0400
> From: Mike Jasnowski <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> Subject: RE: ActionForwards, et al (was SuccessAction)
>
> >This may be a good time to add an ActionContext interface instead of
> >passing all these individual pieces.  This would also slightly remove the
> >dependence on Servlet to allow us more flexibility when we look at the
> >portlet API.
>
> As an outside observer I would like to see something like this added. We've
> already added something like you
> describe to our application.
>

You'll also note that commons-chain (basis for the decomposable request
processor proposal) does exactly this, with the added twist that it lets
you specialize the Context implementation with typesafe property accessors
if you want to, or use generic attributes otherwise.

Craig

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

RE: ActionForwards, et al (was SuccessAction)

On Tue, 12 Aug 2003, Mainguy, Mike wrote:

> Date: Tue, 12 Aug 2003 18:03:14 -0400
> From: "Mainguy, Mike" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: ActionForwards, et al (was SuccessAction)
>
> This conversation seems to be a by-product of looking at the Action classes
> as children of the servlet and consumers of messages instead of stand-alone
> entities.
> One intriguing way of dealing with this (IMHO) would be to consider elements
> as being able to "Pull" the required components out of some other area
> (Context?) (much like how the Turbine framework does).  Instead of Chaining
> commands or passing a context to every execute(), you would make available a
> generic application infrastructure that you could pull your required
> components from.
> Really this is probably just a semantic difference as the implementation (in
> my mind) would probably be much the same, but, to me when you word it as
> something 'Pulling' something out of the Context it makes more sense (errr,
> I can visualize it better at least) than trying to guess what should be
> 'Passed' along.
> Comments?
>

Doesn't "pulling" something from some application infrastructure imply
that somebody else "pushed" it into that infrastructure?  For example, if
you expect to find the HttpServletRequest object in there, presumably the
controller must have seeded that content.  It's also perfectly reasonable
for one Command in a Chain (in commons-sandbox/chain terms) to push
something into the Context that another Command executed later will need.

In terms of making the infrastructure available to callers, it's pretty
clear how passing a context object around makes the infrastructure
available to anyone who needs it.  Are there other options for how you'd
make the infrastructure available without passing it?  I haven't thought
of any.

Craig

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 12, 2003 5:37 PM
> To: Struts Developers List
> Subject: Re: ActionForwards, et al (was SuccessAction)
>
> Craig R. McClanahan wrote:
> > One of the potential problems in a Context-based environment is knowing
> > which keys you are using to store and retrieve stuff -- obviously, the
> > producer and consumer of a piece of data need to agree.  It is also
> > important that people looking at a Command should be able to determine
> > what attributes will be used for what by this particular Command.
> >
> > The convention of exposing the keys that you're using seems quite helpful
> > in this regard, for at least two reasons:
> >
> > * It's automatically configurable in case you want to
> >   reuse the Command implementation in a different way.
> >
> > * The fact that a "fooKey" property exists is automatically
> >   documentation that your Command is going to utilize
> >   a particular attribute for some purpose.
>
> And a potential problem in any Strategy-based implementation is that you
> don't know which of the parameters are actually used by a particular
> instance. For example, every Action is passed the Response, but very few
> every actually use it.
>
> In a framework like Struts, we can be passing some type of ActionContext
> that would have JavaBean properties corresponding to the
> "greatest-denominator" signature. So, given the properties, we'd have
> the same level of documentation as we do now.
>
> In implementing a Strategy-based or Context-based business layer
> framework, something I'm starting to look at know is the idea of
> building validation into the Command processing. So just as we can
> validate ActionForms, you might also want to validate a Context for a
> particular Command, using the Command's Catalog name (to use the Chain
> classnames) as the key.
>
> Of course, here, I'm talking about that fabled business layer framework
> that would live below Struts but use the same architectural patterns =:0)
>
> -Ted.
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message and its contents (to include attachments) are the property of Kmart 
> Corporation (Kmart) and may contain confidential and proprietary information. You 
> are hereby notified that any disclosure, copying, or distribution of this message, 
> or the taking of any action based on information contained herein is strictly 
> prohibited. Unauthorized use of information contained herein may subject you to 
> civil and criminal prosecution and penalties. If you are not the intended recipient, 
> you should delete this message immediately.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsub

Re: Wildcard-matched actions (again)

Matthias Bauer wrote:

I would like to be able to turn off this pattern matching feature, as 
performance is a very critical issue for a CMS. 
+1



--- Matthias

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




--
Robert Leland   [EMAIL PROTECTED]
--
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street   +01-703-525-3580
Arlington VA 22201


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

cvs commit: jakarta-struts/doc/uml StrutsWork.jdm

rleland 2003/08/12 06:45:56

  Added:   doc/uml  StrutsWork.jdm
  Log:
  Add Source to generate UML Diagrams SilverRUN-JD 1.1.
  Just point it towards the source and have it reverse engineer it,
  excluding teh CVS directories.
  
  Revision  ChangesPath
  1.1  jakarta-struts/doc/uml/StrutsWork.jdm
  
<>
  
  

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

Re: ActionForwards, et al (was SuccessAction)

Craig R. McClanahan wrote:
One of the potential problems in a Context-based environment is knowing
which keys you are using to store and retrieve stuff -- obviously, the
producer and consumer of a piece of data need to agree.  It is also
important that people looking at a Command should be able to determine
what attributes will be used for what by this particular Command.
The convention of exposing the keys that you're using seems quite helpful
in this regard, for at least two reasons:
* It's automatically configurable in case you want to
  reuse the Command implementation in a different way.
* The fact that a "fooKey" property exists is automatically
  documentation that your Command is going to utilize
  a particular attribute for some purpose.
And a potential problem in any Strategy-based implementation is that you 
don't know which of the parameters are actually used by a particular 
instance. For example, every Action is passed the Response, but very few 
every actually use it.

In a framework like Struts, we can be passing some type of ActionContext 
that would have JavaBean properties corresponding to the 
"greatest-denominator" signature. So, given the properties, we'd have 
the same level of documentation as we do now.

In implementing a Strategy-based or Context-based business layer 
framework, something I'm starting to look at know is the idea of 
building validation into the Command processing. So just as we can 
validate ActionForms, you might also want to validate a Context for a 
particular Command, using the Command's Catalog name (to use the Chain 
classnames) as the key.

Of course, here, I'm talking about that fabled business layer framework 
that would live below Struts but use the same architectural patterns =:0)

-Ted.







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

Re: Wildcard-matched actions (again)

--- Robert Leland <[EMAIL PROTECTED]> wrote:
> Matthias Bauer wrote:
> 
> >
> > I would like to be able to turn off this pattern matching feature, as 
> > performance is a very critical issue for a CMS. 
> 
> +1

So far I haven't heard any definitive answer to the performance question. 
If there isn't any performance penalty then we don't need the ability to
turn off pattern matching.  I'm starting to think this enhancement should
wait for 1.2.1 instead of trying to squeeze it in for 1.2.0.

David

> 
> >
> >
> > --- Matthias
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> 
> 
> -- 
> Robert Leland [EMAIL PROTECTED]
> --
> Java, J2EE, Struts, Web Application Development
> 
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
> 
> 
> 
> -
> 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]

Wildcard-matched actions (again)

2003-08-14 Thread Don Brown

I'd like to put the wildcard-matched action code from Bug #21813
(http://issues.apache.org/bugzilla/show_bug.cgi?id=21813) into
Struts.  When I mentioned it last, the only concern I heard raised was
from Craig regarding performance penalties.  As I noted in the bug
description, the path isn't checked against compiled wildcards until an
exact match cannot be found.  Even then, it is only checked against action
mappings that actually contain at least one wildcard.

Let me know if anyone has any reason I shouldn't do this or concerns I can
hopefully alleviate.  Thanks.

Don




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

Re: cvs commit: jakarta-struts/doc/resources extensions.xml

Martin Cooper wrote:

On Mon, 11 Aug 2003, David Graham wrote:

 

I'm assuming this commit was prompted by a corresponding enhancement
ticket.  If so, it would be helpful if you included the ticket number in
the commit message so we can reference it later for more info if needed.
I think the typical notation is PR# .
   

As long as you commit from the top level, you'll pick up the CVS template,
which provides the spaces for you to enter bug number and submitter.
--
Martin Cooper
Sounds like I should also use the command line version of CVS, to make 
life easier.

--
Robert Leland   [EMAIL PROTECTED]
--
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street   +01-703-525-3580
Arlington VA 22201

cvs commit: jakarta-struts/doc/userGuide release-notes.xml

rleland 2003/08/12 22:08:33

  Modified:doc/userGuide release-notes.xml
  Log:
  Bug 18002
  
  Document hanges to DispatchAction and LookupDispatchAction
  for specifying cancelled handler and way to generate default() method
  name.
  
  Revision  ChangesPath
  1.29  +12 -6 jakarta-struts/doc/userGuide/release-notes.xml
  
  Index: release-notes.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/release-notes.xml,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- release-notes.xml 10 Aug 2003 02:53:09 -  1.28
  +++ release-notes.xml 13 Aug 2003 05:08:33 -  1.29
  @@ -175,13 +175,19 @@
   The following new features have been added to the basic controller
   framework [org.apache.struts.action]:
   
  -The ActionServlet now provides support for modular Struts applications and
  -sports several new extension points.
  -The new ActionMessages class will support a superset of
  -the capabilities of ActionErrors, and will be useful as
  -a collection of general purpose messages, not just errors.
  +  
  +  
  +
  +Actions Package Additions
  +The following new features have been added to the adapters between the
  +incoming HTTP request and the corresponding business logic
  +framework [org.apache.struts.actions]:
  +
  +  The DispatchAction now provides default cancel handler that can be 
overridden.
  +  It also also possible to specify the default handler name.
  +  The LookupDispatchAction now provides default cancel handler that can be 
overridden.
  +  It also also possible to specify the default handler name.
   
  -
   
   Util Package Additions
   The following new features have been added to the utility classes
  
  
  

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

DO NOT REPLY [Bug 22219] -

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=22219



As I suggested, if you post your code to the Struts user list it will be easier
to try to get to the root of the problem. To subscribe to the mailing list send
an email to [EMAIL PROTECTED] If, after seeking help on
the user list, it does turn out to be a bug in Struts then that would be the
time to reopen the bug report.

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

cvs commit: jakarta-struts LICENSE.txt

rleland 2003/08/11 22:28:07

  Modified:.LICENSE.txt
  Log:
  Remove CVS/RCS tags they give check style a headache, ecause exceptions.
  Also Apache License wording 'Apache Group' should be Apache Software Foundation.
  under 1.1 License.
  
  Revision  ChangesPath
  1.2   +4 -9  jakarta-struts/LICENSE.txt
  
  Index: LICENSE.txt
  ===
  RCS file: /home/cvs/jakarta-struts/LICENSE.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LICENSE.txt   8 Aug 2003 06:00:55 -   1.1
  +++ LICENSE.txt   12 Aug 2003 05:28:07 -  1.2
  @@ -1,9 +1,4 @@
  -/*
  - * $Header$
  - * $Revision$
  - * $Date$
  - *
  - * 
  +/* 
*
* The Apache Software License, Version 1.1
*
  @@ -22,8 +17,8 @@
*the documentation and/or other materials provided with the
*distribution.
*
  - * 3. The end-user documentation included with the redistribution, if
  - *any, must include the following acknowlegement:
  + * 3. The end-user documentation included with the redistribution,
  + *if any, must include the following acknowlegement:
*   "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
  @@ -36,7 +31,7 @@
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
  - *permission of the Apache Group.
  + *permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  
  
  

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

Struts Composable Request Process (was RE: ActionForwards, et al)

2003-08-14 Thread PILGRIM, Peter, FM

> -Original Message-
> From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED]

--//--

> 
> Craig R. McClanahan wrote:
> > On Tue, 12 Aug 2003, Peter A. Pilgrim wrote:
> > 
> > 
> >>So we could have convenience methods such as
> >>
> >>StrutsWebContext  scontext = (StrutsWebContext)context;
> >>// Where ``StrutsWebContext'' is a type of ``ServletWebContext''
> >>
> >>ActionForm form = scontext.getActionForm();
> >>ActionMapping mapping = scontext.getActionMapping();
> > 
> > 
> > If we're talking about a Struts2 world (where we're willing 
> to reconsider
> > the calling sequence of an Action anyway), wouldn't it be 
> better to make
> > StrutsWebContext just extend WebContext instead of 
> ServletWebContext?
> > That way we could have transparent support for servlets and 
> portlets.
> > 
> So instead you would make convenience method from WebContext instead
> I see the `WebContext.getRequestScope()' returns a mutable map of
> attribute values. In other words they are derived from
> `ServletRequest.getAttributeNames()'.
> 
> But looking at the current Struts 1.1 library would you for 
> compatibility
> reason also supply the `HttpServletRequest' object to Struts users?
> 
> HttpServletRequest  = StrutsWebContext.getRequest(); // 
> convenience method
> 
> and like wise `HttpServletResponse' object?
> 
> > 
> >>>Another import idea is that, if we wanted, we could also 
> add other other
> >>>convenience methods to the context without breaking the signature.
> >>>
> >>
> My question above.
> 
> >>And presumably we [as application developer] will be able 
> to subclass
> >>the ServletWebContext and add application features like 
> Single Sign-On
> >>/ Security / personalisation etcetera. We will be able to configure
> >>Struts Module to use our custom `Context' instead of the Struts
> >>default context.
> >>
> >>Yep this is looking sexy.
> >>
> >>
> > 
> > 
> > Yep ... lots of interesting room for playing around here.  
> To say nothing
> > of the fact that you can compose your own request processor 
> pipeline to
> > boot.
> > 
> 
> Moving swiftly back to the original design reason. The [old] 
> request processor
> is now effectively a `Chain' isn't it?
> 
> ( ... I will now continue this note at work )
> 
> -- 
> Peter Pilgrim
> __ _ _ _
>/ //__  // ___// ___/   +  Serverside Java
>   / /___/ // /__ / /__ +  Struts
>  / // ___// ___// ___/ +  Expresso Committer
>   __/ // /__ / /__ / /__   +  Independent Contractor
>  /___///////   +  Intrinsic Motivation
> On Line Resume
> ||
> \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
> 

In the excitment I got caught up the discussion about customised 
action forward, whereas the original design intention got chucked
to the side, namely a ``composable request processor''. So let
me spend some time discussing this:

Now I am at work. I said `RequestProcessor' currently could be
rewritten as a `Chain', because it aggregates a many `Command's.
But I am wondering about that statement. It would be seem
to me `RequestProcessor' is a very complex `Command' 

Going back to the original "Decomposable request Processor" thread
there were at least two concerns:

1) How delegate or nest processors so that they do the right thing.

2) Deciding which methods of the current processor should be decomposed.

3) Configuring the chain of processor from XML.

Delegation: I believe would be like Servlet Filters as they are implemented
now. If we have servlet filters A and B , then we know that if filter A 
chained to filter B. The final effect is not necessarily equal to B 
followed A.

Methods: In the current request processor there is one method
`process()' which has a default implementation:

   public void process(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException

This method calls other ``process*'' methods.

processLocale(request, response);

...

processPreprocess(request, response);

ActionMapping mapping = processMapping(request, response, path);

...

ActionForm form = processActionForm(request, response, mapping);
processPopulate(request, response, form, mapping);

...

Action action = processActionCreate(request, response, mapping);

...
ActionForward forward =
processActionPerform(request, response,
 action, form, mapping);

My question is if we make `RequestProcessor' a common-chain `Command'
then do then in turn make it call other `Command' in order to emulate
all the `process*()' calls. For example

// RequestProcessor implemented as complex `Command'
// Assuming we get a web context from somewhere, 
StrutWebContext sc = ... ; 

processPreprocessCommand.execute( sc );

...

ActionForm form = (Action)

DO NOT REPLY [Bug 22373] - Enhancement of default DefinitionsFactory

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=22373

Enhancement of default DefinitionsFactory





--- Additional Comments From [EMAIL PROTECTED]  2003-08-13 09:05 ---
Created an attachment (id=7790)
should replace att-nr. 7785, I forgot to change package, line 71ff

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

cvs commit: jakarta-struts/src/share/org/apache/struts/actions MappingDispatchAction.java LocalStrings.properties

2003-08-14 Thread sraeburn

sraeburn2003/08/11 20:26:53

  Modified:src/share/org/apache/struts/actions LocalStrings.properties
  Added:   src/share/org/apache/struts/actions
MappingDispatchAction.java
  Log:
  Addition of MappingDispatchAction that dispatches to a method named by the 
ActionMapping parameter
  
  PR:   17117 Suggested by Anthony Kay
  
  Revision  ChangesPath
  1.7   +2 -0  
jakarta-struts/src/share/org/apache/struts/actions/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/actions/LocalStrings.properties,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- LocalStrings.properties   3 Jul 2003 03:14:14 -   1.6
  +++ LocalStrings.properties   12 Aug 2003 03:26:53 -  1.7
  @@ -10,3 +10,5 @@
   include.rd=Cannot create request dispatcher for path {0}
   switch.prefix=Invalid module prefix {0} was specified
   switch.required=Switch requires both 'prefix' and 'page' request parameters
  +success.required=SuccessAction could not find an ActionForward named 'success' for 
path '{0}'
  +mapping.parameter=ActionMapping[{0}] does not define a 'parameter' attribute
  \ No newline at end of file
  
  
  
  1.1  
jakarta-struts/src/share/org/apache/struts/actions/MappingDispatchAction.java
  
  Index: MappingDispatchAction.java
  ===
  /*
   * $Header$
   * $Revision$
   * $Date$
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999-2003 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Struts", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   */
  
  package org.apache.struts.actions;
  
  import javax.servlet.ServletException;
  import javax.servlet.http.HttpServletRequest;
  import javax.servlet.http.HttpServletResponse;
  
  import org.apache.commons.logging.Log;
  import org.apache.commons.logging.LogFactory;
  import org.apache.struts.action.ActionForm;
  import org.apache.struts.action.ActionForward;
  import org.apache.struts.action.ActionMapping;
  
  /**
   * An abstract Action that dispatches to a public
   * method that is named by the parameter attribute of 
   * the corresponding ActionMapping.  This is useful for developers who prefer
   * to combine man

Re: Wildcard-matched actions (again)

2003-08-14 Thread mrdon

You still wouldn't see any performance hit as since you aren't using any
action mappings with wildcards, there would be no pattern matching.  It
can only match a URI against a compiled pattern if one or more action
mappings use wildcards.  If there are no compiled patterns, the method
will simply exit and your default action will be matched.

Now, this also would be a good example of an app that could use wildcards.
 You could match the id's and stick them in the parameter of the action
mapping to retrieve in the action.  I currently use wildcards in my Struts
app that exposes REST-style web services where everything is encoded in
the URI.  The wildcard matching code is very fast as the patterns are
pre-compiled and since the code comes stright from Cocoon who has been
using it for quite a while, it has stood the test of time.

Don

> Well, it indeed looks pretty unlikely at first glance. Still, we are
> doing exactly this...
>
> We have built a Content Managment System (it's called XIST4C) that is
> based on Struts. Each normal content page (i. e. each page that is not
> part of an application integrated in the system) is served by a single
> action called DisplayAction, which is the default action. The different
> content pages are distinguished by ids. In order to be as search engine
> friendly as possible, we are encoding these ids in the url instead of
> appending them as query parameters.
>
> Thus, a typical url looks like this:
>  http://www.medi.de/llcms/web/displayAction_id_1586_.htm
>
> I would like to be able to turn off this pattern matching feature, as
> performance is a very critical issue for a CMS.
>
> --- Matthias
>
>
> -
> 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: [OT] Re: ActionForwards, et al (was SuccessAction)

2003-08-14 Thread Micael

Hi, Peter,

Yah, there are some that don't like free knowledge or listening.  So there 
was no way to not offend some people.  I appreciate that.  Why I don't 
know, and I don't need to know.  But, I have a watch.  LOL.

Micael

At 12:50 AM 8/13/2003 +0100, Peter A. Pilgrim wrote:
Micael wrote:
Sigh!  I cannot stand bad grammar, so once again I must remind my nerd
+++
friends that "et al" strictly applies to people, and that an
  ~~~  ^   ^
ActionForward, while dear to my heart, is just not a person.  LOL!  I
* && ew%&U(R&**
hope you take this as interesting and new knowledge and not as a pain in 
the patoosh.  Bye 'd bye!
  ~~~

Time you had a watch
--
PP
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


LEGAL NOTICE

This electronic mail  transmission and any accompanying documents contain 
information belonging to the sender which may be confidential and legally 
privileged.  This information is intended only for the use of the 
individual or entity to whom this electronic mail transmission was sent as 
indicated above. If you are not the intended recipient, any disclosure, 
copying, distribution, or action taken in reliance on the contents of the 
information contained in this transmission is strictly prohibited.  If you 
have received this transmission in error, please delete the message.  Thank 
you  



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

DO NOT REPLY [Bug 22343] - In J2SDK 1.5.0 (Tiger) enum is a keyword

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=22343

In J2SDK 1.5.0 (Tiger) enum is a keyword

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 15:06 ---
Fixed in 20030813 nightly build.

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

DO NOT REPLY [Bug 22373] - Enhancement of default DefinitionsFactory

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=22373

Enhancement of default DefinitionsFactory





--- Additional Comments From [EMAIL PROTECTED]  2003-08-13 06:42 ---
Sorry, was my first commit here.
I found the place to add the files  8-D

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

DO NOT REPLY [Bug 22382] New: - bean:size and logic:iterate throws JSPException if collection is null

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=22382

bean:size and logic:iterate throws JSPException if collection is null

   Summary: bean:size and logic:iterate throws JSPException if
collection is null
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


bean:size throws JSPException if tested collection is null. It forces using 
logic:present before. 

Is it not simpler, to return size equal to 0 if tested collection does not exist? 

The same concept could be used for logic:iterate.

It is generally correct, that contract between JSP and backand is "no bean, no
result". Such contract saves some memory. But if external library returns
Colelction you must explicite check if it is empty or not, means overhead for
any such case. 

Proposed extension simplifies development and secure application against methods
returning sometimes null and sometimes empty collection.

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

RE: Wildcard-matched actions (again)

2003-08-14 Thread Deadman, Hal

Doesn't the last email from Don imply there is no penalty (if the person
isn't using wildcards)?

-- extract from Don's last email
You still wouldn't see any performance hit as since you aren't using any
action mappings with wildcards, there would be no pattern matching.  It can
only match a URI against a compiled pattern if one or more action mappings
use wildcards.  If there are no compiled patterns, the method will simply
exit and your default action will be matched.

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 12, 2003 3:39 PM
To: Struts Developers List
Subject: Re: Wildcard-matched actions (again)

--- Robert Leland <[EMAIL PROTECTED]> wrote:
> Matthias Bauer wrote:
> 
> >
> > I would like to be able to turn off this pattern matching feature, as 
> > performance is a very critical issue for a CMS. 
> 
> +1

So far I haven't heard any definitive answer to the performance question. 
If there isn't any performance penalty then we don't need the ability to
turn off pattern matching.  I'm starting to think this enhancement should
wait for 1.2.1 instead of trying to squeeze it in for 1.2.0.

David

> 
> >
> >
> > --- Matthias
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> 
> 
> -- 
> Robert Leland [EMAIL PROTECTED]
> --
> Java, J2EE, Struts, Web Application Development
> 
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
> 
> 
> 
> -
> 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]

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

DO NOT REPLY [Bug 21408] - html:errors in redirect mode

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=21408

html:errors in redirect mode





--- Additional Comments From [EMAIL PROTECTED]  2003-08-13 16:31 ---
oops, our proposal in http://issues.apache.org/bugzilla/show_bug.cgi?id=21409
covers this too - sorry!

Radek, you may want to attach your version the you did here as well because it
seems (didn't test it yet) that it does the same as our custom tag.

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

Re: [Vote ?] deprecate ActionErrors

David Graham wrote:

--- Robert Leland <[EMAIL PROTECTED]> wrote:
 

I believe at one time we were going to deprecate ActionErrors since it
is really a shell over ActionMessages. We could still keep the
error tag, just make it use ActionMessages directly.
   

It would be nice to get rid of it but I don't think we can until 2.0. 
ActionForm.validate() (and other methods) return an ActionErrors object. 
There is no way to deprecate those methods with a new version that returns
ActionMessages because return types aren't part of method signatures.  I
think this would break backwards compatibility but I would love to be
wrong on this one :-).

You're right. We could provide a stop gap ActionForm.validateToMsg() or 
whatever that returns a
list of ActionMessages objects. We could then get rid of ActionError 
internally by making it a facade
of ActionMessage instead of extending ActionMessage. The same goes for 
ActionErrors, it would only be a facade.
and only created when needed.

Also, ActionError should be deprecated with ActionErrors because it's just
a useless subclass of ActionMessage.
David

 

[ ] +1 Yes deprecate ActionErrors
[ ]  0  Yes, but you'll have to face the angry crowds yourself.
[ ] -1 No, and here is why.
-Rob



--
Robert Leland   [EMAIL PROTECTED]
--
Java, J2EE, Struts, Web Application Development
804 N. Kenmore Street   +01-703-525-3580
Arlington VA 22201

Re: Wildcard-matched actions (again)

2003-08-14 Thread Matthias Bauer



I haven't actually look at the code yet, but as I understand it, wildcards
are not even considered unless no other match is found. In which case you
would be getting an error page anyway.
   

If that's the way it actually works (and I believe this was the original
proposal), I'm ok with it -- the only potential performance impact for
existing users would be those who rely on the "default action" capability
to handle lots of requests, and that seems pretty unlikely.
Well, it indeed looks pretty unlikely at first glance. Still, we are 
doing exactly this...

We have built a Content Managment System (it's called XIST4C) that is 
based on Struts. Each normal content page (i. e. each page that is not 
part of an application integrated in the system) is served by a single 
action called DisplayAction, which is the default action. The different 
content pages are distinguished by ids. In order to be as search engine 
friendly as possible, we are encoding these ids in the url instead of 
appending them as query parameters.

Thus, a typical url looks like this: 
http://www.medi.de/llcms/web/displayAction_id_1586_.htm

I would like to be able to turn off this pattern matching feature, as 
performance is a very critical issue for a CMS.

--- Matthias

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

Simplifying DynaActionForms

Here's a snippet from my typical Action.execute() that deals with
DynaActionForms:

DynaActionForm dynaForm = (DynaActionForm)form;
String userName = (String) dynaForm.get("userName");
// do something with userName...

Casting to String gets to be quite painful with many form properties. 
Unless I've forgotten/missed an easier way of dealing with
DynaActionForms, I propose we add a DynaActionForm.getAsString(String)
method that does this casting for us.

Thoughts?

David

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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

Re: [Vote ?] deprecate ActionErrors

--- Robert Leland <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> 
> >--- Robert Leland <[EMAIL PROTECTED]> wrote:
> >  
> >
> >>I believe at one time we were going to deprecate ActionErrors since it
> >>is really a shell over ActionMessages. We could still keep the
> >>error tag, just make it use ActionMessages directly.
> >>
> >>
> >>
> >
> >It would be nice to get rid of it but I don't think we can until 2.0. 
> >ActionForm.validate() (and other methods) return an ActionErrors
> object. 
> >There is no way to deprecate those methods with a new version that
> returns
> >ActionMessages because return types aren't part of method signatures. 
> I
> >think this would break backwards compatibility but I would love to be
> >wrong on this one :-).
> >
> You're right. We could provide a stop gap ActionForm.validateToMsg() or 
> whatever that returns a
> list of ActionMessages objects. We could then get rid of ActionError 
> internally by making it a facade
> of ActionMessage instead of extending ActionMessage. The same goes for 
> ActionErrors, it would only be a facade.
> and only created when needed.

This seems overly complicated.  Why not just wait for 2.0 to remove this
and replace it with commons-resources classes?  At least, that's what I
think we were planning.

I think deprecating ActionError is ok because ActionErrors can hold
ActionMessage objects instead.

David

> 
> >
> >Also, ActionError should be deprecated with ActionErrors because it's
> just
> >a useless subclass of ActionMessage.
> >
> >David
> >
> >  
> >
> >>[ ] +1 Yes deprecate ActionErrors
> >>[ ]  0  Yes, but you'll have to face the angry crowds yourself.
> >>[ ] -1 No, and here is why.
> >>
> >>-Rob
> >>
> 
> 
> -- 
> Robert Leland [EMAIL PROTECTED]
> --
> Java, J2EE, Struts, Web Application Development
> 
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
> 
> 


__
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]

DO NOT REPLY [Bug 22351] New: - "Cannot find bean * in scope null" ==> increase robustness

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=22351

"Cannot find bean * in scope null"  ==> increase robustness

   Summary: "Cannot find bean * in scope null"  ==> increase
robustness
   Product: Struts
   Version: 1.0 Final
  Platform: Other
   URL: http://yourhost.com/application/userprofile_en.jsp;jsess
ionid=A0E8C047090D4714AC35DE8567
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When somebody is tampering with the session ID, sometimes, I get
<>
I would rather be able to pageContext.forward("/index.jsp");

Struts should be more robust here?

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

RE: Decomposing RequestProcessor -- Some Code To Play With

2003-08-14 Thread Tom Drake

Forgive me if this has already been brought up, but 
jakarta-commons/sandbox/chain appears to have significant conceptual 
overlap with commons/sandbox/functor. (Command := UnaryPredicate)

Any thoughts about merging these concepts?

Tom 

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 10, 2003 10:24 PM
To: [EMAIL PROTECTED]
Subject: Decomposing RequestProcessor -- Some Code To Play With


During the "Decomposing RequestProcessor" thread a while back, I hinted
that I'd been working on some code to propose for this purpose, but had
never had time to polish it enough to check in.  Well, I actually took a
bunch of time this weekend for precisely that purpose, and have checked in
two chunks of code for your viewing and toying pleasure:

* A new jakarta-commons/sandbox package called "chain" that implements
  the GoF Chain of Responsibility pattern, in a way that lets you compose
  arbitrarily complex processing chains out of very simple classes,
  in a variety of different contexts.  If you're familiar with Cocoon,
  think of the "site map" pattern but without the requirement that every
  dynamic step be an XSLT transformation.  If you're familiar with Axis,
  think of the way you can compose Handler chains, but without the
  restriction that it is only useful in implementing a web service.
  Nightly builds of this package should start showing up tonight at:

  http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-chain/

* A new contrib package in the Struts workspace called "struts-chain"
  that is the beginnings of a decomposition of the RequestProcessor
  processing pipeline, but allows the overall chain to be customzied in
  much more powerful manners than the way that subclassing
  RequestProcessor supports.  You'll need to grab the CVS source to
  play with this one.  None of the code actually works yet -- it is very
  definitely a work in progress -- but I *think* we'll be able to end up
  with something that can be added on to a Struts 1.1 distro.

I won't personally have huge amounts of time to work on this over the next
few months, but I will definitely participate in discussions and
improvements to this code.  If it all works out, I'm going to propose
something like this as a foundational architecture for a Struts 2.x series
that will leverage this design pattern to support extreme customization.

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: [OT] Re: ActionForwards, et al (was SuccessAction)

2003-08-14 Thread Peter A. Pilgrim

Micael wrote:
Sigh!  I cannot stand bad grammar, so once again I must remind my nerd 
+++
friends that "et al" strictly applies to people, and that an 
  ~~~  ^   ^
ActionForward, while dear to my heart, is just not a person.  LOL!  I 
* && ew%&U(R&**
hope you take this as interesting and new knowledge and not as a pain in 
the patoosh.  Bye 'd bye!
  ~~~

Time you had a watch
--
PP
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ActionForwards, et al (was SuccessAction)

On Tue, 12 Aug 2003, Peter A. Pilgrim wrote:

>
> So we could have convenience methods such as
>
> StrutsWebContext  scontext = (StrutsWebContext)context;
> // Where ``StrutsWebContext'' is a type of ``ServletWebContext''
>
> ActionForm form = scontext.getActionForm();
> ActionMapping mapping = scontext.getActionMapping();

If we're talking about a Struts2 world (where we're willing to reconsider
the calling sequence of an Action anyway), wouldn't it be better to make
StrutsWebContext just extend WebContext instead of ServletWebContext?
That way we could have transparent support for servlets and portlets.

>
> >
> > Another import idea is that, if we wanted, we could also add other other
> > convenience methods to the context without breaking the signature.
> >
>
> And presumably we [as application developer] will be able to subclass
> the ServletWebContext and add application features like Single Sign-On
> / Security / personalisation etcetera. We will be able to configure
> Struts Module to use our custom `Context' instead of the Struts
> default context.
>
> Yep this is looking sexy.
>
>

Yep ... lots of interesting room for playing around here.  To say nothing
of the fact that you can compose your own request processor pipeline to
boot.

Craig

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

Re: Struts Composable Request Process (was RE: ActionForwards, etal)

On Wed, 13 Aug 2003, Greg Reddin wrote:

> Date: Wed, 13 Aug 2003 11:54:01 -0500
> From: Greg Reddin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Struts Composable Request Process (was RE: ActionForwards,
>  et al)
>
> > Not only "had in mind" but "already partly done".  There would no longer
> > be any direct calls to each "process" method -- instead, they would all be
> > commands in a chain that is preconfigured by Struts (and then optionally
> > specialized by the app developer).
>
> So is this already partialy implemented in a component that you haven't
> checked in yet?  I see the configuration file that outlines all the
> commands and I see the commands, but I don't see the piece that would be
> the equivalent to today's request processor -- the piece that will
> invoke the chain.
>
> Did I miss something?
>

No, you didn't miss anything ... that's why I said it was *partly* done
:-).

I was mainly trying to be sure that it was technically feasible to use
commos-chain for this kind of decomposition, and that seems to be the
case.  For actually implementing a 1.1-compatible layer, we'd need more
than just me working on the code.  But I wanted to share my initial
progress to see if it caught anyone else's interest.

> Greg

Craig

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

Re: Simplifying DynaActionForms

On Wed, 13 Aug 2003, David Graham wrote:

> Date: Wed, 13 Aug 2003 20:01:59 -0700 (PDT)
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Simplifying DynaActionForms
>
> --- Sgarlata Matt <[EMAIL PROTECTED]> wrote:
> > >> Casting to String gets to be quite painful with many form properties.
> >
> > >> Unless I've forgotten/missed an easier way of dealing with
> > >> DynaActionForms, I propose we add a
> > DynaActionForm.getAsString(String)
> > >> method that does this casting for us.
> >
> > This is a minor point, but how about DynaActionForm.getString(String)
> > instead?
>
> I like your name better :-).
>
> > This would be consistent with naming conventions in
> > java.sql.ResultSet (I can't think of other places with convenience
> > methods like this off the top of my head).  Also, following along in the
> >
> > java.sql.ResultSet thinking, would you also have getters for the other
> > wrappers around primitives and the Date and Calendar objects?  This
> > might just clutter the interface... I wouldn't ever personally use them
> > in my app because almost every form property is a String.
>
> Well, I thought we could start small with the String and take it from
> there.  My form properties are all Strings so that's why my suggestion was
> aimed in that direction.
>

If we go for this idea on DynaActionForm (I'm +0 on it at the moment), we
should provide accessors for String and boolean properties, but I'd
suggest we don't for any other types -- after all, Struts encourages you
not to use things like Date or Calendar for a form bean property :-).

Note that I'd be -1 on doing this sort of thing to the underlying DynaBean
interface itself.  Besides the fact that this would break current
implementations (since DynaBean is an interface), I don't want to see a
very simple API like DynaBean turn into a mass of methods like ResultSet.

Also, if we were to add getString() and getBoolean(), we should also add
setString() and setBoolean() for the same reasons.

> David

Craig

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

Re: Simplifying DynaActionForms

2003-08-14 Thread Kris Schneider

String value = BeanUtils.getProperty(form, "propName");

No casting and it works for *any* form, meaning that your Action code is
independent of your choice of form implementation ("vanilla" or dyna). So, FWIW,
even if you added the method, I personally wouldn't use it. I even find using
PropertyUtils preferable:

String value = (String)PropertyUtils.getProperty(form, "propName");

It's more important to me to abstract the type of the form than the type of the
property.

Quoting Sgarlata Matt <[EMAIL PROTECTED]>:

> >> Casting to String gets to be quite painful with many form properties. 
> >> Unless I've forgotten/missed an easier way of dealing with
> >> DynaActionForms, I propose we add a DynaActionForm.getAsString(String)
> >> method that does this casting for us.
> 
> This is a minor point, but how about DynaActionForm.getString(String) 
> instead?  This would be consistent with naming conventions in 
> java.sql.ResultSet (I can't think of other places with convenience 
> methods like this off the top of my head).  Also, following along in the 
> java.sql.ResultSet thinking, would you also have getters for the other 
> wrappers around primitives and the Date and Calendar objects?  This 
> might just clutter the interface... I wouldn't ever personally use them 
> in my app because almost every form property is a String.
> 
> Matt
> 
> >>
> >> Thoughts?
> >>
> >> David

-- 
Kris Schneider 
D.O.Tech   

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

cvs commit: jakarta-struts/doc volunteers.xml

rleland 2003/08/13 10:36:57

  Modified:doc  volunteers.xml
  Log:
  Add  Leonardo Quijano as Contributor.
  
  Revision  ChangesPath
  1.28  +5 -3  jakarta-struts/doc/volunteers.xml
  
  Index: volunteers.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/volunteers.xml,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- volunteers.xml10 Aug 2003 02:07:34 -  1.27
  +++ volunteers.xml13 Aug 2003 17:36:56 -  1.28
  @@ -42,7 +42,7 @@
   
   
   
  -More than forty developers have contributed code or documentation to Struts.
  +More than fifty developers have contributed code or documentation to Struts.
   We've tried to list all of our volunteers on this page (and apologize to 
anyone we missed!).
   
   
  @@ -147,7 +147,9 @@
   
   Steve Raeburn
   
  -
  +
  +Leonardo Quijano
  +
   
   
   
  @@ -703,7 +705,7 @@
   
   
   
  -To date I have mainly served to pitch in with odds and ends.  
  +To date I have mainly served to pitch in where needed.  
   I continue to amazed at the Struts committers' generous contributions of time, 
   insight, and good will. I feel fortunate to part of the struts team. 
   
  
  
  

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

Re: Simplifying DynaActionForms

--- Kris Schneider <[EMAIL PROTECTED]> wrote:
> String value = BeanUtils.getProperty(form, "propName");
> 
> No casting and it works for *any* form, meaning that your Action code is
> independent of your choice of form implementation ("vanilla" or dyna).

Good point but I think it's still a bit verbose for certain use cases. 
dynaForm.getString("propName") is tidier and allows for easier to read
nested calls like this:

service.doSomeService(dynaForm.getString("propName"))

instead of:

service.doSomeService(BeanUtils.getProperty(form, "propName"))

which could get quite long if you're passing several properties.

David

> So, FWIW,
> even if you added the method, I personally wouldn't use it. I even find
> using
> PropertyUtils preferable:
> 
> String value = (String)PropertyUtils.getProperty(form, "propName");
> 
> It's more important to me to abstract the type of the form than the type
> of the
> property.
> 
> Quoting Sgarlata Matt <[EMAIL PROTECTED]>:
> 
> > >> Casting to String gets to be quite painful with many form
> properties. 
> > >> Unless I've forgotten/missed an easier way of dealing with
> > >> DynaActionForms, I propose we add a
> DynaActionForm.getAsString(String)
> > >> method that does this casting for us.
> > 
> > This is a minor point, but how about DynaActionForm.getString(String) 
> > instead?  This would be consistent with naming conventions in 
> > java.sql.ResultSet (I can't think of other places with convenience 
> > methods like this off the top of my head).  Also, following along in
> the 
> > java.sql.ResultSet thinking, would you also have getters for the other
> 
> > wrappers around primitives and the Date and Calendar objects?  This 
> > might just clutter the interface... I wouldn't ever personally use
> them 
> > in my app because almost every form property is a String.
> > 
> > Matt
> > 
> > >>
> > >> Thoughts?
> > >>
> > >> David
> 
> -- 
> Kris Schneider 
> D.O.Tech   
> 
> -
> 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: Struts for Portlets

2003-08-14 Thread BaTien Duong

Greetings:

I am very interested in this discussion, and will have more time to
think of the overall structure after the release of JSR-168 Reference
Implementation (Pluto).

At a cursory level, i see Struts provides very simple and elegant flow
controllers of what-to-do and how-to-do based on standard Servlet
container. Tiles is an elegant dynamic templating engine, also based on
standard Servlet container. I see JSP tiles as a plus rather than a
short-coming since J2EE has JSP as its dynamic page assembling. JSR-168
portal/portlet containers are official extension of Servlet container.
It seems not a very major issue to make Struts and tiles a 1-2 punch for
JSR-168 portal/portlet containers. Tiles context may be refactored into
Portlet context. Tiles already has a facility to dynamically generate
tile attributes for changing the page assembling. This is probably what
the JSR-168 authors mention that "Portlet can act as controller, fill a
bean with data, and include a JSP to render the output". See this pattern?

The effort is valuable, since many Struts Plug-ins can be parts of our
tools. I see Jetspeed is too heavy, not simple and elegant enough to
realize the potential of JSR-168 and WSRP. We can learn many designs
from Jetspeed to bring them into this new portal/portlet framework with
simple and elegant design infrastructure. I hope many designers and
developers interested in this relevant topic:
Struts-Tiles-Portal-Portlet framework and container.

BaTien
DBGROUPS
Mete Kural wrote:

Hello Struts developers,

I wanted to get your opinions on how Struts should be used as a portlet framework. I think that it would be great if a portlet framework was part of the standard Struts distribution in the near future. JSR-168 which defines standard portlets will be finalized pretty soon (a month?), although the specification draft is pretty much stable hereafter.

I have two main questions:

1) My first question is technical. How do you think portlet support would be best added to Struts? Which classes should be extended? Are there necessary changes at the core classes of Struts in order to provide an efficient framework for building portlets?

2) Second question is about how a Struts-based or Struts-like portlet framework should be distributed. Should it be part of the core Struts distribution? Should there be two different Struts distributions within the Struts project: "Struts for Webapps" and "Struts for Portlets"? Or should it be a seperate Jakarta project?

I look forward to hearing your opinions.

Thank you very much.
Mete
-
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 for Portlets (requesting your opinions)

2003-08-14 Thread Mete Kural

>Agree. I just read Craig "ideal view" and I think this view may be a 
>good start.

I think so too. I will re-state Craig's "ideal goal" below for others to catch up:

"I believe that we should aim for the following ideal state -- a Struts application 
shoud be usable either as a webapp or as a portlet, with little (ideally no) changes.  
Therefore, I believe that we'd build whatever it takes to support this into the 
standard Struts distribution, which would then be used in both environments."

I would like to ask everybody what their opinions are about this topic. Is it 
technically possible for Struts to enable the same application to be turned into a 
webapp or a portlet at the switch of a button? Could the fundamental differences 
between a webapp and a portlet not allow such a possibility?

Mete

-- Original Message --
From: BaTien Duong <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
Date:  Wed, 13 Aug 2003 12:24:47 -0600

>Agree. I just read Craig "ideal view" and I think this view may be a 
>good start.
>
>BaTien
>DBGROUPS
>
>Mete Kural wrote:
>
>>>Struts-Tiles-Portal-Portlet framework and container.
>>>
>>>
>>
>>I think that there is a big difference between the framework used to build a portal 
>>server and a "portlet framework". I see that Struts+Tiles is a very good framework 
>>to build a portal server, but it seems to me that the ways in which Struts would be 
>>used as a framework for building a portal server are very different than Struts 
>>being used as a "portlet framework".
>>
>>IMHO, Struts developers should focus on making Struts an efficient portlet 
>>framework. Portal server developers could tweak Struts in their own ways in order to 
>>use it as a framework for building their portal server, but I don't see the need for 
>>standardization in this area. Standardization is rather necessary in the are of 
>>using Struts as a portlet framework.
>>
>>What are your opinions?
>>
>>-Mete
>>
>>-- Original Message --
>>From: BaTien Duong <[EMAIL PROTECTED]>
>>Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
>>Date:  Wed, 13 Aug 2003 11:02:44 -0600
>>
>>  
>>
>>>Greetings:
>>>
>>>I am very interested in this discussion, and will have more time to 
>>>think of the overall structure after the release of JSR-168 Reference 
>>>Implementation (Pluto).
>>>
>>>At a cursory level, i see Struts provides very simple and elegant flow 
>>>controllers of what-to-do and how-to-do based on standard Servlet 
>>>container. Tiles is an elegant dynamic templating engine, also based on 
>>>standard Servlet container. I see JSP tiles as a plus rather than a 
>>>short-coming since J2EE has JSP as its dynamic page assembling.  JSR-168 
>>>portal/portlet containers are official extension of Servlet container. 
>>>It seems not a very major issue to make Struts and tiles a 1-2 punch for 
>>>JSR-168 portal/portlet containers. Tiles context may be refactored into 
>>>Portlet context. Tiles already has a facility to dynamically generate 
>>>tile attributes for changing the page assembling. This is probably what 
>>>the JSR-168 authors mention that "Portlet can act as controller, fill a 
>>>bean with data, and include a JSP to render the output". See this pattern?
>>>
>>>The effort is valuable, since many Struts Plug-ins can be parts of our 
>>>tools. I see Jetspeed is too heavy, not simple and elegant enough to 
>>>realize the potential of JSR-168 and WSRP. We can learn many designs 
>>>
>>>
>>>from Jetspeed to bring them into this new portal/portlet framework with 
>>  
>>
>>>simple and elegant design infrastructure. I hope many designers and 
>>>developers interested in this relevant topic: 
>>>Struts-Tiles-Portal-Portlet framework and container.
>>>
>>>BaTien
>>>DBGROUPS
>>>
>>>Mete Kural wrote:
>>>
>>>
>>>
Hello Struts developers,

I wanted to get your opinions on how Struts should be used as a portlet framework. 
I think that it would be great if a portlet framework was part of the standard 
Struts distribution in the near future. JSR-168 which defines standard portlets 
will be finalized pretty soon (a month?), although the specification draft is 
pretty much stable hereafter.

I have two main questions:

1) My first question is technical. How do you think portlet support would be best 
added to Struts? Which classes should be extended? Are there necessary changes at 
the core classes of Struts in order to provide an efficient framework for building 
portlets?

2) Second question is about how a Struts-based or Struts-like portlet framework 
should be distributed. Should it be part of the core Struts distribution? Should 
there be two different Struts distributions within the Struts project: "Struts for 
Webapps" and "Struts for Portlets"? Or should it be a seperate Jakarta project?

I look forward to hearing

DO NOT REPLY [Bug 21408] - html:errors in redirect mode

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=21408

html:errors in redirect mode





--- Additional Comments From [EMAIL PROTECTED]  2003-08-14 08:18 ---
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22406 is a related problem
when valid form field content is lost due to an error in another form field.

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

RE: Decomposing RequestProcessor -- Some Code To Play With

2003-08-14 Thread Tom Drake

I've condensed the UnaryPredicate interface here. It provides both a boolean
return and a context parameter.

package org.apache.commons.functor;

public interface UnaryPredicate {
boolean test(Object obj);

}

Granted the method name doesn't seem to represent the intent of the Command
interface. How

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 7:57 PM
To: Struts Developers List
Subject: RE: Decomposing RequestProcessor -- Some Code To Play With

On Wed, 13 Aug 2003, Tom Drake wrote:

> Date: Wed, 13 Aug 2003 16:38:51 -0700
> From: Tom Drake <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Decomposing RequestProcessor -- Some Code To Play With
>
> Forgive me if this has already been brought up, but
> jakarta-commons/sandbox/chain appears to have significant conceptual
> overlap with commons/sandbox/functor. (Command := UnaryPredicate)
>
> Any thoughts about merging these concepts?
>
> Tom
>

Functors (at least the way Rodney did them in the functor package) are
different in two very significant ways:

* They have a return type of void, so you can't
  use the return value as a flag that the chain
  has been completed.

* They don't pass a context around, so you have
  to define some other mechanism to gain access
  to the state information that your command
  operates on.

I didn't like either of those two restrictions, so I don't know how much
you could really combine the two approaches.

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]

ActionForms recycling - why?

2003-08-14 Thread Radek Wisniewski

Could somebody explain, why we actually need ActionForms recycling?

I see one cause: it is "probably" quicker as instantiation of new one.

But i see some drawbacks:

1) To use it properly, you must implement reset() method. But using 
reset() method is error prone, you can easy add new property without 
adding resetting of this one.

2) If you reset all properties, you can not use such ActionForm for 
collecting data among more HTML Forms - it is not easy to undestand for 
new users, for me it's like a trap in this whole design.

3) Sometimes you need prepare (set) some values. The best choice is to 
put such code in logic tier - Action befor forwarding to view. But in 
this case reset() may delete those values if you use redirections.

4) Struts code without recycling could be easier.

5) I spouse, reset() is in most cases not very much quicker as making 
new instance. In any case, instantiatation of new form occurs relative 
seldom.

I think, we schould remove recycling of ActionForms and reset() schould 
be deprecated.

--
Radek Wisniewski


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

Re: Simplifying DynaActionForms

2003-08-14 Thread Sgarlata Matt

Casting to String gets to be quite painful with many form properties. 
Unless I've forgotten/missed an easier way of dealing with
DynaActionForms, I propose we add a DynaActionForm.getAsString(String)
method that does this casting for us.
This is a minor point, but how about DynaActionForm.getString(String) 
instead?  This would be consistent with naming conventions in 
java.sql.ResultSet (I can't think of other places with convenience 
methods like this off the top of my head).  Also, following along in the 
java.sql.ResultSet thinking, would you also have getters for the other 
wrappers around primitives and the Date and Calendar objects?  This 
might just clutter the interface... I wouldn't ever personally use them 
in my app because almost every form property is a String.

Matt

Thoughts?

David

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com




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


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

Re: Simplifying DynaActionForms

2003-08-14 Thread Vic Cekvenich

It is such a small change, and you have done so much for the community, 
I imagine that you should do as you would like.
.V

David Graham wrote:
Here's a snippet from my typical Action.execute() that deals with
DynaActionForms:
DynaActionForm dynaForm = (DynaActionForm)form;
String userName = (String) dynaForm.get("userName");
// do something with userName...
Casting to String gets to be quite painful with many form properties. 
Unless I've forgotten/missed an easier way of dealing with
DynaActionForms, I propose we add a DynaActionForm.getAsString(String)
method that does this casting for us.

Thoughts?

David

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


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

DO NOT REPLY [Bug 21408] - html:errors in redirect mode

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=21408

html:errors in redirect mode





--- Additional Comments From [EMAIL PROTECTED]  2003-08-14 07:17 ---
Created an attachment (id=7811)
TagUtils.patch by Radek

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

DO NOT REPLY [Bug 21613] - nested:error tag stopped displaying error messages (of certain scenario) when upgraded from Struts1.1 R1 to Final version

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=21613

nested:error tag stopped displaying error messages (of certain scenario) when upgraded 
from Struts1.1 R1 to Final version





--- Additional Comments From [EMAIL PROTECTED]  2003-08-14 21:34 ---
I ran into this same problem, and have a work-around that may be useful. I 
added two calls to setName() in NestedErrorsTag.doStartTag().

import org.apache.struts.Globals;
import org.apache.struts.taglib.html.ErrorsTag;
import org.apache.struts.taglib.nested.NestedNameSupport;
import org.apache.struts.taglib.nested.NestedPropertyHelper;

/**
 * NestedErrorsTag.
 * @author Arron Bates
 * @author David Winterfeldt
 * @since Struts 1.1
 * @version $Revision: 1.5 $ $Date: 2003/02/28 05:15:06 $
 */
public class NestedErrorsTag extends ErrorsTag implements NestedNameSupport {

  /**
   * Overriding method of the heart of the matter. Gets the relative property
   * and leaves the rest up to the original tag implementation. Sweet.
   * @return int JSP continuation directive.
   * This is in the hands of the super class.
   */
  public int doStartTag() throws JspException {
// get the original properties
originalName = getName();
originalProperty = getProperty();


// NestedPropertyHelper.setNestedProperties() will only adjust the property
// attribute to its nested value if the 'name' attribute either is null or
// Constants.BEAN_KEY. The causes a problem because the default value for
// 'name' in ErrorsTag is Globals.ERROR_KEY. Setting 'name' to
// Constants.BEAN_KEY...
setName(Constants.BEAN_KEY);

// request
HttpServletRequest request = (HttpServletRequest)pageContext.getRequest();
// set the properties
NestedPropertyHelper.setNestedProperties(request, this);

// Also, setNestedProperties() will set the 'name' attribute to the
// form bean, which will cause an exception below in super.doStartTag()
// when it tries to retrieve the action messages. Resetting 'name' to its
// original value...
setName(Globals.ERROR_KEY);

// let the super do it's thing
return super.doStartTag();
  }

... the rest of the class in unchanged.

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

DO NOT REPLY [Bug 22406] - how to keep valid form values in case of errors when doing redirect