Wished feature: multiple action instances into same session

[BERNARDO ANTONIO BUFFA]

Hi,

will the future of Struts/Shale consider the possibility to have more than
an instance of MyAction (or UseCase, or Dialog, ...) per session?

In my last project I need to edit Persons so I had an EditPersonAction.
EditPersonAction was usefull for Creation/Update Person Objects.
The problem was that Person has an mother, father, spouse properties.
I want to be able creating/editing the mother/father/spouse (m/f/s) of
every edited person using the same EditPersonAction, which uses
EditPersonForm.
But struts maintains only one EditPersonForm instance per session.
So I subclassed RequestProcessor who keeps many EditPersonForm instances
and restore the appropiate one into session based on a request parameter
(useCaseId).
Apologize my poor englisch.

Thanks in advance for you time.
Bernardo Antonio Buffa Colomé



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

Re: svn checkout

[Paul Sundling]

On that note, my patch for minor fixes to the docs including a mention
of current is still waiting for a once over. :) 

http://issues.apache.org/bugzilla/show_bug.cgi?id=33246

Paul Sundling

On Tue, 2005-02-01 at 19:29 -0500, James Mitchell wrote:
> You'd be better off using "current"
> 
> svn co http://svn.apache.org/repos/asf/struts/current
> 
> That gets you only "trunk" of each subproject.  Trust me, you'll quickly get 
> tired of typing an extra "../../" when you are flying around the repository 
> on the command line ;)
> 
> 
> 
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> - Original Message - 
> From: "Peter A. Pilgrim" <[EMAIL PROTECTED]>
> To: "Struts Developers List" 
> Sent: Tuesday, February 01, 2005 5:39 PM
> Subject: Re: svn checkout
> 
> 
> > Joe Germuska wrote:
> >> At 5:30 PM + 2/1/05, Pilgrim, Peter wrote:
> >>
> >>> Hi
> >>>
> >>> Are they any good online docs on using "svn" with Struts 1.3?
> >>> I tried very last night on my linux box:
> >>>
> >>> % svn checkout http://svn.apache.org/repos/asf/struts/trunk  struts
> >>>
> >>> But I must admit I didnt know what I was doing at all.
> >>> Do you have to ``svn login'' or whatever?
> >>
> >>
> >> For the read-only repository, you don't need to log in.
> >>
> >> The authoritative book on SVN is available for free online, and it's very 
> >> good:
> >> http://svnbook.red-bean.com/svnbook-1.1/index.html
> >>
> >> Joe
> >>
> >
> > fyi
> >
> > Yes I had a subversion problem!
> >
> > [EMAIL PROTECTED] [55] > svn checkout 
> > http://svn.apache.org/repos/asf/struts/core/trunk jakarta-struts
> > svn: Valid UTF-8 data
> > (hex:)
> > followed by invalid UTF-8 sequence
> > (hex: 80 0c 09 08)
> >
> > Strange i18n problems as reported by other people on the net and my 
> > machine. Weird!
> > I downgraded from svn 1.1.3 to 1.0.0 and everything works as expected.
> >
> > Anyway here is what I did
> >
> > % cd /my/favourite/workspace
> > % mkdirhier apache-struts
> > % cd apache-struts
> > % svn co http://svn.apache.org/repos/asf/struts/core/trunk  core
> > % svn co http://svn.apache.org/repos/asf/struts/el/trunk  el
> > % svn co http://svn.apache.org/repos/asf/struts/faces/trunk  faces
> > % svn co http://svn.apache.org/repos/asf/struts/sandbox/trunk  sandbox
> >
> > hth sb
> >
> > -- 
> > 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]
> >
> > 
> 
> 
> 
> -
> 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]

svn commit: r149510 - struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemorySubscription.java struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUser.java

[jmitchell]

Author: jmitchell
Date: Wed Feb  2 03:48:06 2005
New Revision: 149510

URL: http://svn.apache.org/viewcvs?view=rev&rev=149510
Log:
Add new User and Subscription for Memory implementation

Added:

struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemorySubscription.java
   (with props)

struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUser.java
   (with props)

Added: 
struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemorySubscription.java
URL: 
http://svn.apache.org/viewcvs/struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemorySubscription.java?view=auto&rev=149510
==
--- 
struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemorySubscription.java
 (added)
+++ 
struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemorySubscription.java
 Wed Feb  2 03:48:06 2005
@@ -0,0 +1,22 @@
+/*
+ * Created on Jan 31, 2005
+ * Author:jmitchell
+ *
+ */
+package org.apache.struts.apps.mailreader.dao.impl.memory;
+
+import org.apache.struts.apps.mailreader.dao.User;
+import org.apache.struts.apps.mailreader.dao.impl.AbstractSubscription;
+
+
+/**
+ * @author jmitchell
+ *
+ */
+public class MemorySubscription extends AbstractSubscription{
+
+public MemorySubscription(User user, String host) {
+super(user, host);
+}
+
+}

Propchange: 
struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemorySubscription.java
--
svn:executable = *

Added: 
struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUser.java
URL: 
http://svn.apache.org/viewcvs/struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUser.java?view=auto&rev=149510
==
--- 
struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUser.java
 (added)
+++ 
struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUser.java
 Wed Feb  2 03:48:06 2005
@@ -0,0 +1,37 @@
+/*
+ * $Id: MemoryUserDatabase.java 149093 2005-01-30 02:02:55Z jmitchell $ 
+ *
+ * Copyright 2000-2004 Apache Software Foundation
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.struts.apps.mailreader.dao.impl.memory;
+
+import org.apache.struts.apps.mailreader.dao.UserDatabase;
+import org.apache.struts.apps.mailreader.dao.impl.AbstractUser;
+
+
+/**
+ * Concrete implementation of [EMAIL PROTECTED] AbstractUser} used for an 
in-memory
+ * database backed by an XML data file.
+ *
+ * @version $Rev$
+ */
+public class MemoryUser extends AbstractUser{
+
+public MemoryUser(UserDatabase database, String username) {
+super(database, username);
+}
+
+}

Propchange: 
struts/apps/trunk/dao/src/java/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUser.java
--
svn:executable = *



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

svn commit: r149511 - in struts/core/trunk: build.properties.sample.lib doc/acquiring.xml doc/faqs/helping.xml doc/learning.xml doc/userGuide/building_controller.xml

[jmitchell]

Author: jmitchell
Date: Wed Feb  2 04:03:14 2005
New Revision: 149511

URL: http://svn.apache.org/viewcvs?view=rev&rev=149511
Log:
Fix a few docs - Thanks Seansvn diff build.properties.sample.lib

Modified:
struts/core/trunk/build.properties.sample.lib
struts/core/trunk/doc/acquiring.xml
struts/core/trunk/doc/faqs/helping.xml
struts/core/trunk/doc/learning.xml
struts/core/trunk/doc/userGuide/building_controller.xml

Modified: struts/core/trunk/build.properties.sample.lib
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/build.properties.sample.lib?view=diff&r1=149510&r2=149511
==
--- struts/core/trunk/build.properties.sample.lib (original)
+++ struts/core/trunk/build.properties.sample.lib Wed Feb  2 04:03:14 2005
@@ -18,7 +18,7 @@
 #   * place a copy of the servlet.jar for your container in the same folder.
 #
 # If you prefer to keep the JARs at another location, the properties
-# at the very top of the file may changed. If you require more versatility
+# at the very top of the file may be changed. If you require more versatility
 # in specifiying JAR locations, see the original "build.properties.sample" 
file.
 #
 # Only the "shared" properties are required for a typical build. 

Modified: struts/core/trunk/doc/acquiring.xml
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/doc/acquiring.xml?view=diff&r1=149510&r2=149511
==
--- struts/core/trunk/doc/acquiring.xml (original)
+++ struts/core/trunk/doc/acquiring.xml Wed Feb  2 04:03:14 2005
@@ -126,10 +126,15 @@
 repository, you will need to specify one of the following URLs:
 
 
+  http://svn.apache.org/repos/asf/struts/apps/trunk
+  http://svn.apache.org/repos/asf/struts/bsf/trunk
   http://svn.apache.org/repos/asf/struts/core/trunk
   http://svn.apache.org/repos/asf/struts/el/trunk
   http://svn.apache.org/repos/asf/struts/faces/trunk
   http://svn.apache.org/repos/asf/struts/sandbox/trunk
+  http://svn.apache.org/repos/asf/struts/shale/trunk
+  http://svn.apache.org/repos/asf/struts/taglib/trunk
+  http://svn.apache.org/repos/asf/struts/tiles/trunk
 
 
 Warning: If you try to take a shortcut, and check out
@@ -144,6 +149,27 @@
 User Guide for prerequisites. There are several JARs from the Jakarta
 Commons project that are required to build Struts.
 
+
+
+To download the trunk (HEAD revision) of all struts projects, a convenience
+directory has been added, named current.  The current directory uses a 
+Subversion feature called externals which stores properties on the 
directory.
+With those properties Subversion has all the information it needs to 
download
+all the struts subprojects together automatically.
+
+There are some caveats to remember.  Since all the subdirectories are 
+still really different slices from the repository, relative paths won't 
+always work as expected, for example.  See the 
+http://svnbook.red-bean.com/en/1.1/ch07s03.html";>Externals 
+Definitions section of the 
+http://svnbook.red-bean.com/";>Subversion Book for details.
+
+
+To take advantage of this shortcut, use the following URL:
+
+
+  http://svn.apache.org/repos/asf/struts/current
+
 
 
 If you are interested in the Tag Library Descriptor (TLD) files, these

Modified: struts/core/trunk/doc/faqs/helping.xml
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/doc/faqs/helping.xml?view=diff&r1=149510&r2=149511
==
--- struts/core/trunk/doc/faqs/helping.xml (original)
+++ struts/core/trunk/doc/faqs/helping.xml Wed Feb  2 04:03:14 2005
@@ -238,7 +238,7 @@
 
 The website portion of the package is the root directory of doc/.
 The User Guide portion is under the userGuide/ folder.
-If the material you'd to add doesn't fit right in with what's there,
+If the material you'd like to add doesn't fit right in with what's there,
 the best thing may to start a new section after the existing material.
 The navigation column can be found in the project.xml document.
 

Modified: struts/core/trunk/doc/learning.xml
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/doc/learning.xml?view=diff&r1=149510&r2=149511
==
--- struts/core/trunk/doc/learning.xml (original)
+++ struts/core/trunk/doc/learning.xml Wed Feb  2 04:03:14 2005
@@ -150,13 +150,13 @@
 
 Documentation - The Struts documentation bundle, as seen on the 
website.
 
+Tiles-Doc - Extensive demonstration of Tiles extension.
+
 MailReader - The original Struts example 
application. Try me first!
 Examples - Various demonstration applications combined as separate 
modules:
 

DO NOT REPLY [Bug 33246] - Documentation Updates: mention current and corrections

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33246


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: svn checkout

[James Mitchell]

Thanks for reminding me.

--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message - 
From: "Paul Sundling" <[EMAIL PROTECTED]>
To: "Struts Developers List" 
Sent: Wednesday, February 02, 2005 5:22 AM
Subject: Re: svn checkout


On that note, my patch for minor fixes to the docs including a mention
of current is still waiting for a once over. :)
http://issues.apache.org/bugzilla/show_bug.cgi?id=33246
Paul Sundling
On Tue, 2005-02-01 at 19:29 -0500, James Mitchell wrote:
You'd be better off using "current"
svn co http://svn.apache.org/repos/asf/struts/current
That gets you only "trunk" of each subproject.  Trust me, you'll quickly 
get
tired of typing an extra "../../" when you are flying around the 
repository
on the command line ;)


--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message - 
From: "Peter A. Pilgrim" <[EMAIL PROTECTED]>
To: "Struts Developers List" 
Sent: Tuesday, February 01, 2005 5:39 PM
Subject: Re: svn checkout

