[Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction

[dev]

   Date: 2004-09-17T00:16:40
   Editor: MichaelMcGrady <[EMAIL PROTECTED]>
   Wiki: Apache Struts Wiki
   Page: StrutsCatalogSimpleDispatchAction
   URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction

   no comment

Change Log:

--
@@ -103,15 +103,21 @@
 String methodName  = null;
 String buttonValue = null;
 String parameter   = mapping.getParameter();
-
-if((parameter != null) && (parameter.endsWith(".x"))) {
-  methodName = parameter.substring(0,parameter.indexOf('.'));
+if((parameter != null) && (parameter.startsWith("method."))) {
+  methodName = parameter.replaceFirst("method.","");
 } else {
   Enumeration enum = request.getParameterNames();
   while(enum.hasMoreElements()) {
 buttonValue = (String)enum.nextElement();
-if(buttonValue.endsWith(".x")) {
-  methodName = buttonValue.substring(0,buttonValue.indexOf(".x"));
+if(buttonValue.startsWith("method.")) {
+  methodName = buttonValue.replaceFirst("method.","");
+  if(methodName.endsWith(".x")) {
+methodName = methodName.replaceFirst(".x","");
+  }
+  if(buttonValue.endsWith(".y")) {
+methodName = methodName.replaceFirst(".y","");
+  }
+  break;
 }
   }
 }

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

[Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction

[dev]

   Date: 2004-09-17T00:25:47
   Editor: MichaelMcGrady <[EMAIL PROTECTED]>
   Wiki: Apache Struts Wiki
   Page: StrutsCatalogSimpleDispatchAction
   URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction

   no comment

Change Log:

--
@@ -268,14 +268,22 @@
String methodName  = null;
String buttonValue = null;
String parameter   = mapping.getParameter();
-if((parameter != null) && (parameter.endsWith(".x"))) {
-  methodName = parameter.substring(0,parameter.indexOf('.'));
+
+if((parameter != null) && (parameter.startsWith("method."))) {
+  methodName = parameter.replaceFirst("method.","");
 } else {
   Enumeration enum = request.getParameterNames();
   while(enum.hasMoreElements()) {
 buttonValue = (String)enum.nextElement();
-if(buttonValue.endsWith(".x")) {
-  methodName = buttonValue.substring(0,buttonValue.indexOf(".x"));
+if(buttonValue.startsWith("method.")) {
+  methodName = buttonValue.replaceFirst("method.","");
+  if(methodName.endsWith(".x")) {
+methodName = methodName.replaceFirst(".x","");
+  }
+  if(buttonValue.endsWith(".y")) {
+methodName = methodName.replaceFirst(".y","");
+  }
+  break;
 }
   }
 }
@@ -373,18 +381,19 @@
 
 
 
-On this we differ. I think the version of SimpleDispatchAction I posted does exactly 
the same as you're version (caveat requires slight modification to DispatchAction) but 
does't bloat the code base by duplicating the majority of whats already in 
DispatchAction. Fundamentally all these things, including SimpleDispatchAcion, do the 
same thing (i.e. use reflection to execute a specified method) and only differ 
slightly code-wise in how they determine the method name.
+On this we differ. I think the version of !SimpleDispatchAction I posted does exactly 
the same as you're version (caveat requires slight modification to !DispatchAction) 
but does't bloat the code base by duplicating the majority of whats already in 
!DispatchAction. Fundamentally all these things, including !SimpleDispatchAcion, do 
the same thing (i.e. use reflection to execute a specified method) and only differ 
slightly code-wise in how they determine the method name.
 
-On the suggestion of factoring out all this code into RequestUtils, I have the 
following comments:
+On the suggestion of factoring out all this code into !RequestUtils, I have the 
following comments:
 
- * All these static utility classes provide a headache because you can't override 
their static methods if you want to modify their behaviour. RequestUtils is just such 
a case - if RequestUtils was refactored to be just a facade to a bean (in the way 
BeanUtils has been) where you can set a custom instance to use then it would resolve 
this. But as it stands these kind of things are a pain - especially in this kind of 
case where alot of the code is the same and you just want to change small parts of the 
behaviour.
+ * All these static utility classes provide a headache because you can't override 
their static methods if you want to modify their behaviour. !RequestUtils is just such 
a case - if !RequestUtils was refactored to be just a facade to a bean (in the way 
!BeanUtils has been) where you can set a custom instance to use then it would resolve 
this. But as it stands these kind of things are a pain - especially in this kind of 
case where alot of the code is the same and you just want to change small parts of the 
behaviour.
 
- * Currently DispatchAction only does the reflection to get the methods once and then 
caches them in a Map - moving this into RequestUtils would mean it would have to use 
reflection each time the method is called.
+ * Currently !DispatchAction only does the reflection to get the methods once and 
then caches them in a Map - moving this into !RequestUtils would mean it would have to 
use reflection each time the method is called.
 
-I do like Hubert's suggestion factoring the code out of Action altogether and not 
having to inherit from a specific super class. I have put together a ActionDispatcher 
class and attached the code to a bug here:
+I do like Hubert's suggestion factoring the code out of Action altogether and not 
having to inherit from a specific super class. I have put together a !ActionDispatcher 
class and attached the code to a bug here:
 
   [http://issues.apache.org/bugzilla/show_bug.cgi?id=31270 Bug 31270]
 
 '''Niall Pemberton'''
 
 
+'''Unfortunately, Niall, you assumed for some reason I was talking about your code.  
I was not talking about your code.  Notice that I did not subclass DispatchAction in 
SimpleDispatchAction so there could have been no code bloat.  In fact, I did not 
subclass DispatchAction beca

[Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction

[dev]

   Date: 2004-09-17T00:29:55
   Editor: MichaelMcGrady <[EMAIL PROTECTED]>
   Wiki: Apache Struts Wiki
   Page: StrutsCatalogSimpleDispatchAction
   URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction

   no comment

Change Log:

--
@@ -113,8 +113,7 @@
   methodName = buttonValue.replaceFirst("method.","");
   if(methodName.endsWith(".x")) {
 methodName = methodName.replaceFirst(".x","");
-  }
-  if(buttonValue.endsWith(".y")) {
+  } else if(buttonValue.endsWith(".y")) {
 methodName = methodName.replaceFirst(".y","");
   }
   break;
@@ -183,7 +182,6 @@
 '''Please note that if you like configuring struts-config.xml and like 
!MappingDispatchAction, !SimpleDispatchAction does everything that class does and 
more.'''
 
 
-'''Michael !McGrady'''
 
 '''Following a suggestion of Hubert Rabago, I have constructed a utility class 
!DispatchUtil so that you can get the same result by using'''
 {{{
@@ -279,8 +277,7 @@
   methodName = buttonValue.replaceFirst("method.","");
   if(methodName.endsWith(".x")) {
 methodName = methodName.replaceFirst(".x","");
-  }
-  if(buttonValue.endsWith(".y")) {
+  } else if(buttonValue.endsWith(".y")) {
 methodName = methodName.replaceFirst(".y","");
   }
   break;
@@ -323,6 +320,16 @@
   }
 }
 }}}
+
+
+
+'''Michael !McGrady'''
[EMAIL PROTECTED]
+
+
+
+
+
 
 
 

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

[Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction

[dev]

   Date: 2004-09-17T00:38:15
   Editor: MichaelMcGrady <[EMAIL PROTECTED]>
   Wiki: Apache Struts Wiki
   Page: StrutsCatalogSimpleDispatchAction
   URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction

   no comment

Change Log:

--
@@ -5,27 +5,23 @@
 
 '''Assume that you have ''button'' code not unlike:'''
 
-'''PAY ATTENTION TO THE OCCURENCE OF .x IN THE FOLLOWING CODE.'''
+'''PAY ATTENTION TO THE OCCURENCE OF "method." IN THE FOLLOWING CODE.'''
 
 '''LINKS:'''
 {{{
-UPDATE
-DELETE
+UPDATE
+DELETE
 }}}
 '''FORM SUBMITS:'''
 {{{
-UPDATE
-DELETE
+UPDATE
+DELETE
 }}}
 '''IMAGES:'''
 {{{
-
-
+
+
 
-or
-
-
-
 }}}
 
 '''or the equivalent, in the various Struts' image taglibs:'''
@@ -382,7 +378,7 @@
 
 '''Thanks, Niall, HOWEVER'''
 
-This is fundametally mistaken, Niall, and rests on an important misconception.  The 
data and the logic of !SimpleDispatchAction differ from all of !DispatchAction, 
!LookupDispatchAction, and !MappingDispatchAction.  The error here is thinking that 
just because they all get the name of the method to call that anything else is just a 
mere difference in internal logic.  That is not the case.  Using one instead of the 
other will break the code in lots of ways, and there are huge diffences between these 
classes.  None of the data used for the struts existing dispatch classes is used to 
determine the method in the !SimpleDispatchAction.  For those interested in this 
approach, I suggest you read the exchanges on the struts-dev apache list.
+This is fundametally mistaken, Niall, and rests on an important misconception.  The 
data and the logic of !SimpleDispatchAction differ from all of !DispatchAction, 
!LookupDispatchAction, and !MappingDispatchAction.  The error here is thinking that 
just because they all get the name of the method to call that anything else is just a 
mere difference in internal logic.  That is not the case.  Using one instead of the 
other will break the code in lots of ways, and there are huge diffences between these 
classes.  None of the data used for the struts existing dispatch classes is used to 
determine the method in the !SimpleDispatchAction.  For those interested in this 
approach, I suggest you read the exchanges on the struts-dev apache list.  
!SimpleDispatchAction certainly should not subclass !DispatchAction.  That just piles 
unwanted and useless code bloat into !SimpleDispatchAction.
 
 '''Michael !McGrady'''
 

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

Maven and SVN [was: Re: [VOTE] Struts 1.2.4 Quality]

[James Mitchell]

On the topic of Maven and SVN...

SVN:
We have discussed moving our current repository over to SVN and I know there
are fancy scripts to do the conversion and all.  We also have been
discussing what 1.2.x, 1.3.x, and maybe 1.4.x will be adding vs. what 2.0
will bring.

Would it make sense just to 'start 2.0 from scratch'?  What I mean is, we
can have SVN setup for 2.0 development without the confusion and mess of the
existing repository.  I know SVN makes moving files/directories easy, but
given the minimum specs we intend to move to, there is just too many hacks
and old code in the existing source for supporting the old specs.  Starting
with a clean slate just seems to make the most sense to me.  Do you agree?


Maven:
I have spent many hours over the last few weeks over in the commons sandbox
'playing around' with Maven (pun intended).  I moved the Hibernate resource
implementation (and tests) over to sf.net.  Both distributions are 100%
mavenized.

I may have been critical of Maven in the past, but I have earned a new
appreciation for this tool.  It really is far superior to just using Ant.  I
believe no matter what path we take, with regards to SVN, that we should
move our primary build system to Maven.  We will lose nothing from what the
current Ant script does, and yes, I am volunteering to help with this.

So, that said, I am +1 for setting up a clean slate (2.0) on SVN and making
it a 100% Mavenized build (multiproject).


Your thoughts?


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




- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, September 16, 2004 6:06 PM
Subject: Re: [VOTE] Struts 1.2.4 Quality


I'm not using Struts in production myself right now, so I'm going to abstain
from voting in favor of them that do. :)

I do still plan to help support the release once it is out.

As to the voting in general ...

On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> I wouldn't veto GA, but I'm not ready to say that I think this
> release is GA either.

A release is a majority vote. It can't be blocked by a veto. If there are 3
+1s and more (binding) +1s than -1s, the vote passes. (So, as of now, the
vote passes. By convention, we wait 72 hours before taking action on a vote,
so that people have a chance to weigh in.)

Any PMC Member can unilaterally veto changes to the codebase and
documentation on technical grounds (consensus vote), but most everything
else is a (political) majority vote. No one person can block a release.

On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> I vote "beta", because I haven't had (and won't have) time to test
> it, and I see no reason to rush to call it GA.

:) Then you probably shouldn't vote it beta, either. :)


> I thought the whole
> point of the new releasing scheme was to allow us to not have to
> cut a new release if beta testing truly demonstrated release
> quality.

As I understand it, the point of the new releasing scheme is to

* avoid re-tagging and re-rolling the final beta in a series, if it is
otherwise ready to go.

* reduce the need to "freeze" the repository for any longer than absolutely
necessary.

Aside from all that, a *huge* problem for Struts is that we keep making GA
releases "triggers" for other events.

* We decided not to transfer the repository to SVN until after we had put a
1.2.x GA release to bed.

* Until we have a Struts 1.2.x GA, we're also holding the Struts Chain in
abeyance, along with other proposed changes.

* Until we have a Struts under SVN, everyone is reluctant to move forward
with reorganizing the project, so we don't have to release *everything* at
once. (Ironic, this one, since the reorganization would simplify the
releases that are preventing us from reorganizing.)

* Pending the reorganization, we have held off introducing new sub projects,
like Struts Scripting.

So, you see, a 1.2.x GA is the first in a long line of dominoes -- bam, bam,
bam, bam, bam.

Of course, the biggest reason of all to bring out a GA release is that:

*** until we can stamp 1.2.x GA, over a year's worth Struts development is
unavailable to thousands of teams that use Struts, but can't use anything
but a GA. ***

Sad, but true.

We shouldn't stamp it GA unless it is GA. But, yes, it *is* urgent that  we
determine whether 1.2.4 is GA or not, so we can fix it and and roll it
again, or let it go and move on.

-Ted.




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

Hello Friends

[Kranti Parisa]

Hello Friends,
This 
is Kranti Parisa, Software Engineer.
I am 
working with Patni Computer Systems Ltd.
Our 
Project using the Struts Framework.
 
So I 
will be in this mailing list from 2day onwards...
 
Have 
a nice time..
 
Bye 
for now
Thanks & Regards
Kranti Kiran Kumar 
Parisa  Software Engineer [ e-Biz ] 

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

RE: Hello Friends

[Sachin Bhutada]

hi Kranti,
 
welcome to the world of Struts 
 
sachin
xoriant, mumbai

-Original Message-
From: Kranti Parisa [mailto:[EMAIL PROTECTED]
Sent: Friday, September 17, 2004 3:23 PM
To: [EMAIL PROTECTED]
Subject: Hello Friends


Hello Friends,
This is Kranti Parisa, Software Engineer.
I am working with Patni Computer Systems Ltd.
Our Project using the Struts Framework.
 
So I will be in this mailing list from 2day onwards...
 
Have a nice time..
 
Bye for now

Thanks & Regards

Kranti Kiran Kumar Parisa 
 Software Engineer [ e-Biz ] 

Re: Hello Friends

[James Mitchell]

Yes, welcome.  Be sure you are subscribed to the user list.  The Dev list is
for questions about the source code for the framework itself, not how to use
it.



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

- Original Message -
From: "Sachin Bhutada" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 5:38 AM
Subject: RE: Hello Friends


> hi Kranti,
>
> welcome to the world of Struts
>
> sachin
> xoriant, mumbai
>
> -Original Message-
> From: Kranti Parisa [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 17, 2004 3:23 PM
> To: [EMAIL PROTECTED]
> Subject: Hello Friends
>
>
> Hello Friends,
> This is Kranti Parisa, Software Engineer.
> I am working with Patni Computer Systems Ltd.
> Our Project using the Struts Framework.
>
> So I will be in this mailing list from 2day onwards...
>
> Have a nice time..
>
> Bye for now
>
> Thanks & Regards
>
> Kranti Kiran Kumar Parisa
>  Software Engineer [ e-Biz ]
>
>


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

Re: Maven and SVN [was: Re: [VOTE] Struts 1.2.4 Quality]

[David Graham]

I don't think we have the volunteer hours to support starting from scratch
and do you really want to rewrite ActionServlet, Action, etc.?  IMO, we
have a lot of tested, used, stable code that we should continue to use.

You're right that we have some crufty old stuff that needs to be removed
(all jsp tags not in the html lib for example) but it's easier to delete
these items than starting from scratch.  Let's use Subversion's abilities
to their fullest and just move things around as needed.

IMO, the current Ant build is hopelessly complex and a major obstacle to
cutting releases.  Not that Ant itself is bad but the simplicity of
running 'maven clean dist' on every Commons project to get all build
artifacts is a dream compared to Struts' build.

David


--- James Mitchell <[EMAIL PROTECTED]> wrote:

> On the topic of Maven and SVN...
> 
> SVN:
> We have discussed moving our current repository over to SVN and I know
> there
> are fancy scripts to do the conversion and all.  We also have been
> discussing what 1.2.x, 1.3.x, and maybe 1.4.x will be adding vs. what
> 2.0
> will bring.
> 
> Would it make sense just to 'start 2.0 from scratch'?  What I mean is,
> we
> can have SVN setup for 2.0 development without the confusion and mess of
> the
> existing repository.  I know SVN makes moving files/directories easy,
> but
> given the minimum specs we intend to move to, there is just too many
> hacks
> and old code in the existing source for supporting the old specs. 
> Starting
> with a clean slate just seems to make the most sense to me.  Do you
> agree?
> 
> 
> Maven:
> I have spent many hours over the last few weeks over in the commons
> sandbox
> 'playing around' with Maven (pun intended).  I moved the Hibernate
> resource
> implementation (and tests) over to sf.net.  Both distributions are 100%
> mavenized.
> 
> I may have been critical of Maven in the past, but I have earned a new
> appreciation for this tool.  It really is far superior to just using
> Ant.  I
> believe no matter what path we take, with regards to SVN, that we should
> move our primary build system to Maven.  We will lose nothing from what
> the
> current Ant script does, and yes, I am volunteering to help with this.
> 
> So, that said, I am +1 for setting up a clean slate (2.0) on SVN and
> making
> it a 100% Mavenized build (multiproject).
> 
> 
> Your thoughts?
> 
> 
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> 
> 
> 
> - Original Message -
> From: "Ted Husted" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Thursday, September 16, 2004 6:06 PM
> Subject: Re: [VOTE] Struts 1.2.4 Quality
> 
> 
> I'm not using Struts in production myself right now, so I'm going to
> abstain
> from voting in favor of them that do. :)
> 
> I do still plan to help support the release once it is out.
> 
> As to the voting in general ...
> 
> On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> > I wouldn't veto GA, but I'm not ready to say that I think this
> > release is GA either.
> 
> A release is a majority vote. It can't be blocked by a veto. If there
> are 3
> +1s and more (binding) +1s than -1s, the vote passes. (So, as of now,
> the
> vote passes. By convention, we wait 72 hours before taking action on a
> vote,
> so that people have a chance to weigh in.)
> 
> Any PMC Member can unilaterally veto changes to the codebase and
> documentation on technical grounds (consensus vote), but most everything
> else is a (political) majority vote. No one person can block a release.
> 
> On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> > I vote "beta", because I haven't had (and won't have) time to test
> > it, and I see no reason to rush to call it GA.
> 
> :) Then you probably shouldn't vote it beta, either. :)
> 
> 
> > I thought the whole
> > point of the new releasing scheme was to allow us to not have to
> > cut a new release if beta testing truly demonstrated release
> > quality.
> 
> As I understand it, the point of the new releasing scheme is to
> 
> * avoid re-tagging and re-rolling the final beta in a series, if it is
> otherwise ready to go.
> 
> * reduce the need to "freeze" the repository for any longer than
> absolutely
> necessary.
> 
> Aside from all that, a *huge* problem for Struts is that we keep making
> GA
> releases "triggers" for other events.
> 
> * We decided not to transfer the repository to SVN until after we had
> put a
> 1.2.x GA release to bed.
> 
> * Until we have a Struts 1.2.x GA, we're also holding the Struts Chain
> in
> abeyance, along with other proposed changes.
> 
> * Until we have a Struts under SVN, everyone is reluctant to move
> forward
> with reorganizing the project, so we don't have to release *everything*
> at
> once. (Ironic, this one, since the reorganization would simplify the
> releases that are preventing us from reorganizing.)
> 
> * Pending the reorganization, we have held off introd

Re: Maven and SVN [was: Re: [VOTE] Struts 1.2.4 Quality]

[Ted Husted]

Writing from the perspective of this roadmap:

  http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=27450



If I were working on Struts NEXT (or 2.x), I'd agree that it would be best to start 
with a clean slate. My suggestion would be to make it a story-and-test driven design. 
That's how I write my own applications now, and it works beautifully. We'd of course 
adopt a lot of code outright, but it would be better to think before pasting :)

But, I don't agree that we can discontinue work on Struts 1.x while people chug away 
on Struts 2.x.

I'm using SVN fulltime now. I strongly prefer SVN to CVS. I do plan to keep applying 
patches people submit to the Struts 1.x series. I would prefer to apply those patches 
using SVN rather than CVS. I would also prefer to have the complete change-history 
under SVN, which is something the conversion scripts would buy us.

And, I would also strongly prefer that we complete the migration to Maven for 1.3  :)

It appears that a Struts 1.2.4 GA release is imminent. Accordingly, I would ask that 
we give Don the go-ahead on the SVN conversion, so we can shuffle things around into 
subprojects (as long-intended), and put each subproject on Maven.

We had projected Sept 17 for the SVN date, which is today. I think we should stick to 
that, regardless of the failed 1.2.3 distribution, and let Don go ahead. If 1.2.4 
doesn't make the grade, we can roll 1.2.5 under SVN. It's not a big deal.

-Ted.

On Fri, 17 Sep 2004 04:48:54 -0400, James Mitchell wrote:
> On the topic of Maven and SVN...
>
> SVN:
> We have discussed moving our current repository over to SVN and I
> know there are fancy scripts to do the conversion and all.  We also
> have been discussing what 1.2.x, 1.3.x, and maybe 1.4.x will be
> adding vs. what 2.0 will bring.
>
> Would it make sense just to 'start 2.0 from scratch'?  What I mean
> is, we can have SVN setup for 2.0 development without the confusion
> and mess of the existing repository.  I know SVN makes moving
> files/directories easy, but given the minimum specs we intend to
> move to, there is just too many hacks and old code in the existing
> source for supporting the old specs.  Starting with a clean slate
> just seems to make the most sense to me.  Do you agree?
>
>
> Maven:
> I have spent many hours over the last few weeks over in the commons
> sandbox 'playing around' with Maven (pun intended).  I moved the
> Hibernate resource implementation (and tests) over to sf.net.  Both
> distributions are 100% mavenized.
>
> I may have been critical of Maven in the past, but I have earned a
> new appreciation for this tool.  It really is far superior to just
> using Ant.  I believe no matter what path we take, with regards to
> SVN, that we should move our primary build system to Maven.  We
> will lose nothing from what the current Ant script does, and yes, I
> am volunteering to help with this.
>
> So, that said, I am +1 for setting up a clean slate (2.0) on SVN
> and making it a 100% Mavenized build (multiproject).
>
>
> 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]

