RE: composable RequestProcessor

[PILGRIM, Peter, FM]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: 04 June 2003 12:05
> To: Struts Developers List
> Subject: Re: composable RequestProcessor
> 
> 
> I still don't see why processing an "action" request is any different 
> than processing a "validation" request.
> 
> Formed like the validation, the default request chain looks like this:
> 
> process="processLocale,processContent,processNoCache,processPr
> eprocess,processMapping,processRoles,processActionForm,process
> Populate,processValidate,processForward,processInclude,process
> ActionCreate,processActionPerform,processForwardConfig"
> 
> where each of these have been defined as a Subprocessor (e.g. 
> Validator).
> 
> As it stands, many of the process methods take different 
> signatures and 
> return different objects. But that could be changed so that they pass 
> around a single data transfer object with a place for all the usual 
> objects (request,response,mapping,form,action,forward).
> 

Right

You can dismantle the signature and create a `ProcessorContext'

class ProcessorContext {
HttpServletRequest request;
ActionMapping mapping;

...

HttpServletRequest getRequest();
ActionMapping getMapping();
...
}

class RoleProcessor extends GenericProcessor {
void processRole( ProcessorContext c) { ... }
}

class IncludeProcessor extends GenericProcessor {
void doInclude( ProcessorContext c ){ ... }
}

This could work well. How does this processor pattern
solve the problem where the RequestProcessor stores
data member? E.g. The list of Actions recorded against
a ModuleConfig.


> Whether each component in this sequence is systemically compatible or 
> whether the order of the processes makes sense, would be the 
> developer's 
> responsibility, just as it is for defining a chain of Validators.
> 
> Right now, the framework describes a lockstep lifecycle. But 
> that really 
> isn't the framework's job. The framework should provide a pre 
> configured 
> default lifecycle, but the developer should as much freedom 
> as possible 
> to define whatever lifecycle works best for a given application.
> 
> The distribution could ship with a library of Subprocessors 
> (just as we 
> ship with a library of Validators). To use Tiles, you would make the 
> appropriate changes to the "process" property to load the Tiles 
> Subprocessors. If someone wanted to handle a different 
> extension point 
> differently (or insert a new one), they could add a 
> Subprocessor to the 
> library (as we can with validators), and amend the "process" property.
> 
> So there would be no pre-ordained processABC and processXYZ 
> methods or 
> call sequence. The processor would call each process in turn until 
> someone cried stop or the sequence was complete. You could 
> put as many 
> or as few Subprocessors into the sequence as you liked, same 
> as we can 
> do with Validators.

If you look at the Tiles source code, then you can see there 
are calling initialisation methods. SHould these be also
`processified'?

> A radical extension, like Tiles, may also need to subclass the main 
> "Processor" (aka the "RequestProcessor") that would call the 
> individual 
> Subprocessors, but hopefully the methods that it overrides (like 
> internalModuleRelativeForward) won't matter to the other 
> Subprocessors.
> 
> Or, maybe if Tiles does not have to live within a lockstep lifecycle, 
> there might be a better way of interpolating the 
> "processTiles" step, so 
> that it doesn't need override "internal" methods.
> 
> So, anyway, the idea is that there would be a Subprocessor 
> interface and 
> concrete implementations for each of the existing process methods (as 
> individual classes). The existing RequestProcessor(s) could 
> implement a 
> Processor interface. The new ProcessManager could also implement the 
> Processor interface but call individual Subprocessors from within the 
> process method. (You might be even be able to do a concept 
> test with a 
> RequestProcessor subclass that called inner classes based on the 
> existing processes.) Which Subprocessors the ProcessManager calls in 
> what order would be configurable.
> 

One question. Is a `ProcessManager' a ``RequestProcessor''?
What you have described is a sort of master delegation pattern.
Where you already have a plug-in architecture as before
in Struts 1.1 a `RequestProcessor'.
Now you want to extend into a manager interface with the
possibility to delegate methods to other objects.

If this is what you are saying this may solve the issues.

I think Matthias touched on the problem that the TilesRequestProcessor
was doing. If it was checking that the RP was subclass or assignable
against itself. If it was not it would throw an exception.

Can a subprocessor check itself for compatiblity as the Tiles RP does?

> While not as simple as what we have now, it would be more extensible, 
> and has the virtue of using the same implem

Re: [OT] SEX SEX SEX

[Arron Bates]

Already voted. IDEA is being severely robbed, IMHO. And 3000 odd votes from
various users at keyboardmonkey.com would look suss. :P

Eclipse has more users, so I suppose it has to give in, but to JBuilder as
well!??... nah. doesn't bode well.


Arron.


> Ok, now that I've got your attention ;)
> 
> Please go and vote:
> http://www.sys-con.com/java/readerschoice2003/index.cfm
> 
> --
> James Mitchell
> Software Developer/Struts Evangelist
> http://www.struts-atlanta.org
> 770-822-3359
> AIM:jmitchtx
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]





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

Re: Status check?

[Arron Bates]

> OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or
> updated the web site, but it's there.
> 
> The Tomcat build did indeed break, and interested parties can see the
> resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe
> for their support.
> 
> --
> Martin Cooper


Fits my personal mantra:
"You can't fight city hall...
...but you can crap on the steps and run like buggery!"

Excellent stuff.

The community gives thanks
(or they should, the filthy beggars :)


Arron.


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

Re: Status check?

[Arron Bates]

-1

Two weeks seems a little tight.

I only say this because the change to the nested tags after RC1 wasn't the
smallest of changes, and I personally feel a little nervous that it would be
shoved out the door with only two weeks on a release. It was a big fix to get
Tomcat 4.1.x going with them, and it was agreed that having the RC2 timespan
to allow uptake on any glaring problems would be fine, but two weeks seems a
little quick.

I've done my best to usher the latest of the tags onto the masses but the
broadcast of a release brings in more people than I could ever hope of
reaching personally. When RC2 comes out I'd like a little more time to be
assured people are comfy with the changes.

And as ted mentioned, some of the docs need updating, and for FileUpload to
run its course.

I know people want it out there but could I stretch the friendship and ask
that there's at least a month of RC2 before final?... (what's two more
weeks?... they'll fly by, I promise  :)



Arron.



> - Original Message - 
> From: "David Graham" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, June 04, 2003 2:42 PM
> Subject: RE: Status check?
> 
> > >Right, but what's the right amount of time to wait?
> > 
> > Craig suggested 2 weeks and I think that sounds good.
> 
> +1
> 
> --
> James Mitchell
> Software Developer/Struts Evangelist
> http://www.struts-atlanta.org
> 770-822-3359
> AIM:jmitchtx



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

RE: composable RequestProcessor

[Gary D Ashley Jr.]

Just thought I'd through an argument out there against using the xml
configuration approach as food for thought.

On my current application, I have around 12 struts modules.  Each is using
dynaActionForms, 3 or 4 plugins, and ranging from 10-50 actions.

I have several developers who do a great job creating jsps, actions, tiles
and struts config entries, etc.  They definitely don't live in the world of
the RequestProcessor level stuff (and don't want to), as they have to much
to already worry about.

I think if to many more complexities are added to an already huge struts
config file, then that just makes life difficult for your basic struts
programmer just trying to get his jsps to display, validate properly, and
reach the action code ok.

It just seems that most average struts developers aren't working at the
level of extending the RequestProcessor, and therefore don't even want to
see a bunch of potentially complicated looking xml configuration code.

It seems like to me that if you have average joe struts developer out there,
and he wants to use 3 diffent extentions, you are going to only increase the
traffic on the struts user list with him trying to figure out the order of
the processXxx methods, etc.

Shouldn't that complexity be left to all you gurus hanging out on this
mailing list to figure out in code?  =:0)

Besides, the complexity seems like it is nearly impossible to manage with
the more extenstions you try to add into the mix.  Why not focus instead on
pulling in the best of these features into the core of struts, and using
action mappings, etc. to provide more options on what to use (like
validation), etc.  :)

Just more food for thought.



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

ActionContext [WAS: RE: composable RequestProcessor]

[Andrew Hill]

I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls the old execute(m, f, r, r) (for backwards
compatibility).


Im doing this in my app - though the execute signature remains the same.
Most of my actions extend some abstract action classes, and most of the
hooks the subclass overrides are passed an ActionContext bean (which simply
has getters for the request,response, mapping etc...). Saves a lot of typing
and makes the code much more readable at the expense of one more tiny object
being created in the execute method. I later found it a good place to add
attributes as well - like the request attributes only scoped to the execute
method of the action (life of the ActionContext bean).

Ive been very tempted to overide my applications RPs processActrionPerform
and instantiate the action context there and pass it to the actions execute
but havent got around to it yet.

-Original Message-
From: Gary D Ashley Jr. [mailto:[EMAIL PROTECTED]
Sent: Friday, 6 June 2003 15:02
To: Struts Developers List
Subject: RE: composable RequestProcessor


>Maybe the interface for processor modules should
>take two arguments, a "StrutsRequestContext" like what you described, which
>would have these properties:
>request
>response
>mapping
>form
>path

>Then a second object, "StrutsModuleContext"
>with these properties, with public accessors, only a public mutator
>(setter) for actions:
>servlet
>moduleConfig
>actions  (a mapped property)

>This object would be created during RequestProcessor.init(servlet,
>moduleConfig)

I really like this idea, if you had 3 interfaces: StrutsRequestContext,
StrutsModuleContext, and StrutsRequestProcessor.

Then add a StrutsRequestHandler object and moved most of the processXxx
logic into that Handler class.  The StrutsRequestProcessor would then only
have 3 methods to implement.  init, destroy, and process.  This seems like
it would provide the maximum flexibility.  Some Struts Extensions may simple
want to forgo using Actions or others parts for completely new ideas, and
some processXxx methods may not apply in all situations (so why be forced to
implement the handful that you can only now conceive of).

So, the ActionServlet would create a StrutsRequestProcessor and a
StrutsModuleContext.  Then for each request, it would call the process
method on the StrutsRequestProcessor and pass it a StrutsModuleContext
object and a StrutsRequestContext object.

Then, the RequestProcessor (default implementation) would create a new
StrutsRequestHandler and delegate all the processXxx calls to that object
from its single process method passing each processXxx method the new
Context objects.

This follows the composition by coding view point, at least that is my first
thought.

New extensions to struts wanting to implement custom processing would simple
provide the implementation for the process,init, and destroy methods.  The
process method could compose any number of Handlers and delegate most of the
work to those kinds of classes.

For those who desired such a thing, maybe a more complex
StrutsRequestProcessor and StrutsRequestHandler could be created to handle
the compose by configuration way of doing things.

No matter what, I hope a StrutsRequestContext gains support.  I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls the old execute(m, f, r, r) (for backwards
compatibility).





-
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: composable RequestProcessor

[Gary D Ashley Jr.]

>Maybe the interface for processor modules should
>take two arguments, a "StrutsRequestContext" like what you described, which
>would have these properties:
>request
>response
>mapping
>form
>path

>Then a second object, "StrutsModuleContext"
>with these properties, with public accessors, only a public mutator
>(setter) for actions:
>servlet
>moduleConfig
>actions  (a mapped property)

>This object would be created during RequestProcessor.init(servlet,
>moduleConfig)

I really like this idea, if you had 3 interfaces: StrutsRequestContext,
StrutsModuleContext, and StrutsRequestProcessor.

Then add a StrutsRequestHandler object and moved most of the processXxx
logic into that Handler class.  The StrutsRequestProcessor would then only
have 3 methods to implement.  init, destroy, and process.  This seems like
it would provide the maximum flexibility.  Some Struts Extensions may simple
want to forgo using Actions or others parts for completely new ideas, and
some processXxx methods may not apply in all situations (so why be forced to
implement the handful that you can only now conceive of).

So, the ActionServlet would create a StrutsRequestProcessor and a
StrutsModuleContext.  Then for each request, it would call the process
method on the StrutsRequestProcessor and pass it a StrutsModuleContext
object and a StrutsRequestContext object.

Then, the RequestProcessor (default implementation) would create a new
StrutsRequestHandler and delegate all the processXxx calls to that object
from its single process method passing each processXxx method the new
Context objects.

This follows the composition by coding view point, at least that is my first
thought.

New extensions to struts wanting to implement custom processing would simple
provide the implementation for the process,init, and destroy methods.  The
process method could compose any number of Handlers and delegate most of the
work to those kinds of classes.

For those who desired such a thing, maybe a more complex
StrutsRequestProcessor and StrutsRequestHandler could be created to handle
the compose by configuration way of doing things.

No matter what, I hope a StrutsRequestContext gains support.  I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls the old execute(m, f, r, r) (for backwards
compatibility).





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

DO NOT REPLY [Bug 20389] - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20389

Need mechanism that lets more than one forms points to the same form bean instance in 
a HTML page





--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 11:42 ---
Hold on. There still is a problem in javascript validation. Because if more 
than one forms have the same format name, then the generated JavaScript might 
use the same format name to refer to the form fields which are in different 
HTML forms, how can we handle this situation?

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

DO NOT REPLY [Bug 20389] - Need mechanism that lets more than one forms points to the same form bean instance in a HTML page

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20389

Need mechanism that lets more than one forms points to the same form bean instance in 
a HTML page





--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 11:34 ---
Yeah, it's a good idea that we just use document.forms[0], and document.forms
[1] to different the form in the same HTML page. I will test it in our 
project. Thanks a lot,

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

DO NOT REPLY [Bug 20486] - Explaining that logic:iterate was ported to struts-el but has now been superseded

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20486

Explaining that logic:iterate was ported to struts-el but has now been superseded

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-06 04:36 ---
I added a statement covering the same points.

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

cvs commit: jakarta-struts/contrib/struts-el README.txt

[dmkarr]

dmkarr  2003/06/05 21:33:35

  Modified:contrib/struts-el README.txt
  Log:
  Bug: 20486
  
  Added a note about the history of the porting of the "iterate" tag and the
  implementation of code to check for "c:forEach" in addition to "logic:iterate".
  Also clarified that the Jakarta Taglibs implementation of the JSTL is being
  used for the EL engine.
  
  Revision  ChangesPath
  1.3   +12 -3 jakarta-struts/contrib/struts-el/README.txt
  
  Index: README.txt
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-el/README.txt,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- README.txt27 Dec 2002 02:23:52 -  1.2
  +++ README.txt6 Jun 2003 04:33:35 -   1.3
  @@ -8,8 +8,8 @@
   This subproject is an extension of the Struts tag library.  Each JSP custom tag
   in this library is a subclass of an associated tag in the Struts tag library.
   One difference is that this tag library does not use "rtexprvalues", it uses
  -the expression evaluation engine in the JSP Standard Tag Library (version 1.0)
  -to evaluate attribute values.
  +the expression evaluation engine in the Jakarta Taglibs implementation of the
  +JSP Standard Tag Library (version 1.0) to evaluate attribute values.
   
   In addition, some of the Struts tags were not ported to this library, as it was
   determined that their functionality was entirely supplied by the JSTL.  These
  @@ -30,7 +30,9 @@
   library.  This section reviews which Struts tags are NOT implemented in the
   Struts-EL library, and which JSTL tags provide that feature.
   
  -Many of the non-porting decisions were based on the fact that the JSTL expression 
language itself provides the same functionality.  In those cases, in addition to a 
possible JSTL tag name, the symbol "EL" will be listed.
  +Many of the non-porting decisions were based on the fact that the JSTL
  +expression language itself provides the same functionality.  In those cases, in
  +addition to a possible JSTL tag name, the symbol "EL" will be listed.
   
   Bean Tag Library Tags NOT Implemented in Struts-EL
   --
  @@ -57,6 +59,13 @@
   lessThan c:if, c:when, EL
   notEmpty c:if, c:when, EL
   notEqual c:if, c:when, EL
  +
  +(Note that the "iterate" tag was originally ported, even with the presence of
  +the "c:forEach" tag, as the "indexed tag" functionality was not supported when
  +using "c:forEach" instead of "logic:iterate".  This has since been rectified,
  +such that the "indexed tag" functionality checks for being contained in a
  +"c:forEach" tag, in addition to the "logic:iterate" tag.  However, the ported
  +"iterate" tag has not been removed from Struts-EL, for backward compatibility.)
   
   Html Tag Library Tags NOT Implemented in Struts-EL
   --
  
  
  

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

Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces

[Arron Bates]

Isn't JSF just another spec like Servlets and JSP?...

Any vendor can make a JSP impl based on the spec, so they should also be able
to make a JSF impl. Struts-Faces allows Struts to play with any compliant JSF
implementation. If it doesn't we get to go Craig-bashing. :)

Struts plays with Servlet/JSP, it now plays with Servlet/JSP & JSF.

But don't worry, as soon as there's a real sniff of vendor lock-in happening,
there'll be more than a few people up in arms.


Arron.


BTW: I have iPlanet WebServer 4, and App Servers 2 & 6 on my resume from two
separate organisations.  ;)