> Joe Germuska wrote:
>> At 5:30 PM + 2/1/05, Pilgrim, Peter wrote:
>>
>>> Hi
>>>
>>> Are they any good online docs on using "svn" with Struts 1.3?
>>> I tried very last night on my linux box:
>>>
>>> % svn checkout http://svn.apache.org/repos/asf/struts/trunk  struts
>>>
>>> But I must admit I didnt know what I was doing at all.
>>> Do you have to ``svn login'' or whatever?
>>
>>
>> For the read-only repository, you don't need to log in.
>>
>> The authoritative book on SVN is available for free online, and it's 
>> very
>> good:
>> http://svnbook.red-bean.com/svnbook-1.1/index.html
>>
>> Joe
>>
>
> fyi
>
> Yes I had a subversion problem!
>
> [EMAIL PROTECTED] [55] > svn checkout
> http://svn.apache.org/repos/asf/struts/core/trunk jakarta-struts
> svn: Valid UTF-8 data
> (hex:)
> followed by invalid UTF-8 sequence
> (hex: 80 0c 09 08)
>
> Strange i18n problems as reported by other people on the net and my
> machine. Weird!
> I downgraded from svn 1.1.3 to 1.0.0 and everything works as expected.
>
> Anyway here is what I did
>
> % cd /my/favourite/workspace
> % mkdirhier apache-struts
> % cd apache-struts
> % svn co http://svn.apache.org/repos/asf/struts/core/trunk  core
> % svn co http://svn.apache.org/repos/asf/struts/el/trunk  el
> % svn co http://svn.apache.org/repos/asf/struts/faces/trunk  faces
> % svn co http://svn.apache.org/repos/asf/struts/sandbox/trunk  sandbox
>
> hth sb
>
> -- 
> 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]
>
>


-
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: Wished feature: multiple action instances into same session

[James Mitchell]

Why couldn't you just put a single field (HashMap) called persons that holds 
a PersonBean (a mother, a father, and a spouse) all keyed off of the 
useCaseId?

That way you could do something like...

Or, if you knew you always needed those 3, just make each a field on the 
EditPersonForm.

 private PersonBean mother;
 private PersonBean father;
 private PersonBean spouse;
   (with appropriate getters and setters)
then, you can:



--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message - 
From: "BERNARDO ANTONIO BUFFA" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, February 02, 2005 3:02 AM
Subject: Wished feature: multiple action instances into same session


Hi,
will the future of Struts/Shale consider the possibility to have more than
an instance of MyAction (or UseCase, or Dialog, ...) per session?
In my last project I need to edit Persons so I had an EditPersonAction.
EditPersonAction was usefull for Creation/Update Person Objects.
The problem was that Person has an mother, father, spouse properties.
I want to be able creating/editing the mother/father/spouse (m/f/s) of
every edited person using the same EditPersonAction, which uses
EditPersonForm.
But struts maintains only one EditPersonForm instance per session.
So I subclassed RequestProcessor who keeps many EditPersonForm instances
and restore the appropiate one into session based on a request parameter
(useCaseId).
Apologize my poor englisch.
Thanks in advance for you time.
Bernardo Antonio Buffa Colomé

-
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: svn checkout

[Paul Sundling]

Thanks for applying my patch. :)  Soon I'll try to follow up on the
other stuff I mentioned earlier.

Paul Sundling

On Wed, 2005-02-02 at 07:05 -0500, James Mitchell wrote:
> Thanks for reminding me.
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> - Original Message - 
> From: "Paul Sundling" <[EMAIL PROTECTED]>
> To: "Struts Developers List" 
> Sent: Wednesday, February 02, 2005 5:22 AM
> Subject: Re: svn checkout
> 
> 
> > On that note, my patch for minor fixes to the docs including a mention
> > of current is still waiting for a once over. :)
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=33246
> >
> > Paul Sundling
> >
> > On Tue, 2005-02-01 at 19:29 -0500, James Mitchell wrote:
> >> You'd be better off using "current"
> >>
> >> svn co http://svn.apache.org/repos/asf/struts/current
> >>
> >> That gets you only "trunk" of each subproject.  Trust me, you'll quickly 
> >> get
> >> tired of typing an extra "../../" when you are flying around the 
> >> repository
> >> on the command line ;)
> >>
> >>
> >>
> >> --
> >> James Mitchell
> >> Software Engineer / Open Source Evangelist
> >> EdgeTech, Inc.
> >> 678.910.8017
> >> AIM: jmitchtx
> >>
> >> - Original Message - 
> >> From: "Peter A. Pilgrim" <[EMAIL PROTECTED]>
> >> To: "Struts Developers List" 
> >> Sent: Tuesday, February 01, 2005 5:39 PM
> >> Subject: Re: svn checkout
> >>
> >>
> >> > Joe Germuska wrote:
> >> >> At 5:30 PM + 2/1/05, Pilgrim, Peter wrote:
> >> >>
> >> >>> Hi
> >> >>>
> >> >>> Are they any good online docs on using "svn" with Struts 1.3?
> >> >>> I tried very last night on my linux box:
> >> >>>
> >> >>> % svn checkout http://svn.apache.org/repos/asf/struts/trunk  struts
> >> >>>
> >> >>> But I must admit I didnt know what I was doing at all.
> >> >>> Do you have to ``svn login'' or whatever?
> >> >>
> >> >>
> >> >> For the read-only repository, you don't need to log in.
> >> >>
> >> >> The authoritative book on SVN is available for free online, and it's 
> >> >> very
> >> >> good:
> >> >> http://svnbook.red-bean.com/svnbook-1.1/index.html
> >> >>
> >> >> Joe
> >> >>
> >> >
> >> > fyi
> >> >
> >> > Yes I had a subversion problem!
> >> >
> >> > [EMAIL PROTECTED] [55] > svn checkout
> >> > http://svn.apache.org/repos/asf/struts/core/trunk jakarta-struts
> >> > svn: Valid UTF-8 data
> >> > (hex:)
> >> > followed by invalid UTF-8 sequence
> >> > (hex: 80 0c 09 08)
> >> >
> >> > Strange i18n problems as reported by other people on the net and my
> >> > machine. Weird!
> >> > I downgraded from svn 1.1.3 to 1.0.0 and everything works as expected.
> >> >
> >> > Anyway here is what I did
> >> >
> >> > % cd /my/favourite/workspace
> >> > % mkdirhier apache-struts
> >> > % cd apache-struts
> >> > % svn co http://svn.apache.org/repos/asf/struts/core/trunk  core
> >> > % svn co http://svn.apache.org/repos/asf/struts/el/trunk  el
> >> > % svn co http://svn.apache.org/repos/asf/struts/faces/trunk  faces
> >> > % svn co http://svn.apache.org/repos/asf/struts/sandbox/trunk  sandbox
> >> >
> >> > hth sb
> >> >
> >> > -- 
> >> > 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]
> >> >
> >> >
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

DO NOT REPLY [Bug 33355] New: - computeURLWithCharEncoding doesn't encodes the & created by the response.encudeURL call

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33355

   Summary: computeURLWithCharEncoding doesn't encodes the & created
by the response.encudeURL call
   Product: Struts
   Version: 1.2.6 Beta
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: trivial
  Priority: P4
 Component: Custom Tags
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


When the emcopdeURL called from the TagUtils computeURLWithCharEncoding  and 
only one parameter exists then encodeURL insert a & sign to separate the old 
parameter from the sessionid.
example:
http://s.ss.s/CustomerlistActoion%3Flistid=1 
encoded as
http://s.ss.s/CustomerlistActoion%3Fjsessionid=111&listid=1
But the usage of & signs is invalid in the PCDATA encoded href attribute. The 
usage of th & is allowed here.

There have to be encoded the URL to PCDATA after the calling of encodeURL to 
avoid html validation errors.
The current code first creates a URL like 
http://s.ss.s/CustomerlistActoion%3Flistid=1&bubu=bubu2
The servlet engina parse it as :
Base: "http://s.ss.s/CustomerlistActoion"; 
parameter1 =  "listid" 
value of parameter1 = 1&bubu=bubu2
The good solution:
Step1:Create an urlencoded url wiht usage of & as separators.
Step2:Calling of response.encodeURL
Step3: Call the PCDATA encoding to whole url.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Extending RequestProcessor to handle validation errors

[Frank W. Zammetti (MLists)]

Hi folks... I'm working on an update of my Struts Web Services project,
and I can't seem to work out how to do something...

What I want to do is have a way to redirect to a given JSP when ActionForm
validation errors occur that will OVERRIDE whatever might be configured in
the action mapping.  In other words... in a normal application, validation
errors occur and we get forwarded back to the input page.  I want to be
able to redirect to a different JSP, REGARDLESS of what the input page is.

I looked at overriding the processValidate() method of RequestProcessor,
but I don't see how that can work... Looking at the source of the original
RP (v1.1 this all is) I see that it does the forward and then returns a
boolean, true if no errors occur or false otherwise, so it doesn't look
like I have the opportunity to do something like the following
psuedo-code:

myOverriden_ProcessValidate() {

  boolean b = super.processValidate();
  if (!b) {
forward to my jsp
  }

}

... because by the time I hit my check of b, the forward or redirect has
already been done.  Is it possible to override the forward or redirect
that the super.processValidate() could do?  I didn't think so.  Am I
missing the obvious somewhere on how to do this, or maybe I'm barking up
the wrong tree to begin with?  Thanks all!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

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

RE: Extending RequestProcessor to handle validation errors

[Benedict, Paul C]

Frank,

I am not sure of why you need this solution. I never came across your need
-- and perhaps because I never encountered the problem.

I can't imagine why you would want to dynamically control the input page.
For instance, I use MappingDispatchAction and each action entry has its own
specified input and success forward.

Is your question actually posed by a misdesign?

Thanks,
Paul

-Original Message-
From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 02, 2005 12:39 PM
To: dev@struts.apache.org
Subject: Extending RequestProcessor to handle validation errors


Hi folks... I'm working on an update of my Struts Web Services project,
and I can't seem to work out how to do something...

What I want to do is have a way to redirect to a given JSP when ActionForm
validation errors occur that will OVERRIDE whatever might be configured in
the action mapping.  In other words... in a normal application, validation
errors occur and we get forwarded back to the input page.  I want to be
able to redirect to a different JSP, REGARDLESS of what the input page is.

I looked at overriding the processValidate() method of RequestProcessor,
but I don't see how that can work... Looking at the source of the original
RP (v1.1 this all is) I see that it does the forward and then returns a
boolean, true if no errors occur or false otherwise, so it doesn't look
like I have the opportunity to do something like the following
psuedo-code:

myOverriden_ProcessValidate() {

  boolean b = super.processValidate();
  if (!b) {
forward to my jsp
  }

}

... because by the time I hit my check of b, the forward or redirect has
already been done.  Is it possible to override the forward or redirect
that the super.processValidate() could do?  I didn't think so.  Am I
missing the obvious somewhere on how to do this, or maybe I'm barking up
the wrong tree to begin with?  Thanks all!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

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




--
Notice:  This e-mail message, together with any attachments, contains 
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New 
Jersey, USA 08889), and/or its affiliates (which may be known outside the 
United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as 
Banyu) that may be confidential, proprietary copyrighted and/or legally 
privileged. It is intended solely for the use of the individual or entity named 
on this message.  If you are not the intended recipient, and have received this 
message in error, please notify us immediately by reply e-mail and then delete 
it from your system.
--

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

Re: Extending RequestProcessor to handle validation errors

[Joe Germuska]

With the ComposableRequestProcessor, the validation is independent 
from the command which puts an ActionForward into the context in the 
event of a failed form validation.  It should be very straightforward 
for you to change the "SelectInput" command or add another one which 
uses request context information to decide whether it should override 
the normal behavior or assume that some other command will handle 
things.

Joe
At 12:38 PM -0500 2/2/05, Frank W. Zammetti (MLists) wrote:
Hi folks... I'm working on an update of my Struts Web Services project,
and I can't seem to work out how to do something...
What I want to do is have a way to redirect to a given JSP when ActionForm
validation errors occur that will OVERRIDE whatever might be configured in
the action mapping.  In other words... in a normal application, validation
errors occur and we get forwarded back to the input page.  I want to be
able to redirect to a different JSP, REGARDLESS of what the input page is.
I looked at overriding the processValidate() method of RequestProcessor,
but I don't see how that can work... Looking at the source of the original
RP (v1.1 this all is) I see that it does the forward and then returns a
boolean, true if no errors occur or false otherwise, so it doesn't look
like I have the opportunity to do something like the following
psuedo-code:
myOverriden_ProcessValidate() {
  boolean b = super.processValidate();
  if (!b) {
forward to my jsp
  }
}
... because by the time I hit my check of b, the forward or redirect has
already been done.  Is it possible to override the forward or redirect
that the super.processValidate() could do?  I didn't think so.  Am I
missing the obvious somewhere on how to do this, or maybe I'm barking up
the wrong tree to begin with?  Thanks all!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