wrapping of POJO's with WrapDyanBean

[bryan]

Hello and sorry to disturb everyone, 

I want to use Niall Pemberton's wrapping on POJO's addition to 
struts for my application.  

I personally see it as a great idea that removes one of the main
reasons why I might use spring over struts ie having to inherit 
from ActionForm or whatever. 

However before I commit to this approach and start coding 
my application arround it I have to ask the question.

Is it an accepted change and does struts team intend to preserve 
this change going forward ? 

--b

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

Re: [VOTE] Struts 1.2.4 Quality

[Don Brown]

I tested my production application with the 1.2.4 build and everything 
checks out which is quite encouraging as I tend to utilize a number of 
Struts extension projects.  I'm really looking forward to working 1.3.x 
though, even if it requires Maven :) 

Don
Martin Cooper wrote:
The Struts 1.2.4 test build has been available for a few days now. 
Once you have had a chance to form an opinion on the quality of this 
build, please respond to the following vote.

-
Based on its quality, the Struts 1.2.4 build should be classified as:
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
-
If you are voting for Alpha or Beta, please state your concerns with 
the build as it is today.

Only the votes of Struts PMC members are binding. However, all 
opinions and feedback are welcome.

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

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

[Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction

[dev]

   Date: 2004-09-17T07:53:09
   Editor: NiallPemberton <[EMAIL PROTECTED]>
   Wiki: Apache Struts Wiki
   Page: StrutsCatalogSimpleDispatchAction
   URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction

   no comment

Change Log:

--
@@ -400,3 +400,25 @@
 
 
 '''Unfortunately, Niall, you assumed for some reason I was talking about your code.  
I was not talking about your code.  Notice that I did not subclass DispatchAction in 
SimpleDispatchAction so there could have been no code bloat.  In fact, I did not 
subclass DispatchAction because I don't like the code bloat in that Action.  I was 
talking about your understanding of this class.  I wish you would slow down and see 
what is going on before making all these decisions.  I suppose calmer reflection will 
eventually prevail but presently you are doing things while clearly misapprehending 
what is going on with this class.  You might take some pause at that statement, since 
I am the author of the class in the frist instance.  However, as I said, time will 
tell.  I think I know my class alright.'''
+
+
+
+ * I did notice that your SimpleDispatchAction didn't subclass DispatchAction and my 
comment about code bloat is just the fact that you have duplicated almost everything 
in DispatchAction in your SimpleDispatchAction rather than sub-classing it and 
re-using the code. The only ''real'' difference is in the contents of the 
getMethodName() method. Comparing the SimpleDispatchAction methods to DispatchAction:
+
+* execute() - same code '''except''' SimpleDispatchAction doesn't handle 
cancelled and doesn't retrieve a parameter from the action mapping.
+* unspecified() - identical to DispatchAction
+* cancelled() - identical to DispatchAction
+* dispatchMethod() - identical to DispatchAction
+* getMethod() - identical to DispatchAction
+
+
+
+ * I don't see any 'bloat' in DispatchAction and think you're talking nonsense.
+
+ * I'm not making any decisions - just taking part in a debate - so I don't 
understand that comment.
+
+ * Seems to me that its you thats misapprehending whats going on and I can't 
understand why you can't see that SimpleDispatchAction is ''almost'' identical to 
DispatchAction.
+
+
+'''Niall Pemberton'''
+

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

Re: DispatchAction

[Rick Reumann]

Now my 1 cent worth:)...
(sorry if this is wordy but I do wish some of you comment on it.. esp 
Martin and Niall because I'd be interested in your approaches)..

First off, I've used all the flavors of DispatchAction available so I'm 
familiar with their use. I'm certainly anti LookupDispatchAction ( could 
give plenty of reasons why but that's not the topic of this). At the 
moment I'm not bigoted one way or the other 'yet:)' towards use of the 
regular Dispatch, MappingDispatch, or Michael's SimpleDispatch.