iPlanet Web Server 4 was THE java web server. Times change.
AppLogic components on the old netscape app server (Kiva)?... oh yeah!



> Is ASF allowed to distribute Sun JDK?  Not AFAIK.
> 
> I think main argument is license, ex: what is cost of JSF?  Is it 
> similar to JBoss issue?
> I am not against JSF integration w/Struts at all. The more the better.
> 
> When there is only a single choice, this can't be good, standard or not. 
> No one has educated me with another example of ASF file link like this. 
> (and endorsing a replacement. Ex: On Tomcat 5 there is no files on 
> apache.org... use BEA, here is the jar)
> I would feel better (and you would feel better for making me feel better 
> :-) if others were listed as integrating with Struts with any disclaimer 
> you want. (Ex: XYZ integrates with Struts but is not Standard to JCP 
> 666, but this jar here is standard).
> OR:  put the url link on Struts site, but the files outside of 
> apache.org on sf.net or wherever, so someone has a chance to think I 
> trust ASF but now I have linked outside of ASF. (just in case it blows up)
> 
> Unless ASF is endorsing JSF and I  just didt't get it.
> 
> Looks like no one jumping to my side, therefore end of discussion.
> With a large pool you will not please everyone, I am not pleased. Some 
> diversity is OK, so just say let me pout.
> 
> .V
> 
> (on technology side, majority of my revenue contribution is project 
> recovery, ya)
> 
> Steve Raeburn wrote:
> > Vic,
> > 
> > The JSF Expert group includes :
> > 
> > Specification Lead
> > Ed Burns   Sun Microsystems, Inc.
> > Craig R. McClanahanSun Microsystems, Inc.
> > 
> > Expert Group
> > Aligo, Inc. Apache Software Foundation
> > BEA Systems Bayern, Shawn
> > Bergsten, Hans  Berkovitz, Joseph
> > Bogaert, MathiasBorland Software Corporation
> > Carapetyan, PeteDevelopmentor
> > Documentum, Inc.Droplets, Inc.
> > EDS Fujitsu Limited
> > Geary, DavidHewlett-Packard
> > IBM ILOG
> > IONA Technologies PLC   Lazarus, Eric
> > Macromedia, Inc.Mettu, Kumar
> > Nash, Michael   Netdecisions Holdings United
> > Novell, Inc.Oracle
> > SAS Institute Inc.  Siemens AG
> > Strachan, James Sun Microsystems, Inc.
> > Zukowski, John A.
> > 
> > That's a fairly representative sample of the industry, so I think we can
> > definitely conclude that JSF != Sun either.
> > 
> > If you don't think JSF is the right technical direction, then that's one
> > thing, but you are undermining your argument by making this about licensing
> > and Sun.
> > 
> > Steve




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

DO NOT REPLY [Bug 20502] New: - MANIFEST.MF Class-Path wrongly formatted

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20502

MANIFEST.MF Class-Path wrongly formatted

   Summary: MANIFEST.MF Class-Path wrongly formatted
   Product: Struts
   Version: 1.1 RC1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


There are several Class-Path statements in the struts.jar MANIFEST.MF, this is
not correct according to the specs - JDK's could choose to ignore those
additional lines regsrding these as duplicates. There should be only a single
Class-Path statement for the jar.

J2SDK 1.4.2 Beta directly complains about the struts.jar MANIFEST.MF content.

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

DO NOT REPLY [Bug 20535] - Dynamically size arrays to allow array types in request scope DynaActionForm forms

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20535

Dynamically size arrays to allow array types in request scope DynaActionForm forms

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement

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

DO NOT REPLY [Bug 20432] - Validator returns nulls in JavaScript validation

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20432

Validator returns nulls in JavaScript validation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-06-05 01:21 ---
Fixed the line throwing the NPE.

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

DO NOT REPLY [Bug 20486] - Explaining that logic:iterate was ported to struts-el but has now been superseded

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20486

Explaining that logic:iterate was ported to struts-el but has now been superseded

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement

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

DO NOT REPLY [Bug 20486] - Explaining that logic:iterate was ported to struts-el but has now been superseded

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20486

Explaining that logic:iterate was ported to struts-el but has now been superseded





--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 22:59 ---
Created an attachment (id=6637)
struts-el readme patch

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

DO NOT REPLY [Bug 20486] New: - Explaining that logic:iterate was ported to struts-el but has now been superseded

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20486

Explaining that logic:iterate was ported to struts-el but has now been superseded

   Summary: Explaining that logic:iterate was ported to struts-el
but has now been superseded
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


See the patch.

Against 6/4/2003 nightly build file jakarta-struts\contrib\struts-el\README.txt

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

RE: Validator Javascript being displayed on the jsp page

[ernest . argetsinger]

Sounds like it could be 11950

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11950

hth,
e.





"David Graham" <[EMAIL PROTECTED]>
06/04/2003 02:26 PM
Please respond to "Struts Developers List"

 
To: [EMAIL PROTECTED]
cc: 
Subject:RE: Validator Javascript being displayed on the jsp page


Sorry, my search of bugzilla didn't turn up anything but you can search it 

yourself if you have some time.

David