RE: Extending RequestProcessor to handle validation errors

[fzlists]

Are you familiar with my project Paul?  If not, I'll briefly explain 
(otherwise, just skip to the third paragraph)...

It is a project that allows Actions to be exposed as Web Services with no 
changes to the existing code.  All a developer has to do is add a plug-in, and 
optionally a new webservices-config.xml file, and the Actions can be called by 
SOAP clients without doing anything more.

However, one of the things that is lacking in the current version is proper 
handling of form validation errors.  I think essentially the request would die 
a horrible death at worst, and at best just return gibberish, because the 
errors are not handled in any way.  I need to add that capability.

To address your specific question, the input page is irrelevant in this 
situation because input did not come from that page.  However, I want such a 
request to return a "real" error message, still as a valid SOAP-based response. 
 As all the output is now generated by JSP templates, it makes sense to do the 
same to handle these validation errors.  So, I therefore need a way to make the 
RequestProcessor (where all the things that make this work in the first place 
are done) forward to a JSP, regardless of what the input page attribute might 
say.

Alternatively, a developer would have to add an extra mapping for every Action 
they want to expose as a service, but that is contrary to my "quick ,easy and 
transparent" goal that I've been following all along.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, February 2, 2005 12:46 pm, Benedict, Paul C said:
> Frank,
> 
> I am not sure of why you need this solution. I never came across your need
> -- and perhaps because I never encountered the problem.
> 
> I can't imagine why you would want to dynamically control the input page.
> For instance, I use MappingDispatchAction and each action entry has its
> own
> specified input and success forward.
> 
> Is your question actually posed by a misdesign?
> 
> Thanks,
> Paul
> 
> -Original Message-
> From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 02, 2005 12:39 PM
> To: dev@struts.apache.org
> Subject: Extending RequestProcessor to handle validation errors
> 
> 
> Hi folks... I'm working on an update of my Struts Web Services project,
> and I can't seem to work out how to do something...
> 
> What I want to do is have a way to redirect to a given JSP when ActionForm
> validation errors occur that will OVERRIDE whatever might be configured in
> the action mapping.  In other words... in a normal application, validation
> errors occur and we get forwarded back to the input page.  I want to be
> able to redirect to a different JSP, REGARDLESS of what the input page is.
> 
> I looked at overriding the processValidate() method of RequestProcessor,
> but I don't see how that can work... Looking at the source of the original
> RP (v1.1 this all is) I see that it does the forward and then returns a
> boolean, true if no errors occur or false otherwise, so it doesn't look
> like I have the opportunity to do something like the following
> psuedo-code:
> 
> myOverriden_ProcessValidate() {
> 
>   boolean b = super.processValidate();
>   if (!b) {
> forward to my jsp
>   }
> 
> }
> 
> ... because by the time I hit my check of b, the forward or redirect has
> already been done.  Is it possible to override the forward or redirect
> that the super.processValidate() could do?  I didn't think so.  Am I
> missing the obvious somewhere on how to do this, or maybe I'm barking up
> the wrong tree to begin with?  Thanks all!
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> --
> Notice:  This e-mail message, together with any attachments, contains
> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New
> Jersey, USA 08889), and/or its affiliates (which may be known outside the
> United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as
> Banyu) that may be confidential, proprietary copyrighted and/or legally
> privileged. It is intended solely for the use of the individual or entity
> named on this message.  If you are not the intended recipient, and have
> received this message in error, please notify us immediately by reply
> e-mail and then delete it from your system.
> --
> 

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

Re: Extending RequestProcessor to handle validation errors

[fzlists]

You are referring to the CoR-based Struts build, correct Joe?  If not, I'm not 
seeing that class in the 1.1 javadocs.

If your talking CoR as I think you are though, I haven't gotten that far yet :) 
 I'm trying to get this to a point of equillibrium that I'm happy with based on 
the current codebase, then move on beyond that to a CoR-based implementation 
(which should be relatively easy as you indicate).

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, February 2, 2005 12:53 pm, Joe Germuska said:
> With the ComposableRequestProcessor, the validation is independent
> from the command which puts an ActionForward into the context in the
> event of a failed form validation.  It should be very straightforward
> for you to change the "SelectInput" command or add another one which
> uses request context information to decide whether it should override
> the normal behavior or assume that some other command will handle
> things.
> 
> Joe
> 
> 
> At 12:38 PM -0500 2/2/05, Frank W. Zammetti (MLists) wrote:
>>Hi folks... I'm working on an update of my Struts Web Services project,
>>and I can't seem to work out how to do something...
>>
>>What I want to do is have a way to redirect to a given JSP when
>> ActionForm
>>validation errors occur that will OVERRIDE whatever might be configured
>> in
>>the action mapping.  In other words... in a normal application,
>> validation
>>errors occur and we get forwarded back to the input page.  I want to be
>>able to redirect to a different JSP, REGARDLESS of what the input page
>> is.
>>
>>I looked at overriding the processValidate() method of RequestProcessor,
>>but I don't see how that can work... Looking at the source of the
>> original
>>RP (v1.1 this all is) I see that it does the forward and then returns a
>>boolean, true if no errors occur or false otherwise, so it doesn't look
>>like I have the opportunity to do something like the following
>>psuedo-code:
>>
>>myOverriden_ProcessValidate() {
>>
>>   boolean b = super.processValidate();
>>   if (!b) {
>> forward to my jsp
>>   }
>>
>>}
>>
>>... because by the time I hit my check of b, the forward or redirect has
>>already been done.  Is it possible to override the forward or redirect
>>that the super.processValidate() could do?  I didn't think so.  Am I
>>missing the obvious somewhere on how to do this, or maybe I'm barking up
>>the wrong tree to begin with?  Thanks all!
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 

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

RE: Extending RequestProcessor to handle validation errors

[fzlists]