Some thoughts first. One of the benefits in using Struts is that in the 
end it reduces the time it takes to develop a web application and makes 
it easy to maintain.  The main reason I like the use of a DispatchAction 
is in regard to situations where you have multiple buttons on a form.

*Without using Javascript to swap out the form Action name, I'm curious 
how you guys accomplish using multiple buttons for a form without the 
use of a DispatchAction?* I know Martin and Niall said they don't like 
the DispatchAction so I am particularly interested in their approach to 
this. If I could solve that problem cleanly I might consider going back 
to separate regular Action classes to handle things - 
(EmployeeUpdateAction, EmployeeSetUpAction, EmployeeDeleteAction, etc). 
( We could also debate whether a DispatchAction organizes things better 
- all CRUD in one related class -  which I'd actually argue that a 
DispatchAction really does NOT help that much does save some typing, 
especially in regard to the Struts config.. but that's not too big a 
deal imo). Separate Actions would be fine for me if I could figure out 
the multiple button issue.

For example maybe a user form with two buttons "Update" and "Delete" 
which will either update the user information displayed or delete the 
user you are looking at. I'm curious how you would tackle this? You 
could of course submit to one regular Action that will look at the 
parameters but then you end up doing what a DispatchAction does. You 
could use Javascript to swap out the action name for the form (not a bad 
approach really. I was doing this). (Probably this example above is bad 
because in reality to do the delete all you would need is the delete 
button have an onClick that goes to a different Action passing in the 
user id and not really submit the form, but there are plenty of real 
life cases that do come up where you need the form submitted and do 
different things bases on what submit button was clicked).