>Using the latest version of commons-validator (1.0.2) helped resolve the
>problem. You mentioned that 'This sounds like a bug that was fixed some 
>time
>ago'. Can u please elaborate on what the bug was and if u have the bug 
id,
>that would be helpful too... just for future reference... The reason I 
want
>to understand this issue is that this particular problem used to come up
>only on some servers. On some of the servers the app displayed the pages
>correctly.. Still confused about that...
>
>Thanx for all ur help,
>Manisha
>
>-Original Message-
>From: David Graham [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, June 03, 2003 9:49 AM
>To: [EMAIL PROTECTED]
>Subject: RE: Validator Javascript being displayed on the jsp page
>
>
>Well there was Struts 1.1b1, b2, b3, RC1, and nightly builds...which one 
>did
>
>you download?  It looks like you have an old version of 
commons-validator.
>Try downloading comons-validator-1.0.2.
>
>David
>
>
> >I am not sure how to find the version of 1.1...
> >
> >I have the Mainfest.mf for struts:
> >Manifest-Version: 1.0
> >Created-By: Apache Ant 1.5.1
> >Extension-Name: Struts Framework
> >Specification-Title: Struts Framework
> >Specification-Vendor: Apache Software Foundation
> >Specification-Version: 1.1
> >Implementation-Title: Struts Framework
> >Implementation-Vendor: Apache Software Foundation
> >Implementation-Vendor-Id: org.apache
> >Implementation-Version: 1.1
> >Class-Path: commons-beanutils.jar
> >Class-Path: commons-collections.jar
> >Class-Path: commons-dbcp.jar
> >Class-Path: commons-digester.jar
> >Class-Path: commons-logging.jar
> >Class-Path: commons-pool.jar
> >Class-Path: commons-services.jar
> >Class-Path: commons-validator.jar
> >Class-Path: jakarta-oro.jar
> >
> >and mainfest file for commons-validator:
> >Manifest-Version: 1.0
> >Created-By: Apache Ant 1.5.1
> >Extension-Name: org.apache.commons.validator
> >Specification-Vendor: Apache Software Foundation
> >Specification-Version: 1.0
> >Implementation-Vendor: Apache Software Foundation
> >Implementation-Version: 1.0
> >
> >Let me know if this helps...
> >
> >Thanx,
> >Manisha
> >
> >-Original Message-
> >From: David Graham [mailto:[EMAIL PROTECTED]
> >Sent: Monday, June 02, 2003 10:56 PM
> >To: [EMAIL PROTECTED]
> >Subject: RE: Validator Javascript being displayed on the jsp page
> >
> >
> >That doesn't really help us.  1.1 has been around for over a year. What
> >version of 1.1 are you using?
> >
> >David
> >
> >
> > >
> > >I am using Struts 1.1.
> > >
> > >Thanx,
> > >Manisha
> > >
> > >-Original Message-
> > >From: David Graham [mailto:[EMAIL PROTECTED]
> > >Sent: Monday, June 02, 2003 10:23 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: Validator Javascript being displayed on the jsp page
> > >
> > >
> > >This sounds like a bug that was fixed some time ago.  What version 
are
> >you
> > >using?
> > >
> > >David
> > >
> > >
> > > >From: "Manisha.Datye" <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > > >To: "'[EMAIL PROTECTED]'" 
<[EMAIL PROTECTED]>
> > > >Subject: Validator Javascript being displayed on the jsp page
> > > >Date: Mon, 2 Jun 2003 22:18:07 -0500
> > > >
> > > >My application is using the struts validator (struts 1.1). It has 
>some
> > > >pages
> > > >that don't use the validator.
> > > >Illustration:
> > > >Page 1 - InitialSearch.jsp (validator)
> > > >Page 2 - SearchResults.jsp (no validator)
> > > >When the InitialSearch.jsp page is displayed the first time it 
>displays
> > > >correctly. But if I navigate to the page 2 and return to page 1, 
the
> >page
> >
> > >1
> > > >now displays the validator javascript along with the generated jsp
> >page.
> > > >The
> > > >html source is missing the script tag and the function
> > > >validateInitialSearchForm. As there is no start and end tag for 
>script,
> > >the
> > > >script is displayed on the page. This happens only in the 
production
> > > >environment.
> > > >Any help is appreciated. Any clue on why the javascript generated 
by
> >the
> > > >validator is be displayed on the jsp page ?
> > > >Thanx,
> > > >Manisha
> > > >



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

RE: Validator Javascript being displayed on the jsp page

[David Graham]

Sorry, my search of bugzilla didn't turn up anything but you can search it 
yourself if you have some time.

David

Using the latest version of commons-validator (1.0.2) helped resolve the
problem. You mentioned that 'This sounds like a bug that was fixed some 
time
ago'. Can u please elaborate on what the bug was and if u have the bug id,
that would be helpful too... just for future reference... The reason I want
to understand this issue is that this particular problem used to come up
only on some servers. On some of the servers the app displayed the pages
correctly.. Still confused about that...

Thanx for all ur help,
Manisha
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 9:49 AM
To: [EMAIL PROTECTED]
Subject: RE: Validator Javascript being displayed on the jsp page
Well there was Struts 1.1b1, b2, b3, RC1, and nightly builds...which one 
did

you download?  It looks like you have an old version of commons-validator.
Try downloading comons-validator-1.0.2.
David

>I am not sure how to find the version of 1.1...
>
>I have the Mainfest.mf for struts:
>Manifest-Version: 1.0
>Created-By: Apache Ant 1.5.1
>Extension-Name: Struts Framework
>Specification-Title: Struts Framework
>Specification-Vendor: Apache Software Foundation
>Specification-Version: 1.1
>Implementation-Title: Struts Framework
>Implementation-Vendor: Apache Software Foundation
>Implementation-Vendor-Id: org.apache
>Implementation-Version: 1.1
>Class-Path: commons-beanutils.jar
>Class-Path: commons-collections.jar
>Class-Path: commons-dbcp.jar
>Class-Path: commons-digester.jar
>Class-Path: commons-logging.jar
>Class-Path: commons-pool.jar
>Class-Path: commons-services.jar
>Class-Path: commons-validator.jar
>Class-Path: jakarta-oro.jar
>
>and mainfest file for commons-validator:
>Manifest-Version: 1.0
>Created-By: Apache Ant 1.5.1
>Extension-Name: org.apache.commons.validator
>Specification-Vendor: Apache Software Foundation
>Specification-Version: 1.0
>Implementation-Vendor: Apache Software Foundation
>Implementation-Version: 1.0
>
>Let me know if this helps...
>
>Thanx,
>Manisha
>
>-Original Message-
>From: David Graham [mailto:[EMAIL PROTECTED]
>Sent: Monday, June 02, 2003 10:56 PM
>To: [EMAIL PROTECTED]
>Subject: RE: Validator Javascript being displayed on the jsp page
>
>
>That doesn't really help us.  1.1 has been around for over a year.  What
>version of 1.1 are you using?
>
>David
>
>
> >
> >I am using Struts 1.1.
> >
> >Thanx,
> >Manisha
> >
> >-Original Message-
> >From: David Graham [mailto:[EMAIL PROTECTED]
> >Sent: Monday, June 02, 2003 10:23 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Validator Javascript being displayed on the jsp page
> >
> >
> >This sounds like a bug that was fixed some time ago.  What version are
>you
> >using?
> >
> >David
> >
> >
> > >From: "Manisha.Datye" <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > >Subject: Validator Javascript being displayed on the jsp page
> > >Date: Mon, 2 Jun 2003 22:18:07 -0500
> > >
> > >My application is using the struts validator (struts 1.1). It has 
some
> > >pages
> > >that don't use the validator.
> > >Illustration:
> > >Page 1 - InitialSearch.jsp (validator)
> > >Page 2 - SearchResults.jsp (no validator)
> > >When the InitialSearch.jsp page is displayed the first time it 
displays
> > >correctly. But if I navigate to the page 2 and return to page 1, the
>page
>
> >1
> > >now displays the validator javascript along with the generated jsp
>page.
> > >The
> > >html source is missing the script tag and the function
> > >validateInitialSearchForm. As there is no start and end tag for 
script,
> >the
> > >script is displayed on the page. This happens only in the production
> > >environment.
> > >Any help is appreciated. Any clue on why the javascript generated by
>the
> > >validator is be displayed on the jsp page ?
> > >Thanx,
> > >Manisha
> > >
> > >-
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >_
> >STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> >http://join.msn.com/?page=features/junkmail
> >
> >
> >-
> >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]
> >
>
>_
>Add photos to your messages with MSN 8. Get 2 months FREE*.
>http://join.msn.com/?page=features/featuredemail
>
>
>-
>To unsubscribe, 

Re: composable RequestProcessor

[David Graham]

But I guess this is just speculating about hte future. Maybe the best 
solution is to create a simple composable RequestProcessor for 1.2 and then 
see what the future might bring?
A new RequestProcessor in any form warrants its own point release.  1.2 is 
already scheduled for a move to commons-resources so this would have to wait 
until 1.3 at the earliest (if we can even agree on an implementation by 
1.3).

David

- Kent

Ted Husted <[EMAIL PROTECTED]> wrote:
> Jeff Robertson wrote:
> > Wow. Mr. Husted, this may seem like an obvious conclusion
> to you, but to me
> > (and probably others as well) this is a big "hey, why
> didn't I think of
> > that!" moment.
>
> I know the feeling -- I just got it reading the latest docs
> for the
> Struts Workflow extension =:0)
>
> IMHO, Matthais is pointing out a very real issue with the
> current
> architecture. It's moving in the right direction, but
> doesn't go far
> enough. In order to bring out extensions like Workflow, he
> has to do a
> special Tiles version. People really shouldn't have to do
> that, and the
> implication is either the Tiles or RequestProcessor
> implementations are
> falling short of the mark.
>
> I don't know when a version of Struts based on Filters will
> be
> available. But I do know that if someone came up with a
> implementation
> of a composable RequestProcessor that worked like the
> Validator, I'd
> probably commit it.
>
> One day, this work all may be obviated by Filters, but until
> then, it
> would be a good way to see how Filters might be used in
> Struts 2.0.
>
> I also think that given the codebase for the Validator and
> the existing
> RequestProcessor, it's not that much of a stretch. If we
> define the
> interface right, we should be able to keep the original
> RequestProcessor, so the whole composible thing becomes a
> bleeding-edge
> option, and not a required implementation.
>
> -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]
_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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

RE: Status check?

[Craig R. McClanahan]

On Wed, 4 Jun 2003, James Turner wrote:

> Sounds very Lincoln-ian... Two years and two weeks ago, Craig McClanahan
> brought forth upon the Java community a new framework, conceived of MVC,
> and devoted to the notion that all business logic should be treated
> separate.
>

:-)

> Advice to Craig:  Avoid theatres.
>

Hope the stage in Hall E at JavaOne doesn't count  :-)

> James
>

Craig

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

RE: Validator Javascript being displayed on the jsp page

[Manisha.Datye]

Hi David,

Using the latest version of commons-validator (1.0.2) helped resolve the
problem. You mentioned that 'This sounds like a bug that was fixed some time
ago'. Can u please elaborate on what the bug was and if u have the bug id,
that would be helpful too... just for future reference... The reason I want
to understand this issue is that this particular problem used to come up
only on some servers. On some of the servers the app displayed the pages
correctly.. Still confused about that...

Thanx for all ur help,
Manisha

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 9:49 AM
To: [EMAIL PROTECTED]
Subject: RE: Validator Javascript being displayed on the jsp page


Well there was Struts 1.1b1, b2, b3, RC1, and nightly builds...which one did

you download?  It looks like you have an old version of commons-validator.  
Try downloading comons-validator-1.0.2.

David


>I am not sure how to find the version of 1.1...
>
>I have the Mainfest.mf for struts:
>Manifest-Version: 1.0
>Created-By: Apache Ant 1.5.1
>Extension-Name: Struts Framework
>Specification-Title: Struts Framework
>Specification-Vendor: Apache Software Foundation
>Specification-Version: 1.1
>Implementation-Title: Struts Framework
>Implementation-Vendor: Apache Software Foundation
>Implementation-Vendor-Id: org.apache
>Implementation-Version: 1.1
>Class-Path: commons-beanutils.jar
>Class-Path: commons-collections.jar
>Class-Path: commons-dbcp.jar
>Class-Path: commons-digester.jar
>Class-Path: commons-logging.jar
>Class-Path: commons-pool.jar
>Class-Path: commons-services.jar
>Class-Path: commons-validator.jar
>Class-Path: jakarta-oro.jar
>
>and mainfest file for commons-validator:
>Manifest-Version: 1.0
>Created-By: Apache Ant 1.5.1
>Extension-Name: org.apache.commons.validator
>Specification-Vendor: Apache Software Foundation
>Specification-Version: 1.0
>Implementation-Vendor: Apache Software Foundation
>Implementation-Version: 1.0
>
>Let me know if this helps...
>
>Thanx,
>Manisha
>
>-Original Message-
>From: David Graham [mailto:[EMAIL PROTECTED]
>Sent: Monday, June 02, 2003 10:56 PM
>To: [EMAIL PROTECTED]
>Subject: RE: Validator Javascript being displayed on the jsp page
>
>
>That doesn't really help us.  1.1 has been around for over a year.  What
>version of 1.1 are you using?
>
>David
>
>
> >
> >I am using Struts 1.1.
> >
> >Thanx,
> >Manisha
> >
> >-Original Message-
> >From: David Graham [mailto:[EMAIL PROTECTED]
> >Sent: Monday, June 02, 2003 10:23 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Validator Javascript being displayed on the jsp page
> >
> >
> >This sounds like a bug that was fixed some time ago.  What version are 
>you
> >using?
> >
> >David
> >
> >
> > >From: "Manisha.Datye" <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > >Subject: Validator Javascript being displayed on the jsp page
> > >Date: Mon, 2 Jun 2003 22:18:07 -0500
> > >
> > >My application is using the struts validator (struts 1.1). It has some
> > >pages
> > >that don't use the validator.
> > >Illustration:
> > >Page 1 - InitialSearch.jsp (validator)
> > >Page 2 - SearchResults.jsp (no validator)
> > >When the InitialSearch.jsp page is displayed the first time it displays
> > >correctly. But if I navigate to the page 2 and return to page 1, the 
>page
>
> >1
> > >now displays the validator javascript along with the generated jsp 
>page.
> > >The
> > >html source is missing the script tag and the function
> > >validateInitialSearchForm. As there is no start and end tag for script,
> >the
> > >script is displayed on the page. This happens only in the production
> > >environment.
> > >Any help is appreciated. Any clue on why the javascript generated by 
>the
> > >validator is be displayed on the jsp page ?
> > >Thanx,
> > >Manisha
> > >
> > >-
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >_
> >STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> >http://join.msn.com/?page=features/junkmail
> >
> >
> >-
> >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]
> >
>
>_
>Add photos to your messages with MSN 8. Get 2 months FREE*.
>http://join.msn.com/?page=features/featuredemail
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>--

Re: composable RequestProcessor

[Kent Sølvsten Rasmussen]

Doctor it hurts when I do that

Then don't do that!

A lot of places in the Struts framework, simple inheritance is used. Some places 
because it's the simplest thing that might possibly work, other places to avoid 
unwanted flexibility (ActionForm).

When the simple solution is starting to feel awkward or even hurt, it might be time to 
consider a more complex, but more flexible solution, often by using some sort of 
composition/delegation (like splitting up the ActionServlet), since we have chosen to 
use a language without multiple inheritance.

There seem to be a consensus, that the RequestProcessor is indeed an improvement over 
the old ActionServlet, but it's starting to hurt. Most people also seem to agree that 
some sort of composition is the next logical step.

A lot of people seem to disagree about HOW to implement decomposition best.

The most obvious solution seem to be an interface for each of the 16 (??) methods and 
someway to configure which implementations to use where.

It might be possible though to keep the solution a bit simpler by grouping some of the 
methods in the same interfaces, methods that are seldom overwritten, or methods that 
tend to be overwritten together, or methods with tight cooperation.

This would be a step forward in flexibility, but with a small increase in complexity.

One danger with this solution is, that some of the methods tend to depend on each 
other, and thus the aforementioned solution might contain too many degrees of freedom. 
But maybe it's just FUD.

Ted pointed out the similarity between the Validator and a composable 
RequestProcessor. It could be a way to restrict the freedom by defining some sort of 
dependencies between the processing methods (both by somehow defining a lifecycle, and 
by somehow defining dependencies between implementations. It might be unneccesary, it 
might be too complex, it might not be the best solution, and it might not even work! 
The question is: The validator and a composable RequestProcessor have some 
similarities conceptually. Are these so big, that they should result in similarities 
in the implementation, or would that be a bad idea?

But I guess this is just speculating about hte future. Maybe the best solution is to 
create a simple composable RequestProcessor for 1.2 and then see what the future might 
bring?

- Kent


Ted Husted <[EMAIL PROTECTED]> wrote:
> Jeff Robertson wrote:
> > Wow. Mr. Husted, this may seem like an obvious conclusion
> to you, but to me
> > (and probably others as well) this is a big "hey, why
> didn't I think of
> > that!" moment.
> 
> I know the feeling -- I just got it reading the latest docs
> for the 
> Struts Workflow extension =:0)
> 
> IMHO, Matthais is pointing out a very real issue with the
> current 
> architecture. It's moving in the right direction, but
> doesn't go far 
> enough. In order to bring out extensions like Workflow, he
> has to do a 
> special Tiles version. People really shouldn't have to do
> that, and the 
> implication is either the Tiles or RequestProcessor
> implementations are 
> falling short of the mark.
> 
> I don't know when a version of Struts based on Filters will
> be 
> available. But I do know that if someone came up with a
> implementation 
> of a composable RequestProcessor that worked like the
> Validator, I'd 
> probably commit it.
> 
> One day, this work all may be obviated by Filters, but until
> then, it 
> would be a good way to see how Filters might be used in
> Struts 2.0.
> 
> I also think that given the codebase for the Validator and
> the existing 
> RequestProcessor, it's not that much of a stretch. If we
> define the 
> interface right, we should be able to keep the original 
> RequestProcessor, so the whole composible thing becomes a
> bleeding-edge 
> option, and not a required implementation.
> 
> -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]

RE: Status check?

[James Turner]

> From: Ted Husted [mailto:[EMAIL PROTECTED] 
> So, pending advice to the contrary, I'll plan on putting 29 
> June 2003 in 
>   the Release Plan (two years and two weeks after Struts 1.0).

Sounds very Lincoln-ian... Two years and two weeks ago, Craig McClanahan
brought forth upon the Java community a new framework, conceived of MVC,
and devoted to the notion that all business logic should be treated
separate.

Advice to Craig:  Avoid theatres.

James



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

Re: Status check?

[Ted Husted]

Ted Husted wrote:
Craig R. McClanahan wrote:
 > I do think we should say something like "two weeks after RC2, barring
 > any major bugs" so that we can encourage people to actually try RC2 in
 > that time frame.
June 15 would the be second anniversary of Struts 1.0 -- but I reckon 
that's a might too close, so let's say June 22, barring any showstoppers.
Though, , JavaOne is next week, and so that shouldn't really 
count. Meanwhile, there's still a few places where the 1.1 documentation 
is a bit skimpy, and the News and Resources sections are way behind, and 
I'd like to beef those up before the world comes knocking on our door.

There's also the small matter of whether FileUpload has gone final. 
AFAIK, we need final versions of all our dependent JARs, or else Struts 
will still not be accessible to many teams.

So, pending advice to the contrary, I'll plan on putting 29 June 2003 in 
 the Release Plan (two years and two weeks after Struts 1.0).

-Ted.



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

Re: Status check?

[Ted Husted]

Craig R. McClanahan wrote:
> I do think we should say something like "two weeks after RC2, barring
> any major bugs" so that we can encourage people to actually try RC2 in
> that time frame.
June 15 would the be second anniversary of Struts 1.0 -- but I reckon 
that's a might too close, so let's say June 22, barring any showstoppers.

-T.



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

[OT] SEX SEX SEX

[James Mitchell]

Ok, now that I've got your attention ;)

Please go and vote:
http://www.sys-con.com/java/readerschoice2003/index.cfm



--
James Mitchell
Software Developer/Struts Evangelist
http://www.struts-atlanta.org
770-822-3359
AIM:jmitchtx



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

Re: composable RequestProcessor

[Ted Husted]

Jeff Robertson wrote:
Wow. Mr. Husted, this may seem like an obvious conclusion to you, but to me
(and probably others as well) this is a big "hey, why didn't I think of
that!" moment.
I know the feeling -- I just got it reading the latest docs for the 
Struts Workflow extension =:0)

IMHO, Matthais is pointing out a very real issue with the current 
architecture. It's moving in the right direction, but doesn't go far 
enough. In order to bring out extensions like Workflow, he has to do a 
special Tiles version. People really shouldn't have to do that, and the 
implication is either the Tiles or RequestProcessor implementations are 
falling short of the mark.

I don't know when a version of Struts based on Filters will be 
available. But I do know that if someone came up with a implementation 
of a composable RequestProcessor that worked like the Validator, I'd 
probably commit it.

One day, this work all may be obviated by Filters, but until then, it 
would be a good way to see how Filters might be used in Struts 2.0.

I also think that given the codebase for the Validator and the existing 
RequestProcessor, it's not that much of a stretch. If we define the 
interface right, we should be able to keep the original 
RequestProcessor, so the whole composible thing becomes a bleeding-edge 
option, and not a required implementation.

-Ted.



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

Re: Status check?

[James Mitchell]

- Original Message - 
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 04, 2003 2:42 PM
Subject: RE: Status check?


> >Right, but what's the right amount of time to wait?
> 
> Craig suggested 2 weeks and I think that sounds good.

+1


--
James Mitchell
Software Developer/Struts Evangelist
http://www.struts-atlanta.org
770-822-3359
AIM:jmitchtx

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

RE: Status check?

[James Turner]

Good for me too.

James

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 04, 2003 2:43 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Status check?
> 
> 
> >Right, but what's the right amount of time to wait?
> 
> Craig suggested 2 weeks and I think that sounds good.
> 
> David
> 
> >
> >James
> >
> > > -Original Message-
> > > From: David Graham [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, June 04, 2003 2:34 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Status check?
> > >
> > >
> > > Setting release dates is not a good idea for many 
> reasons. IMO, 1.1 
> > > final should be released after enough time that people have tested
> > > apps with RC2
> > > and there are no show stopping bugs.
> > >
> > > David
> > >
> > > >Good for me.  Since the intent is for RC2 to go final after
> > > testing and
> > > >a FileUpload Final, do we want to set a date for Struts 
> 1.1 final?
> > > >
> > > >Think we can have RC2 live before we head off for SF?  
> It would be 
> > > >a nice trophy to bring to JavaOne, especially with a target
> > > release date
> > > >for Final.
> > > >
> > > >James
> > > >
> > > > > -Original Message-
> > > > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > > > Sent: Wednesday, June 04, 2003 2:25 PM
> > > > > To: Struts Developers List
> > > > > Subject: Re: Status check?
> > > > >
> > > > >
> > > > >
> > > > > Martin Cooper wrote:
> > > > > > OK, FileUpload 1.0 RC1 is out. I haven't done the
> > > > > announcement yet, or
> > > > > > updated the web site, but it's there.
> > > > > >
> > > > > > The Tomcat build did indeed break, and interested parties
> > > > > can see the
> > > > > > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to 
> > > > > > David and Joe for their support.
> > > > >
> > > > > Excellent. I'm blocking out Friday morning to work on 
> releasing 
> > > > > struts-legacy and then RC2. I assume it's OK with 
> everyone if we 
> > > > > just update the RC1 plan and work from that.
> > > > >
> > > > > -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]
> > > >
> > >
> > > _
> > > Help STOP SPAM with the new MSN 8 and get 2 months FREE* 
> > > http://join.msn.com/?page=features/junkmail
> > >
> > >
> > > 
> 
> > > -
> > > 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]
> >
> 
> _
> Protect your PC - get McAfee.com VirusScan Online  
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> 
> 
> -
> 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]