Nothing to excuse Paul!  Thanks for being "at the ready" to help in any case :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, February 2, 2005 1:09 pm, Benedict, Paul C said:
> Frank,
> 
> Excuse my ignorance then :) Your explanation now makes perfect sense.
> Also,
> Joe's explanation is the right answer.
> 
> Thanks,
> Paul
> 
> -Original Message-
> From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 02, 2005 1:04 PM
> To: Benedict, Paul C
> Subject: RE: Extending RequestProcessor to handle validation errors
> 
> 
> Are you familiar with my project Paul?  If not, I'll briefly explain
> (otherwise, just skip to the third paragraph)...
> 
> It is a project that allows Actions to be exposed as Web Services with no
> changes to the existing code.  All a developer has to do is add a plug-in,
> and optionally a new webservices-config.xml file, and the Actions can be
> called by SOAP clients without doing anything more.
> 
> However, one of the things that is lacking in the current version is
> proper handling of form validation errors.  I think essentially the
> request would die a horrible death at worst, and at best just return
> gibberish, because the errors are not handled in any way.  I need to add
> that capability.
> 
> To address your specific question, the input page is irrelevant in this
> situation because input did not come from that page.  However, I want such
> a request to return a "real" error message, still as a valid SOAP-based
> response.  As all the output is now generated by JSP templates, it makes
> sense to do the same to handle these validation errors.  So, I therefore
> need a way to make the RequestProcessor (where all the things that make
> this work in the first place are done) forward to a JSP, regardless of
> what the input page attribute might say.
> 
> Alternatively, a developer would have to add an extra mapping for every
> Action they want to expose as a service, but that is contrary to my "quick
> ,easy and transparent" goal that I've been following all along.
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> On Wed, February 2, 2005 12:46 pm, Benedict, Paul C said:
>> Frank,
>>
>> I am not sure of why you need this solution. I never came across your
>> need
>> -- and perhaps because I never encountered the problem.
>>
>> I can't imagine why you would want to dynamically control the input
>> page.
>> For instance, I use MappingDispatchAction and each action entry has its
>> own
>> specified input and success forward.
>>
>> Is your question actually posed by a misdesign?
>>
>> Thanks,
>> Paul
>>
>> -Original Message-
>> From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, February 02, 2005 12:39 PM
>> To: dev@struts.apache.org
>> Subject: Extending RequestProcessor to handle validation errors
>>
>>
>> Hi folks... I'm working on an update of my Struts Web Services project,
>> and I can't seem to work out how to do something...
>>
>> What I want to do is have a way to redirect to a given JSP when
>> ActionForm
>> validation errors occur that will OVERRIDE whatever might be configured
>> in
>> the action mapping.  In other words... in a normal application,
>> validation
>> errors occur and we get forwarded back to the input page.  I want to be
>> able to redirect to a different JSP, REGARDLESS of what the input page
>> is.
>>
>> I looked at overriding the processValidate() method of RequestProcessor,
>> but I don't see how that can work... Looking at the source of the
>> original
>> RP (v1.1 this all is) I see that it does the forward and then returns a
>> boolean, true if no errors occur or false otherwise, so it doesn't look
>> like I have the opportunity to do something like the following
>> psuedo-code:
>>
>> myOverriden_ProcessValidate() {
>>
>>   boolean b = super.processValidate();
>>   if (!b) {
>> forward to my jsp
>>   }
>>
>> }
>>
>> ... because by the time I hit my check of b, the forward or redirect has
>> already been done.  Is it possible to override the forward or redirect
>> that the super.processValidate() could do?  I didn't think so.  Am I
>> missing the obvious somewhere on how to do this, or maybe I'm barking up
>> the wrong tree to begin with?  Thanks all!
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
> 
> --
>> Notice:  This e-mail message, together with any attachments, contains
>> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
>> New
>> Jersey, USA 08889), and/or its affiliates (whic

RE: Extending RequestProcessor to handle validation errors

[Joe Germuska]

This actually stimulated another thought.  Perhaps instead of 
overriding process validate, you could arrange to have your 
ActionMappings dynamically instantiated with the correct value for 
"input" (assuming that you can know it before you do the validation.)

There is nothing sacred about the original instances of ActionMapping 
which are created by processing the struts-config file.  The wildcard 
mapping support results in dynamic construction of ActionMappings 
which have parameters replaced according to the wildcard match.

You could either use your own ModuleConfig implementation with a 
custom implementation of findActionConfig(path) or, if the 
determination of the input depends on request data as well as the 
path, override processMapping in the RequestProcessor.

I still think using the ComposableRequestProcessor is an easier solution!
Joe
At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
Frank,
I am not sure of why you need this solution. I never came across your need
-- and perhaps because I never encountered the problem.
I can't imagine why you would want to dynamically control the input page.
For instance, I use MappingDispatchAction and each action entry has its own
specified input and success forward.
Is your question actually posed by a misdesign?
Thanks,
Paul
-Original Message-
From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 02, 2005 12:39 PM
To: dev@struts.apache.org
Subject: Extending RequestProcessor to handle validation errors
Hi folks... I'm working on an update of my Struts Web Services project,
and I can't seem to work out how to do something...
What I want to do is have a way to redirect to a given JSP when ActionForm
validation errors occur that will OVERRIDE whatever might be configured in
the action mapping.  In other words... in a normal application, validation
errors occur and we get forwarded back to the input page.  I want to be
able to redirect to a different JSP, REGARDLESS of what the input page is.
I looked at overriding the processValidate() method of RequestProcessor,
but I don't see how that can work... Looking at the source of the original
RP (v1.1 this all is) I see that it does the forward and then returns a
boolean, true if no errors occur or false otherwise, so it doesn't look
like I have the opportunity to do something like the following
psuedo-code:
myOverriden_ProcessValidate() {
  boolean b = super.processValidate();
  if (!b) {
forward to my jsp
  }
}
... because by the time I hit my check of b, the forward or redirect has
already been done.  Is it possible to override the forward or redirect
that the super.processValidate() could do?  I didn't think so.  Am I
missing the obvious somewhere on how to do this, or maybe I'm barking up
the wrong tree to begin with?  Thanks all!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Notice:  This e-mail message, together with any attachments, 
contains information of Merck & Co., Inc. (One Merck Drive, 
Whitehouse Station, New Jersey, USA 08889), and/or its affiliates 
(which may be known outside the United States as Merck Frosst, Merck 
Sharp & Dohme or MSD and in Japan, as Banyu) that may be 
confidential, proprietary copyrighted and/or legally privileged. It 
is intended solely for the use of the individual or entity named on 
this message.  If you are not the intended recipient, and have 
received this message in error, please notify us immediately by 
reply e-mail and then delete it from your system.
--

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

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

RE: Extending RequestProcessor to handle validation errors

[fzlists]

On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
> This actually stimulated another thought.  Perhaps instead of
> overriding process validate, you could arrange to have your
> ActionMappings dynamically instantiated with the correct value for
> "input" (assuming that you can know it before you do the validation.)

Actually, now you've stimulated a though in me! :)

Correct me if I'm wrong, but processPreprocess() fires BEFORE 
processValidate(), correct?  In that case, since I can in fact determine the 
input after processPreprocess() fires, I can simply call setInput() on the 
mapping with the new value, and everything should work as expected.

Sound about right to you Joe?
 
> I still think using the ComposableRequestProcessor is an easier solution!

You didn't answer the question I was hoping you would though :)  Is that class 
based on the CoR-based Struts codebase?  If so, while I in no way diagree with 
you that it's probably the better/easier solution, I'm not quite ready to move 
to the CoR paradigm with this yet.
 
> Joe

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

> At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
>>Frank,
>>
>>I am not sure of why you need this solution. I never came across your
>> need
>>-- and perhaps because I never encountered the problem.
>>
>>I can't imagine why you would want to dynamically control the input page.
>>For instance, I use MappingDispatchAction and each action entry has its
>> own
>>specified input and success forward.
>>
>>Is your question actually posed by a misdesign?
>>
>>Thanks,
>>Paul
>>
>>-Original Message-
>>From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
>>Sent: Wednesday, February 02, 2005 12:39 PM
>>To: dev@struts.apache.org
>>Subject: Extending RequestProcessor to handle validation errors
>>
>>
>>Hi folks... I'm working on an update of my Struts Web Services project,
>>and I can't seem to work out how to do something...
>>
>>What I want to do is have a way to redirect to a given JSP when
>> ActionForm
>>validation errors occur that will OVERRIDE whatever might be configured
>> in
>>the action mapping.  In other words... in a normal application,
>> validation
>>errors occur and we get forwarded back to the input page.  I want to be
>>able to redirect to a different JSP, REGARDLESS of what the input page
>> is.
>>
>>I looked at overriding the processValidate() method of RequestProcessor,
>>but I don't see how that can work... Looking at the source of the
>> original
>>RP (v1.1 this all is) I see that it does the forward and then returns a
>>boolean, true if no errors occur or false otherwise, so it doesn't look
>>like I have the opportunity to do something like the following
>>psuedo-code:
>>
>>myOverriden_ProcessValidate() {
>>
>>   boolean b = super.processValidate();
>>   if (!b) {
>> forward to my jsp
>>   }
>>
>>}
>>
>>... because by the time I hit my check of b, the forward or redirect has
>>already been done.  Is it possible to override the forward or redirect
>>that the super.processValidate() could do?  I didn't think so.  Am I
>>missing the obvious somewhere on how to do this, or maybe I'm barking up
>>the wrong tree to begin with?  Thanks all!
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>--
>>Notice:  This e-mail message, together with any attachments,
>>contains information of Merck & Co., Inc. (One Merck Drive,
>>Whitehouse Station, New Jersey, USA 08889), and/or its affiliates
>>(which may be known outside the United States as Merck Frosst, Merck
>>Sharp & Dohme or MSD and in Japan, as Banyu) that may be
>>confidential, proprietary copyrighted and/or legally privileged. It
>>is intended solely for the use of the individual or entity named on
>>this message.  If you are not the intended recipient, and have
>>received this message in error, please notify us immediately by
>>reply e-mail and then delete it from your system.
>>--
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 

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

Re: Extending RequestProcessor to handle validation errors

[Niall Pemberton]

The ActionMapping will be "frozen" and trying to set the input will throw an
exception. You could get round this by overriding the processMapping()
method and returning a "clone" of the ActionMapping.

Niall

- Original Message - 
From: <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, February 02, 2005 6:28 PM
Subject: RE: Extending RequestProcessor to handle validation errors


> On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
> > This actually stimulated another thought.  Perhaps instead of
> > overriding process validate, you could arrange to have your
> > ActionMappings dynamically instantiated with the correct value for
> > "input" (assuming that you can know it before you do the validation.)
>
> Actually, now you've stimulated a though in me! :)
>
> Correct me if I'm wrong, but processPreprocess() fires BEFORE
processValidate(), correct?  In that case, since I can in fact determine the
input after processPreprocess() fires, I can simply call setInput() on the
mapping with the new value, and everything should work as expected.
>
> Sound about right to you Joe?
>
> > I still think using the ComposableRequestProcessor is an easier
solution!
>



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

DO NOT REPLY [Bug 33238] - Escape double quotes in JavascriptValidatorTag

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33238





--- Additional Comments From [EMAIL PROTECTED]  2005-02-02 19:43 ---
(In reply to comment #0)
> To escape double quotes when generating dynamic javascript in 
> JavascriptValidatorTag, to allow the evaluation of javascript expressions. 
> This could set the stage for a Rhino-like Validator, in the future.

I was checking for the struts dynamic javascript error problem. (Error: 
Expected ')' )

Actually, the line had a
Due to the double quotes, its throwing the error. And When I changed the 
generated js script to single quotes, it worked fine.

Now, how do I fix my struts validation part? Is there any tag that I shoudl 
use? Or should I have to update for the latest Struts download?

Thx & Rgds
Naveen

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Wished feature: multiple action instances into same session

[BERNARDO ANTONIO BUFFA]

Really, this subclass of RequestProcessor is a runtime for inter usecases
invocation. E.G.: I'm editing an expedient and for adding involved
customers
, I invoke an UC SelectCustomers (using SelectCustomersForm).
The application allows the user to launch many 'windows' (javascripted on
the client).
eg: The user is able to view or edit many expedients
Your solution was in fact my first aproach to the problem, but then I though
that this forces me to:

1) have many 'parallel' HashMaps to keep ALL the ActionForm properties.
(the Expedient, Person, WhatEver being edited, a copy of the same object
for  user 'rollback' of edition and more helping properties).

2) or have only one HashMap with values with ALL the ActionForm properties
each one, (, or with just my subclass of ActionForm as values)

the second option was exactly the same work that now does this
RequestProcessor.

I'm trying to be simple and hope to express myself clear.
I'm viewing real added value to that feature, and I believe a from zero
coded as Shale could be a good place for this discussion.

>> Apologize my poor englisch. (again)


>> Thanks in advance for you time.
>> Bernardo Antonio Buffa Colomé



> Why couldn't you just put a single field (HashMap) called persons that
> holds  a PersonBean (a mother, a father, and a spouse) all keyed off of
> the  useCaseId?
>
> That way you could do something like...
>
>  
>
> Or, if you knew you always needed those 3, just make each a field on the
>  EditPersonForm.
>
>   private PersonBean mother;
>   private PersonBean father;
>   private PersonBean spouse;
>
> (with appropriate getters and setters)
>
>
> then, you can:
>
>  
>
>
>
>
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
>
> - Original Message -
> From: "BERNARDO ANTONIO BUFFA" <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, February 02, 2005 3:02 AM
> Subject: Wished feature: multiple action instances into same session
>
>
>> Hi,
>>
>> will the future of Struts/Shale consider the possibility to have more
>> than an instance of MyAction (or UseCase, or Dialog, ...) per session?
>>
>> In my last project I need to edit Persons so I had an
>> EditPersonAction. EditPersonAction was usefull for Creation/Update
>> Person Objects. The problem was that Person has an mother, father,
>> spouse properties. I want to be able creating/editing the
>> mother/father/spouse (m/f/s) of every edited person using the same
>> EditPersonAction, which uses
>> EditPersonForm.
>> But struts maintains only one EditPersonForm instance per session. So
>> I subclassed RequestProcessor who keeps many EditPersonForm instances
>> and restore the appropiate one into session based on a request
>> parameter (useCaseId).
>> Apologize my poor englisch.
>>
>> Thanks in advance for you time.
>> Bernardo Antonio Buffa Colomé
>>
>>
>>
>> -
>> 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: Extending RequestProcessor to handle validation errors

[Joe Germuska]

At 10:28 AM -0800 2/2/05, [EMAIL PROTECTED] wrote:
On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
 This actually stimulated another thought.  Perhaps instead of
 overriding process validate, you could arrange to have your
 ActionMappings dynamically instantiated with the correct value for
 "input" (assuming that you can know it before you do the validation.)
Actually, now you've stimulated a though in me! :)
Correct me if I'm wrong, but processPreprocess() fires BEFORE 
processValidate(), correct?  In that case, since I can in fact 
determine the input after processPreprocess() fires, I can simply 
call setInput() on the mapping with the new value, and everything 
should work as expected.

Sound about right to you Joe?

The order in which request processor "template" methods are called is 
laid out at
http://struts.apache.org/userGuide/building_controller.html#request_processor

you don't yet have an ActionMapping when processPreprocess() fires, 
but I guess you could pre-compute something and put it in the request 
scope, and then get it out later.

Of course, you can see it in all its glory at 
http://svn.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/action/RequestProcessor.java?view=markup

(hooray for fixed viewCVS!)
 > I still think using the ComposableRequestProcessor is an easier solution!
You didn't answer the question I was hoping you would though :)  Is 
that class based on the CoR-based Struts codebase?  If so, while I 
in no way diagree with you that it's probably the better/easier 
solution, I'm not quite ready to move to the CoR paradigm with this 
yet.
yeah, I sent this before I saw that.  The ComposableRequestProcessor 
is the subclass of RequestProcessor which delegates to a 
commons-chain command for processing, so if you're not ready, you're 
not ready.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: Extending RequestProcessor to handle validation errors

[fzlists]

> The problem as I discovered is that I can't just call setInput() in 
> processValidate() because the configuration is frozen at that point.  And, 
> since the RequestProcessor isn't in the same package as ActionConfig (where > 
> setInput() is found), I couldn't call setInput() since it's protected.

Sorry, I confused myself there for a minute... setInput() isn't what's 
protected. the configured field in ActionConfig is.  What I meant to say was 
that I couldn't just set it directly from the request processor, I HAD to use 
setInput().  That's the reason for the ACUnfreezer class, that allows me to set 
the configured field directly (since there's no unfreeze() method, which makes 
sense).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Extending RequestProcessor to handle validation ...

[fzlists]

 My mail client is flaking out again, so I don't think this went through 
the first time.  This should be read BEFORE my post about confusing myself, 
otherwise it'll likely be YOU who is confused :) 


GOT IT!

But, this might be the worst piece of hackery I've ever done.  Check it out...

Joe's last response spurred me to realize that if I could override the input 
field of the ActionMapping, I could do what I want.  As I thought, 
processPreprocess() fires before processValidate(), which means I can identify 
a Web Service request in processValidate() based on some attributes I set in 
processPreprocess().

The problem as I discovered is that I can't just call setInput() in 
processValidate() because the configuration is frozen at that point.  And, 
since the RequestProcessor isn't in the same package as ActionConfig (where 
setInput() is found), I couldn't call setInput() since it's protected.

So, enter the hackery of the following class...

package org.apache.struts.config;

import org.apache.struts.action.ActionMapping;
public class ACUnfreezer {
  public static void unfreeze(ActionMapping mapping) {
mapping.configured = false;
  }
}

So, in processValidate(), I simply do:

if (request is a web service) [
  ACUnfreezer.unfreeze(mapping);
  mapping.setInput(the new JSP to go to in case of validation errors);
  mapping.freeze(); // Just for good measure
}
return super.processValidate(request, response, form, mapping);

So, regular requests work as before, and the Web Service requests will be 
redirected if validation errors occur. Beautiful!

In an EXTREMELY hacky kind of way!

