Re: Extending RequestProcessor to handle validation errors
Hi Kishore, I've actually decided to not use this trick anyway, based on a point raised by Niall. I'll actually be cloning the ActionMapping and changing the input in that clone. I hope to actually implement this today, but I have a huge conference call most of the day, so we'll see. This might fail in the case where the Controller's 'inputForward' is set to true. I'm pretty sure my code would overrule that, but it winds up being I think amoot point in light of the above planned change. 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 It will come from a config file, or if none is used than it will be a default, which at least for the initial pass will be in a known place. I will probably have to decree that my webservices-config.xml file, which is now optional, is required eventually because that's where a setting like the default would be placed. I'm going through this iteratively though, so I don't mind leaving one or two limitations in it the first time through. * 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) Same answer as above... as it currently stands, what you do, usually, is create a webservices-config.xml file. This contains all the settings to turn a regular mapping into a Web Service. One of the things you can set is what JSP to use for generating the response, and now you can also set what JSP to use for validation failures. If the answer is NO to the above questions then, there are two relatively easy ways. 1) Override processValidate() like so [snip] 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 [snip] Thoughts? I'm leaning towards the first approach, but I frankly have to take some time to digest what you've written here. I'm just about to leave for work, and I hope to have some time to work on this today, otherwise tonight. Thank you for your suggestions, I'll let you know which way I go. -- 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]
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]
RE: Extending RequestProcessor to handle validation errors
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
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
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
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
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 (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
RE: Extending RequestProcessor to handle validation errors
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
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
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: dev@struts.apache.org 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]
RE: Extending RequestProcessor to handle validation errors
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
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
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-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
RE: Extending RequestProcessor to handle validation errors
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();
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
RE: Extending RequestProcessor to handle validation errors
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 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
Re: Extending RequestProcessor to handle validation errors
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: dev@struts.apache.org 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
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 the input page
is.
I looked at overriding the processValidate() method
RE: Extending RequestProcessor to handle validation errors
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]
--
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extending RequestProcessor to handle validation errors
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: dev@struts.apache.org
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 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