What I do like about the SimpleDispatchAction is it does make things 
'simple' you have one consistent way to handle all scenarios.

The main benefit I find in the use of the SimpleDispatchAction is that 
it handles the problem of multiple buttons or images on a form without 
having to use javascript to set a hidden dispatch parameter (or without 
having to use javascript to change a form action name if using 
MappingDispatchAction).  What is nice is that the approach you use with 
these buttons is the same one used for links (pass in a name like 
update.x) (Using LookupDispatchAction with links is just very ugly).

In reference to the security issues of passing in exposed names of 
non-trivial Java methods in URLs, I agree this is a problem. But don't 
you run into the same problem using regular Actions? Your Action name 
itself if going to give a way what you are trying to accomplish (ie 
/udpateEmployee.do)

Martin Cooper wrote the following on 9/16/2004 10:59 PM:
I guess this thread has come to the point where I just have to throw
in my 2 cents worth... ;-)
IMHO, dispatch actions, whatever flavour, are a bad idea in the first
place. They are essentially second-level controllers. What for? You
already have a perfectly good controller in the Struts ActionServlet,
so why have your own additional levels of controller below that? It
only complicates the mechanism by which an incoming request is handed
off to the relevant body of code, and confuses people trying to
understand how the application works.
As for which of SimpleDA, MappingDA, FubarDA, whatever, is the best,
all I have to say is that exposing the names of non-trivial Java
methods in URLs, and so visible outside the container, makes me very
queasy from a security perspective. So if I was forced to use a
dispatch action, I would certainly choose one that did not rely on a
query string parameter to specify the method name.
--
Martin Cooper
On Thu, 16 Sep 2004 17:54:03 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:

You're making the assumption that everyone wants to do things the way you
do - SimpleDispatchAction doesn't replace any of them if people don't.
Personally (if I used them :-)) MappingDispatchAction looks good to me for
most use cases or if I didn't want to specify anything in the
struts-config.xml then have a custom DispatchAction that just always used
"method" as the parameter name to find the method name from the request.
Niall
I guess I am n

RFC: BLOBAction

[Frank W. Zammetti (MLists)]

One of the things I see asked very frequently on the Users mailing list is
how to return PDF's and other BLOB fields from a database (or from a file
system).  People either have trouble figuring out how to do it and require
help, or have trouble making it work.