Thanks for the talkback Paul and Joe, I'm not sure how long it would have taken 
on my own to get to this solution, if at all.  Of course, I suppose that means 
you have to accept some of the blame for such a hack-job :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
> This actually stimulated another thought.  Perhaps instead of
> overriding process validate, you could arrange to have your
> ActionMappings dynamically instantiated with the correct value for
> "input" (assuming that you can know it before you do the validation.)
> 
> There is nothing sacred about the original instances of ActionMapping
> which are created by processing the struts-config file.  The wildcard
> mapping support results in dynamic construction of ActionMappings
> which have parameters replaced according to the wildcard match.
> 
> You could either use your own ModuleConfig implementation with a
> custom implementation of findActionConfig(path) or, if the
> determination of the input depends on request data as well as the
> path, override processMapping in the RequestProcessor.
> 
> I still think using the ComposableRequestProcessor is an easier solution!
> 
> Joe
> 
> 
> At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
>>Frank,
>>
>>I am not sure of why you need this solution. I never came across your
>> need
>>-- and perhaps because I never encountered the problem.
>>
>>I can't imagine why you would want to dynamically control the input page.
>>For instance, I use MappingDispatchAction and each action entry has its
>> own
>>specified input and success forward.
>>
>>Is your question actually posed by a misdesign?
>>
>>Thanks,
>>Paul
>>
>>-Original Message-
>>From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
>>Sent: Wednesday, February 02, 2005 12:39 PM
>>To: dev@struts.apache.org
>>Subject: Extending RequestProcessor to handle validation errors
>>
>>
>>Hi folks... I'm working on an update of my Struts Web Services project,
>>and I can't seem to work out how to do something...
>>
>>What I want to do is have a way to redirect to a given JSP when
>> ActionForm
>>validation errors occur that will OVERRIDE whatever might be configured
>> in
>>the action mapping.  In other words... in a normal application,
>> validation
>>errors occur and we get forwarded back to the input page.  I want to be
>>able to redirect to a different JSP, REGARDLESS of what the input page
>> is.
>>
>>I looked at overriding the processValidate() method of RequestProcessor,
>>but I don't see how that can work... Looking at the source of the
>> original
>>RP (v1.1 this all is) I see that it does the forward and then returns a
>>boolean, true if no errors occur or false otherwise, so it doesn't look
>>like I have the opportunity to do something like the following
>>psuedo-code:
>>
>>myOverriden_ProcessValidate() {
>>
>>   boolean b = super.processValidate();
>>   if (!b) {
>> forward to my jsp
>>   }
>>
>>}
>>
>>... because by the time I hit my check of b, the forward or redirect has
>>already been done.  Is it possible to override the forward or redirect
>>that the super.processValidate() could do?  I didn't think so.  Am I
>>missing the obvious somewhere on how to do this, or maybe I'm barking up
>>the wrong tree to begin with?  Thanks all

RE: Extending RequestProcessor to handle validation errors

[fzlists]

On Wed, February 2, 2005 1:28 pm, [EMAIL PROTECTED] said:
> Actually, now you've stimulated a though in me! :)
> 
> Correct me if I'm wrong, but processPreprocess() fires BEFORE
> processValidate(), correct?  In that case, since I can in fact determine
> the input after processPreprocess() fires, I can simply call setInput() on
> the mapping with the new value, and everything should work as expected.
> 
> Sound about right to you Joe?

Actually, I can answer my own question: NO.  IllegalStateException: 
Configuration is frozen.  Argh.

Next question: where is the ActionMapping instantiated from and stored, and can 
I create a new one myself and replace the first one?
 
-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Extending RequestProcessor to handle validation errors

[fzlists]

GOT IT!

But, this might be the worst piece of hackery I've ever done.  Check it out...

Joe's last response spurred me to realize that if I could override the input 
field of the ActionMapping, I could do what I want.  As I thought, 
processPreprocess() fires before processValidate(), which means I can identify 
a Web Service request in processValidate() based on some attributes I set in 
processPreprocess().

The problem as I discovered is that I can't just call setInput() in 
processValidate() because the configuration is frozen at that point.  And, 
since the RequestProcessor isn't in the same package as ActionConfig (where 
setInput() is found), I couldn't call setInput() since it's protected.

So, enter the hackery of the following class...

package org.apache.struts.config;

import org.apache.struts.action.ActionMapping;
public class ACUnfreezer {
  public static void unfreeze(ActionMapping mapping) {
mapping.configured = false;
  }
}

So, in processValidate(), I simply do:

if (request is a web service) [
  ACUnfreezer.unfreeze(mapping);
  mapping.setInput(the new JSP to go to in case of validation errors);
  mapping.freeze(); // Just for good measure
}
return super.processValidate(request, response, form, mapping);

So, regular requests work as before, and the Web Service requests will be 
redirected if validation errors occur. Beautiful!

In an EXTREMELY hacky kind of way!

Thanks for the talkback Paul and Joe, I'm not sure how long it would have taken 
on my own to get to this solution, if at all.  Of course, I suppose that means 
you have to accept some of the blame for such a hack-job :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
> This actually stimulated another thought.  Perhaps instead of
> overriding process validate, you could arrange to have your
> ActionMappings dynamically instantiated with the correct value for
> "input" (assuming that you can know it before you do the validation.)
> 
> There is nothing sacred about the original instances of ActionMapping
> which are created by processing the struts-config file.  The wildcard
> mapping support results in dynamic construction of ActionMappings
> which have parameters replaced according to the wildcard match.
> 
> You could either use your own ModuleConfig implementation with a
> custom implementation of findActionConfig(path) or, if the
> determination of the input depends on request data as well as the
> path, override processMapping in the RequestProcessor.
> 
> I still think using the ComposableRequestProcessor is an easier solution!
> 
> Joe
> 
> 
> At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
>>Frank,
>>
>>I am not sure of why you need this solution. I never came across your
>> need
>>-- and perhaps because I never encountered the problem.
>>
>>I can't imagine why you would want to dynamically control the input page.
>>For instance, I use MappingDispatchAction and each action entry has its
>> own
>>specified input and success forward.
>>
>>Is your question actually posed by a misdesign?
>>
>>Thanks,
>>Paul
>>
>>-Original Message-
>>From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
>>Sent: Wednesday, February 02, 2005 12:39 PM
>>To: dev@struts.apache.org
>>Subject: Extending RequestProcessor to handle validation errors
>>
>>
>>Hi folks... I'm working on an update of my Struts Web Services project,
>>and I can't seem to work out how to do something...
>>
>>What I want to do is have a way to redirect to a given JSP when
>> ActionForm
>>validation errors occur that will OVERRIDE whatever might be configured
>> in
>>the action mapping.  In other words... in a normal application,
>> validation
>>errors occur and we get forwarded back to the input page.  I want to be
>>able to redirect to a different JSP, REGARDLESS of what the input page
>> is.
>>
>>I looked at overriding the processValidate() method of RequestProcessor,
>>but I don't see how that can work... Looking at the source of the
>> original
>>RP (v1.1 this all is) I see that it does the forward and then returns a
>>boolean, true if no errors occur or false otherwise, so it doesn't look
>>like I have the opportunity to do something like the following
>>psuedo-code:
>>
>>myOverriden_ProcessValidate() {
>>
>>   boolean b = super.processValidate();
>>   if (!b) {
>> forward to my jsp
>>   }
>>
>>}
>>
>>... because by the time I hit my check of b, the forward or redirect has
>>already been done.  Is it possible to override the forward or redirect
>>that the super.processValidate() could do?  I didn't think so.  Am I
>>missing the obvious somewhere on how to do this, or maybe I'm barking up
>>the wrong tree to begin with?  Thanks all!
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>-
>>To unsubscribe, e

RE: Extending RequestProcessor to handle validation errors

[dbrosius]

i might put that freeze in a finally block, if you're gonna do something nasty,
better make sure you leave no footprints. :)


if (request is a web service) {
  try {
ACUnfreezer.unfreeze(mapping);
mapping.setInput(the new JSP to go to in case of validation errors);
  } finally {
mapping.freeze(); // Just for good measure
  }
}


Quoting [EMAIL PROTECTED]:

> GOT IT!
> 
> But, this might be the worst piece of hackery I've ever done.  Check it
> out...
> 
> Joe's last response spurred me to realize that if I could override the input
> field of the ActionMapping, I could do what I want.  As I thought,
> processPreprocess() fires before processValidate(), which means I can
> identify a Web Service request in processValidate() based on some attributes
> I set in processPreprocess().
> 
> The problem as I discovered is that I can't just call setInput() in
> processValidate() because the configuration is frozen at that point.  And,
> since the RequestProcessor isn't in the same package as ActionConfig (where
> setInput() is found), I couldn't call setInput() since it's protected.
> 
> So, enter the hackery of the following class...
> 
> package org.apache.struts.config;
> 
> import org.apache.struts.action.ActionMapping;
> public class ACUnfreezer {
>   public static void unfreeze(ActionMapping mapping) {
> mapping.configured = false;
>   }
> }
> 
> So, in processValidate(), I simply do:
> 
> if (request is a web service) [
>   ACUnfreezer.unfreeze(mapping);
>   mapping.setInput(the new JSP to go to in case of validation errors);
>   mapping.freeze(); // Just for good measure
> }
> return super.processValidate(request, response, form, mapping);
> 
> So, regular requests work as before, and the Web Service requests will be
> redirected if validation errors occur. Beautiful!
> 
> In an EXTREMELY hacky kind of way!
> 
> Thanks for the talkback Paul and Joe, I'm not sure how long it would have
> taken on my own to get to this solution, if at all.  Of course, I suppose
> that means you have to accept some of the blame for such a hack-job :)
> 
> -- 
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
> > This actually stimulated another thought.  Perhaps instead of
> > overriding process validate, you could arrange to have your
> > ActionMappings dynamically instantiated with the correct value for
> > "input" (assuming that you can know it before you do the validation.)
> > 
> > There is nothing sacred about the original instances of ActionMapping
> > which are created by processing the struts-config file.  The wildcard
> > mapping support results in dynamic construction of ActionMappings
> > which have parameters replaced according to the wildcard match.
> > 
> > You could either use your own ModuleConfig implementation with a
> > custom implementation of findActionConfig(path) or, if the
> > determination of the input depends on request data as well as the
> > path, override processMapping in the RequestProcessor.
> > 
> > I still think using the ComposableRequestProcessor is an easier solution!
> > 
> > Joe
> > 
> > 
> > At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
> >>Frank,
> >>
> >>I am not sure of why you need this solution. I never came across your
> >> need
> >>-- and perhaps because I never encountered the problem.
> >>
> >>I can't imagine why you would want to dynamically control the input page.
> >>For instance, I use MappingDispatchAction and each action entry has its
> >> own
> >>specified input and success forward.
> >>
> >>Is your question actually posed by a misdesign?
> >>
> >>Thanks,
> >>Paul
> >>
> >>-Original Message-
> >>From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
> >>Sent: Wednesday, February 02, 2005 12:39 PM
> >>To: dev@struts.apache.org
> >>Subject: Extending RequestProcessor to handle validation errors
> >>
> >>
> >>Hi folks... I'm working on an update of my Struts Web Services project,
> >>and I can't seem to work out how to do something...
> >>
> >>What I want to do is have a way to redirect to a given JSP when
> >> ActionForm
> >>validation errors occur that will OVERRIDE whatever might be configured
> >> in
> >>the action mapping.  In other words... in a normal application,
> >> validation
> >>errors occur and we get forwarded back to the input page.  I want to be
> >>able to redirect to a different JSP, REGARDLESS of what the input page
> >> is.
> >>
> >>I looked at overriding the processValidate() method of RequestProcessor,
> >>but I don't see how that can work... Looking at the source of the
> >> original
> >>RP (v1.1 this all is) I see that it does the forward and then returns a
> >>boolean, true if no errors occur or false otherwise, so it doesn't look
> >>like I have the opportunity to do something like the following
> >>psuedo-code:
> >>
> >>myOverriden_ProcessValidate() {
> >>
> >>   boolean b = super.processValidate();
> >

RE: Extending RequestProcessor to handle validation errors

[fzlists]

Excellent point!  It's done.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, February 2, 2005 2:23 pm, [EMAIL PROTECTED] said:
> i might put that freeze in a finally block, if you're gonna do something
> nasty,
> better make sure you leave no footprints. :)
> 
> 
> if (request is a web service) {
>   try {
> ACUnfreezer.unfreeze(mapping);
> mapping.setInput(the new JSP to go to in case of validation errors);
>   } finally {
> mapping.freeze(); // Just for good measure
>   }
> }
> 
> 
> Quoting [EMAIL PROTECTED]:
> 
>> GOT IT!
>>
>> But, this might be the worst piece of hackery I've ever done.  Check it
>> out...
>>
>> Joe's last response spurred me to realize that if I could override the
>> input
>> field of the ActionMapping, I could do what I want.  As I thought,
>> processPreprocess() fires before processValidate(), which means I can
>> identify a Web Service request in processValidate() based on some
>> attributes
>> I set in processPreprocess().
>>
>> The problem as I discovered is that I can't just call setInput() in
>> processValidate() because the configuration is frozen at that point. 
>> And,
>> since the RequestProcessor isn't in the same package as ActionConfig
>> (where
>> setInput() is found), I couldn't call setInput() since it's protected.
>>
>> So, enter the hackery of the following class...
>>
>> package org.apache.struts.config;
>>
>> import org.apache.struts.action.ActionMapping;
>> public class ACUnfreezer {
>>   public static void unfreeze(ActionMapping mapping) {
>> mapping.configured = false;
>>   }
>> }
>>
>> So, in processValidate(), I simply do:
>>
>> if (request is a web service) [
>>   ACUnfreezer.unfreeze(mapping);
>>   mapping.setInput(the new JSP to go to in case of validation errors);
>>   mapping.freeze(); // Just for good measure
>> }
>> return super.processValidate(request, response, form, mapping);
>>
>> So, regular requests work as before, and the Web Service requests will
>> be
>> redirected if validation errors occur. Beautiful!
>>
>> In an EXTREMELY hacky kind of way!
>>
>> Thanks for the talkback Paul and Joe, I'm not sure how long it would
>> have
>> taken on my own to get to this solution, if at all.  Of course, I
>> suppose
>> that means you have to accept some of the blame for such a hack-job :)
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>>
>> On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
>> > This actually stimulated another thought.  Perhaps instead of
>> > overriding process validate, you could arrange to have your
>> > ActionMappings dynamically instantiated with the correct value for
>> > "input" (assuming that you can know it before you do the validation.)
>> >
>> > There is nothing sacred about the original instances of ActionMapping
>> > which are created by processing the struts-config file.  The wildcard
>> > mapping support results in dynamic construction of ActionMappings
>> > which have parameters replaced according to the wildcard match.
>> >
>> > You could either use your own ModuleConfig implementation with a
>> > custom implementation of findActionConfig(path) or, if the
>> > determination of the input depends on request data as well as the
>> > path, override processMapping in the RequestProcessor.
>> >
>> > I still think using the ComposableRequestProcessor is an easier
>> solution!
>> >
>> > Joe
>> >
>> >
>> > At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
>> >>Frank,
>> >>
>> >>I am not sure of why you need this solution. I never came across your
>> >> need
>> >>-- and perhaps because I never encountered the problem.
>> >>
>> >>I can't imagine why you would want to dynamically control the input
>> page.
>> >>For instance, I use MappingDispatchAction and each action entry has
>> its
>> >> own
>> >>specified input and success forward.
>> >>
>> >>Is your question actually posed by a misdesign?
>> >>
>> >>Thanks,
>> >>Paul
>> >>
>> >>-Original Message-
>> >>From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
>> >>Sent: Wednesday, February 02, 2005 12:39 PM
>> >>To: dev@struts.apache.org
>> >>Subject: Extending RequestProcessor to handle validation errors
>> >>
>> >>
>> >>Hi folks... I'm working on an update of my Struts Web Services
>> project,
>> >>and I can't seem to work out how to do something...
>> >>
>> >>What I want to do is have a way to redirect to a given JSP when
>> >> ActionForm
>> >>validation errors occur that will OVERRIDE whatever might be
>> configured
>> >> in
>> >>the action mapping.  In other words... in a normal application,
>> >> validation
>> >>errors occur and we get forwarded back to the input page.  I want to
>> be
>> >>able to redirect to a different JSP, REGARDLESS of what the input page
>> >> is.
>> >>
>> >>I looked at overriding the processValidate() method of
>> RequestProcessor,
>> >>but I don't see how that can work... Looking at th