[ANNOUNCE] Updated Struts-Faces Integration Library

[Craig R. McClanahan]

As you might already be aware, the Public Draft 2 version of the
JavaServer Faces specification is now available:

  http://java.sun.com/j2ee/javaserverfaces/download.html

with many new and exciting features.  The EA4 version of the JavaServer
Faces reference implementation is available as part of the Java
Web Services Developer Pack 1.2 release (and easily separable for
use on other containers):

  http://java.sun.com/webservices/downloads/webservicespack.html

I have updated the Struts-Faces integration library that was previously
published, to accomodate the API changes in the new version.  Nightly
builds of the updated code, starting with the 20030605 version (i.e.
tonight) will be available at:

  http://jakarta.apache.org/builds/jakarta-struts/nightly/struts-faces/

(Versions up through and including 20030604 are for the EA3 release of
Faces; wait until tomorrow to grab the updated code.)

Craig McClanahan


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

RE: Status check?

[David Graham]

Right, but what's the right amount of time to wait?
Craig suggested 2 weeks and I think that sounds good.

David

James

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 04, 2003 2:34 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Status check?
>
>
> Setting release dates is not a good idea for many reasons.
> IMO, 1.1 final
> should be released after enough time that people have tested
> apps with RC2
> and there are no show stopping bugs.
>
> David
>
> >Good for me.  Since the intent is for RC2 to go final after
> testing and
> >a FileUpload Final, do we want to set a date for Struts 1.1 final?
> >
> >Think we can have RC2 live before we head off for SF?  It would be a
> >nice trophy to bring to JavaOne, especially with a target
> release date
> >for Final.
> >
> >James
> >
> > > -Original Message-
> > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, June 04, 2003 2:25 PM
> > > To: Struts Developers List
> > > Subject: Re: Status check?
> > >
> > >
> > >
> > > Martin Cooper wrote:
> > > > OK, FileUpload 1.0 RC1 is out. I haven't done the
> > > announcement yet, or
> > > > updated the web site, but it's there.
> > > >
> > > > The Tomcat build did indeed break, and interested parties
> > > can see the
> > > > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David
> > > > and Joe for their support.
> > >
> > > Excellent. I'm blocking out Friday morning to work on releasing
> > > struts-legacy and then RC2. I assume it's OK with everyone if we
> > > just update the RC1 plan and work from that.
> > >
> > > -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]
> >
>
> _
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
> -
> 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]
_
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

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

RE: Status check?

[James Turner]

Right, but what's the right amount of time to wait?

James

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 04, 2003 2:34 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Status check?
> 
> 
> Setting release dates is not a good idea for many reasons.  
> IMO, 1.1 final 
> should be released after enough time that people have tested 
> apps with RC2 
> and there are no show stopping bugs.
> 
> David
> 
> >Good for me.  Since the intent is for RC2 to go final after 
> testing and 
> >a FileUpload Final, do we want to set a date for Struts 1.1 final?
> >
> >Think we can have RC2 live before we head off for SF?  It would be a 
> >nice trophy to bring to JavaOne, especially with a target 
> release date 
> >for Final.
> >
> >James
> >
> > > -Original Message-
> > > From: Ted Husted [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, June 04, 2003 2:25 PM
> > > To: Struts Developers List
> > > Subject: Re: Status check?
> > >
> > >
> > >
> > > Martin Cooper wrote:
> > > > OK, FileUpload 1.0 RC1 is out. I haven't done the
> > > announcement yet, or
> > > > updated the web site, but it's there.
> > > >
> > > > The Tomcat build did indeed break, and interested parties
> > > can see the
> > > > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David 
> > > > and Joe for their support.
> > >
> > > Excellent. I'm blocking out Friday morning to work on releasing 
> > > struts-legacy and then RC2. I assume it's OK with everyone if we 
> > > just update the RC1 plan and work from that.
> > >
> > > -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]
> >
> 
> _
> Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
> http://join.msn.com/?page=features/junkmail
> 
> 
> -
> 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: Status check?

[Craig R. McClanahan]

On Wed, 4 Jun 2003, Ted Husted wrote:

> Date: Wed, 04 Jun 2003 14:25:15 -0400
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Status check?
>
>
> Martin Cooper wrote:
> > OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or
> > updated the web site, but it's there.
> >
> > The Tomcat build did indeed break, and interested parties can see the
> > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe
> > for their support.
>
> Excellent. I'm blocking out Friday morning to work on releasing
> struts-legacy and then RC2. I assume it's OK with everyone if we just
> update the RC1 plan and work from that.
>

>From a planning perspective, this sounds fine.

On a release date, is anyone going to believe any date we publish in the
plan, no matter what it is?  :-)

I do think we should say something like "two weeks after RC2, barring any
major bugs" so that we can encourage people to actually try RC2 in that
time frame.

> -Ted.

Craig

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

RE: Status check?

[David Graham]

Setting release dates is not a good idea for many reasons.  IMO, 1.1 final 
should be released after enough time that people have tested apps with RC2 
and there are no show stopping bugs.

David

Good for me.  Since the intent is for RC2 to go final after testing and
a FileUpload Final, do we want to set a date for Struts 1.1 final?
Think we can have RC2 live before we head off for SF?  It would be a
nice trophy to bring to JavaOne, especially with a target release date
for Final.
James

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 04, 2003 2:25 PM
> To: Struts Developers List
> Subject: Re: Status check?
>
>
>
> Martin Cooper wrote:
> > OK, FileUpload 1.0 RC1 is out. I haven't done the
> announcement yet, or
> > updated the web site, but it's there.
> >
> > The Tomcat build did indeed break, and interested parties
> can see the
> > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and
> > Joe for their support.
>
> Excellent. I'm blocking out Friday morning to work on releasing
> struts-legacy and then RC2. I assume it's OK with everyone if we just
> update the RC1 plan and work from that.
>
> -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]
_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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

RE: Status check?

[James Turner]

Good for me.  Since the intent is for RC2 to go final after testing and
a FileUpload Final, do we want to set a date for Struts 1.1 final?

Think we can have RC2 live before we head off for SF?  It would be a
nice trophy to bring to JavaOne, especially with a target release date
for Final.