Please find attached source for a new Action called BLOBAction that I
submit to you all for comments and, perhaps eventually, inclusion in
Struts as a built-in Action like ForwardAction and the like.

Consider this proof-of-concept code, quality-wise... You can read my
rather verbose comments on this, but in short... Right now it works by
accepting a bunch of parameters submitted with the request.  This I feel
is NOT the right approach.  I was hoping that Struts would read in unknown
attributes for  mappings from struts-config.xml, but that does not
seem to be the case.  I believe most, if not all, of these parameters
should become attributes of the action mappings themselves, but this is
one of the things I'm looking for feedback on.

I am using this code (essentially this code... this is more generic
though) in a production app here at work, so I know it works (aside from
my tests here on this particular code which of course work).  I'm sure
it's not ready as-is, but I don't think it's too bad either.

I look forward to any comments you may have (first and foremost: is this
even worth it?  I think it is, but I may be wrong on even that basic
point!)

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

/*
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999-2003 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Struts", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * .
 *
 */


package org.apache.struts.action;



import java.io.BufferedInputStream;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.sql.Blob;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletOutputStream;
import javax.sql.DataSource;


/**
 * A BLOBAction can be used generically to return a BLOB, i.e., an image or a
 * PDF or anything else.  It can use a database or the file system as the
 * source of the BLOB.  Note that this version, which is basically a more
 * generic proof-of-concept of an Action I u

Re: RFC: BLOBAction

[bryan]

Ok, I'm not knocking jdbc but for me using hibernate this is what my 
action class looks like  

public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
Long id = new Long(request.getParameter("imageId"));

PropertyImage image = (PropertyImage) this.getPropertyImageService()
.getImage(id);

//session.save(propertyImage);
OutputStream outputStream = response.getOutputStream();
response.setContentType("image/jpeg");
outputStream.write(image.getData());
outputStream.flush();
outputStream.close();

//END NEW

return null;
}

I know I'm hung up on hibernate but I cant help it. 

--b


On Fri, 17 Sep 2004 11:06:45 -0400 (EDT), Frank W. Zammetti (MLists)
<[EMAIL PROTECTED]> wrote:
> One of the things I see asked very frequently on the Users mailing list is
> how to return PDF's and other BLOB fields from a database (or from a file
> system).  People either have trouble figuring out how to do it and require
> help, or have trouble making it work.
> 
> Please find attached source for a new Action called BLOBAction that I

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

Re: wrapping of POJO's with WrapDyanBean

[Niall Pemberton]

Its a good question and what I would say is...

* no ones objected to the change and it is in the Struts 1.2.4 release which
is being voted on now. There are no guarantees for the future but the
convention in Struts is that we maintain backward compatibility and IMO
someone would have to have good reason to remove it and break compatibility
once it has been "released"- at least in the 1.x.x series (Struts 2.0
revolution is another case).

* the critical change for wrapping POJO's was actually before the POJO
behaviour was added - it was changing the FormBeanConfig to be effectively a
factory class for ActionForms (see revsion 1.14 of FormBeanConfig). What
this means is that even in your worst case scenarion (i.e. the POJO
behaviour was removed) then it would be simple to create your own custom
FormBeanConfig, implement this POJO behaviour in its createActionForm()
method and configure Struts to use your custom implementation.

Niall

- Original Message - 
From: "bryan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 3:05 PM
Subject: wrapping of POJO's with WrapDyanBean


> Hello and sorry to disturb everyone,
>
> I want to use Niall Pemberton's wrapping on POJO's addition to
> struts for my application.
>
> I personally see it as a great idea that removes one of the main
> reasons why I might use spring over struts ie having to inherit
> from ActionForm or whatever.
>
> However before I commit to this approach and start coding
> my application arround it I have to ask the question.
>
> Is it an accepted change and does struts team intend to preserve
> this change going forward ?
>
> --b



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

DO NOT REPLY [Bug 31270] - DisptachAction discussions/proposals

[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=31270

DisptachAction discussions/proposals

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

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

RE: wrapping of POJO's with WrapDyanBean

[Durham David R Jr Contr 805 CSPTS/SCE]

> There are no guarantees for the future but the
> convention in Struts is that we maintain backward compatibility and
IMO
> someone would have to have good reason to remove it and break
compatibility
> once it has been "released"- at least in the 1.x.x series (Struts 2.0
> revolution is another case).

On this subject, has anyone mentioned anything about conversion
utilities from Struts 1.x to Struts 2.0?  I'm thinking it would make
sense to design and develop these kinds of tools along side the Struts
2.0 development.



- Dave

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

Re: DO NOT REPLY [Bug 31270] - DisptachAction discussions/proposals

[Hubert Rabago]

Niall,

Why did you marked this invalid?

Hubert

On 17 Sep 2004 15:45:46 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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=31270
> 
> DisptachAction discussions/proposals
> 
> [EMAIL PROTECTED] changed:
> 
>   What|Removed |Added
> 
> Status|NEW |RESOLVED
> Resolution||INVALID
> 
> -
> 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: SimpleDispatchAction

[Niall Pemberton]

Lets I'd rather keep everything onlist rather than offlist - thanks.

Firstly I'm not *doing* anything except taking part in a debate and posting
opinions/code samples on the wiki. I don't understand the reference to
*butchering* your code. Your code stands as you posted it on the wiki
unchanged by me, all I did was post an alternative code sample to that wiki
that I believed was a more elegant implementation of your idea. I also
posted a possible class in bugzilla (bug 31270) which combined your idea and
Hubert's suggestion. I only created a bugzilla entry because IMO its easier
to attach something rather than pasting it in the wiki.

I am now regretting taking part in this debate at all, have no plans to do
anything on struts in this area and have closed the bugzilla ticket. You are
free to have any input you like, but please not with me off list and you're
free to join in any discussion in bugzilla - I'm certainly not going to stop
you having a voice.

Niall


- Original Message - 
From: "Michael G. McGrady" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 3:19 PM
Subject: SimpleDispatchAction


> Let me apologize for venting my frustrations last night, Niall.  I just
> got so frustrated with people making assumptions and not listening about
> the class.  I am sure you are doing what you think is right.  I would
> like to know if I can somehow have any input on this without doing it
> all on the list.
>
> Michael McGrady
>

- Original Message - 
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 9:08 AM
Subject: SimpleDispatchAction


> I don't know why you are doing this to this code, Niall, but you
> clearly do not understand in this instance what you are doing.  I won't
> offer more code if it is going to be butchered like this.  You have not
> even bothered to understand it.  I don't understand what your dog is in
> this hunt, but I think this is not right.  Is there anyway I can join in
> on this discussion on bugzilla or do I have to watch the carnage of my
> work without a voice?
>
> Michael McGrady



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

Re: DO NOT REPLY [Bug 31270] - DisptachAction discussions/proposals

[Niall Pemberton]

I'm just regretting taking part in this whole DisptachAction discussion and
am trying to back out of it. Feel free to re-open this if you're interested
in pursuing it further.

Niall

- Original Message - 
From: "Hubert Rabago" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 4:53 PM
Subject: Re: DO NOT REPLY [Bug 31270] - DisptachAction discussions/proposals


> Niall,
>
> Why did you marked this invalid?
>
> Hubert
>
> On 17 Sep 2004 15:45:46 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> > 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=31270
> >
> > DisptachAction discussions/proposals
> >
> > [EMAIL PROTECTED] changed:
> >
> >   What|Removed |Added
>
> --
--
> > Status|NEW |RESOLVED
> > Resolution||INVALID
> >
> > -
> > 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]

FW: [Myfaces-develop] [FYI] Nirvana - HTML2JSF converter

[Matthias Wessendorf]

FYI

Regards,
Matthias

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Takashi Okamoto
Sent: Friday, September 17, 2004 6:23 PM
To: [EMAIL PROTECTED]
Subject: [Myfaces-develop] [FYI] Nirvana - HTML2JSF converter


Hi, 

I would like you to inform Nirvana which is HTML Compiler. You could
write your server pages as POHP(Plain Old HTML Pages) like POJO. Nirvana
compile HTML pages into JSF pages. It seems really cool.

[Nirvana Project]
https://enterprise-incubator.dev.java.net/

[Demo Applicaiton]
https://nirvana.dev.java.net/files/documents/2158/6900/demo.war

regards,

Takashi Okamoto



---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
___
Myfaces-develop mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/myfaces-develop


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

Re: SimpleDispatchAction

[Michael McGrady]

Niall Pemberton wrote:
Lets I'd rather keep everything onlist rather than offlist - thanks.
As you like it!  I think removing the ticket was the best solution.  
Thinking about these things first is always helpful.  I have not really 
been involved with this sort of activity in this regard before and was 
amazed at how it actually works.  This has been a real comedy of 
errors.  I really will not put something like this up for discussion 
without watching the necessary politics in the future.  Hopefully that 
will avoid the tempest.  I would rather focus on the code and its value 
than these personality issues.  Like most things, however, this has been 
much ado about nothing because the only issue is how the class works and 
how it might be useful.  Right?  Anyway, all's well that ends well.

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

Re: wrapping of POJO's with WrapDyanBean

[bryan]

Well I don't contribute to struts but I have to say that one of the
distinguishing
features of the ( less mature ) springframework is that action forms don't have
to inherit a concrete class. 

There has been a lot of criticism of this ( ActionForm etc ) in the past. 

I think it would be a very bad idea not to go forward with this POJO support.

In fact for struts 2 it would be a good idea to get rid of inheritance
and support
POJO instead with option to implement certain interfaces/attributes for 
certain behaviour such as a validation interface etc etc. 

--b


On Fri, 17 Sep 2004 10:43:58 -0500, Durham David R Jr Contr 805
CSPTS/SCE <[EMAIL PROTECTED]> wrote:
> > There are no guarantees for the future but the
> > convention in Struts is that we maintain backward compatibility and
> IMO
> > someone would have to have good reason to remove it and break
> compatibility
> > once it has been "released"- at least in the 1.x.x series (Struts 2.0
> > revolution is another case).
> 
> On this subject, has anyone mentioned anything about conversion
> utilities from Struts 1.x to Struts 2.0?  I'm thinking it would make
> sense to design and develop these kinds of tools along side the Struts
> 2.0 development.
> 
> - Dave
> 
> 
> 
> -
> 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: wrapping of POJO's with WrapDyanBean

[Martin Cooper]

On Fri, 17 Sep 2004 18:55:29 +0200, bryan <[EMAIL PROTECTED]> wrote:
> Well I don't contribute to struts but I have to say that one of the
> distinguishing
> features of the ( less mature ) springframework is that action forms don't have
> to inherit a concrete class.
> 
> There has been a lot of criticism of this ( ActionForm etc ) in the past.

It has also been pointed out, many many times, why this is a *good*
thing. You'll find those reasons in the archives.

--
Martin Cooper


> 
> I think it would be a very bad idea not to go forward with this POJO support.
> 
> In fact for struts 2 it would be a good idea to get rid of inheritance
> and support
> POJO instead with option to implement certain interfaces/attributes for
> certain behaviour such as a validation interface etc etc.
> 
> --b
> 
> On Fri, 17 Sep 2004 10:43:58 -0500, Durham David R Jr Contr 805
> 
> 
> CSPTS/SCE <[EMAIL PROTECTED]> wrote:
> > > There are no guarantees for the future but the
> > > convention in Struts is that we maintain backward compatibility and
> > IMO
> > > someone would have to have good reason to remove it and break
> > compatibility
> > > once it has been "released"- at least in the 1.x.x series (Struts 2.0
> > > revolution is another case).
> >
> > On this subject, has anyone mentioned anything about conversion
> > utilities from Struts 1.x to Struts 2.0?  I'm thinking it would make
> > sense to design and develop these kinds of tools along side the Struts
> > 2.0 development.
> >
> > - Dave
> >
> >
> >
> > -
> > 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]

Regular Action? Re: DispatchAction

[Rick Reumann]

Rick Reumann wrote the following on 9/17/2004 11:03 AM:
The main reason I like the use of a DispatchAction 
is in regard to situations where you have multiple buttons on a form.

You know, the more I think about I think I might just go back to using 
reular ActionForms and not even bother with any of the Dispatch types. 
For cases where I would have a few extra buttons that would behave 
differently, I could just check that parameter in the execute method. I 
know this ends up being a dispatch of sorts, but to me it won't be 
'that' bad since 1) I usually don't have that many situations where 
there are a lot of extra buttons on a form and 2) So what if it acts 
like a dispatch action? It's only a few extra lines of code creating the 
if/else checks for the parameter name (Or I can do one check for that 
dispatch paramater name and if exists just execute that ActionDispatcher 
class that Niall created ).

I'm still curious on other approaches concerning mutliple buttons that 
submit a form (that don't involve use of a Dispatch flavor).

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

Re: DispatchAction

[Mike Kienenberger]

Rick Reumann <[EMAIL PROTECTED]> wrote:
> *Without using Javascript to swap out the form Action name, I'm curious 
> how you guys accomplish using multiple buttons for a form without the 
> use of a DispatchAction?*

> You could of course submit to one regular Action that will look at the 
> parameters but then you end up doing what a DispatchAction does.

This is the approach I decided on.  Downsides are that they're somewhat 
hardcoded into each action.  Upsides include better security and no "base 
class" multiple inheritance issues.


> You could use Javascript to swap out the action name for the form (not a 
bad 
> approach really. I was doing this).

Requires that your end users have javascript enabled.  In my opinion, 
javascript should enhance an application if available, but not be a 
necessity.


> What I do like about the SimpleDispatchAction is it does make things 
> 'simple' you have one consistent way to handle all scenarios.
> 
> In reference to the security issues of passing in exposed names of 
> non-trivial Java methods in URLs, I agree this is a problem.

Yeah, and this is the reason why, although I like the simplicity of 
SimpleDispatchAction, I will probably never use it.
Any time you allow an end user an opportunity to specify a parameter for 
reflection, you're introducing security concerns.
However, a "secure" version could be created by only allowing a dispatch to 
a hardcoded list of methods.


> But don't you run into the same problem using regular Actions? Your Action 
name 
> itself if going to give a way what you are trying to accomplish (ie 
> /udpateEmployee.do)

Not relevent to my situation.  We require a WebObjects-like page state cache 
to handle backtracking issues.   Thus our URLs end up looking like 
http://.com:/ebpp/duSRSod7x598ZkHOQ16p1spKaMzS3yj1Dj_1.1.psc and 
contain no user-meaningful information.

This allowed me to get rid of two of the  three struts security issues I 
identified when first using the technology:

- all pages are "random-access" accessible

- page-scope variables are passed back to the client between requests and 
are subject to alteration


Downside is that you have to add your own bookmarking scheme (could be as 
simple as &bookmark=x appended to the end) if you care about that.  Other 
downside is that you have develop a page state servlet :) but that took less 
than a week.

-Mike

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

Re: Regular Action? Re: DispatchAction

[Rick Reumann]

Sorry to clug the dev list with this, but since the topic started here, 
I'll continue. What about this approach that when enable the use of 
regular Actions and would handle the multiple button problem

I like the concept of using single Actions since it isolates what you 
are doing in a single class (vs a method in a class). What I was 
thinking is in the cases where you needed to use multipe buttons on a 
form you could simple create an Action that would handle this request 
and call the appropriate Action. For example, you have yoru typical 
UserUpdateAction, UserDeleteAction etc., but then you might have a 
UserMultipleActionHandler that would call one of the above Actions based 
on a param. The benefit to this your regular Actions remain independent 
and can be used as normal. You'd only need the handler when you have 
multiple buttons submitting the form.

Uggh the whole problem with all of this is it seems like I'm going 
backwards:) In other words, my first MVC app had one controller servlet 
and simple Command objects that would be called (which would return a 
foward param). When you think about it, that's all Actions really are 
(but with a handle to the Request/Response).

Rick Reumann wrote the following on 9/17/2004 2:12 PM:
Rick Reumann wrote the following on 9/17/2004 11:03 AM:
The main reason I like the use of a DispatchAction is in regard to 
situations where you have multiple buttons on a form.

You know, the more I think about I think I might just go back to using 
reular ActionForms and not even bother with any of the Dispatch types. 
For cases where I would have a few extra buttons that would behave 
differently, I could just check that parameter in the execute method. I 
know this ends up being a dispatch of sorts, but to me it won't be 
'that' bad since 1) I usually don't have that many situations where 
there are a lot of extra buttons on a form and 2) So what if it acts 
like a dispatch action? It's only a few extra lines of code creating the 
if/else checks for the parameter name (Or I can do one check for that 
dispatch paramater name and if exists just execute that ActionDispatcher 
class that Niall created ).

I'm still curious on other approaches concerning mutliple buttons that 
submit a form (that don't involve use of a Dispatch flavor).


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

Re: DispatchAction

[Rick Reumann]

Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
Not relevent to my situation.  We require a WebObjects-like page state cache 
to handle backtracking issues.   Thus our URLs end up looking like 
http://.com:/ebpp/duSRSod7x598ZkHOQ16p1spKaMzS3yj1Dj_1.1.psc and 
contain no user-meaningful information.
Wow I'd like to see how you implemented that some day. Sounds pretty 
cool. So I take it your Struts JSP Form would look like...


Where you'd pass to the page this encoded String for the action name and 
then it gets translated somewhere in the RequestProcessor to equate to 
an actual mapping in the struts-config?

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

PageStateCache design [was: DispatchAction]

[Mike Kienenberger]

Rick Reumann <[EMAIL PROTECTED]> wrote:
> Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
> 
> > Not relevent to my situation.  We require a WebObjects-like page state 
cache 
> > to handle backtracking issues.   Thus our URLs end up looking like 
> > http://.com:/ebpp/duSRSod7x598ZkHOQ16p1spKaMzS3yj1Dj_1.1.psc and 

> > contain no user-meaningful information.
> 
> Wow I'd like to see how you implemented that some day. Sounds pretty 
> cool.

Yeah, I'm hoping to get permission to open source it when my current project 
using it goes production and the smoke clears (which is next week).  I find 
it hard to believe much work can get done without something like this.  I'm 
hoping something like this can be added to the next "revolution" of struts.


>  So I take it your Struts JSP Form would look like...
>  
> 
> Where you'd pass to the page this encoded String for the action name


Actually, I use Velocity rather than JSP, but almost the right idea.  I let 
the  (actually StrutsLinkTool) do the encoding.   I just 
subclassed StrutsLinkTool to enhance toString() to generate the encoded URL. 
 It's almost a one-liner except for a bit of a hack necessary to add in # 
anchor support.  I'd imagine the taglib version would just subclass the 
appropriate html:form code to do the same thing.

By doing it this way, there's no difference between the html template that 
uses such a cache and one that doesn't.  This is helpful since some pages 
are "normal" struts pages (external) and some are "cached" (internal) pages. 
  I can change between the two types in code just by changing the page state 
manager setting for the session.  Obviously, this only works for pages that 
have no expected page state since those page state attributes won't be there 
for normal struts.  I suppose it could be handled by automatically passing 
them through as parameters, but I've never had the need to regress to that.


> and  then it gets translated somewhere in the RequestProcessor to equate 
to 
> an actual mapping in the struts-config?

Nope, took advantage of the servlet architecture and just created a servlet 
that decodes "psc" requests into struts "do" requests via the 
RequestDispatcher.forward method.





  pageState

  
com.gvea.servlet.pageStateCache.PageStateCacheServlet

 5




The only "hooks" into struts are the modification of the , and, 
for my own needs, a hook into RequestProcessor so that on a validation 
failure, the previous pagestate attributes get copied into the current page 
state.  Otherwise, I was losing all of my state when the Validator found an 
error.  You also need a pagestate attribute accessor (a PageState tool in 
velocity -- not sure how it's done in JSP), but that's not really a 
modification of struts. 


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

RE: [VOTE] Struts 1.2.4 Quality

[Arnaud HERITIER]

Based on its quality, the Struts 1.2.4 build should be classified as:

[X] General Availability (GA)

(from a user). I successfully tested it with several webapps.


> Struts extension projects.  I'm really looking forward to working 1.3.x
> though, even if it requires Maven :)

Don, do you have something to reproach to maven?? Let it us know on
the maven user's list !

Arnaud

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

Re: DispatchAction

[Rick Reumann]

Martin Cooper wrote the following on 9/16/2004 10:59 PM:
IMHO, dispatch actions, whatever flavour, are a bad idea in the first
place. They are essentially second-level controllers. What for?  
I'm still not totally convinced DispatchActions don't have their place 
for handling CRUD stuff. Do you create separate DAO classes for each 
Database operation DaoUpdateEmployee, DaoDeleteEmployee? Usually you 
have a Dao that encapsulates those common operations related to an 
Employee - EmployeeDAO. I think of DispatchActions in a similar light.

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

Re: DispatchAction

[Rick Reumann]

Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
Any time you allow an end user an opportunity to specify a parameter for 
reflection, you're introducing security concerns.
However, a "secure" version could be created by only allowing a dispatch to 
a hardcoded list of methods.
But your approach to encoding could do the same thing for a dispatch 
param so I'm not certain that using an Action vs DispatchAction is any 
more secure.

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

Re: DispatchAction security

[Mike Kienenberger]

Rick Reumann <[EMAIL PROTECTED]> wrote:
> Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
> > Any time you allow an end user an opportunity to specify a parameter for 

> > reflection, you're introducing security concerns.
> > However, a "secure" version could be created by only allowing a dispatch 
to 
> > a hardcoded list of methods.
> 
> But your approach to encoding could do the same thing for a dispatch 
> param so I'm not certain that using an Action vs DispatchAction is any 
> more secure.

I must not be understanding you.

If you have url of "/page&method=X" and use reflection to resolve X, then 
you have far less control than if you simply check to see if "X" is in your 
list of approved methods.

On the other hand, a pure action with /page&SaveButtonName=ButtonValue is 
always going to go to my save code if the "SaveButtonName" parameter exists, 
and it'll go to my default code if not.   There's no other option.  That's 
as secure as it gets.


On the other hand, if you're just saying that you can encode your reflection 
dispatch name so that "/page&method=X" becomes "/a1b2c3d4e5.psc", you've 
just made the security more obscure.  If someone figures out your encoding, 
they can still bypass it.

The first rule of computer security programming is never trust user data.  
Let users specify indexes of items in lists, never the item values 
themselves.


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

Re: DispatchAction security

[Michael McGrady]

Mike Kienenberger wrote:
Rick Reumann <[EMAIL PROTECTED]> wrote:
 

Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
   

Any time you allow an end user an opportunity to specify a parameter for 
 

 

reflection, you're introducing security concerns.
However, a "secure" version could be created by only allowing a dispatch 
 

to 
 

a hardcoded list of methods.
 

But your approach to encoding could do the same thing for a dispatch 
param so I'm not certain that using an Action vs DispatchAction is any 
more secure.
   

I must not be understanding you.
If you have url of "/page&method=X" and use reflection to resolve X, then 
you have far less control than if you simply check to see if "X" is in your 
list of approved methods.

On the other hand, a pure action with /page&SaveButtonName=ButtonValue is 
always going to go to my save code if the "SaveButtonName" parameter exists, 
and it'll go to my default code if not.   There's no other option.  That's 
as secure as it gets.

On the other hand, if you're just saying that you can encode your reflection 
dispatch name so that "/page&method=X" becomes "/a1b2c3d4e5.psc", you've 
just made the security more obscure.  If someone figures out your encoding, 
they can still bypass it.

The first rule of computer security programming is never trust user data.  
Let users specify indexes of items in lists, never the item values 
themselves.
 

I am not sure what you are saying, Mike.  Suppose we have use the 
following actions.  One action has the following:

1.  SOLUTION ONE
Action that Chooses What CRUD to Use from the Button
 public ActionForward execute(...) {
   String command = getCommandName();
   if("save".equals(command)) {
 save(request.getParameter("SaveButtonName"));
   } else if ("delete").equals(command)) {
 delete(request.getParameter("DeleteButtonName"));
   }
  }
 return mapping.getInput();
}
2.  SOLUTION TWO: Dispatchers
Action that Chooses what CRUD Method to Call Via Reflection
 public ActionForward execute(...) {
   // Dispatch util is a method to get the methodName and use one of 
the following methods by reflection
   forward = new 
DispatchUtil().dispatch(this,mapping,form,request,response);
  }

   public ActionForward save( ...) {
 String ButtonValue = request.getParameter("SaveButtonName");
 // use ButtonValue
   }
   public ActionForward delete( ... ) {
  String ButtonValue = request.getParameter("DeleteButtonName")'
  // use ButtonValue
   }
 }
3.  SOLUTION THREE:
  Plain Old Action Objects
  SaveButtonAction
  public ActionForward execute () {
 String ButtonValue = request.getParameter("SaveButtonName");
 /// do whatever
  }
  DeleteButtonAction
  public ActionForward execute () {
 String ButtonValue = request.getParameter("DeleteButtonName");
 /// do whatever
  }
Isn't the third option in fact the least safe?  And, isn't the dispatch 
option at least tied for the most safe?  The safety of the parameter and 
its value is in all three models, but in the plain old action object, 
that is the only "distance" between a hack and the application, whereas 
in the other cases there are added levels of security due to the 
complexity of the internal logic.  Ultimately the level of complexity 
and the bottom security the name/value pair from a request parameter for 
what must be deleted, etc. is the same in ALL cases.  What is different 
is that the object for deleting is an obvious target whereas the 
operations are hidden in an object represening, in essence, an actor 
rather than an action. 

Please do not take this question as disingenuous or otherwise as an 
attack on you.  I don't even know you.  This is just an attempt to 
exchange ideas.  I don't mean to suggest you would react that way but I 
have gotton gun shy on this list.  Thanks.  I am interested in your answers.

Michael McGrady

  



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

Re: Maven and SVN [was: Re: [VOTE] Struts 1.2.4 Quality]

[Martin Cooper]

On Fri, 17 Sep 2004 06:13:39 -0700 (PDT), David Graham
<[EMAIL PROTECTED]> wrote:
> I don't think we have the volunteer hours to support starting from scratch
> and do you really want to rewrite ActionServlet, Action, etc.?  IMO, we
> have a lot of tested, used, stable code that we should continue to use.
> 
> You're right that we have some crufty old stuff that needs to be removed
> (all jsp tags not in the html lib for example) but it's easier to delete
> these items than starting from scratch.  Let's use Subversion's abilities
> to their fullest and just move things around as needed.
> 
> IMO, the current Ant build is hopelessly complex and a major obstacle to
> cutting releases.  Not that Ant itself is bad but the simplicity of
> running 'maven clean dist' on every Commons project to get all build
> artifacts is a dream compared to Struts' build.

I've seen several people comment on the complexity of the Ant build,
and frankly I don't get it. And I _really_ don't get that it is a
"major obstacle to cutting releases".

Yes, the Ant build requires that you know where you put the packages
that Struts depends on, but surely that's not so hard. Most people
know where they've put stuff after they've downloaded it. ;-) Once
you've done that, there is little more to cutting a release than 'ant
release' (and testing, of course ;).

I can't say for sure how the now-withdrawn 1.2.2 release was built,
but I can say with absolute certainty that it was not done using 'ant
release'. That target is rock solid, and has never failed me. So an
absolute minimum requirement for a move to Maven, in my book, is that
there is a way to construct a release, with the same structure as we
do today, as easily as there is with the Ant build.

When I first started using Maven, I thought it was the bees knees.
After I'd spent more time with it, I continued to believe that it was
a great advance - when things worked as expected. The way it will go
off and download dependencies or deploy the web site is great.

The problem I have with Maven is when things go wrong (which seems to
be all too often for me). Unlike with Ant, with which all is plain for
all to see, when something goes wrong with Maven, it seems to be a
total mystery as to what happened. I'm frequently told "Oh, you need a
later version of the foo plugin". Managing the tool's dependencies
becomes far worse than managing the dependencies of the project I'm
trying to build or release.

--
Martin Cooper


> 
> David
> 
> 
> 
> 
> --- James Mitchell <[EMAIL PROTECTED]> wrote:
> 
> > On the topic of Maven and SVN...
> >
> > SVN:
> > We have discussed moving our current repository over to SVN and I know
> > there
> > are fancy scripts to do the conversion and all.  We also have been
> > discussing what 1.2.x, 1.3.x, and maybe 1.4.x will be adding vs. what
> > 2.0
> > will bring.
> >
> > Would it make sense just to 'start 2.0 from scratch'?  What I mean is,
> > we
> > can have SVN setup for 2.0 development without the confusion and mess of
> > the
> > existing repository.  I know SVN makes moving files/directories easy,
> > but
> > given the minimum specs we intend to move to, there is just too many
> > hacks
> > and old code in the existing source for supporting the old specs.
> > Starting
> > with a clean slate just seems to make the most sense to me.  Do you
> > agree?
> >
> >
> > Maven:
> > I have spent many hours over the last few weeks over in the commons
> > sandbox
> > 'playing around' with Maven (pun intended).  I moved the Hibernate
> > resource
> > implementation (and tests) over to sf.net.  Both distributions are 100%
> > mavenized.
> >
> > I may have been critical of Maven in the past, but I have earned a new
> > appreciation for this tool.  It really is far superior to just using
> > Ant.  I
> > believe no matter what path we take, with regards to SVN, that we should
> > move our primary build system to Maven.  We will lose nothing from what
> > the
> > current Ant script does, and yes, I am volunteering to help with this.
> >
> > So, that said, I am +1 for setting up a clean slate (2.0) on SVN and
> > making
> > it a 100% Mavenized build (multiproject).
> >
> >
> > Your thoughts?
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > EdgeTech, Inc.
> > 678.910.8017
> > AIM: jmitchtx
> >
> >
> >
> >
> > - Original Message -
> > From: "Ted Husted" <[EMAIL PROTECTED]>
> > To: "Struts Developers List" <[EMAIL PROTECTED]>
> > Sent: Thursday, September 16, 2004 6:06 PM
> > Subject: Re: [VOTE] Struts 1.2.4 Quality
> >
> >
> > I'm not using Struts in production myself right now, so I'm going to
> > abstain
> > from voting in favor of them that do. :)
> >
> > I do still plan to help support the release once it is out.
> >
> > As to the voting in general ...
> >
> > On Thu, 16 Sep 2004 08:09:18 -0500, Joe Germuska wrote:
> > > I wouldn't veto GA, but I'm not ready to say that I think this
> > > release is GA either.
> >
> > A release is a