Re: Extending RequestProcessor to handle validation errors

[fzlists]

Yep, I found that out in short order.  My eMail client is driving me nuts 
today, some messages are going through right away, some are delayed 10-15 
minutes.  You'll probably see the other messages preceeding this one where I 
found that out, tossed some ideas around and finally settled on a solution.  
Not a pretty one, but it does have the virtue of working :)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, February 2, 2005 1:43 pm, Niall Pemberton said:
> The ActionMapping will be "frozen" and trying to set the input will throw
> an
> exception. You could get round this by overriding the processMapping()
> method and returning a "clone" of the ActionMapping.
> 
> Niall
> 
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, February 02, 2005 6:28 PM
> Subject: RE: Extending RequestProcessor to handle validation errors
> 
> 
>> On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
>> > This actually stimulated another thought.  Perhaps instead of
>> > overriding process validate, you could arrange to have your
>> > ActionMappings dynamically instantiated with the correct value for
>> > "input" (assuming that you can know it before you do the validation.)
>>
>> Actually, now you've stimulated a though in me! :)
>>
>> Correct me if I'm wrong, but processPreprocess() fires BEFORE
> processValidate(), correct?  In that case, since I can in fact determine
> the
> input after processPreprocess() fires, I can simply call setInput() on the
> mapping with the new value, and everything should work as expected.
>>
>> Sound about right to you Joe?
>>
>> > I still think using the ComposableRequestProcessor is an easier
> solution!
>>
> 
> 
> 
> -
> 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: Extending RequestProcessor to handle validation errors

[Joe Germuska]

I would recommend against unfreezing the ActionMappings; they are 
shared throughout the application, and you have no way of knowing 
whether some non-webservice request may come along in a minute and 
get the same ActionMapping instance and get stuck with an incorrect 
value for the "input" property.

As Niall mentioned (and I thought I did too, but maybe I just thought 
about mentioning it! ;-) ), it is possible to clone the ActionMapping 
and use a new instance for each request.  The precedent for this is 
already established by the ActionConfigMatcher which supports 
wild-card action mappings.

 Joe
At 2:23 PM -0500 2/2/05, [EMAIL PROTECTED] wrote:
i might put that freeze in a finally block, if you're gonna do 
something nasty,
better make sure you leave no footprints. :)

if (request is a web service) {
  try {
ACUnfreezer.unfreeze(mapping);
mapping.setInput(the new JSP to go to in case of validation errors);
  } finally {
mapping.freeze(); // Just for good measure
  }
}
Quoting [EMAIL PROTECTED]:
 GOT IT!
 But, this might be the worst piece of hackery I've ever done.  Check it
 out...
 Joe's last response spurred me to realize that if I could override the input
 field of the ActionMapping, I could do what I want.  As I thought,
 processPreprocess() fires before processValidate(), which means I can
 identify a Web Service request in processValidate() based on some attributes
 I set in processPreprocess().
 The problem as I discovered is that I can't just call setInput() in
 processValidate() because the configuration is frozen at that point.  And,
 since the RequestProcessor isn't in the same package as ActionConfig (where
 setInput() is found), I couldn't call setInput() since it's protected.
 So, enter the hackery of the following class...
 package org.apache.struts.config;
 import org.apache.struts.action.ActionMapping;
 public class ACUnfreezer {
   public static void unfreeze(ActionMapping mapping) {
 mapping.configured = false;
   }
 }
 So, in processValidate(), I simply do:
 if (request is a web service) [
   ACUnfreezer.unfreeze(mapping);
   mapping.setInput(the new JSP to go to in case of validation errors);
   mapping.freeze(); // Just for good measure
 }
 return super.processValidate(request, response, form, mapping);
 So, regular requests work as before, and the Web Service requests will be
 redirected if validation errors occur. Beautiful!
 In an EXTREMELY hacky kind of way!
 Thanks for the talkback Paul and Joe, I'm not sure how long it would have
 taken on my own to get to this solution, if at all.  Of course, I suppose
 that means you have to accept some of the blame for such a hack-job :)
 --
 Frank W. Zammetti
 Founder and Chief Software Architect
 Omnytex Technologies
 http://www.omnytex.com
 On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
 > This actually stimulated another thought.  Perhaps instead of
 > overriding process validate, you could arrange to have your
 > ActionMappings dynamically instantiated with the correct value for
 > "input" (assuming that you can know it before you do the validation.)
 >
 > There is nothing sacred about the original instances of ActionMapping
 > which are created by processing the struts-config file.  The wildcard
 > mapping support results in dynamic construction of ActionMappings
 > which have parameters replaced according to the wildcard match.
 >
 > You could either use your own ModuleConfig implementation with a
 > custom implementation of findActionConfig(path) or, if the
 > determination of the input depends on request data as well as the
 > path, override processMapping in the RequestProcessor.
 >
 > I still think using the ComposableRequestProcessor is an easier solution!
 >
 > Joe
 >
 >
 > At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
 >>Frank,
 > >>
 >>I am not sure of why you need this solution. I never came across your
 >> need
 >>-- and perhaps because I never encountered the problem.
 >>
 >>I can't imagine why you would want to dynamically control the input page.
 >>For instance, I use MappingDispatchAction and each action entry has its
 >> own
 >>specified input and success forward.
 >>
 >>Is your question actually posed by a misdesign?
 >>
 >>Thanks,
 >>Paul
 >>
 >>-Original Message-
 >>From: Frank W. Zammetti (MLists) [mailto:[EMAIL PROTECTED]
 >>Sent: Wednesday, February 02, 2005 12:39 PM
 >>To: dev@struts.apache.org
 >>Subject: Extending RequestProcessor to handle validation errors
 >>
 >>
 >>Hi folks... I'm working on an update of my Struts Web Services project,
 >>and I can't seem to work out how to do something...
 >>
 >>What I want to do is have a way to redirect to a given JSP when
 >> ActionForm
 >>validation errors occur that will OVERRIDE whatever might be configured
 >> in
 >>the action mapping.  In other words... in a normal application,
 >> validation
 >>errors occur and we get forwarded back to the input page.  I want to be
 >>able to redirect to a different JSP, REGARDLESS of what

RE: Extending RequestProcessor to handle validation errors

[fzlists]

That makes sense, cloning as Niall does sound right (shucks, had it working and 
done!).

Simple question: how should the mapping be cloned?  I mean, clearly when I 
override processMapping() I'll just call the super version and then clone what 
I recieve and return that, but how should I literally do the clone?  clone() in 
Object it's just a shallow copy, correct?  Is 
org.apache.commons.beanutils.BeanUtils.cloneBean() the right answer?  Just want 
to be sure I'm not missing something else I should be using.

Thanks again for all the help guys, this all I think makes my project quite a 
bit more useful!

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, February 2, 2005 2:37 pm, Joe Germuska said:
> I would recommend against unfreezing the ActionMappings; they are
> shared throughout the application, and you have no way of knowing
> whether some non-webservice request may come along in a minute and
> get the same ActionMapping instance and get stuck with an incorrect
> value for the "input" property.
> 
> As Niall mentioned (and I thought I did too, but maybe I just thought
> about mentioning it! ;-) ), it is possible to clone the ActionMapping
> and use a new instance for each request.  The precedent for this is
> already established by the ActionConfigMatcher which supports
> wild-card action mappings.
> 
>   Joe
> 
> 
> At 2:23 PM -0500 2/2/05, [EMAIL PROTECTED] wrote:
>>i might put that freeze in a finally block, if you're gonna do
>>something nasty,
>>better make sure you leave no footprints. :)
>>
>>
>>if (request is a web service) {
>>   try {
>> ACUnfreezer.unfreeze(mapping);
>> mapping.setInput(the new JSP to go to in case of validation errors);
>>   } finally {
>> mapping.freeze(); // Just for good measure
>>   }
>>}
>>
>>
>>Quoting [EMAIL PROTECTED]:
>>
>>>  GOT IT!
>>>
>>>  But, this might be the worst piece of hackery I've ever done.  Check
>>> it
>>>  out...
>>>
>>>  Joe's last response spurred me to realize that if I could override the
>>> input
>>>  field of the ActionMapping, I could do what I want.  As I thought,
>>>  processPreprocess() fires before processValidate(), which means I can
>>>  identify a Web Service request in processValidate() based on some
>>> attributes
>>>  I set in processPreprocess().
>>>
>>>  The problem as I discovered is that I can't just call setInput() in
>>>  processValidate() because the configuration is frozen at that point. 
>>> And,
>>>  since the RequestProcessor isn't in the same package as ActionConfig
>>> (where
>>>  setInput() is found), I couldn't call setInput() since it's protected.
>>>
>>>  So, enter the hackery of the following class...
>>>
>>>  package org.apache.struts.config;
>>>
>>>  import org.apache.struts.action.ActionMapping;
>>>  public class ACUnfreezer {
>>>public static void unfreeze(ActionMapping mapping) {
>>>  mapping.configured = false;
>>>}
>>>  }
>>>
>>>  So, in processValidate(), I simply do:
>>>
>>>  if (request is a web service) [
>>>ACUnfreezer.unfreeze(mapping);
>>>mapping.setInput(the new JSP to go to in case of validation errors);
>>>mapping.freeze(); // Just for good measure
>>>  }
>>>  return super.processValidate(request, response, form, mapping);
>>>
>>>  So, regular requests work as before, and the Web Service requests will
>>> be
>>>  redirected if validation errors occur. Beautiful!
>>>
>>>  In an EXTREMELY hacky kind of way!
>>>
>>>  Thanks for the talkback Paul and Joe, I'm not sure how long it would
>>> have
>>>  taken on my own to get to this solution, if at all.  Of course, I
>>> suppose
>>>  that means you have to accept some of the blame for such a hack-job :)
>>>
>>>  --
>>>  Frank W. Zammetti
>>>  Founder and Chief Software Architect
>>>  Omnytex Technologies
>>>  http://www.omnytex.com
>>>
>>>  On Wed, February 2, 2005 1:10 pm, Joe Germuska said:
>>>  > This actually stimulated another thought.  Perhaps instead of
>>>  > overriding process validate, you could arrange to have your
>>>  > ActionMappings dynamically instantiated with the correct value for
>>>  > "input" (assuming that you can know it before you do the
>>> validation.)
>>>  >
>>>  > There is nothing sacred about the original instances of
>>> ActionMapping
>>>  > which are created by processing the struts-config file.  The
>>> wildcard
>>>  > mapping support results in dynamic construction of ActionMappings
>>>  > which have parameters replaced according to the wildcard match.
>>>  >
>>>  > You could either use your own ModuleConfig implementation with a
>>>  > custom implementation of findActionConfig(path) or, if the
>>>  > determination of the input depends on request data as well as the
>>>  > path, override processMapping in the RequestProcessor.
>>>  >
>>>  > I still think using the ComposableRequestProcessor is an easier
>>> solution!
>>>  >
>>>  > Joe
>>>  >
>>>  >
>>>  > At 12:46 PM -0500 2/2/05, Benedict, Paul C wrote:
>>>  >>Frank,
>>  