James

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 04, 2003 2:25 PM
> To: Struts Developers List
> Subject: Re: Status check?
> 
> 
> 
> Martin Cooper wrote:
> > OK, FileUpload 1.0 RC1 is out. I haven't done the 
> announcement yet, or 
> > updated the web site, but it's there.
> > 
> > The Tomcat build did indeed break, and interested parties 
> can see the 
> > resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and 
> > Joe for their support.
> 
> Excellent. I'm blocking out Friday morning to work on releasing 
> struts-legacy and then RC2. I assume it's OK with everyone if we just 
> update the RC1 plan and work from that.
> 
> -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]

RE: composable RequestProcessor

[David Graham]

I don't see anything in the ActionServlet that couldn't be provided by some 
other class.

David


In the past the argument for creating redundant services from within Struts
was that it allowed for easier and condensed configuration management of
Struts stuff from non-struts stuff. For example, we have the plugin
(lifecylce) config which is essentially the same as using a servlet for
initialization. But, it is cleaner to manage these thing from within the
Struts lifecycle.
I guess this situation is different in the sense that the filters may be
working where the ActionServlet used to (pre RP). So, it's like coming full
circle, except now the RP has fully replaced the ActionServlet as a chain 
of
filters and we lose the  tag in the struts-config.

Yet, if we are talking about ditching the ActionServlet then we will have 
to
pass a reference of some sort to the Action classes. Currently they have an
ActionServlet reference in order to access the container methods. So, it
still might be a good thing to retain it. Don't you think?

Brandon Goodin

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 12:01 PM
To: [EMAIL PROTECTED]
Subject: RE: composable RequestProcessor
>If we use Filters in lieu of the RP wouldn't that require that we move 
the
>ActionServlet to a filter as well? Where does the ActionServlet fit in to
>this?

The ActionServlet initializes Struts from the config files but all
processing goes through the RP.  So, we could still have the servlet init.
everything if we wanted but then step aside and let the filters process
requests.  Alternatively, we could remove the ActionServlet and init. 
Struts
some other way.

David

>
>Brandon Goodin
>
>-Original Message-
>From: David Graham [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, June 04, 2003 11:44 AM
>To: [EMAIL PROTECTED]
>Subject: Re: composable RequestProcessor
>
>
>
> >David Graham wrote:
> >>Why should we duplicate the effort of the container inside Struts?
> >
> >We often duplicate the effort of the container. Actions duplicate
>servlets.
> >Modules duplicate multiple applications.
> >
> >In each of these cases, the effect of the container feature is the 
same,
> >but the justification has always been "it more lightweight".
>
>In this case it's more heavyweight.  We would have to alter the DTD,
>transform the new DTD elements to objects, code up the chaining 
mechanism,
>write unit tests, and deal with the bugs.
>
>Adding a RequestHandler interface is *much* simpler and acheives the
>desired
>results (if not in the xml configuration manner some would prefer).  It
>doesn't make sense to me, to disregard all the work that containers have
>put
>into Filters and write our own.
>
>Even after implementing our own approach we would have to spend time
>supporting and modifying it.  This especially seems like a waste of time
>given there's already a standard solution out there.
>
>This reminds me of modules where they sounded like a great idea and then
>there's nobody to support the bugs.
>
>David
>
> >
> >*If someone wanted to write it*, I don't see that a composable request
> >processor would have to be a 2.x change. The major changes could all 
take
> >place within the process method, and the original RequestProcessor 
could
> >remain available.
> >
> >Things like the DTD may have to be expanded, but it would not be 
anything
> >more radical than what we did between 1.0 and 1.1. [As if that's a good
> >justification for anything =:0)]
> >
> >-Ted.
> >
> >
> >--
> >Ted Husted,
> >Struts in Action 
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>_
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus
>
>
>-
>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]
>

_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
-
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]
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

---

Re: Status check?

[Ted Husted]

Martin Cooper wrote:
OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or
updated the web site, but it's there.
The Tomcat build did indeed break, and interested parties can see the
resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe
for their support.
Excellent. I'm blocking out Friday morning to work on releasing 
struts-legacy and then RC2. I assume it's OK with everyone if we just 
update the RC1 plan and work from that.

-Ted.



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

RE: composable RequestProcessor

[Brandon Goodin]

In the past the argument for creating redundant services from within Struts
was that it allowed for easier and condensed configuration management of
Struts stuff from non-struts stuff. For example, we have the plugin
(lifecylce) config which is essentially the same as using a servlet for
initialization. But, it is cleaner to manage these thing from within the
Struts lifecycle.

I guess this situation is different in the sense that the filters may be
working where the ActionServlet used to (pre RP). So, it's like coming full
circle, except now the RP has fully replaced the ActionServlet as a chain of
filters and we lose the  tag in the struts-config.

Yet, if we are talking about ditching the ActionServlet then we will have to
pass a reference of some sort to the Action classes. Currently they have an
ActionServlet reference in order to access the container methods. So, it
still might be a good thing to retain it. Don't you think?

Brandon Goodin

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 12:01 PM
To: [EMAIL PROTECTED]
Subject: RE: composable RequestProcessor


>If we use Filters in lieu of the RP wouldn't that require that we move the
>ActionServlet to a filter as well? Where does the ActionServlet fit in to
>this?

The ActionServlet initializes Struts from the config files but all
processing goes through the RP.  So, we could still have the servlet init.
everything if we wanted but then step aside and let the filters process
requests.  Alternatively, we could remove the ActionServlet and init. Struts
some other way.

David

>
>Brandon Goodin
>
>-Original Message-
>From: David Graham [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, June 04, 2003 11:44 AM
>To: [EMAIL PROTECTED]
>Subject: Re: composable RequestProcessor
>
>
>
> >David Graham wrote:
> >>Why should we duplicate the effort of the container inside Struts?
> >
> >We often duplicate the effort of the container. Actions duplicate
>servlets.
> >Modules duplicate multiple applications.
> >
> >In each of these cases, the effect of the container feature is the same,
> >but the justification has always been "it more lightweight".
>
>In this case it's more heavyweight.  We would have to alter the DTD,
>transform the new DTD elements to objects, code up the chaining mechanism,
>write unit tests, and deal with the bugs.
>
>Adding a RequestHandler interface is *much* simpler and acheives the
>desired
>results (if not in the xml configuration manner some would prefer).  It
>doesn't make sense to me, to disregard all the work that containers have
>put
>into Filters and write our own.
>
>Even after implementing our own approach we would have to spend time
>supporting and modifying it.  This especially seems like a waste of time
>given there's already a standard solution out there.
>
>This reminds me of modules where they sounded like a great idea and then
>there's nobody to support the bugs.
>
>David
>
> >
> >*If someone wanted to write it*, I don't see that a composable request
> >processor would have to be a 2.x change. The major changes could all take
> >place within the process method, and the original RequestProcessor could
> >remain available.
> >
> >Things like the DTD may have to be expanded, but it would not be anything
> >more radical than what we did between 1.0 and 1.1. [As if that's a good
> >justification for anything =:0)]
> >
> >-Ted.
> >
> >
> >--
> >Ted Husted,
> >Struts in Action 
> >
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>_
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus
>
>
>-
>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]
>

_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail


-
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: composable RequestProcessor

[Ted Husted]

David Graham wrote:
This reminds me of modules where they sounded like a great idea and then 
there's nobody to support the bugs.
Amen to that, brother.

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=133116

-Ted.



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

RE: composable RequestProcessor

[David Graham]

If we use Filters in lieu of the RP wouldn't that require that we move the
ActionServlet to a filter as well? Where does the ActionServlet fit in to
this?
The ActionServlet initializes Struts from the config files but all 
processing goes through the RP.  So, we could still have the servlet init. 
everything if we wanted but then step aside and let the filters process 
requests.  Alternatively, we could remove the ActionServlet and init. Struts 
some other way.

David

Brandon Goodin

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 11:44 AM
To: [EMAIL PROTECTED]
Subject: Re: composable RequestProcessor


>David Graham wrote:
>>Why should we duplicate the effort of the container inside Struts?
>
>We often duplicate the effort of the container. Actions duplicate 
servlets.
>Modules duplicate multiple applications.
>
>In each of these cases, the effect of the container feature is the same,
>but the justification has always been "it more lightweight".

In this case it's more heavyweight.  We would have to alter the DTD,
transform the new DTD elements to objects, code up the chaining mechanism,
write unit tests, and deal with the bugs.
Adding a RequestHandler interface is *much* simpler and acheives the 
desired
results (if not in the xml configuration manner some would prefer).  It
doesn't make sense to me, to disregard all the work that containers have 
put
into Filters and write our own.

Even after implementing our own approach we would have to spend time
supporting and modifying it.  This especially seems like a waste of time
given there's already a standard solution out there.
This reminds me of modules where they sounded like a great idea and then
there's nobody to support the bugs.
David

>
>*If someone wanted to write it*, I don't see that a composable request
>processor would have to be a 2.x change. The major changes could all take
>place within the process method, and the original RequestProcessor could
>remain available.
>
>Things like the DTD may have to be expanded, but it would not be anything
>more radical than what we did between 1.0 and 1.1. [As if that's a good
>justification for anything =:0)]
>
>-Ted.
>
>
>--
>Ted Husted,
>Struts in Action 
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
-
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]
_
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

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

RE: composable RequestProcessor

[Brandon Goodin]

If we use Filters in lieu of the RP wouldn't that require that we move the
ActionServlet to a filter as well? Where does the ActionServlet fit in to
this?

Brandon Goodin

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 11:44 AM
To: [EMAIL PROTECTED]
Subject: Re: composable RequestProcessor



>David Graham wrote:
>>Why should we duplicate the effort of the container inside Struts?
>
>We often duplicate the effort of the container. Actions duplicate servlets.
>Modules duplicate multiple applications.
>
>In each of these cases, the effect of the container feature is the same,
>but the justification has always been "it more lightweight".

In this case it's more heavyweight.  We would have to alter the DTD,
transform the new DTD elements to objects, code up the chaining mechanism,
write unit tests, and deal with the bugs.

Adding a RequestHandler interface is *much* simpler and acheives the desired
results (if not in the xml configuration manner some would prefer).  It
doesn't make sense to me, to disregard all the work that containers have put
into Filters and write our own.

Even after implementing our own approach we would have to spend time
supporting and modifying it.  This especially seems like a waste of time
given there's already a standard solution out there.

This reminds me of modules where they sounded like a great idea and then
there's nobody to support the bugs.

David

>
>*If someone wanted to write it*, I don't see that a composable request
>processor would have to be a 2.x change. The major changes could all take
>place within the process method, and the original RequestProcessor could
>remain available.
>
>Things like the DTD may have to be expanded, but it would not be anything
>more radical than what we did between 1.0 and 1.1. [As if that's a good
>justification for anything =:0)]
>
>-Ted.
>
>
>--
>Ted Husted,
>Struts in Action 
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>

_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus


-
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: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2

[Craig R. McClanahan]

You can count me retroactively +1 as well ... sorry, it's been insanely
busy lately.

Craig

On Wed, 4 Jun 2003, James Turner wrote:

> Date: Wed, 4 Jun 2003 00:31:38 -0400
> From: James Turner <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2
>
> I went back and checked, you did indeed.  So the final list is:
> James Holmes [EMAIL PROTECTED]
> James Turner [EMAIL PROTECTED]
> James Mitchell [EMAIL PROTECTED]
> Arron Bates [EMAIL PROTECTED]
> David Graham [EMAIL PROTECTED]
>
> > -Original Message-
> > From: David Graham [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 04, 2003 12:25 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2
> >
> >
> > I'm fairly certain I voted +1 on this.
> >
> > David
> >
> >
> > >From: "James Turner" <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Subject: [RESULTS] Release Struts RC2 with FileUpload RC1/Beta2
> > >Date: Tue, 3 Jun 2003 23:47:12 -0400
> > >
> > >+1
> > >James Holmes [EMAIL PROTECTED]
> > >James Turner [EMAIL PROTECTED]
> > >James Mitchell [EMAIL PROTECTED]
> > >Arron Bates [EMAIL PROTECTED]
> > >
> > >No other votes (unless Ted and David Graham want to +1
> > retroactively,
> > >since they seemed to be supportive but didn't explicitly +1)
> > >
> > >Therefore, the vote passes.
> > >
> > >James Turner
> > >Director of Software Development
> > >Benefit Systems, Inc.
> > >[EMAIL PROTECTED]
> > >
> > >Track Chair, Strategic Open Source
> > >2003 Fall COMDEX
> > >
> > >Author:
> > > MySQL & JSP Web Applications
> > > Struts Kick Start
> > > JavaServer Faces Kick Start
> > >
> > >
> > >
> > >-
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> > _
> > The new MSN 8: smart spam protection and 2 months FREE*
> > http://join.msn.com/?page=features/junkmail
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: composable RequestProcessor

[David Graham]

David Graham wrote:
Why should we duplicate the effort of the container inside Struts?
We often duplicate the effort of the container. Actions duplicate servlets. 
Modules duplicate multiple applications.

In each of these cases, the effect of the container feature is the same, 
but the justification has always been "it more lightweight".
In this case it's more heavyweight.  We would have to alter the DTD, 
transform the new DTD elements to objects, code up the chaining mechanism, 
write unit tests, and deal with the bugs.

Adding a RequestHandler interface is *much* simpler and acheives the desired 
results (if not in the xml configuration manner some would prefer).  It 
doesn't make sense to me, to disregard all the work that containers have put 
into Filters and write our own.

Even after implementing our own approach we would have to spend time 
supporting and modifying it.  This especially seems like a waste of time 
given there's already a standard solution out there.

This reminds me of modules where they sounded like a great idea and then 
there's nobody to support the bugs.

David

*If someone wanted to write it*, I don't see that a composable request 
processor would have to be a 2.x change. The major changes could all take 
place within the process method, and the original RequestProcessor could 
remain available.

Things like the DTD may have to be expanded, but it would not be anything 
more radical than what we did between 1.0 and 1.1. [As if that's a good 
justification for anything =:0)]

-Ted.

--
Ted Husted,
Struts in Action 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

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

cvs commit: jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example LinkSubscriptionRenderer.java LinkSubscriptionTag.java

[craigmcc]

craigmcc2003/06/04 10:37:36

  Modified:contrib/struts-faces/src/example/org/apache/struts/webapp/example
LinkSubscriptionRenderer.java
LinkSubscriptionTag.java
  Log:
  Update the example app sources for the new EA4 release of JavaServer
  Faces.
  
  Revision  ChangesPath
  1.2   +14 -6 
jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example/LinkSubscriptionRenderer.java
  
  Index: LinkSubscriptionRenderer.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example/LinkSubscriptionRenderer.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LinkSubscriptionRenderer.java 7 Mar 2003 03:22:42 -   1.1
  +++ LinkSubscriptionRenderer.java 4 Jun 2003 17:37:36 -   1.2
  @@ -64,10 +64,14 @@
   
   import java.io.IOException;
   import javax.faces.FacesException;
  +import javax.faces.FactoryFinder;
  +import javax.faces.application.Application;
  +import javax.faces.application.ApplicationFactory;
   import javax.faces.component.UIComponent;
   import javax.faces.component.UIOutput;
   import javax.faces.context.FacesContext;
   import javax.faces.context.ResponseWriter;
  +import javax.faces.el.ValueBinding;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
   import org.apache.commons.logging.Log;
  @@ -119,17 +123,21 @@
   
   ResponseWriter writer = context.getResponseWriter();
   HttpServletRequest request = (HttpServletRequest)
  -context.getServletRequest();
  +context.getExternalContext().getRequest();
   HttpServletResponse response = (HttpServletResponse)
  -context.getServletResponse();
  +context.getExternalContext().getResponse();
   String name = (String) component.getAttribute("name");
   String page = (String) component.getAttribute("page");
   
   // Generate the URL to be encoded
   StringBuffer url = new StringBuffer(request.getContextPath());
   url.append(page);
  +ApplicationFactory factory = (ApplicationFactory)
  +FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
  +Application application = factory.getApplication();
  +ValueBinding binding = application.getValueBinding(name);
   Subscription subscription = (Subscription)
  -context.getModelValue(name);
  +binding.getValue(context);
   if (subscription == null) {
   throw new FacesException
   ("No subscription under attribute '" + name + "'");
  
  
  
  1.2   +9 -11 
jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example/LinkSubscriptionTag.java
  
  Index: LinkSubscriptionTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example/LinkSubscriptionTag.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LinkSubscriptionTag.java  7 Mar 2003 03:22:42 -   1.1
  +++ LinkSubscriptionTag.java  4 Jun 2003 17:37:36 -   1.2
  @@ -65,9 +65,7 @@
   
   import java.io.IOException;
   import javax.faces.component.UIComponent;
  -import javax.faces.component.UIOutput;
  -import javax.faces.webapp.FacesTag;
  -import javax.servlet.jsp.JspException;
  +import javax.faces.webapp.UIComponentTag;
   
   
   /**
  @@ -78,7 +76,7 @@
* @version $Revision$ $Date$
*/
   
  -public class LinkSubscriptionTag extends FacesTag {
  +public class LinkSubscriptionTag extends UIComponentTag {
   
   
   // - Attributes
  @@ -108,11 +106,11 @@
   
   
   /**
  - * Create a new component for this tag.
  + * Return the component type for this tag.
*/
  -public UIComponent createComponent() {
  +public String getComponentType() {
   
  -return (new UIOutput());
  +return ("Output");
   
   }
   
  
  
  

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

cvs commit: jakarta-struts/contrib/struts-faces/web/example/WEB-INF web.xml

[craigmcc]

craigmcc2003/06/04 10:37:02

  Modified:contrib/struts-faces/web/example logon.jsp registration.jsp
subscription.jsp
   contrib/struts-faces/web/example/WEB-INF web.xml
  Log:
  Update the web portion of the Struts-Faces example app for the new
  EA4 release of JavaServer Faces.
  
  Revision  ChangesPath
  1.2   +2 -2  jakarta-struts/contrib/struts-faces/web/example/logon.jsp
  
  Index: logon.jsp
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-faces/web/example/logon.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- logon.jsp 7 Mar 2003 03:22:45 -   1.1
  +++ logon.jsp 4 Jun 2003 17:37:02 -   1.2
  @@ -39,14 +39,14 @@
   
   
   
  +valueRef="logonForm.username"/>
   
   
 
   
   
   
  +  valueRef="logonForm.password"/>
   
   
   
  -  
  +  
   
 
   
 
  +valueRef="registrationForm.username"/>
   
   
 
   
  + valueRef="registrationForm.username"/>
   
  +valueRef="registrationForm.username"/>
 
   
   
  @@ -92,35 +92,35 @@
   
   
   
  +size="16" valueRef="registrationForm.password"/>
   
   
 
   
   
   
  +size="16" valueRef="registrationForm.password2"/>
   
   
 
   
   
   
  +size="50" valueRef="registrationForm.fullName"/>
   
   
 
   
   
   
  +size="50" valueRef="registrationForm.fromAddress"/>
   
   
 
   
   
   
  +size="50" valueRef="registrationForm.replyToAddress"/>
   
   
   
  -  
  -  
  -  
  -  
  -  
  -
  -  
  -
  -
  -  
  -
  -  
  +   valueRef="user.subscriptions">
  +  
  +  
  +  
  +  
  +  
  +
  +  
  +  
  +  
  +
  +
  +  
  +  
  +  
  +
  +  
   
   
 
   
  -  
  -
  +  
  +
  +
 
   
   
  
  
  
  1.2   +9 -9  jakarta-struts/contrib/struts-faces/web/example/subscription.jsp
  
  Index: subscription.jsp
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-faces/web/example/subscription.jsp,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- subscription.jsp  7 Mar 2003 03:22:45 -   1.1
  +++ subscription.jsp  4 Jun 2003 17:37:02 -   1.2
  @@ -33,7 +33,7 @@
   
   
   
  -  
  +  
   
 
   
   
  + valueRef="user.username"/>
   
   
 
  @@ -78,13 +78,13 @@
   
 
   
  +  valueRef="subscriptionForm.host"/>
 
 
   
 
  -  
  +valueRef="subscriptionForm.host"/>
  +  
   
 
   
  @@ -94,21 +94,21 @@
   
   
   
  +size="50" valueRef="subscriptionForm.username"/>
   
   
 
   
   
   
  +size="50" valueRef="subscriptionForm.password"/>
   
   
 
   
   
   
  +  valueRef="subscriptionForm.type">
 
 
   
  @@ -118,7 +118,7 @@
   
   
   
  +  valueRef="subscriptionForm.autoConnect"/>
   
   
 
  
  
  
  1.2   +1 -0  jakarta-struts/contrib/struts-faces/web/example/WEB-INF/web.xml
  
  Index: web.xml
  ===
  RCS file: /home/cvs/jakarta-struts/contrib/struts-faces/web/example/WEB-INF/web.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- web.xml   7 Mar 2003 03:22:45 -   1.1
  +++ web.xml   4 Jun 2003 17:37:02 -   1.2
  @@ -6,6 +6,7 @@
   
   
   
  +  Struts-Faces Integration Library Example
   
 
 
  
  
  

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

Re: Status check?

[Martin Cooper]

On Sat, 31 May 2003, Martin Cooper wrote:

>
> "Ted Husted" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Martin Cooper wrote:
> >  > Now, about the Struts 1.1 RC2 release. The problem is the staging
> >  > needed to get FileUpload out the door. It's currently at Beta 1, and
> >  > the code base in CVS has some methods that have been deprecated since
> >  > Beta 1. The deprecated methods need to be removed before 1.0 Final,
> >  > which means that we need a Beta 2 to publicise the deprecations. Then
> >  > they can be removed in an RC1, shortly to be followed (hopefully) by
> >  > 1.0 Final.
> >
> > So, Martin, just to confirm, if you can squeak out a FileUpload Beta 2
> > this weekend, I can then cut RC2 with that, if you like.
>
> The bugs are all resolved now. (1 fixed, 1 remind, 3 later (enhancements).)
> So it's just a matter of what release this will be, and what to do about the
> deprecated methods. Then I can send out the vote.

OK, FileUpload 1.0 RC1 is out. I haven't done the announcement yet, or
updated the web site, but it's there.

The Tomcat build did indeed break, and interested parties can see the
resulting fun on commons-dev or tomcat-dev. ;-) Thanks to David and Joe
for their support.

--
Martin Cooper


>
> >
> > I'm going to release the struts-generic package first thing in the
> > morning, and move the nightly build dependencies over to that, so we can
> > then just plug in the latest FileUpload.
> >
> > IMHO, you might consider taking FileUpload straight to RC1. It's
> > unreleased software and API changes are to be expected. If this were FU
> > 2.0, and you were removing something that was in FU 1.0's established
> > API, it would be different. But greater latitude as to API changes
> > should be given to unreleased, pre-1.0 packages.
>
> So you're suggesting that I rip out the deprecated methods now, go for RC1,
> and damn the torpedoes that the API is incompatible between Beta 1 and RC1,
> and there was no warning (other than nightly builds)? You really think
> that's OK?
>
> Gump builds for Tomcat and Turbine will start failing as soon as I remove
> the deprecated methods. Tapestry won't be affected, since Mr. Tapestry
> doesn't like the way Gump works, and has nailed Tapestry to Beta 1. Struts
> already has the necessary changes.
>
> --
> Martin Cooper
>
>
> >
> > If you were to go to FileUpload RC1, then perhaps Struts and FileUpload
> > can then go to final together.
> >
> > -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]

DO NOT REPLY [Bug 11852] - The bean:message tag should accept Objects as arguments

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=11852

The bean:message tag should accept Objects as arguments





--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 17:33 ---
>JSTL apparently supports this functionality.  We should not duplicate the 
>standarized effort in Struts. 

JSTL requires a 2.3 compliant Web Container (AFAIK). If we are to support Struts
1.X, this functionality is required.

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

Re: composable RequestProcessor

[Ted Husted]

David Graham wrote:
Why should we duplicate the effort of the container inside Struts?  
We often duplicate the effort of the container. Actions duplicate 
servlets. Modules duplicate multiple applications.

In each of these cases, the effect of the container feature is the same, 
but the justification has always been "it more lightweight".

*If someone wanted to write it*, I don't see that a composable request 
processor would have to be a 2.x change. The major changes could all 
take place within the process method, and the original RequestProcessor 
could remain available.

Things like the DTD may have to be expanded, but it would not be 
anything more radical than what we did between 1.0 and 1.1. [As if 
that's a good justification for anything =:0)]

-Ted.

--
Ted Husted,
Struts in Action 


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

RE: Re: composable RequestProcessor

[Brandon Goodin]

Actions have some drastically different logical contents that may make them
incompatible with other Actions. I'm not sure how you could create a
composable Action process without rewriting the whole underlying struts
Action architecture. Also, there are other ways to avoid the "pitfalls" of
Action chaining. Take a look at Struts Chaining extenstion
http://sf.net/projects/strutschaining. I posted an Announcement about Struts
Chaining being on sourceforge and on increasing it's flexibility not too
long ago. I don't think that compoosable Actions are a good idea to impose
on all actions. It is, however, possible to do now, if you need to.

Brandon Goodin

-Original Message-
From: Andrew Hill [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 10:23 AM
To: Struts Developers List
Subject: RE: Re: composable RequestProcessor



I'm not sure why you shouldn't open it up all the way.


Sounds good to me. Why stop at the RP. Why not take it all the way to the
action as well?
A lot of people have been clamoring for some kind of method to configurably
compose action functionality in a way that avoids the deadly pitfalls of
'action chaining'.

-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: Thursday, 5 June 2003 00:15
To: Struts Developers List
Subject: RE: Re: composable RequestProcessor


At 9:36 -0600 6/4/03, Brandon Goodin wrote:
>That sounds very complex. With Validator we are dealing with quantifiable
>results. This is not so cut and dry with RP stuff. With the RP I think we
>would do best not to add anymore complexity than neccessary. One process
>should be ignorant of the other unless data is provided in the Tranfer
>Object to trigger certain behavior of functionality. Can you think of an
>example where this would be neccessary? If your extension has dependencies
>on another extension, I think it would be best to just document it.


My initial reaction was also "too complex," but at least from the way
Ted has presented it, there's not even anyway for the Struts
developers to stop it!

At 7:04 -0400 6/4/03, Ted Husted wrote:
>process="processLocale,processContent,processNoCache,processPreprocess,proc
essMapping,processRoles,processActionForm,processPopulate,processValidate,pr
ocessForward,processInclude,processActionCreate,processActionPerform,process
ForwardConfig"
>
>where each of these have been defined as a Subprocessor (e.g. Validator).
>
>As it stands, many of the process methods take different signatures
>and return different objects. But that could be changed so that they
>pass around a single data transfer object with a place for all the
>usual objects (request,response,mapping,form,action,forward).
>
>Whether each component in this sequence is systemically compatible
>or whether the order of the processes makes sense, would be the
>developer's responsibility, just as it is for defining a chain of
>Validators.

Not that we have to use Ted's configuration syntax.  However, the
alternative I think of is to have a bunch of named attributes like
this:

processLocale="com.foo.RequestProcessor"
processContent="com.foo.RequestProcessor"
processNoCache="org.bar.RequestProcessor"
processPreprocess="org.bar.RequestProcessor"
...

with a fallback for undefined stages to a default behavior.  From a
strict valid-XML standpoint, this is not very extensible, but if the
goal is to control things, that may be good.  But once you open the
general topic of a highly configurable request processing chain, I'm
not sure why you shouldn't open it up all the way.  If there were a
default configuration file like the default validation rules, and if
you could make named groups of processes like ANT or Maven
dependencies, then the complexity for most people would be invisible,
while the flexibility would be available.

I don't have a very strong opinion on this.  Anyone have comparisons
from other webapp frameworks?  I'm kind of suspicious of the
comparison to build tools - yes, the syntax is similar, but the use
cases aren't.

Joe

--
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier

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


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



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

Re: composable RequestProcessor

[David Graham]

I'm not convinced that this configuration is Struts' responsibility.  If we 
want to define a chain of methods that will process a request we should be 
using Filters and web.xml to configure them.  Filters are the standard 
method of doing this and fit in well with our RequestProcessor (RP) methods.

All of the RP.process* methods accept a request and response object as their 
first two arguments just like Filter.doFilter().  The other args to these 
methods would need to be stored in the request and retrieved by the filter.  
So, each RP.process* method becomes a filter that performs its specialized 
task.  If you want to add Tiles or some other extension you would configure 
appropriate filters in the web.xml chain.

Why should we duplicate the effort of the container inside Struts?  
Obviously, this would be a 2.0 change so I still support the idea of making 
a RequestHandler (or some other named) interface that people can code custom 
RequestProcessors behind for 1.x.

David


I still don't see why processing an "action" request is any different than 
processing a "validation" request.

Formed like the validation, the default request chain looks like this:

process="processLocale,processContent,processNoCache,processPreprocess,processMapping,processRoles,processActionForm,processPopulate,processValidate,processForward,processInclude,processActionCreate,processActionPerform,processForwardConfig"

where each of these have been defined as a Subprocessor (e.g. Validator).

As it stands, many of the process methods take different signatures and 
return different objects. But that could be changed so that they pass 
around a single data transfer object with a place for all the usual objects 
(request,response,mapping,form,action,forward).

Whether each component in this sequence is systemically compatible or 
whether the order of the processes makes sense, would be the developer's 
responsibility, just as it is for defining a chain of Validators.

Right now, the framework describes a lockstep lifecycle. But that really 
isn't the framework's job. The framework should provide a pre configured 
default lifecycle, but the developer should as much freedom as possible to 
define whatever lifecycle works best for a given application.

The distribution could ship with a library of Subprocessors (just as we 
ship with a library of Validators). To use Tiles, you would make the 
appropriate changes to the "process" property to load the Tiles 
Subprocessors. If someone wanted to handle a different extension point 
differently (or insert a new one), they could add a Subprocessor to the 
library (as we can with validators), and amend the "process" property.

So there would be no pre-ordained processABC and processXYZ methods or call 
sequence. The processor would call each process in turn until someone cried 
stop or the sequence was complete. You could put as many or as few 
Subprocessors into the sequence as you liked, same as we can do with 
Validators.

A radical extension, like Tiles, may also need to subclass the main 
"Processor" (aka the "RequestProcessor") that would call the individual 
Subprocessors, but hopefully the methods that it overrides (like 
internalModuleRelativeForward) won't matter to the other Subprocessors.

Or, maybe if Tiles does not have to live within a lockstep lifecycle, there 
might be a better way of interpolating the "processTiles" step, so that it 
doesn't need override "internal" methods.

So, anyway, the idea is that there would be a Subprocessor interface and 
concrete implementations for each of the existing process methods (as 
individual classes). The existing RequestProcessor(s) could implement a 
Processor interface. The new ProcessManager could also implement the 
Processor interface but call individual Subprocessors from within the 
process method. (You might be even be able to do a concept test with a 
RequestProcessor subclass that called inner classes based on the existing 
processes.) Which Subprocessors the ProcessManager calls in what order 
would be configurable.

While not as simple as what we have now, it would be more extensible, and 
has the virtue of using the same implementation pattern as another Struts 
component, the Validator. Which also means that ProcessManager would not be 
any more difficult for developers to configure and use than the Validator.

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

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

DO NOT REPLY [Bug 20459] - html:form focus and focusIndex problem

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20459

html:form focus and focusIndex problem





--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 16:35 ---
Sorry for the confusion, I sited a case for using radio buttons but my example
was using checkboxes. We have pages in our application that use radio buttons
and we have pages in our application that use a group of checkboxes depending on
if the selection of more than one item is appropriate. In most cases those items
are generated dynamically from the database so there may be 1 or more depending
on the data.

In the case of the radio buttons, we merely want to put focus on the first one,
we do not want to automatically select the item for the user.

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

RE: Re: composable RequestProcessor

[Andrew Hill]

I'm not sure why you shouldn't open it up all the way.


Sounds good to me. Why stop at the RP. Why not take it all the way to the
action as well?
A lot of people have been clamoring for some kind of method to configurably
compose action functionality in a way that avoids the deadly pitfalls of
'action chaining'.

-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: Thursday, 5 June 2003 00:15
To: Struts Developers List
Subject: RE: Re: composable RequestProcessor


At 9:36 -0600 6/4/03, Brandon Goodin wrote:
>That sounds very complex. With Validator we are dealing with quantifiable
>results. This is not so cut and dry with RP stuff. With the RP I think we
>would do best not to add anymore complexity than neccessary. One process
>should be ignorant of the other unless data is provided in the Tranfer
>Object to trigger certain behavior of functionality. Can you think of an
>example where this would be neccessary? If your extension has dependencies
>on another extension, I think it would be best to just document it.


My initial reaction was also "too complex," but at least from the way
Ted has presented it, there's not even anyway for the Struts
developers to stop it!

At 7:04 -0400 6/4/03, Ted Husted wrote:
>process="processLocale,processContent,processNoCache,processPreprocess,proc
essMapping,processRoles,processActionForm,processPopulate,processValidate,pr
ocessForward,processInclude,processActionCreate,processActionPerform,process
ForwardConfig"
>
>where each of these have been defined as a Subprocessor (e.g. Validator).
>
>As it stands, many of the process methods take different signatures
>and return different objects. But that could be changed so that they
>pass around a single data transfer object with a place for all the
>usual objects (request,response,mapping,form,action,forward).
>
>Whether each component in this sequence is systemically compatible
>or whether the order of the processes makes sense, would be the
>developer's responsibility, just as it is for defining a chain of
>Validators.

Not that we have to use Ted's configuration syntax.  However, the
alternative I think of is to have a bunch of named attributes like
this:

processLocale="com.foo.RequestProcessor"
processContent="com.foo.RequestProcessor"
processNoCache="org.bar.RequestProcessor"
processPreprocess="org.bar.RequestProcessor"
...

with a fallback for undefined stages to a default behavior.  From a
strict valid-XML standpoint, this is not very extensible, but if the
goal is to control things, that may be good.  But once you open the
general topic of a highly configurable request processing chain, I'm
not sure why you shouldn't open it up all the way.  If there were a
default configuration file like the default validation rules, and if
you could make named groups of processes like ANT or Maven
dependencies, then the complexity for most people would be invisible,
while the flexibility would be available.

I don't have a very strong opinion on this.  Anyone have comparisons
from other webapp frameworks?  I'm kind of suspicious of the
comparison to build tools - yes, the syntax is similar, but the use
cases aren't.

Joe

--
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier

-
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: Re: composable RequestProcessor

[Joe Germuska]

At 9:36 -0600 6/4/03, Brandon Goodin wrote:
That sounds very complex. With Validator we are dealing with quantifiable
results. This is not so cut and dry with RP stuff. With the RP I think we
would do best not to add anymore complexity than neccessary. One process
should be ignorant of the other unless data is provided in the Tranfer
Object to trigger certain behavior of functionality. Can you think of an
example where this would be neccessary? If your extension has dependencies
on another extension, I think it would be best to just document it.


My initial reaction was also "too complex," but at least from the way 
Ted has presented it, there's not even anyway for the Struts 
developers to stop it!

At 7:04 -0400 6/4/03, Ted Husted wrote:
process="processLocale,processContent,processNoCache,processPreprocess,processMapping,processRoles,processActionForm,processPopulate,processValidate,processForward,processInclude,processActionCreate,processActionPerform,processForwardConfig"

where each of these have been defined as a Subprocessor (e.g. Validator).

As it stands, many of the process methods take different signatures 
and return different objects. But that could be changed so that they 
pass around a single data transfer object with a place for all the 
usual objects (request,response,mapping,form,action,forward).

Whether each component in this sequence is systemically compatible 
or whether the order of the processes makes sense, would be the 
developer's responsibility, just as it is for defining a chain of 
Validators.
Not that we have to use Ted's configuration syntax.  However, the 
alternative I think of is to have a bunch of named attributes like 
this:

processLocale="com.foo.RequestProcessor"
processContent="com.foo.RequestProcessor"
processNoCache="org.bar.RequestProcessor"
processPreprocess="org.bar.RequestProcessor"
...
with a fallback for undefined stages to a default behavior.  From a 
strict valid-XML standpoint, this is not very extensible, but if the 
goal is to control things, that may be good.  But once you open the 
general topic of a highly configurable request processing chain, I'm 
not sure why you shouldn't open it up all the way.  If there were a 
default configuration file like the default validation rules, and if 
you could make named groups of processes like ANT or Maven 
dependencies, then the complexity for most people would be invisible, 
while the flexibility would be available.

I don't have a very strong opinion on this.  Anyone have comparisons 
from other webapp frameworks?  I'm kind of suspicious of the 
comparison to build tools - yes, the syntax is similar, but the use 
cases aren't.

Joe

--
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

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

DO NOT REPLY [Bug 20432] - Validator returns nulls in JavaScript validation

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20432

Validator returns nulls in JavaScript validation

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Validator Framework |Validator
Product|Struts  |Commons
Version|Nightly Build   |1.0 Alpha



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 16:13 ---
This looks like a bug in the development version of commons-validator that 
Struts unfortunately picked up during its build.  Replace the commons-validator.
jar with the commons-validator 1.0.2 release.  Moving over to commons...

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

DO NOT REPLY [Bug 20265] - Locale missing when constructing a MessageFormat in MessageResources

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20265

Locale missing when constructing a MessageFormat in MessageResources

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 16:02 ---
*** Bug 20468 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 20468] - MessageResources always uses the default Locale for MessageFormats

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20468

MessageResources always uses the default Locale for MessageFormats

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 16:02 ---


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

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

DO NOT REPLY [Bug 11852] - The bean:message tag should accept Objects as arguments

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=11852

The bean:message tag should accept Objects as arguments

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 15:59 ---
*** Bug 20466 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 20466] - should accept Object args instead of String args

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=20466

 should accept Object args instead of String args

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|Unknown |Custom Tags
 Resolution||DUPLICATE
Summary|bean:message should accept  | should accept
   |Object args instead of  |Object args instead of
   |String args |String args



--- Additional Comments From [EMAIL PROTECTED]  2003-06-04 15:59 ---


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

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

RE: Re: composable RequestProcessor

[Brandon Goodin]

That sounds very complex. With Validator we are dealing with quantifiable
results. This is not so cut and dry with RP stuff. With the RP I think we
would do best not to add anymore complexity than neccessary. One process
should be ignorant of the other unless data is provided in the Tranfer
Object to trigger certain behavior of functionality. Can you think of an
example where this would be neccessary? If your extension has dependencies
on another extension, I think it would be best to just document it.

Brandon Goodin

-Original Message-
From: Kent Sølvsten Rasmussen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 9:19 AM
To: Struts Developers List
Subject: Re: Re: composable RequestProcessor


Just a thought...

Would it be possible to take the anology to Validator one step further?

Instead of a predefined or configurable lifecycle, would it be possible to
let the SubProcessors depend on each other, just like some of the
validations "depend" on each other?

Maybe the configurationfile could contain a number of named subprocessors,
some default, some from Tiles, some from other extensions. This way it might
be possible to declare that processYYY from extension XXX depends on
processZZZ.

This way a chain might be defined, not by defining the chain itself, but by
defining dependencies among it's subprocessors.

Sorry for being unclear, but hopefully You get the idea.

-Kent




Ted Husted <[EMAIL PROTECTED]> wrote:
> I still don't see why processing an "action" request is any
> different
> than processing a "validation" request.
>
> Formed like the validation, the default request chain looks
> like this:
>
> process="processLocale,processContent,processNoCache,process
> Preprocess,processMapping,processRoles,processActionForm,pro
> cessPopulate,processValidate,processForward,processInclude,p
> rocessActionCreate,processActionPerform,processForwardConfig
> "
>
> where each of these have been defined as a Subprocessor
> (e.g. Validator).
>
> As it stands, many of the process methods take different
> signatures and
> return different objects. But that could be changed so that
> they pass
> around a single data transfer object with a place for all
> the usual
> objects (request,response,mapping,form,action,forward).
>
> Whether each component in this sequence is systemically
> compatible or
> whether the order of the processes makes sense, would be the
> developer's
> responsibility, just as it is for defining a chain of
> Validators.
>
> Right now, the framework describes a lockstep lifecycle. But
> that really
> isn't the framework's job. The framework should provide a
> pre configured
> default lifecycle, but the developer should as much freedom
> as possible
> to define whatever lifecycle works best for a given
> application.
>
> The distribution could ship with a library of Subprocessors
> (just as we
> ship with a library of Validators). To use Tiles, you would
> make the
> appropriate changes to the "process" property to load the
> Tiles
> Subprocessors. If someone wanted to handle a different
> extension point
> differently (or insert a new one), they could add a
> Subprocessor to the
> library (as we can with validators), and amend the "process"
> property.
>
> So there would be no pre-ordained processABC and processXYZ
> methods or
> call sequence. The processor would call each process in turn
> until
> someone cried stop or the sequence was complete. You could
> put as many
> or as few Subprocessors into the sequence as you liked, same
> as we can
> do with Validators.
>
> A radical extension, like Tiles, may also need to subclass
> the main
> "Processor" (aka the "RequestProcessor") that would call the
> individual
> Subprocessors, but hopefully the methods that it overrides
> (like
> internalModuleRelativeForward) won't matter to the other
> Subprocessors.
>
> Or, maybe if Tiles does not have to live within a lockstep
> lifecycle,
> there might be a better way of interpolating the
> "processTiles" step, so
> that it doesn't need override "internal" methods.
>
> So, anyway, the idea is that there would be a Subprocessor
> interface and
> concrete implementations for each of the existing process
> methods (as
> individual classes). The existing RequestProcessor(s) could
> implement a
> Processor interface. The new ProcessManager could also
> implement the
> Processor interface but call individual Subprocessors from
> within the
> process method. (You might be even be able to do a concept
> test with a
> RequestProcessor subclass that called inner classes based on
> the
> existing processes.) Which Subprocessors the ProcessManager
> calls in
> what order would be configurable.
>
> While not as simple as what we have now, it would be more
> extensible,
> and has the virtue of using the same implementation pattern
> as another
> Struts component, the Validator. Which also means that
> ProcessManager
> would not be any more difficult for developers to configure
> and use than
> the Vali

RE: Re: composable RequestProcessor

[Andrew Hill]

Like targets in Ant...

-Original Message-
From: Kent Sølvsten Rasmussen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 4 June 2003 23:19
To: Struts Developers List
Subject: Re: Re: composable RequestProcessor


Just a thought...

Would it be possible to take the anology to Validator one step further?

Instead of a predefined or configurable lifecycle, would it be possible to
let the SubProcessors depend on each other, just like some of the
validations "depend" on each other?

Maybe the configurationfile could contain a number of named subprocessors,
some default, some from Tiles, some from other extensions. This way it might
be possible to declare that processYYY from extension XXX depends on
processZZZ.

This way a chain might be defined, not by defining the chain itself, but by
defining dependencies among it's subprocessors.

Sorry for being unclear, but hopefully You get the idea.

-Kent




Ted Husted <[EMAIL PROTECTED]> wrote:
> I still don't see why processing an "action" request is any
> different
> than processing a "validation" request.
>
> Formed like the validation, the default request chain looks
> like this:
>
> process="processLocale,processContent,processNoCache,process
> Preprocess,processMapping,processRoles,processActionForm,pro
> cessPopulate,processValidate,processForward,processInclude,p
> rocessActionCreate,processActionPerform,processForwardConfig
> "
>
> where each of these have been defined as a Subprocessor
> (e.g. Validator).
>
> As it stands, many of the process methods take different
> signatures and
> return different objects. But that could be changed so that
> they pass
> around a single data transfer object with a place for all
> the usual
> objects (request,response,mapping,form,action,forward).
>
> Whether each component in this sequence is systemically
> compatible or
> whether the order of the processes makes sense, would be the
> developer's
> responsibility, just as it is for defining a chain of
> Validators.
>
> Right now, the framework describes a lockstep lifecycle. But
> that really
> isn't the framework's job. The framework should provide a
> pre configured
> default lifecycle, but the developer should as much freedom
> as possible
> to define whatever lifecycle works best for a given
> application.
>
> The distribution could ship with a library of Subprocessors
> (just as we
> ship with a library of Validators). To use Tiles, you would
> make the
> appropriate changes to the "process" property to load the
> Tiles
> Subprocessors. If someone wanted to handle a different
> extension point
> differently (or insert a new one), they could add a
> Subprocessor to the
> library (as we can with validators), and amend the "process"
> property.
>
> So there would be no pre-ordained processABC and processXYZ
> methods or
> call sequence. The processor would call each process in turn
> until
> someone cried stop or the sequence was complete. You could
> put as many
> or as few Subprocessors into the sequence as you liked, same
> as we can
> do with Validators.
>
> A radical extension, like Tiles, may also need to subclass
> the main
> "Processor" (aka the "RequestProcessor") that would call the
> individual
> Subprocessors, but hopefully the methods that it overrides
> (like
> internalModuleRelativeForward) won't matter to the other
> Subprocessors.
>
> Or, maybe if Tiles does not have to live within a lockstep
> lifecycle,
> there might be a better way of interpolating the
> "processTiles" step, so
> that it doesn't need override "internal" methods.
>
> So, anyway, the idea is that there would be a Subprocessor
> interface and
> concrete implementations for each of the existing process
> methods (as
> individual classes). The existing RequestProcessor(s) could
> implement a
> Processor interface. The new ProcessManager could also
> implement the
> Processor interface but call individual Subprocessors from
> within the
> process method. (You might be even be able to do a concept
> test with a
> RequestProcessor subclass that called inner classes based on
> the
> existing processes.) Which Subprocessors the ProcessManager
> calls in
> what order would be configurable.
>
> While not as simple as what we have now, it would be more
> extensible,
> and has the virtue of using the same implementation pattern
> as another
> Struts component, the Validator. Which also means that
> ProcessManager
> would not be any more difficult for developers to configure
> and use than
> the Validator.
>
> -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]


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

Re: Re: composable RequestProcessor

[Kent Sølvsten Rasmussen]

Just a thought...

Would it be possible to take the anology to Validator one step further?

Instead of a predefined or configurable lifecycle, would it be possible to let the 
SubProcessors depend on each other, just like some of the validations "depend" on each 
other?

Maybe the configurationfile could contain a number of named subprocessors, some 
default, some from Tiles, some from other extensions. This way it might be possible to 
declare that processYYY from extension XXX depends on processZZZ.

This way a chain might be defined, not by defining the chain itself, but by defining 
dependencies among it's subprocessors.

Sorry for being unclear, but hopefully You get the idea.

-Kent




Ted Husted <[EMAIL PROTECTED]> wrote:
> I still don't see why processing an "action" request is any
> different 
> than processing a "validation" request.
> 
> Formed like the validation, the default request chain looks
> like this:
> 
> process="processLocale,processContent,processNoCache,process
> Preprocess,processMapping,processRoles,processActionForm,pro
> cessPopulate,processValidate,processForward,processInclude,p
> rocessActionCreate,processActionPerform,processForwardConfig
> "
> 
> where each of these have been defined as a Subprocessor
> (e.g. Validator).
> 
> As it stands, many of the process methods take different
> signatures and 
> return different objects. But that could be changed so that
> they pass 
> around a single data transfer object with a place for all
> the usual 
> objects (request,response,mapping,form,action,forward).
> 
> Whether each component in this sequence is systemically
> compatible or 
> whether the order of the processes makes sense, would be the
> developer's 
> responsibility, just as it is for defining a chain of
> Validators.
> 
> Right now, the framework describes a lockstep lifecycle. But
> that really 
> isn't the framework's job. The framework should provide a
> pre configured 
> default lifecycle, but the developer should as much freedom
> as possible 
> to define whatever lifecycle works best for a given
> application.
> 
> The distribution could ship with a library of Subprocessors
> (just as we 
> ship with a library of Validators). To use Tiles, you would
> make the 
> appropriate changes to the "process" property to load the
> Tiles 
> Subprocessors. If someone wanted to handle a different
> extension point 
> differently (or insert a new one), they could add a
> Subprocessor to the 
> library (as we can with validators), and amend the "process"
> property.
> 
> So there would be no pre-ordained processABC and processXYZ
> methods or 
> call sequence. The processor would call each process in turn
> until 
> someone cried stop or the sequence was complete. You could
> put as many 
> or as few Subprocessors into the sequence as you liked, same
> as we can 
> do with Validators.
> 
> A radical extension, like Tiles, may also need to subclass
> the main 
> "Processor" (aka the "RequestProcessor") that would call the
> individual 
> Subprocessors, but hopefully the methods that it overrides
> (like 
> internalModuleRelativeForward) won't matter to the other
> Subprocessors.
> 
> Or, maybe if Tiles does not have to live within a lockstep
> lifecycle, 
> there might be a better way of interpolating the
> "processTiles" step, so 
> that it doesn't need override "internal" methods.
> 
> So, anyway, the idea is that there would be a Subprocessor
> interface and 
> concrete implementations for each of the existing process
> methods (as 
> individual classes). The existing RequestProcessor(s) could
> implement a 
> Processor interface. The new ProcessManager could also
> implement the 
> Processor interface but call individual Subprocessors from
> within the 
> process method. (You might be even be able to do a concept
> test with a 
> RequestProcessor subclass that called inner classes based on
> the 
> existing processes.) Which Subprocessors the ProcessManager
> calls in 
> what order would be configurable.
> 
> While not as simple as what we have now, it would be more
> extensible, 
> and has the virtue of using the same implementation pattern
> as another 
> Struts component, the Validator. Which also means that
> ProcessManager 
> would not be any more difficult for developers to configure
> and use than 
> the Validator.
> 
> -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]

Re: composable RequestProcessor

[Matthias Bauer]

Joe, I agree that it makes sense to wrap things up on the wiki page. And 
the status it currently has is a good snapshot of the current situation. 
We will see how this progresses and when it makes sense to change the 
wiki pages again.

I still need to look at the current request processor code with Ted's 
proposal in mind in order to decide whether I want to switch from the 
code to the configuration side again. ;-)

--- Matthias



Joe Germuska wrote:

At 21:14 +0800 6/4/03, Andrew Hill wrote:

Just had a look at the updated wiki.
Is it just me lacking sleep or are the contents for the 
singleInterface page
and the composableRequestprocessor page kindof in the wrong places? 
(ie the
stuff for composable on the single page and vice versa)


I don't think so.  The only thing on the Composable page is a link to 
Ted's message.  The chunk at the head of the SingleInterface page is 
cut from the original single page (and might be more confusing), but 
the diagram below is all about inheriting, not composing.

Matthias, I see your point about the mailing list having your 
attention.  My thought is just that people could copy some of what 
they send to the list into the Wiki page(s) without too much extra 
effort.  Not everything that is in the thread; that defeats the purpose.

Maybe that's too much work.  For me, the Wiki page is an experiment in 
another way of conducting this discussion.  I agree that the 
discussion happens on the mailing list, but if it never gets trapped 
outside of the list archives, it's pretty hard to "see the forest for 
the trees" as they say.

Joe



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

RE: composable RequestProcessor

[Joe Germuska]

At 21:14 +0800 6/4/03, Andrew Hill wrote:
Just had a look at the updated wiki.
Is it just me lacking sleep or are the contents for the singleInterface page
and the composableRequestprocessor page kindof in the wrong places? (ie the
stuff for composable on the single page and vice versa)
I don't think so.  The only thing on the Composable page is a link to 
Ted's message.  The chunk at the head of the SingleInterface page is 
cut from the original single page (and might be more confusing), but 
the diagram below is all about inheriting, not composing.

Matthias, I see your point about the mailing list having your 
attention.  My thought is just that people could copy some of what 
they send to the list into the Wiki page(s) without too much extra 
effort.  Not everything that is in the thread; that defeats the 
purpose.

Maybe that's too much work.  For me, the Wiki page is an experiment 
in another way of conducting this discussion.  I agree that the 
discussion happens on the mailing list, but if it never gets trapped 
outside of the list archives, it's pretty hard to "see the forest for 
the trees" as they say.

Joe

--
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

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