Re: Extending RequestProcessor to handle validation errors

[Niall Pemberton]

BeanUtils.cloneBean() would work but it probably won't copy the
ExceptionConfigs / ForwardConfigs associated with the ActionMapping as there
aren't appropriately named getters/setters - but you could use
BeanUtils.cloneBean() to copy the other and then retrieve the
ExceptionConfigs / ForwardConfigs from the original mapping and add them in
idividually - as long as you're not modifying any of them theres no need to
clone them.

As you say, its a shame we don't have a way of cloning already built in
(ActionForward does - through a constructor which takes an ActionForward).
If it was me I would just create my own custom ActionMapping and have a
constructor which takes an ActionConfig and clones all its properties.

Niall

- Original Message - 
From: <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, February 02, 2005 7:57 PM
Subject: RE: Extending RequestProcessor to handle validation errors


> That makes sense, cloning as Niall does sound right (shucks, had it
working and done!).
>
> Simple question: how should the mapping be cloned?  I mean, clearly when I
override processMapping() I'll just call the super version and then clone
what I recieve and return that, but how should I literally do the clone?
clone() in Object it's just a shallow copy, correct?  Is
org.apache.commons.beanutils.BeanUtils.cloneBean() the right answer?  Just
want to be sure I'm not missing something else I should be using.
>
> Thanks again for all the help guys, this all I think makes my project
quite a bit more useful!
>
> -- 
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Wed, February 2, 2005 2:37 pm, Joe Germuska said:
> > I would recommend against unfreezing the ActionMappings; they are
> > shared throughout the application, and you have no way of knowing
> > whether some non-webservice request may come along in a minute and
> > get the same ActionMapping instance and get stuck with an incorrect
> > value for the "input" property.
> >
> > As Niall mentioned (and I thought I did too, but maybe I just thought
> > about mentioning it! ;-) ), it is possible to clone the ActionMapping
> > and use a new instance for each request.  The precedent for this is
> > already established by the ActionConfigMatcher which supports
> > wild-card action mappings.
> >
> >   Joe
> >
> >
> > At 2:23 PM -0500 2/2/05, [EMAIL PROTECTED] wrote:
> >>i might put that freeze in a finally block, if you're gonna do
> >>something nasty,
> >>better make sure you leave no footprints. :)
> >>
> >>
> >>if (request is a web service) {
> >>   try {
> >> ACUnfreezer.unfreeze(mapping);
> >> mapping.setInput(the new JSP to go to in case of validation
errors);
> >>   } finally {
> >> mapping.freeze(); // Just for good measure
> >>   }
> >>}
> >>
> >>
> >>Quoting [EMAIL PROTECTED]:
> >>
> >>>  GOT IT!
> >>>
> >>>  But, this might be the worst piece of hackery I've ever done.  Check
> >>> it
> >>>  out...
> >>>
> >>>  Joe's last response spurred me to realize that if I could override
the
> >>> input
> >>>  field of the ActionMapping, I could do what I want.  As I thought,
> >>>  processPreprocess() fires before processValidate(), which means I can
> >>>  identify a Web Service request in processValidate() based on some
> >>> attributes
> >>>  I set in processPreprocess().
> >>>
> >>>  The problem as I discovered is that I can't just call setInput() in
> >>>  processValidate() because the configuration is frozen at that point.
> >>> And,
> >>>  since the RequestProcessor isn't in the same package as ActionConfig
> >>> (where
> >>>  setInput() is found), I couldn't call setInput() since it's
protected.
> >>>
> >>>  So, enter the hackery of the following class...
> >>>
> >>>  package org.apache.struts.config;
> >>>
> >>>  import org.apache.struts.action.ActionMapping;
> >>>  public class ACUnfreezer {
> >>>public static void unfreeze(ActionMapping mapping) {
> >>>  mapping.configured = false;
> >>>}
> >>>  }
> >>>
> >>>  So, in processValidate(), I simply do:
> >>>
> >>>  if (request is a web service) [
> >>>ACUnfreezer.unfreeze(mapping);
> >>>mapping.setInput(the new JSP to go to in case of validation
errors);
> >>>mapping.freeze(); // Just for good measure
> >>>  }
> >>>  return super.processValidate(request, response, form, mapping);
> >>>
> >>>  So, regular requests work as before, and the Web Service requests
will
> >>> be
> >>>  redirected if validation errors occur. Beautiful!
> >>>
> >>>  In an EXTREMELY hacky kind of way!
> >>>
> >>>  Thanks for the talkback Paul and Joe, I'm not sure how long it would
> >>> have
> >>>  taken on my own to get to this solution, if at all.  Of course, I
> >>> suppose
> >>>  that means you have to accept some of the blame for such a hack-job
:)
> >>>
> >>>  --
> >>>  Frank W. Zammetti
> >>>  Founder and Chief Software Architect
> >>>  Omnytex Technologies
> >>>  http://www.omnytex.com
> >>>
> >>>  On Wed, February 2, 2005 1:10 pm, Joe 

svn commit: r151074 - in struts/core/trunk/src: share/org/apache/struts/action/ share/org/apache/struts/chain/commands/ share/org/apache/struts/util/ share/org/apache/struts/validator/ share/org/apache/struts/validator/validwhen/ test/org/apache/struts/action/ test/org/apache/struts/util/

[jmitchell]

Author: jmitchell
Date: Wed Feb  2 14:38:02 2005
New Revision: 151074

URL: http://svn.apache.org/viewcvs?view=rev&rev=151074
Log:
clean up a few duplicate or unnecessary imports and 2 useless (deprecated) 
calls in TestDynaActionFormClass.java

Modified:

struts/core/trunk/src/share/org/apache/struts/action/DynaActionFormClass.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExceptionHandler.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExecuteAction.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectAction.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectInput.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectLocale.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectModule.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/CreateAction.java

struts/core/trunk/src/share/org/apache/struts/chain/commands/CreateActionForm.java
struts/core/trunk/src/share/org/apache/struts/util/ResponseUtils.java
struts/core/trunk/src/share/org/apache/struts/validator/FieldChecks.java

struts/core/trunk/src/share/org/apache/struts/validator/LazyValidatorForm.java

struts/core/trunk/src/share/org/apache/struts/validator/validwhen/ValidWhenLexer.java

struts/core/trunk/src/test/org/apache/struts/action/TestDynaActionFormClass.java
struts/core/trunk/src/test/org/apache/struts/util/TestRequestUtils.java

Modified: 
struts/core/trunk/src/share/org/apache/struts/action/DynaActionFormClass.java
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/action/DynaActionFormClass.java?view=diff&r1=151073&r2=151074
==
--- 
struts/core/trunk/src/share/org/apache/struts/action/DynaActionFormClass.java 
(original)
+++ 
struts/core/trunk/src/share/org/apache/struts/action/DynaActionFormClass.java 
Wed Feb  2 14:38:02 2005
@@ -28,7 +28,6 @@
 import org.apache.commons.beanutils.DynaProperty;
 import org.apache.struts.config.FormBeanConfig;
 import org.apache.struts.config.FormPropertyConfig;
-import org.apache.struts.config.ModuleConfig;
 import org.apache.struts.util.RequestUtils;
 
 

Modified: 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExceptionHandler.java
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExceptionHandler.java?view=diff&r1=151073&r2=151074
==
--- 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExceptionHandler.java
 (original)
+++ 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExceptionHandler.java
 Wed Feb  2 14:38:02 2005
@@ -26,7 +26,6 @@
 import org.apache.struts.config.ExceptionConfig;
 import org.apache.struts.config.ForwardConfig;
 import org.apache.struts.config.ModuleConfig;
-import org.apache.struts.chain.Constants;
 
 
 /**

Modified: 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExecuteAction.java
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExecuteAction.java?view=diff&r1=151073&r2=151074
==
--- 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExecuteAction.java
 (original)
+++ 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractExecuteAction.java
 Wed Feb  2 14:38:02 2005
@@ -24,7 +24,6 @@
 import org.apache.struts.action.ActionForm;
 import org.apache.struts.config.ActionConfig;
 import org.apache.struts.config.ForwardConfig;
-import org.apache.struts.chain.Constants;
 
 
 /**

Modified: 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectAction.java
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectAction.java?view=diff&r1=151073&r2=151074
==
--- 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectAction.java
 (original)
+++ 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectAction.java
 Wed Feb  2 14:38:02 2005
@@ -24,7 +24,6 @@
 import org.apache.struts.chain.Constants;
 import org.apache.struts.config.ActionConfig;
 import org.apache.struts.config.ModuleConfig;
-import org.apache.struts.chain.Constants;
 
 
 /**

Modified: 
struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectInput.java
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/src/share/org/apache/struts/chain/commands/AbstractSelectInput.java?view=diff&r1=151073&r2=151074
==
--- 
struts/core/tru

svn commit: r151077 - struts/core/trunk/xdocs/userGuide/installation-jr30.xml

[jmitchell]

Author: jmitchell
Date: Wed Feb  2 14:47:56 2005
New Revision: 151077

URL: http://svn.apache.org/viewcvs?view=rev&rev=151077
Log:
fix missing  - my fault

Modified:
struts/core/trunk/xdocs/userGuide/installation-jr30.xml

Modified: struts/core/trunk/xdocs/userGuide/installation-jr30.xml
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/xdocs/userGuide/installation-jr30.xml?view=diff&r1=151076&r2=151077
==
--- struts/core/trunk/xdocs/userGuide/installation-jr30.xml (original)
+++ struts/core/trunk/xdocs/userGuide/installation-jr30.xml Wed Feb  2 14:47:56 
2005
@@ -177,6 +177,7 @@
 index.jsp, logon.jsp: Change  to 
>
 logon.jsp: Change  to >
 registration.jsp, subscription.jsp: Change all instances of filter="true" 
to filter=<%= true %>
+
   
   Back to Installation
 



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

DO NOT REPLY [Bug 33238] - Escape double quotes in JavascriptValidatorTag

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33238





--- Additional Comments From [EMAIL PROTECTED]  2005-02-03 01:02 ---
(In reply to comment #2)
If you require the double quotes to be escaped when generating the javascript, 
you would need to create your own custom validator, with the associated TLD 
file (before the patch is applied) and use the custom validator in your 
application.

Hopefully, more people would vote for this bug, so that the patch can be 
applied and we will be able to enjoy the feature by Struts 1.2.7 or Struts 
1.3.x.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r151103 - in struts/taglib/trunk/src: java/org/apache/struts/taglib/ java/org/apache/struts/taglib/html/ test/org/apache/struts/taglib/html/ test/org/apache/struts/taglib/logic/ webapp/test/java/org/apache/struts/action/ webapp/test/java/org/apache/struts/util/ webapp/test/java/org/apache/struts/validator/

[jmitchell]

Author: jmitchell
Date: Wed Feb  2 18:39:23 2005
New Revision: 151103

URL: http://svn.apache.org/viewcvs?view=rev&rev=151103
Log:
clean up a few duplicate or unnecessary imports and 2 useless (deprecated) 
calls in TestDynaActionFormClass.java

Modified:
struts/taglib/trunk/src/java/org/apache/struts/taglib/TagUtils.java
struts/taglib/trunk/src/java/org/apache/struts/taglib/html/ImgTag.java

struts/taglib/trunk/src/test/org/apache/struts/taglib/html/TestResetTag2.java

struts/taglib/trunk/src/test/org/apache/struts/taglib/logic/TestEqualTag.java

struts/taglib/trunk/src/webapp/test/java/org/apache/struts/action/TestDynaActionFormClass.java

struts/taglib/trunk/src/webapp/test/java/org/apache/struts/util/TestRequestUtils.java

struts/taglib/trunk/src/webapp/test/java/org/apache/struts/validator/PojoBean.java

Modified: struts/taglib/trunk/src/java/org/apache/struts/taglib/TagUtils.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/java/org/apache/struts/taglib/TagUtils.java?view=diff&r1=151102&r2=151103
==
--- struts/taglib/trunk/src/java/org/apache/struts/taglib/TagUtils.java 
(original)
+++ struts/taglib/trunk/src/java/org/apache/struts/taglib/TagUtils.java Wed Feb 
 2 18:39:23 2005
@@ -20,9 +20,7 @@
 
 import java.io.IOException;
 import java.lang.reflect.InvocationTargetException;
-import java.lang.reflect.Method;
 import java.net.MalformedURLException;
-import java.net.URLEncoder;
 import java.util.HashMap;
 import java.util.Iterator;
 import java.util.Locale;

Modified: struts/taglib/trunk/src/java/org/apache/struts/taglib/html/ImgTag.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/java/org/apache/struts/taglib/html/ImgTag.java?view=diff&r1=151102&r2=151103
==
--- struts/taglib/trunk/src/java/org/apache/struts/taglib/html/ImgTag.java 
(original)
+++ struts/taglib/trunk/src/java/org/apache/struts/taglib/html/ImgTag.java Wed 
Feb  2 18:39:23 2005
@@ -25,7 +25,6 @@
 import javax.servlet.http.HttpServletResponse;
 import javax.servlet.jsp.JspException;
 
-import org.apache.struts.Globals;
 import org.apache.struts.config.ModuleConfig;
 import org.apache.struts.taglib.TagUtils;
 import org.apache.struts.util.MessageResources;

Modified: 
struts/taglib/trunk/src/test/org/apache/struts/taglib/html/TestResetTag2.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/test/org/apache/struts/taglib/html/TestResetTag2.java?view=diff&r1=151102&r2=151103
==
--- 
struts/taglib/trunk/src/test/org/apache/struts/taglib/html/TestResetTag2.java 
(original)
+++ 
struts/taglib/trunk/src/test/org/apache/struts/taglib/html/TestResetTag2.java 
Wed Feb  2 18:39:23 2005
@@ -17,18 +17,15 @@
  */
 package org.apache.struts.taglib.html;
 
-import java.util.ArrayList;
-import java.util.HashMap;
 import java.util.Locale;
-import java.util.StringTokenizer;
 
 import javax.servlet.jsp.PageContext;
+
 import junit.framework.Test;
 import junit.framework.TestSuite;
 
 import org.apache.cactus.JspTestCase;
 import org.apache.struts.Globals;
-import org.apache.struts.taglib.SimpleBeanForTesting;
 
 /**
  * Suite of unit tests for the

Modified: 
struts/taglib/trunk/src/test/org/apache/struts/taglib/logic/TestEqualTag.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/test/org/apache/struts/taglib/logic/TestEqualTag.java?view=diff&r1=151102&r2=151103
==
--- 
struts/taglib/trunk/src/test/org/apache/struts/taglib/logic/TestEqualTag.java 
(original)
+++ 
struts/taglib/trunk/src/test/org/apache/struts/taglib/logic/TestEqualTag.java 
Wed Feb  2 18:39:23 2005
@@ -18,8 +18,8 @@
 package org.apache.struts.taglib.logic;
 
 import javax.servlet.ServletException;
-import javax.servlet.http.Cookie;
 import javax.servlet.jsp.JspException;
+
 import junit.framework.Test;
 import junit.framework.TestSuite;
 

Modified: 
struts/taglib/trunk/src/webapp/test/java/org/apache/struts/action/TestDynaActionFormClass.java
URL: 
http://svn.apache.org/viewcvs/struts/taglib/trunk/src/webapp/test/java/org/apache/struts/action/TestDynaActionFormClass.java?view=diff&r1=151102&r2=151103
==
--- 
struts/taglib/trunk/src/webapp/test/java/org/apache/struts/action/TestDynaActionFormClass.java
 (original)
+++ 
struts/taglib/trunk/src/webapp/test/java/org/apache/struts/action/TestDynaActionFormClass.java
 Wed Feb  2 18:39:23 2005
@@ -136,10 +136,8 @@
 
 public void tearDown() {
 
-DynaActionFormClass.clear();
 dynaClass = null;
 beanConfig = null;
-DynaActionFormClass.clear();
 
 }
 

Modified: 
struts/taglib/trunk/src/webapp/test/java/org/apache/struts/util/TestRequestUtils.java
UR

duplicate files

[James Mitchell]

In case anyone missed it in the last batch of commits, there are duplicate 
files under:

core/src/test
and
taglib/src/webapp/test/java
I'm sure I screwed up somewhere, but the weird thing isunder core/src, 
there's a "test" and a "test-cactus", which only serves to split 
TestActionServlet.java (and that's it!)  Other than that, there's no 
difference.  I'm guessing this was an attempt to split off what is needed by 
cactus, and what can be handled by Mock objectsbut not sure.

Anyone care to comment on this, or give me a suggestion which way to go?
I was planning to remove the ones from core, since the corresponding JSPs 
are already in taglib...your thoughts?

--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

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

Re: duplicate files

[Martin Cooper]

I moved TestActionServlet to test-cactus recently, as part of the
Maven build cleanup for core. The point is that Maven expects to find
JUnit tests in 'test' and the Cactus plugin expects to find Cactus
unit tests in 'test-cactus'. Once I moved that one class, both the
JUnit tests and the Cactus tests "just worked". I'd like to keep it
that way. ;-)

As far as duplicate files go, shouldn't it just be a case of
taglib-independent stuff goes in core, and taglib-dependent stuff goes
in taglib? Am I missing something?

--
Martin Cooper


On Wed, 2 Feb 2005 22:14:45 -0500, James Mitchell <[EMAIL PROTECTED]> wrote:
> In case anyone missed it in the last batch of commits, there are duplicate
> files under:
> 
> core/src/test
> 
> and
> 
> taglib/src/webapp/test/java
> 
> I'm sure I screwed up somewhere, but the weird thing isunder core/src,
> there's a "test" and a "test-cactus", which only serves to split
> TestActionServlet.java (and that's it!)  Other than that, there's no
> difference.  I'm guessing this was an attempt to split off what is needed by
> cactus, and what can be handled by Mock objectsbut not sure.
> 
> Anyone care to comment on this, or give me a suggestion which way to go?
> 
> I was planning to remove the ones from core, since the corresponding JSPs
> are already in taglib...your thoughts?
> 
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

DO NOT REPLY [Bug 33380] New: - I18nFactorySet hides methods unnecessarily

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33380

   Summary: I18nFactorySet hides methods unnecessarily
   Product: Struts
   Version: 1.2.4
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P4
 Component: Tiles framework
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


parseXmlFiles and parseXmlFile are unnecessarily private, making I18nFactorySet
difficult to extend. Similarly, calculatePostixes would be helpful as a
protected method so that it is even accessible from a subclass and does not need
to be static.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Extending RequestProcessor to handle validation errors

[Kishore Senji]

> if (request is a web service) [
>  ACUnfreezer.unfreeze(mapping);
>  mapping.setInput(the new JSP to go to in case of validation errors);

This might fail in the case where the Controller's 'inputForward' is
set to true.

I have couple of questions regarding the "jsp" that you want to go to
incase of a validation error.
* Is the path to that jsp going to be a constant one or is it going to
come from a config file
* Is the path to the jsp going to be constant no matter what
web-service you are going to execute (More precisely, does the path
depend on the ActionMapping)

If the answer is NO to the above questions then, there are two
relatively easy ways.

1) Override processValidate() like so

protected boolean processValidate(HttpServletRequest request,
  HttpServletResponse response,
  ActionForm form,
  ActionMapping mapping)
throws IOException, ServletException {


if(request is a webservice){
  ActionMapping am = new ActionMapping();
  
  // clone the whole bean as Niall and Joe suggested 
  // or just "input"
  
  am.setInput(moduleConfig.getControllerConfig().getInputForward() ?
"webservice_error_foward" : "/webservice_error_jsp.jsp");
}
else{
  am = mapping;
}

return super.validate(request, response, form, am);
 }

2) Override "processForwardConfig" and
"internalModuleRelativeForward". These are the two methods used by
processValidate() to forward or redirect when an input validation
happens. Just create a new method which checks whether validation
passed or not by looking in the request for ActionErrors

protected boolean isRequestValid(HttpServletRequest request){
 ActionErrors errors =
(ActionErrors)request.getAttribute(Globals.ERROR_KEY);
 return errors == null || errors.isEmpty();
}
 
protected void processForwardConfig(HttpServletRequest request,
HttpServletResponse response,
ForwardConfig forward)
throws IOException, ServletException {

boolean noErrors = isRequestValid(request);

if((!noErrors) && (request is a webservice)){
  doForward("/webservice_error_jsp.jsp", request, response);
}

return super.processForwardConfig(request, response, forward);
} 

protected void internalModuleRelativeForward(
String uri,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
url = isRequestValid(request) ? url : (request is a
webservice) ? "/webservice_error_jsp.jsp" : url;
return super.internalModuleRelativeForward(uri, request, response); 
   
}

There are pros and cons for the both hacks.

First one creates a new ActionMapping. If the validate() method on the
ActionForm is using the ActionMapping then you might have to clone the
entire bean as apposed to set setting the input. (If you consider
cloning as a con). Pros- You just change one method. Probably less
impact on the future releases of Struts.

Second one is simple though you have to change in two places. In
future releases Struts might choose to keep the ActionErrors under a
different key in the request (Although unlikely). Second one doesn't
have any knowledge about ActionMapping, so it's difficult to show
different error pages for different webservice invocations. (Now you
know why I asked those questions)

Thoughts?

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