from:"Craig R. McClanahan"

Quoting James Holmes <[EMAIL PROTECTED]>:

> +1 on this!!
> 

Agreed.

> You hit the nail on the head.  Many people (mostly managers) are reluctant
> to adopt Struts add-ons because they are not perceived as having the same
> "tried and true" stamp as the official Struts core.  I think doing this
> would be a huge boon for Struts and would foster a lot of the development
> interest that's been talked about over the past couple of days.
> 
> Also, +1 on having the creators of those projects become committers so long
> as they've shown a protracted history in maintaining their respective
> projects and have an interest to continue doing so.
> 

There's yet another reason that is important -- the ASF board wants to ensure
that everything packaged in an ASF software distribution has either the Apache
License or something less restrictive.  Currently, we're fine because all we
ship is ASF code.  Bringing add-ons under the Struts TLP umbrella means that
they'd automatically be Apache licensed as well.

> -James
> http://www.jamesholmes.com/struts/

Craig


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

Re: Making Struts Build Easier (Re: "coming out" for JSF + Struts, was: Struts JSR?)

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> On Mon, 22 Mar 2004, Ted Husted wrote:
> 
> > On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote:
> > > While it's great to break out things into separate "modules" - I'd
> > > love to be able to get struts.jar w/ everything in it - including
> > > EL and tags.  I can live with all the commons-* JARs (even if it is
> > > annoying), but in general - the less JARs, the better.  It just
> > > simplifies things for the developer.
> > >
> > > I don't care how things are partitioned in CVS, as long as
> > > everything builds with one checkout and one command.
> >
> > If that were someone's itch, it could certainly be done. Ant doesn't know
> about the module partitions, and so someone could write a uber-build that did
> something like this.
> 
> If we have all of the pieces in separate repositories, though, where would
> the files for such an uber-build be checked in? That's one of the problems
> I have with the multi-repository solution - there is no place for files
> that span those repositories. If we have one repository split into pieces,
> then we still have the top level for these things.
> 

On the multi-repository projects I've worked on, we had a special repository
just for integration tasks like this.

> > But, the problem with thinking of Struts as one monothic build is that
> every aspect of the framework has to be perfect, all at the same time, before
> we can call it a "general availability" ready-for-prime-time release.  One of
> the many reasons 1.1 took so long was that if there was any bug in any
> component anywhere in the framework, everything gridlocked.  :(  :(   :(
> 
> That doesn't need to be true if we don't want it to. Recall that for a
> time we had a separtely built, separately distributed component called
> struts-legacy to handle the data source situation. There is no need for a
> one-to-one correlation between repositories and distributable entities.
> 
> > What we want to do ... need to do ... is be able to release fixes to
> components like the taglibs independently of the core controller. Likewise,
> we need to release changes to Struts EL or Struts Faces (once it goes 1.0)
> without having to be sure every other component is ready to roll. We should
> also be able to release updates to the example applications without
> re-releasing the rest of the framework, if that's all we want to roll right
> now.
> 
> Absolutely. And the number of repositories we have is entirely orthogonal
> to this.
> 

Ultimately true, although it's still somewhat easier to visualize if you have
separate repositories.

> > Some people may not like more JARs, but I know for certain that the single
> JAR approach is a momentum killer. It's made my life much more difficult, and
> I think it's chased away some Committers who became frustrated by having to
> "everything right" in order to one little feature into a formal release.
> 
> For the people who want / need a single jar, it would be simple enough for
> us to provide an Ant target that explodes the desired individual jars and
> recombines them into a single jar. The only tricky part, I think, would be
> creating a manifest that identifies the versions of the individual pieces
> in that jar. That's assuming people want such a beast, of course. (I'm not
> in that camp myself, though, just as I'd never use the Commons Combo
> build.)
> 
> > If we can get more code into the hands of more developers in less time,
> then a few more JARs seems like a small price to pay. :)
> 
> +1
> 

Yep.

> > Here's something else to mull over:
> >
> > Now that Struts is a TLP, we might want to talk about whether we want to
> ask the most popular open source Struts extensions -- like Struts Menu,
> Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their
> code to the ASF and live as Struts "opt" subprojects. This would be a
> continuation of what we started with Tiles, Validator, and Nested, which are
> all favorites with our community. People working on such packages might be
> brought on as Struts Committers, since they have proved they have what it
> takes to run a project, and after an appropriate period, later invited to
> join the Struts PMC.
> >
> > IMHO, when people talk about JSF replacing Struts, they are unaware of the
> true breadth of the Struts platform. Perhaps it's time we made sure people
> know how much they are missing :)
> >
> > A sad truth: In working with various teams managing larger projects, I've
> found a surprising reluctance to use extensions that were not distributed by
> the Struts project itself. By giving these very fine extensions "the nod", we
> can make them available to a greater number of Struts teams, to everyone's
> benefit. If we don't help make these extensions available to everyone, then
> we end up "hiding our light under a bushel".
> >
> > Now, I haven't brought this idea up to any of the other Committers, and
> have no idea how any else will feel about it. But

Re: Making Struts Build Easier (Re: "coming out" for JSF + Struts, was: Struts JSR?)

Quoting David Graham <[EMAIL PROTECTED]>:

> Personally, I find the Struts build files to be complex and confusing. 
> I've come to associate Maven with easy builds because building commons
> components (including the distro, website, tests, etc) is a snap compared
> to Struts.  I agree that storing jars in cvs isn't a good idea which is
> why using Maven is so nice; it downloads the correct jars automatically.  
> 

It's also possible to set up Maven with a local repository so that offline
builds still work, too.

> Anything we can do to make the build more straightforward, whether it's
> with Ant or Maven, is a good thing :-).
> 

Yep ... that's why we need to finish the "how many repositories" discussion so
we can start migrating towards something that is simpler.

> David

Craig

> 
> --- Joe Germuska <[EMAIL PROTECTED]> wrote:
> > >For me, the main discouraging thing about contributing to the 
> > >development of Struts has been the build process.  In the past, you 
> > >had to download all of jakarta-commons and spend a day or two 
> > >figuring out how to get that to build.  Recently, I tried to build 
> > >Struts and was successful using the Maven stuff.  Personally, I 
> > >don't mind using Maven, but I don't know that it should be 
> > >*required* to build a project from scratch.  I'd love to be able to 
> > >cvs co Struts, navigate to jakarta-struts and type "ant jar".
> > >
> > >I realize this is no easy thing to accomplish with a build file - 
> > >but it has been the most discouraging factor for me. ;-)
> > 
> > The only way we could accomplish something like that with a build 
> > file would be by including JARs in CVS, and if you ask me, there are 
> > enough reasons why that's a bad idea that I prefer the way it is, 
> > even though I'd very much like to see people feel more comfortable 
> > getting in and working on Struts source code.
> > 
> > When you say "I don't know that [Maven] should be *required*..." is 
> > your point that Ant is a widely accepted Java tool, while Maven has 
> > yet to cut a 1.0 release?  That's fair -- just want to make sure I 
> > understand you.
> > 
> > The build.xml file generated by 'maven ant' uses the ant 'get' task 
> > and the Maven iBiblio repository to download dependencies; we could 
> > perhaps look at copying some of that into our ant script to reduce 
> > build.properties to being more about configuration stuff and less 
> > about dependency stuff.
> > 
> > Joe
> > 
> > -- 
> > Joe Germuska
> > [EMAIL PROTECTED]  
> > http://blog.germuska.com
> >"Imagine if every Thursday your shoes exploded if you tied them 
> > the usual way.  This happens to us all the time with computers, and 
> > nobody thinks of complaining."
> >  -- Jef Raskin
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> __
> Do you Yahoo!?
> Yahoo! Finance Tax Center - File online. File on time.
> http://taxes.yahoo.com/filing.html
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




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

Re: Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> At 5:24 PM -0800 3/21/04, Craig R. McClanahan wrote:
> >I think the presentation-tier-independent things about Tiles (like mapping
> >forwards to definitions) should be built in to the core, so there isn't any
> >such thing as a separate TilesRequestProcessor (or a separate chain or
> >whatever).  In turn, this probably means we might need an API abstraction
> that
> >alternative presentation tier technologies can use to integrate 
> >themselves into
> >the underlying support.
> 
> I managed to make Tiles work with struts-chain with a single 
> pre-processor Command.  It basically looks up a tiles definition and 
> replaces the ForwardConfig returned from an action with its own that 
> has a path which RequestDispatcher to which can forward.
> 
> But it still uses the TilesPlugIn...  is that part of what you think 
> should be moved up into the core?  Or do you think even the single 
> Command is not the best future implementation?

I'll express my goals for this from a couple of perspectives:

>From the user's perspective, the fact that I'm using Tiles (or not) should not
require anything extra in the config (other than adding the definitions of the
tiles themselves, of course).  This probably implies that the configuration
data migrates into struts-config.xml as well.

>From the Struts developer perspective, I don't want to have to maintain two
request processors (or really even two command chains) -- the standard chain
should handle requests whether or not you reference a Tile.  So, if your
command that looks up the Tiles definition works on non-Tiles requests as well,
we can just build it in to the standard chain and call it good.


> Joe

Craig


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

Re: "coming out" for JSF + Struts, was: Struts JSR?

Quoting Thomas L Roche <[EMAIL PROTECTED]>:

> Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM)
> >> summary: McClanahan should clearly state *in some major publication*
> 
> >> * that JSF does/will not "replace Struts"
> 
> >> * how JSF and Struts will likely tend to specialize, in future
> 
> >> * how probable specializations will complement (and compete) in
> >>   webapp development
> 
> Ted Husted Sun, 21 Mar 2004 20:28:17 -0500
> > But I think either of us would rather be developing Struts than
> > evangelizing Struts.
> 
> This is not about "evangelizing": it's about clarifying the
> relationship between 2 large parts of J2EE's future, and correcting
> some (apparently) false perceptions. Frankly, I'm perplexed why the
> propagation of the latter has gone unchecked for so long.
> 

That's actually easy to understand.  People believe what they want to believe,
no matter what I or anyone else says.  I've said exactly the same thing about
the relationship between Struts and JavaServer Faces for the last 18 months,
and it's going to work out pretty much exactly as I've been saying all along. 
That doesn't mean anyone is listening, however.

My personal plan is to speak more with code than with words, and ensure that
Struts continues to include useful functionality that is not present in the
J2EE platform and its associated standards.  That way, the choice of whether or
not to use Struts will be based on benefits you gain from using it, just like
it always has been, and just like it was P.J. (pre-JavaServer Faces :-).

Craig


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

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

2004-03-21 Thread Craig R. McClanahan

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> On Sun, 21 Mar 2004, Martin Cooper wrote:
> 
> > On Sun, 21 Mar 2004, Ted Husted wrote:
> >
> > > On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote:
> > > > Option 1 works for me. Simplest thing that could possibly work. As
> > > > you've said, we can always change things around later.
> > >
> > > The problem is that is that we already have the simplest thing. And, if
> we want multiple Maven-based products with independent release cycles, then
> what we have won't work. :)
> >
> > We already have the simplest thing in terms of one repo, but we have far
> > from the simplest thing when it comes to organising within that repo. The
> > point I was trying to make with (1) is to distinguish between organising
> > using multiple repos versus organising within one repo.
> >
> > For example, if we do what you suggest below, and have 7 separate CVS
> > repos, we will face a number of problems, as I see it:
> >
> > a) We will not make friends with the infrastructure folks. Each time we
> > add a new committer, they will have to add 7 separate avail entries with
> > that account.
> >
> > b) People will need to do 7 separate 'cvs update' invocations to get all
> > of the latest code. That just doesn't seem practical to me.
> >
> > c) It's not clear to me that the Maven reactor could be made to work
> > across multiple repos. And even if it could, which repo would the Maven
> > files live in?
> >
> > d) Any multi-repo build would have to make assumptions about the location
> > of the other repos on the local disk. It would be reasonable to assume
> > that they are peers within the same directory, but that is an assumption
> > that we would have to make.
> >
> > e) Web site maintenance is going to be, um, challenging. We would actually
> > need an 8th repo for site-wide documentation, and then we'd need to have
> > some tools to avoid having to do 8 separate 'cvs update' invocations to
> > update the entire site on www.
> >
> > f) Any time we want to add something new (e.g. opt-foo or core2), we would
> > need to go back to infrastructure and ask for yet another repo.
> >
> > I see little advantage of all those separate repos over just one repo,
> > since that one repo could be organised in exactly the same way. In other
> > words, why use separate repos over something like this:
> >
> >   struts/
> > core/
> > taglib/
> > app/
> > opt-legacy/
> > opt-el/
> > opt-faces/
> > opt-sandbox/
> > site/
> >
> > or even this:
> >
> >   struts/
> > core/
> > taglib/
> > app/
> > opt/
> >   legacy/
> >   el/
> >   faces/
> >   sandbox/
> > site/
> 
> Another thought on this. When we get to Struts 2, I'd like to see us
> remove all of the JSP-ness of Struts from the core, and also add some
> degree of support for other presentation technologies, such as XSLT and
> Velocity. So, instead of having 'taglib' where it is in the above tree, we
> might want to do something like:
> 
>   struts/
> ...
> presentation/ (or whatever name we want)
>   jsp/
> taglib/
>   {others when we get to them}/
> ...
> 

I think Ted's been advocating a similar philosophy, although any support for JSF
is going to be an interesting one in this kind of hierarchy, because you can
use JSF via JSP or through other presentation technologies as well.

> Incidentally, where would Tiles land in all of this? In theory, it's not
> tied to JSP, but rather to Servlets, so it might be applicable to some
> other presentation technologies, but clearly not all.
> 

I think the presentation-tier-independent things about Tiles (like mapping
forwards to definitions) should be built in to the core, so there isn't any
such thing as a separate TilesRequestProcessor (or a separate chain or
whatever).  In turn, this probably means we might need an API abstraction that
alternative presentation tier technologies can use to integrate themselves into
the underlying support.

> --
> Martin Cooper

Craig


> 
> 
> >
> > Actually, I'm not sure that a sandbox should be under 'opt' at all. I
> > could see us using a separate repo for that, since there is precedent in
> > both Commons and Taglibs.
> >
> > I am now leaning towards 3 repos myself:
> >
> >   struts-legacy
> > This is our current repo, renamed. I don't really care for this
> > name, but I can't think of anything better right now, and I hate
> > sticking numbers in repo names, because they become invalid
> > quite rapidly if they are associated with versions (unless we
> > start a new repo for each major version, a la Tomcat, but I
> > don't like that idea either, for CVS history reasons).
> >   struts
> > This would be structured per one of the suggestions above.
> >   struts-sandbox
> > A separate sandbox, a la Commons and Taglibs.
> >
> > The reason I've changed my mind since yesterday about 2 repos versus 1
> > (ignoring the sandbox for the moment

RE: branching 1.2 and 1.3 and CVS reorg for TLP status

2004-03-21 Thread Craig R. McClanahan

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> On Sun, 21 Mar 2004, Ted Husted wrote:
> 
> > On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote:
> > > Option 1 works for me. Simplest thing that could possibly work. As
> > > you've said, we can always change things around later.
> >
> > The problem is that is that we already have the simplest thing. And, if we
> want multiple Maven-based products with independent release cycles, then what
> we have won't work. :)
> 
> We already have the simplest thing in terms of one repo, but we have far
> from the simplest thing when it comes to organising within that repo. The
> point I was trying to make with (1) is to distinguish between organising
> using multiple repos versus organising within one repo.
> 
> For example, if we do what you suggest below, and have 7 separate CVS
> repos, we will face a number of problems, as I see it:
> 
> a) We will not make friends with the infrastructure folks. Each time we
> add a new committer, they will have to add 7 separate avail entries with
> that account.
> 

That turns out not to be the case, for at least two reasons:

* A single "avail" line can be attached to multiple repositories
  (as is already true, for example, for Tomcat's multiple repos).

* Infrastructure needn't be bothered with CVS karma issues anyway ...
  lots of folks (including me) can do that edit directly.

> b) People will need to do 7 separate 'cvs update' invocations to get all
> of the latest code. That just doesn't seem practical to me.
> 

At work our CVS admins have set up aliases so you can do a single "cvs co" or
"cvs update" on an alias and get them all at once.  Don't know how that works
with IDEs that interact, but it certainly works sweetly from the command line.

> c) It's not clear to me that the Maven reactor could be made to work
> across multiple repos. And even if it could, which repo would the Maven
> files live in?
> 

I plead clueless on the Maven-related aspects of this, but have seen that the
Geronimo folks seem to have a pretty good multi-subproject setup going (albeit
from a single repository).

> d) Any multi-repo build would have to make assumptions about the location
> of the other repos on the local disk. It would be reasonable to assume
> that they are peers within the same directory, but that is an assumption
> that we would have to make.
> 
> e) Web site maintenance is going to be, um, challenging. We would actually
> need an 8th repo for site-wide documentation, and then we'd need to have
> some tools to avoid having to do 8 separate 'cvs update' invocations to
> update the entire site on www.
> 

I think we should rip the website stuff out of the webapps anyway.

> f) Any time we want to add something new (e.g. opt-foo or core2), we would
> need to go back to infrastructure and ask for yet another repo.
> 

Nope ... just an additional name on the "avail" list, something that I (or
anyone else with cvsadmin karma) can do.

> I see little advantage of all those separate repos over just one repo,
> since that one repo could be organised in exactly the same way. In other
> words, why use separate repos over something like this:
> 
>   struts/
> core/
> taglib/
> app/
> opt-legacy/
> opt-el/
> opt-faces/
> opt-sandbox/
> site/
> 
> or even this:
> 
>   struts/
> core/
> taglib/
> app/
> opt/
>   legacy/
>   el/
>   faces/
>   sandbox/
> site/
> 
> Actually, I'm not sure that a sandbox should be under 'opt' at all. I
> could see us using a separate repo for that, since there is precedent in
> both Commons and Taglibs.
> 
> I am now leaning towards 3 repos myself:
> 
>   struts-legacy
> This is our current repo, renamed. I don't really care for this
> name, but I can't think of anything better right now, and I hate
> sticking numbers in repo names, because they become invalid
> quite rapidly if they are associated with versions (unless we
> start a new repo for each major version, a la Tomcat, but I
> don't like that idea either, for CVS history reasons).
>   struts
> This would be structured per one of the suggestions above.
>   struts-sandbox
> A separate sandbox, a la Commons and Taglibs.
> 
> The reason I've changed my mind since yesterday about 2 repos versus 1
> (ignoring the sandbox for the moment) is that I realised that all of the
> CVS shuffling we want to do will make it very hard, if not impossible, to
> continue to work on older (pre-shuffle) versions of the product.
> 
> One other minor comment: I'd prefer to use something like 'archive' over
> 'legacy', since the latter has a more negative connotation, in my mind at
> least. But I won't make a big deal of it if other people prefer 'legacy'.
> ;-)
> 

I'd be happy with either the seven approach or the three approach.  As you've
concluded, I don't see how we can gracefully refactor and continue to work on
the old code with only one.  Maybe "struts-original" has b

RE: Struts JSR?

Quoting Steve Raeburn <[EMAIL PROTECTED]>:

> Like most people, I imagine, I still haven't had time to do more than
> give JSF a cursory glance. It's clear that there is some overlap between
> JSF and Struts. However, that does not mean that one or other will
> simply disappear.
> 
> Craig has previously stated that there is still a role for Struts to
> play. He has demonstrated by developing a means to integrate the two and
> making it available in the Struts distribution. See Struts-Faces in the
> Struts contrib directory.
> 
> As the creator of Struts and spec lead for JSF, I think Craig is in a
> unique position to understand where all this is going. I take the fact
> that he has accepted the role of Chair of the newly formed Apache Struts
> PMC as a sign that he believes Struts has a strong future and that he's
> willing to help its continuing evolution and growth.
> 

Yep.

> Let me be very clear that I'm not trying to speak for Craig here. I'm
> just relaying how *I* view things right now. As I don't yet have any
> meaningful personal experience with JSF, I have to gauge things based on
> what others are saying and doing. I would rather base *my* actions and
> effort on Craig's direction than on the fears of others who also have no
> meaningful experience of JSF (or Struts).
> 
> Bottom line is, Struts will evolve to fill any need not met by the
> standards. Which is pretty much how the whole thing got started.
> 

My personal vision is that Struts developers will focus their energy on the
controller and model tiers, leveraging the existence of standard (and not)
technologies in the view tier.  The Struts HTML tags have had their three years
of fame :-) -- it's time to get on with life and develop innovative solutions
where there are still holes in the big picture.  But that's up to each of us
individually, of course.

There is going to be tremendous support for JSF in the industry; fortunately, we
can continue to maintain and enhance Struts without having to give that up
(thanks to the integration library).  Instead, we can embrace it (just like we
did with JSTL, and are talking about doing with Servlet 2.4 and JSP 2.0).

> Steve
> 

Craig


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

Re: [PROPOSAL] Struts infrastructure changes

Miscellaneous comments intermixed.

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> The following is a set of proposed changes to the Apache infrastructure to
> accommodate the Struts move to an Apache top level project. The idea is to
> come up with a single agreed-upon set of changes that we can submit to the
> infrastructure folks as a single request, rather than submitting each one
> piecemeal. Your feedback is appreciated.
> 
> Mailing Lists
>   New mail domain: struts.apache.org
>   The following lists are standard for an Apache TLP:
> user@
> dev@
> cvs@ (usually forwarded to dev@)

I would like to maintain our current practice that these are *always* forwarded
to dev, instead of it being a separate mailing list.

> pmc@

As noted in other messages in this thread, we need an announcements list too.
>   Moderator: Ted Husted (same as today)
>   Existing subscribers need to be migrated.
>   Old list addresses should be forwarded for some period of time.
> 
> Web Site
>   New virtual host: struts.apache.org
>   Redirect from jakarta.apache.org/struts for some period of time.
>   Writeable by group: struts (see below)
> 
> Wiki
>   New wiki: wiki.apache.org/struts
>   Migrate pages from: StrutsProjectPages on old wiki (nagoya)
> 

This would be on the Apache infrastructure, right?

> Unix Group
>   New group: struts
>   Members: (Struts PMC members)

It would ultimately need to include all of the committers (not just PMC
members), in order for CVS commits to actually work.

> 
> Source Control
>   Old CVS repo: jakarta-struts
>   New CVS repo: struts

This can certainly be a starting point.  We should consider whether it's worth
separating subprojects into their own repositories for ease of management
purposes (but I agree with your other comments that commit karma would still be
to all subprojects, no matter how this decision comes out).

>   Optional: Move to Subversion (IMO, not now, but we can discuss.)
> 

Given the amount of work this would involve, and assuming we can import our CVS
log history somehow, this would be OK with me; but seems like something we
could also defer to later after the dust settles.

> Bug Database
>   Optional: Move to Jira (IMO, now's as good a time as any.)

I'm OK with either Jira or Bugzilla.  Note that other projects migrating to Jira
have been able to import their bug history, so we wouldn't lose that.

> One other thing is that we'll want to get external mail archivers to
> switch to the new mailing lists once those are set up. I'm not clear on
> whether the infrastructure folks arrange that or we need to do it
> ourselves, but I'll ask when I submit the above.
> 
> Anything else I missed? (There are a lot of internal changes we'll want to
> make as well, but I'm not trying to address those here.)
> 
> --
> Martin Cooper
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


Craig


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

Re: OT: Struts JSR?

Quoting Thomas L Roche <[EMAIL PROTECTED]>:

> David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of 
> his remarks include
> 
> - Is JSF a replacement for Struts? Yes!
> 
> - JSF is a standard. Struts will never be a standard.
> 
> which I believe to be pretty-nearly-direct quotes. I'm assuming he
> really meant
> 
> + JSF 1.0 can do pretty much everything Struts 1.1 can.
> 

There is definitely substantial overlap, especially in the HTML tags area, as
well as things like outcome-based navigation handling and creating form beans.
The design of JavaServer Faces benefited tremendously from the experience we've
had with Struts, and the design in these areas exceeds the current
functionality of Struts in many respects.

Two particular features of Struts that are not present in JavaServer Faces 1.0
-- Tiles for layout management, and the Validator Framework for creating client
side JavaScript to enforce the rules (in addition to enforcing them at the
server).  Fortunately, however, you can use these Struts features in
conjunction with JavaServer Faces by using the Struts-Faces integration
library.

There is a huge amount of momentum around Struts, and it's not going to go away
any time soon.  That being said, however, it's time for Struts to start doing
some more innovation instead of incremental improvements, in order to remain as
popular for new development.

> + JSF is a JSR, and Struts will never be a JSR.
> 
> but I'm wondering about that last statement. What prevents Struts
> from undergoing the JCP? Are there circumstances under which you
> might consider this?
> 

For those not familiar with it, some brief background on the JCP would be
useful
here.  More details are at the JCP web site .

Anyone who is a JCP member can propose a JSR.  To be accepted, it would to be 
accepted by the 16 members of the Executive Committee for the J2SE/J2EE
platform (note that Sun has one of these 16 votes -- people who believe that
Sun could "veto" a JSR proposal for something like this, even if Sun wanted to,
are misinformed; that veto ability only applies to language changes or "uber"
JSRs like the ones for the entire J2SE and J2EE platforms).  The person(s) or
organization(s) proposing the JSR would need to plan on (if it's accepted)
providing a specification documenting the Java API or technology to be
standardized, a Technology Compatibility Kit (TCK) against which other
company's implementations of the technology can be tested, and a Reference
Implementation (RI) -- which must pass the TCK -- proving that the technology
can actually be implemented.

If by the "you" in your question you are referring to the Struts committers, we
could indeed propose such a JSR (Apache is a JCP member, and is currently also
a voting member of the Executive Committee).  But it wouldn't really be a JSR
to "standardize Struts" ... at most it could be a JSR to "standardize the APIs
supported by Struts."  After all, the JCP is really a standards organization
that creates specifications to be implemented by others.  Struts (and many
other open source projects) are often not implementations of some standard --
they can be seen as sort of a combination of spec and implementation rolled
into one.  If the long term goal is that everyone continues to use the "one and
only" implementation, then the JCP is not really the right development approach.
 

Beyond that, the Executive Committee members will tend to not desire multiple
JSRs with large amounts of functional overlap -- which would definitely be the
case if someone tried to propose the Struts APIs.  After all, these are
companies that would need to fund the development of their own versions of the
hypothetical "standard Struts", and the cost of integrating it into their own
products.  It is much more cost effective (as well as less confusing and costly
for users) to support a single standard in each technology area, and add
functionality in future versions as it makes sense to standardize.

As such, it seems much more likely that the Executive Committee would accept a
JSR for some future version of JavaServer Faces that built on top of of the 1.0
version than a JSR for a different way to solve many of the same problems.  The
planning for the next steps in this direction, in fact, is already in
progress.

We as Struts developers, then, should focus on adding additional functionality
to our "platform", to maintain and enhance its usefulness.  Not being
constrained by a standards process, we can proceed at a pace solely limited by
our capabilities to imagine the new things and then implement and test them.

Craig McClanahan


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

Re: branching 1.2 and 1.3 and CVS reorg for TLP status

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> At 2:48 PM -0500 3/14/04, Ted Husted wrote:
> >I'd say we could branch what we have as 1.2 and start thinking of 
> >the HEAD as 1.3.
> >
> >IMHO, the quickest way to sort out what we need to do with the 
> >Struts-Chain RequestProcessor is to get it out there as the nightly 
> >build. [Many hands make light work ;)]
> >
> >So, we could reserve the 1.2 for any desperate fixes (as we've done 
> >before), but do anything resembling new development against the HEAD 
> >(1.3).
> 
> I might do something like this over the weekend, depending on my time 
> (then again, I may not at all!)
> 
> But if I did, I'd want to see if anyone had any strong feelings, or 
> fixes they thought they'd like to get in before a branch, or... ?
> 
> Or should all of this wait until we get the move to struts.apache.org 
> settled?  I'm assuming we'll reorganize CVS as part of that, into 
> struts-core, struts-taglib, etc...

I think there's a lot of merit in rationalizing the directory structures as part
of the move to TLP-ness.

>  Speaking of that, can we/should 
> we do anything to preserve CVS logs if we move files?  Or will we 
> start fresh?   I think if we move the actual CVS files it will all be 
> preserved, but I've never tried that.
> 

There are ways to preserve history, but I suspect there will be difficulties if
we decide to split up what has been a single repository (jakarta-struts) into
per-subpackage repositories.  A guru on CVS would definitely be useful here.

> I'm interested in getting the Struts Chain stuff mainstreamed, but 
> like I said, this may very well not be the weekend I start on it.  In 
> any case, I figured a branch would be cause for a little bit of 
> discussion amongst committers.
> 

I'm going to focus some energy as well on commons-chain and struts-chain now
that JavaServer Faces is done.

> Joe

Craig


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

Re: Splitting struts-config into multiple jar and read them as resource stream

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> >We'd like not to subclass ActionServlet, but is really difficult to 
> >do something like this outside the ActionServlet hierarchy mainly 
> >'cause of the call to "initConfigDigester()", that's obviously 
> >protected.
> >
> >The questions are:
> >
> >- is there a way to do the same without subclassing ActionServlet?
> >- do you think is it reasonable to include a similar feature in the 
> >main source tree on CVS (dynamic read pieces of struts-config from 
> >jar files)?
> 
> It seems plausible that a factory class could be factored out of the 
> ActionServlet. I'd think you could do this in Struts 1 in a backwards 
> compatible fashion.  I think people would like to be able to 
> configure struts from a variety of sources; another popular request 
> is for dynamic reconfiguration -- without a redeploy -- but that's a 
> different and more complicated question.
> 

Along the same lines, one of the things we did in JavaServer Faces (with regards
to configuration) is to have the controller servlet automatically recognize
"META-INF/faces-config.xml" resources in any JAR files that were included in
the application.  This makes it very easy to package a module, or some other
sub-unit of an overall webapp, as a single JAR file that self-configures.

> Joe

Craig


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

Re: Struts Jericho DTD

Quoting Greg Reddin <[EMAIL PROTECTED]>:

> Ted Husted wrote:
> > On Fri, 12 Mar 2004 10:30:08 -0600, Hookom, Jacob wrote:
> > What I would like to do is develop Struts 2.0 test-first. The idea being we
> cold start with a simple application and write just enough of 2.0 to develop
> the first page (or story). Then just enough to develop the second page, and
> so forth. Each component developed would have to be fully testable outside of
> a servlet/portlet/soap environment. 
> 
> I like this idea and would love to help.  I'm not highly experienced in 
> test-first design and think this would be a great way to get acclimated. 
>   Plus, I'm very interested in the Struts 2.0 approach.
> 

+1 on test-first.  We used that approach to build the JavaServer Faces RI, and
were basically able to keep up with a fairly rapid-fire set of changes as the
expert group evolved the design, while catching regressions before they turned
in to bugs.

I also need to catch back up on the recent design thinking for Struts futures
:-).

> Greg
>

Craig


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

RE: Struts Logo

2004-03-08 Thread Craig R. McClanahan

Quoting Steve Raeburn <[EMAIL PROTECTED]>:

> The intention is that anyone will be able to submit a logo.
> 
> But first, the committers will have to decide whether they want a new
> logo. ** There is no competition yet! **
> 

For the record, I'm +1 on having a new logo (well, maybe it's really "havig a
logo" :-), +1 on doing it with this kind of a contest, and +1 on the timing of
doing it now.

It seems to me we want to end up with two different sized logos ... one that
would go in the upper right corner (or wherever) of our own website, and a
smaller "powered by" that would hopefully be posted on applications that used
Struts.  We can go spelunk what other projects have done (Geronimo did this not
long ago) for technical details like image sizes.

Craig


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

Re: DO NOT REPLY [Bug 17667] - Client-side validation with multi-form page

2004-03-08 Thread Craig R. McClanahan

> This is fixed in the Nightly build of Validator as of March 9th.
> It may take a few days for the nightly build of Struts to
> start using this version, and so it's client side validation
> will be broken until that point.

I'm picking up the most recent changes for tonight's nightly build.

Obviously, this is not a situation we really want, even for a nightly build.  I
hope we'll see an updated validator dot-dot release soon to pick up the fix.

Craig


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

Updated Struts-Faces Integration Library

2004-03-08 Thread Craig R. McClanahan

I'm happy to announce the availability of the first nightly build of the
integration library supporting the use of JavaServer Faces and Struts that has
been updated to support the final release of JavaServer Faces 1.0.  This is not
a formal Apache release; however, it is intended to support experimentation and
trigger bug reports so that we can complete a release in the next couple of
months.  Pick up the files dated 20040308 (or later) from:

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

Key new features (see the README.txt file for full details):

* Supports the final release of JavaServer Faces 1.0 (previous
  versions supported the beta version).

* Fully worked out examples with and without Tiles.

* You can use value binding expressions ("#{...}") for all attributes
  of the Struts specific components, just like you can with all attributes
  of standard JavaServer Faces components.

* A managed bean named "struts" is available to provide access to
  Struts-internal objects, similar in spirit to the 
  tag in the existing libraries.

* The integration library supports either prefix mapping (/faces/*)
  or extension mapping (*.faces) for the JavaServer Faces servlet.

* You can use the new  tag to expose a Struts
  MessageResources object as a Map, so that messages can be looked
  up using value binding expressions, similar to the way that the
  standard  tag works with resource bundles.  This allows
  you to use your existing Struts application resources seamlessly with
  non-Struts component tags.

Craig McClanahan


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

Re: ASL 2.0

2004-03-07 Thread Craig R. McClanahan

Quoting "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:

> An alternative is to directly run the python scripts,
> it's probably easier than applying the patch.
> I could do that.
> 

In the committers module (relicense directory) there is also a Java version of
the relicensing tool that works quite well.  I used it with great success
converting some of the commons packages.

Also, be aware that I just committed a pretty massive update to the
contrib/struts-faces subdirectory, so any previous patch against those files
will likely fail on mismatches.

Craig

> 
> > -Original Message-
> > From: David Graham [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, March 7, 2004 10:08 PM
> > To: 'Struts Developers List'
> > Subject: Re: ASL 2.0
> > 
> > I attempted to apply the patches but Eclipse wouldn't cooperate.  I don't
> > have any other cvs tools on my windows box, which is the only one with
> > Struts development setup at the moment.
> > 
> > David
> > 
> > --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > > Would anyone have a chance to apply Paul's patch this afternoon?
> > > 
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=27137
> > > 
> > > I'm out of town and this might be a bear for me to commit over a 28.8
> > > modem connection :)
> > > 
> > > Otherwise, I'll try to do it later tonight.
> > > 
> > > -Ted.
> > > 
> > > 
> > > 
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > 
> > 
> > 
> > __
> > Do you Yahoo!?
> > Yahoo! Search - Find what you?re looking for faster
> > http://search.yahoo.com
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




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

Re: [VOTE] Struts as an Apache Top Level Project

2004-03-06 Thread Craig R. McClanahan

+1 on the TLP proposal.

+0 on me as VP (I'm willing, but don't consider this a prerequisite to
TLP-ness), although I should point out that this is actually only a
*recommendation* to the ASF Board.  The Board is free to appoint whomever they
wish, although they've historically tended to go along with the community's
recommendations in this regard.

Craig

(And +1 on adding Joe to the list -- sorry about that!)

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> Following up on a brief thread on this list in December [1], Craig, Ted
> and I have put together a draft resolution to the board of directors [2],
> along with a cover letter [3], that would promote Struts to an Apache
> top-level project (TLP).
> 
> The main reasons for moving to a TLP are described on the wiki [4]. In
> Craig's words, "The short answer, though, is we will be in charge of our
> own releases (currently, the Jakarta PMC is the only body legally
> recognized to vote on releases of *any* software under Jakarta)." In
> practice, we can really just continue doing what we've always done.
> 
> As most of you are no doubt aware, several Jakarta sub-projects have
> already made the transition to TLPs, including Ant, Avalon, Gump, James,
> Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in
> favour of the migrations, largely because a single PMC cannot possibly
> oversee a code base the size of all of Jakarta.
> 
> If you're OK with Struts being a top-level Apache project, please respond
> to this thread with either a +1 or +0. Otherwise, please reply with your
> concerns. When we previously discussed this, it did not seem like anyone
> was opposed to the idea, but if anyone is, now is the time to speak up.
> 
> The resolution as drafted lists the Struts Committers who could
> reasonably be considered active at this time. Of course, we should not
> put anyone on the PMC without their buy-in, so the final resolution would
> only list the Committers who responded to the Vote with a +1 or +0.
> 
> The draft resolution also leaves the name of the Vice President blank.
> Craig seems like the logical candidate, and is willing to act in this
> capacity, but we wanted the VP selection to be a community decision. So,
> please also respond with your nomination for Vice President, Apache
> Struts.
> 
> Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice
> President.
> 
> --
> Martin Cooper
> 
> [1]
>
http://nagoya.apache.org/eyebrowse/SearchList?listId=&[EMAIL 
PROTECTED]&searchText=%22Why+you+*want*+to+be+on+the+PMC%22&defaultField=subject&Search=Search
> [2] http://www.apache.org/~martinc/struts/tlp/resolution.html
> [3] http://www.apache.org/~martinc/struts/tlp/cover.html
> [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges
> 
> -
> 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: automatically handle invalid input format

2004-02-27 Thread Craig R. McClanahan

Quoting enzhong fu <[EMAIL PROTECTED]>:

> Currently, Struts recommends all fields of ActionForm be of type String. If
> you use other type (such as Date), and user inputs the value in an invalid
> format so the value could not convert to the suitable type, BeanUtils would
> throw an exception and it would propagate back to the user. Use only String
> type for ActionForm fields can display to the user the original values they
> input, but in your Action class code is needed to transform from String type
> to type used in business objects.
> 

As the original designer of Struts :-), I must point out that the design of
ActionForm (and the recommendation that form bean properties be Strings) is
***very*** deliberate.  The reason this is needed is obvious when you consider
the following use case:

* You have an input form that, say, accepts only integers.

* Your form bean property is of type "int".

* The user types "1b3" instead of "123", by accident.

* Based on experience with any garden variety GUI application,
  the user will expect that they receive an error message,
  plus a redisplay of the form ***WITH THE INCORRECT VALUES
  THAT WERE ENTERED DISPLAYED SO THE USER CAN CORRECT THEM***.

* The current Struts environment will throw an exception
  due to the conversion failure.

* The suggested solution will ***hopelessly*** confuse the
  nature of a form bean, which is part of the VIEW tier, with
  model beans that have native data types.

Struts does not include any sort of "user interface component model" where the
details of conversion are hidden inside the user interface component.  If that
is what you are after, you should look at a *real* user interface component
model (such as using JavaServer Faces with a Struts application).  Corrupting
the functionality of a form bean to *pretend* that it is a user interface
component is only going to create complications for the world.

In case it is not clear, the recommended approach here is very much antithetical
to the fundamental nature of Struts, so I will oppose it.



> Not all people like this. Today one more developer posted it as a bug.
> Ideally, we hope to use more types in a form bean while still able to display
> the original inputs to the user when a validation error occurs. I think the
> following solution can achieve it,
> 
> 0. Basic validation, "Valid Format" and "Required", should be handled during
> populating form bean.
> 
> 1. In RequestProcessor class, processPopulate() should mimic
> processValidate(). It returns a boolean to indicate whether processPopulate
> is successful or not. If not successful, it should forward to the input page
> like processValidate does.
> 
> 2. Instead of throwing exception, BeanUtils class should catch the exception
> for populating error and continue. It returns a list of the fields that have
> problem (normally invalid format). Error messages constructed based on these
> fields will be stored in Globals.ERROR_KEY.
> 
> 3. When there is populating error, a HashMap is created to hold the original
> request parameters (all Strings, nested fields can have nested HashMaps). The
> HashMap is stored at a global key (Globals.xxx) in the request.
> 
> 4. The html:form tag will get the stored HashMap and put it to
> Constants.BEAN_KEY for field tags to use (when there is populating error).
> 
> Thus, you can use other types in form bean (nest business objects in form
> bean, for example) and Struts can still display the user's original input
> when in error. I tried it on Struts1.1-rc2 and it worked. I did not try
> complex cases such as array type and nested fields but I think it will work.
> What's your opinion? I began to look at Struts source code only recently and
> I'm still not quite familiar with the code. Comments from you people on
> whether it's worthwhile to implement it in Struts and the best way to do it
> if we decide to move on would be very helpful.
> 

You are trying to mix tiers with this solution -- I'm going to be very much
opposed to this sort of thing.  The ***only*** purpose for a form bean is to
store the server-side view of the contents of a user input property -- even if
the user input something that is not acceptable to the ultimate business
object.  Treating a form bean as part of the model tier is a fundamental
divergence from what Struts is designed to do for you.

> Andrew
> 


Craig McClanahan



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

Re: Tagging and freezing (was Re: Bug in JavascriptValidatorTag)

2004-02-27 Thread Craig R. McClanahan

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> On Wed, 25 Feb 2004, Joe Germuska wrote:
> 
> > Perhaps this is understood, but I'm assuming that we also want to say
> > that the RM "owns" the release tags for the release he or she is
> > managing, and only the RM should *ever* move the tags?
> 
> It's never been stated as such, but that's not a bad idea at all. I can't
> think of a good reason to move tags, other than to tweak things as part of
> the release process, and only the RM should be doing that.
> 
> Now, where can we document this? ;-)
> 

Why, in the "Struts Release Management Process" pages, of course :-)

In reality, it's sort of a sad commentary that we haven't done enough releases
for this to be a noticeable issue :-).

FWIW, I'm a fan of letting the RM decide on one of two alternative approaches
for each release:

* Announce a freeze of the HEAD branch (as was done here).

* Create a CVS branch for this release, which starts as a snapshot
  of the development tree when the release candidate is initially
  created, and allows the RM to incorporate whatever subsequent HEAD
  branch commits make sense (by either doing a CVS join or manually
  interpoating the fixes).

The latter strategy has worked very well for me lately ... it's worth trying on
the Struts release process as well.  (CVS branches are essentially free.)

Craig

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

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

Re: [OT] Maven (was Re: [ANNOUNCE] Struts 1.2.0 Test Build available)

2004-02-27 Thread Craig R. McClanahan

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> Oh yeah, also I can't go back from having versioned JAR in my lib 
> directories.  I suspect that's a matter of taste too, but I'll take 
> the overhead of pruning old JARs when new versions are deployed over 
> the mystery of knowing which versions your apps depend on any day...
> 

Interestingly, this touches on my single biggest frustration with Maven.

Professionally, I live in a world where there are some fairly large projects,
which integrate *lots* of open source projects (a very large number of
jakarta.apache.org and xml.apache.org subprojects are included).  Many of these
open source projects have overlapping dependencies on several Jakarta Commons
packages -- not a surprise, those packages were *designed* for reuse.  But
Maven (like many other build environments) encourages you to define the
specific version dependencies for each package you build independently.  That's
not good enough for enterprise development.

All of the Ant build.xml files I care about include a line like this:

  

that lets me define the individual versions of *all* dependencies for *all*
projects so that I can say, for example, use *this* version of
commons-beanutils and *that* version of commons-digester to build ***all*** of
the components that are going in to my overall exectable.  I am *so* not
interested in dealing with runtime exceptions because different dependent
packages were compiled against different versions of the dependent libraries.

Can someone please help me understand how to do this with Maven?  Without it,
I'm not planning to switch any of my personal or internal-to-Sun projects (even
if the Struts committers decide to switch Struts development itself).

> Joe

Craig McClanahan


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

Re: 1.2.0 is tagged and frozen

2004-02-23 Thread Craig R. McClanahan

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> On Mon, 23 Feb 2004, Ted Husted wrote:
> 
> > On Sun, 22 Feb 2004 22:38:24 -0800 (PST), Martin Cooper wrote:
> > > Actually, with this new release strategy, where should the
> > > announcement message go, since it's not a Final release? The same
> > > lists, or a subset? Thoughts?
> >
> > Following Craig's description of the Tomcat release approach (copy below),
> I'd say we should make an announcement to the Struts DEV and USER lists, with
> an URL leading to one of our home directories (or wherever Tomcat and others
> have been posting such things), but not the Jakarta announcement list. I
> imagine we'd now reserve the latter for a General Availability release that's
> being mirrored.
> 
> I'm fine with restricting the announcement as you describe. However, given
> the size of the struts-user list in particular, I'm not so sure about not
> taking advantage of mirroring for downloads. I'll take a look at what the
> Tomcat folks are doing in this regard, though, and just do what they do.
> ;-)
> 

They do what Ted mentioned -- just go to the DEV and USER lists with test
announcements, asking for feedback.  The tomcat-user list (2512 subscribers) is
somewhat smaller than ours (2948 subscribers) but I suspect that the number of
people who will actually download and test an alpha release will be fairly
small.  If it's not, we'll know enough to mirror next time.

> >
> > Sorry if the taglib-exercise module is flaky. If it is, mea culpa. But once
> it's up there, we can still announce it, see if there is anything else we can
> fix, and then try again with 1.2.1. That would also give us a chance to apply
> that license patch.
> 
> No biggie. As I said, I'm not overly concerned by the failures I saw,
> although I do want to verify that the problems with (2c) are also test app
> problems and not actual bugs in the core. I'll try to check that tonight,
> but I'd be happy if someone else beat me to it. ;-)
> 
> Once I get the build uploaded (grr!), I'd like someone to try out the
> Cactus tests and make sure that most of them, at least, run OK before I
> send out an announcement.
> 
> After 1.2.0 is out of the gate, we can apply Paul's license patches, as
> you suggest. Per Greg's board summary, we'll want to make sure we
> have the license on all applicable files. Also, since the board is now
> officially discouraging the use of @author tags, I'd like to see us
> remove those too.
> 

+1

> --
> Martin Cooper
> 

Craig


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

RE: string concatenation

2004-02-15 Thread Craig R. McClanahan

Quoting Andrew Hill <[EMAIL PROTECTED]>:

> It seems like utter madness to me.
> Mad! Mad! I tell you!
> 
> Half of commons was split off from struts originally anyhow, and now to go
> and say we dont want to depend on it, lets redevelop it yet again
> internally...
> WTF?
> 
> Will we then see another cycle where the internally redevloped code is again
> split off to form a sort of neo-commons??? 
> 
> 
> 
> 
> My preference would be for leveraging code that is in a logical place (ala
> commons-lang) and documenting the dependencies.
> 
> +1
> 

-1.

The commons-collections folks screwed much of the world (although not us,
because we only depend on a couple of classes that weren't moved to new
packages without backwards compatible deprecations) with their recent backwards
incompatible changes.  I'm not interested in supporting that behavior by
continuing to depend on them.  

Put yourself in the position of a sysadmin for a Tomcat 5 installation where
some webapps need the old version of commons-collections.jar and some need the
new version.  What are *you* going to do?

Craig


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

RE: string concatenation

2004-02-15 Thread Craig R. McClanahan

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> 
> 
> > -Original Message-
> > From: David Graham [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, February 15, 2004 1:01 PM
> > To: Struts Developers List
> > Subject: RE: string concatenation
> >
> >
> > Struts has many dependencies already and I'd like to avoid adding one with
> > lang.  Why not just size a large StringBuffer and trade memory for speed?
> 
> We already have a dependency on Lang, albeit indirectly, so why not take
> advantage of it?
> 
> Frankly, I disagree with the push I see from some folks (including Craig on
> commons-dev recently) to reduce dependencies between components by
> duplicating functionality. The whole point of Commons is to avoid
> duplication, so why are people pushing back against using the successful
> components that we helped create here in Struts?
> 

My particular concern on reducing dependencies is with the recent changes in
commons-collections -- it's going to lead to disaster.

Not for us ... our dependencies are very narrow, and did not get obsoleted ...
but for anyone using Tomcat (and that is a *lot* of people) the fact that
collections is no longer backwards compatible is a *huge* issue for people who
are going to be stuck with needing to put commons-collections.jar into Tomcat's
common/lib directory.

I've already committed the necessary changes to the CVS tree in
commons-digester.  When I get back from my trip to Japan next week (speaking at
Java Tech Days on the 18th and 19th), I'm going to do the same for the HEAD of
commons-beanutils (dependence on collections is mostly about FastHashMap, which
we contributed initially; dependence on commons-lang is a really bad idea
because we have no need for 99.9% of that stuff).  Anyone who depends on
commons-collections in a deeper way than we do is totally screwed by the most
recent release.  That sort of behavior should be condemned, not condoned.

> --
> Martin Cooper

Craig


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

Re: [resources] new implementations [was: Re: cvs commit: jakart...]

2004-02-06 Thread Craig R. McClanahan

Quoting James Mitchell <[EMAIL PROTECTED]>:

> 
> P.S.
> 
> I'll be adding a few more items later tonight and/or this weekend:
> - a build script in resources/contrib that let's us produce
>   a distribution of any single one of the implementations under
>   contrib
> - a few docs
> - tutorial on how to setup and use these impls.
> - a plugin (location: jakarta-struts/contrib ) that acts as
>   a wrapper to the current (Struts 1.1) message resources api.
>   This would let anyone use a current distribution of
>   commons-resources with Struts 1.1 (going for the
>   backwards-compatibility crowd)
> 
> 
> Future:
> - an iBatis implementation
> - a Torque implementation
> - a basic LDAP implementation
> - a [?? enter your choice ??] implementation
> - mods to all the current database impls that allow
>   datasource configuration/pooling via JNDI
> 
> 
> Did I miss anything?
> 

This list sounds awesome ... thanks James!

I agree that the Struts 1.1 wrapper should go in jakarta-struts/contrib ...
perhaps a new "resources-wrapper" subdirectory?

Craig


> 
> --
> James Mitchell
> Software Engineer / Struts Evangelist
> http://www.struts-atlanta.org
> 678.910.8017 (cell)
> AIM: jmitchtx
> MSN: [EMAIL PROTECTED]
> 
> 
> 
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, February 06, 2004 8:26 AM
> Subject: cvs commit: jakarta-commons-sandbox/resources/contrib/hibernate/sql
> mysql.sql
> 
> 
> > jmitchell2004/02/06 05:26:09
> >
> >   Added:   resources/contrib/hibernate/src/test hibernate.cfg.xml
> > hibernate.properties log4j.properties
> > oscache.properties
> >
> resources/contrib/hibernate/src/java/org/apache/commons/resources/impl
> > HibernateBasicMessage.hbm.xml
> > HibernateBasicMessage.java HibernateResources.java
> > HibernateResourcesFactory.java
> >
> resources/contrib/hibernate/src/test/org/apache/commons/resources/impl
> > HibernateResourcesTestCase.java
> >resources/contrib/hibernate/sql mysql.sql
> >   Log:
> >   Add new Database implementation that uses the
> >   Hibernate O/R mapping framework.  This particular
> >   contribution was fully tested with the latest release
> >   (2.1.2).
> >
> >   Revision  ChangesPath
> >   1.1
> jakarta-commons-sandbox/resources/contrib/hibernate/src/test/hibernate.cfg.x
> ml
> >
> >   Index: hibernate.cfg.xml
> >   ===
> >   
> >>   PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN"
> >   "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd";>
> >
> >   
> >
> >   
> >
> >   
> >name="hibernate.dialect">net.sf.hibernate.dialect.MySQLDialect.java y>
> >name="hibernate.connection.driver_class">org.gjt.mm.mysql.Driver
> >name="hibernate.connection.url">jdbc:mysql://localhost/resources
> >name="hibernate.connection.username">resourcesTest
> >name="hibernate.connection.password">resourcesTest
> >   4
> >   100
> >   true
> >   0
> >name="hibernate.cglib.use_reflection_optimizer">true
> >
> >resource="org/apache/commons/resources/impl/HibernateBasicMessage.hbm.xml"/>
> >
> >   
> >
> >   
> >
> >
> >
> >   1.1
> jakarta-commons-sandbox/resources/contrib/hibernate/src/test/hibernate.prope
> rties
> >
> >   Index: hibernate.properties
> >   ===
> >   ##
> >   ### Query Language ###
> >   ##
> >
> >   ## define query language constants / function names
> >
> >   hibernate.query.substitutions true 1, false 0, yes 'Y', no 'N'
> >
> >
> >
> >   #
> >   ### Platforms ###
> >   #
> >
> >   ## JNDI Datasource
> >
> >   #hibernate.connection.datasource jdbc/test
> >   #hibernate.connection.username db2
> >   #hibernate.connection.password db2
> >
> >
> >   ## HypersonicSQL
> >
> >   hibernate.dialect net.sf.hibernate.dialect.HSQLDialect
> >   hibernate.connection.driver_class org.hsqldb.jdbcDriver
> >   hibernate.connection.username sa
> >   hibernate.connection.password
> >   hibernate.connection.url jdbc:hsqldb:hsql://localhost
> >   hibernate.connection.url jdbc:hsqldb:test
> >   hibernate.connection.url jdbc:hsqldb:.
> >
> >
> >   ## PostgreSQL
> >
> >   #hibernate.dialect net.sf.hibernate.dialect.PostgreSQLDialect
> >   #hibernate.connection.driver_class org.postgresql.Driver
> >   #hibernate.connection.url jdbc:postgresql:template1
> >   #hibernate.connection.username pg
> >   #hibernate.connection.password
> >   #hibernate.query.substitutions yes 'Y', no 'N'
> >
> >
> >   ## DB2
> >
> >   #hibernate.dialect net.sf.hibernate.dialect.DB2Dialect
> >   #hiberna

Re: [chain] Chain as a mini-workflow engine?

2004-02-02 Thread Craig R. McClanahan

Quoting Jeff Caddel <[EMAIL PROTECTED]>:

> It's striking me that my chain-config.xml files are looking somewhat 
> similar to the example workflow xml file over in the sandbox/workflow area.
> 

There are indeed some overlaps in concept ... after all, I didn't forget
everything I learned from creating [workflow] in jakarta-commons-sandbox before
starting on [chain].

> In addition ComposableRequestProcessor by it's very name has a 
> workflow-ish ring to it.
> 
> A "ComposableBusinessLogicInvoker" seems like it would fit the bill for 
> me very nicely, and would be rapidly closing in on the stated goals for 
> the functionality of the sandbox/workflow component.
> 

The most important feature that [workflow] includes, but is not present in
[chain], is the idea that is formally known as a "continuation" -- you can
describe a single flow of commands that (if you're building a webapp) requires
more than one HTTP interaction with the client.  Without that, [chain] is still
useful to do AOP-ish sorts of things for a single request, but it doesn't
really solve all of the important problems I would consider relevant to a
package named "workflow".

In an ideal world, I'd like to see a single package that incorporated the
concepts of both [chain] and [workflow], but also leveraging the recent
advances in expression languages (employed in JSP 2.0, JSTL, jelly, jexl, et.
al.) instead of trying to invent control flow syntax in XMl like [workflow]
currently does.  I *hope* to have time to work on this sort of thing, now that
JavaServer Faces 1.0 is approaching release.

Craig McClanahan


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

Re: multipart requests in struts-chain

2004-02-02 Thread Craig R. McClanahan

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> It seems that struts-chain's AbstractPopulateActionForm was 
> implemented with its own strategy for moving values from the context 
> to the form.  Unfortunately, this strategy doesn't support multipart 
> forms (file uploads).
> 
> I've hacked to make it work, but I thought I should understand the 
> design decisions before committing any changes.  Or rather, let me 
> explain how I fixed it -- trying to fit within the existing design -- 
> and see if anyone (Craig?) has feedback.
> 
> I refactored the "execute" method of AbstractPopulateActionForm to this:
> 
>  ActionForm actionForm = ...
>  if (actionForm == null) {
>  return (false);
>  }
> 
>  ActionConfig actionConfig = ...
> 
>  reset(context, actionConfig, actionForm);
>  populate(context, actionConfig, actionForm);
>  handleCancel(context, actionConfig, actionForm);
> 
>  return (false);
> 
> I moved the behavior which was there before into the two protected 
> methods, "populate" and "handleCancel".  Then, in 
> ...servlet.PopulateActionForm, I overrode populate() to extract the 
> suffix and prefix and call RequestUtils.populate(Object, prefix, 
> suffix, request), which does handle file uploads.
> 
> I'm assuming the goal was to keep HttpServletRequest out of the base 
> implementation.  Therefore, I'm assuming that these changes are in 
> line with the design goals.  But I'd like a nod before I commit them.
> 
> The extraction of "handleCancel" was just to make the base "execute" 
> read more clearly, and that method is not overridden in 
> ...servlet.PopulateActionForm.
> 
> Thanks
>   Joe
> 

The original design in struts-chain did not contemplate the complexities
required to support file upload at all.  If you can refactor the existing code
to support that gracefully support both use cases, that's awesome ... if it
requires separate chains for the two use cases, that's ok (indeed, that's part
of the reason that refactoring the request processor into a chain makes things
easier to customize).

Craig


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

Re: Compartmentalization of Modules (was Re: [18111] et al)

2004-01-22 Thread Craig R. McClanahan

Quoting Ted Husted <[EMAIL PROTECTED]>:

>  I'm still working on the changes and refactorings to add contextRelative to
> the link and rewrite tags. I'll post those first, and then  do the changes to
> deprecate contextRelative in favor of module. 
> 
> -T.
> 

Orthogonal to adding a "module" attribute and other sorts of things associated
with this thread (I agree with the things I've read along that line), I
remember that Martin proposed (*many* moons ago) the idea that module
configurations might be organized hierarchically -- they would inherit default
behavior from a parent module in a manner similar to how Tiles do it.  If that
is not in the current thinking, it would still be something worth thinking
about for the future.

Just thinking out loud, we could keep the existing non-hierarchical behavior as
a default (for backwards compatibility), but add a "parent module" attribute
into ModuleConfig to enable one to define the inheritance hierarchy.

Craig


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

RE: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)

2004-01-22 Thread Craig R. McClanahan

Quoting Gary Gregory <[EMAIL PROTECTED]>:

> (1) "eventually" is, sadly I think, a ways off in the future. See
> discussions on this list WRT J2ee containers, WebSphere, most common
> installed base of such containers, etc.
> 



As a major proponent of long-term support for existing packages that want to do
evolutionary development, this is an important issue.  My own experience with
Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important
for existing users.  And it will continue to be.  *Nobody* in the real world
can migrate to more current technologies as fast as the developers of those
technologies would wish that they could.

However, I get really impatient with this reality for *future* users. 
Many/most
Jakarta projects tend to focus on the "what is widely deployed now" scenario --
but limiting ongoing development to this kind of platform is *very* bad for the
Java platform in the long run.

Personally, I will continue to invest effort in supporting existing users of
the
Apache/Jakarta packages I contribute to.  But my primary focus for future
efforts are going to be focused on leveraging the platforms that are more
current in the mainstream ... with the expectation that folks on platforms that
don't have this current support *will* be taken care of by the time that the
revolutionary software is (if it ever is) ready for general release.

As such, I'm personally not interested in working on any revolutionary Struts
or
Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base
platform as the minimum requirement.  That's not to say that the needs of
exisiting pre-1.4-based users, or non-mainstream platforms that don't support
SE/EE 1.4, aren't important --- nothing could be further from the truth! -- but
limiting the ongoing development of Jakarta-based software (overall, the
convention seems to be to support JDK 1.2 as the minimum platform with some
packages supporting 1.1 compatible versions) is going to be very detrimental to
the long-term success of the Java platform.

The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the tip of the
state of the art.  Would you willing to accept being required to work on such a
hardware system today?

It's time for us to recognize that there are *millions* of mainstream users,
who
*can* provide a 1.4 baseline runtime environmment -- and, as a whole, the
Jakarta community is not paying enough attention to what kinds of capabilities
can not be assumed.  Lets *stop* limiting our revolutionary advances by an
assumption that we have to be backwards compatible with what (in computer
terms) is now considered the Iron Age of computing.


Craig McClanahan


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

RE: why are form beans required for html:form?

2004-01-22 Thread Craig R. McClanahan

Quoting Ted Husted <[EMAIL PROTECTED]>:

> 
> 
> >> Heck, if you throw the JSF extension into the mix, I wager you
> >> could write significant Struts applications now without writing
> >> any Java code at all. :)
> >>
> >> http://struts.sourceforge.net/struts-bsf/index.html
> >>
> >
> > I have in fact thrown the BSF extension into the mix, and I'm
> > pretty excited about it!
> 
> Yep. Lost track of who I was chatting with :)
> 
> 

Next, James Stachan will insist we need a way to use Groovy for actions :-).

(A smiley only because I always smile when seeing how passionate James gets when
he talks about Groovy -- it's actually a pretty good idea.)

> > Joe
> 
> 

Craig


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

Re: @author tags in Struts code

2004-01-09 Thread Craig R. McClanahan

Quoting Paul Sundling <[EMAIL PROTECTED]>:

> If the group was interested in removing all author tags and 
> consolidating all the names onto volunteer.html I would be willing to 
> make a tar of patches or whatever format is most convenient. If you're 
> interested, let me know if that would be useful and I'll try to give you 
> 24 hour or less tournaround time. I'd probably have to ask for couple 
> questions and then I'd submit it through bugzilla. It's in the realm of 
> busy work, but I'm very detail oriented and pretty good with a CLI. :)
> 

+1 on such a patch, attached to a Bugzilla ticket in "cvs diff -u" format as
David pointed out.

Ironically, this would definitely count as enough work to get you added to the
contributor list if you are not already :-).

> Paul Sundling

Craig


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

Re: @author tags in Struts code

2004-01-07 Thread Craig R. McClanahan

Quoting Paul Sundling <[EMAIL PROTECTED]>:

> I can see a lot of valid points in the article.  I also don't buy the 
> positive side regarding author tags helping point out who to go to for 
> help on a particular file.   Whatever the final decision, the philosophy 
> should be documented on the web site in the section where it talks about 
> how to help.  There are however two reasons why I think such artifacts 
> as author tags are good (although I think CVS comments are better if 
> consistent).
> 
> 1.  For non-committers, it gives us warm fuzzies.  It's like a little 
> flag that says I actually made my contribution to open source, like more 
> of us out there should.  You can't go in CVS and see that people like me 
> added a patch, unless a committer actually takes time to actually 
> mention it without an author tag.

That particular practice is something we focus on pretty heavily on Struts --
the only times I've ever seen someone forget this was an oversight or a
too-quick press of the submit button; in those cases, the standard practice has
been to note the contribution in a message to STRUTS-DEV (where the CVS
messages also go) in order to ensure that credit is logged someplace
historical.

  If there were some template text, 
> like "Based on a patch contributed to ASF by [EMAIL PROTECTED] related 
> to bugzilla # ." in the CVS log I think that would be good enough. 
> 

The CVS commit template already includes "Submitted by:" for Struts, to nag us
committers into remembering to give credit where credit is due.

> Even though I've had a VERY VERY minor contribution, it was quite a rush 
> to have an author tag on a minor support file.  It made me feel like a 
> part of the project and it made me want to get more involved.  [I'm 
> getting into unit testing, so I figure I might make contributions there 
> first down the line.]  I would never want to cause any resentment 
> against those doing the brunt of the work or claim that I'm on the same 
> level.  At the same time, it's nice to have a little reminder somewhere 
> that I'm making a contribution, however small.
> 

Every committer to Struts will *welcome* contributions on unit testing!  But I
guess I need to ask ... does getting properly acknowledged in the CVS commit
messages give you the same level of warm fuzzies?  I ask because that is an
automatic process (at least when I do commits based off a contributed patch);
but it's a judgement call on whether the change was significant enough to
warrant adding an @author tag -- where do you draw the line?  A one-line typo
fix?  A ten line patch?  A hundred line new method?  A complete new class?

There's no decision needed for CVS commit attribution -- and that attribution is
visible to the world at large too:

  http://cvs.apache.org/viewcvs/jakarta-struts/

> 2. There should be some tracking for the origins of code in case we ever 
> get attacked by a company like SCO.  Maybe there's already some cross 
> referencing system that I'm not aware of between bugzilla and CVS that 
> already takes care of this.  I guess this is counter to legal protection 
> under the ASF umbrella.  Let's say I work at Top Secret Corp or Run By 
> Lawyers Inc.  and I submit a patch that my employer would see as 
> infringing code.  It's good code and one of committers (David Graham for 
> instance, since I'm replying to his message) commits it into CVS.  It 
> now looks like David was the source for the code and when Top Secret 
> Corp lawyers started sniffing around it'd be harder to find out the true 
> source.  I would guess this might end up being a major issue depending 
> on how the SCO law suit ends.
> 

This is one of the topics that is being addressed in discussions on an updated
Apache Software Foundation license that is currently being discussed and
reviewed.  But your point is taken ... attribution is defensive as well as
warm-fuzzy-producing :-).

> Paul Sundling
> 

Craig


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

Re: @author tags in Struts code

2004-01-07 Thread Craig R. McClanahan

Quoting David Graham <[EMAIL PROTECTED]>:

> The @author javadoc tag topic has been discussed on commons-dev recently
> and Ted brought it up in a recent struts-dev thread so I thought it might
> be nice to get the Struts community's opinion on it.  Some arguments
> against @author tags by Greg Stein can be found here:
> http://tinyurl.com/yrlhu
> 

I'm +1 on removing @author tags.  Struts is a work of many many hands, and
removing them avoids any need to decide how "significant" a particular
contribution is before it warrants adding that person.

> I'm not too concerned about the legal issues because I don't think there
> are any.  I think it's a good idea to remove all of the tags rather than
> each person removing their own so that the remaining tags don't
> misrepresent who did most of the work (kind of an all or nothing deal).

I'm not at all concerned about any potential legal issues related to @author. 
It's the social impact of this being a community project that is more
important.  The fact that my name is all over the place, for example, distorts
the reality of the last year or so when I haven't had as much time as I'd like
to participate.

> 
> Comments?
> 
> David
> 

Craig


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

Re: [Proposal] ActionFactory refactoring

2004-01-02 Thread Craig R. McClanahan

Quoting Don Brown <[EMAIL PROTECTED]>:

> What if we extracted the creation of Actions and ActionForms (including
> DynaActionForms) into an ActionFactory, overridable by the user?
> 

The idea of factories for all Struts objects is an appealing one (I don't buy
the "too hard to teach" assertion either -- if you don't like teaching it, go
tell the GoF that they've got things all wrong :-).  The idea of a single
factory for all of them isn't quite so appealing -- every time we want to add a
new Struts API object, we need to go back and modify the standard factory
class, which is messy.

One interesting approach to this would be to add a responsibility to the
existing set of FooConfig objects, adding an appropriate create method to each.
 After all, if you want a specialized type of Action or ActionForm object,
you're probably going to need someplace to store extra configuration
information also, and the config object is exactly where you'd want to add
those properties.  Instead of createDynaActionForm() and
createDefaultActionForm(), then, we'd simply have createActionForm() on the
FormBeanConfig class, and it would do the right thing.  Using this approach,
configuring a specialized config bean class automatically configures a new
factory method as well, so you don't have to change two configuration settings
in struts-config.xml either.

An additional decision related to this whole condept, of course, is whether we
stick with the pure JavaBeans style object creation (zero-args constructor,
configure everything with property setters) or something like what Pico wants
(everything configured by arguments to the constructor).  I've dealt with
enough tools vendors in the last couple of years to be convinced that the
former (JavaBeans style) is *substantially* easier to build tools for, and
would therefore favor continuing that design pattern for any kinds of objects
(and object factories) that we create in the future.

Craig McClanahan


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

Nighty Builds of Struts-Faces Integration Library

2003-12-24 Thread Craig R. McClanahan



Nightly binary builds of the Struts-Faces Integration Library, updated to work
with the new beta release of JavaServer Faces, are now available:

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

As always, the source code for this library is in the "contrib/struts-faces"
directory of the nightly Struts source distro:

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

This code is *not* ready for prime time yet, but the test application at least
works.  Tops on my list is ensuring that it works with Tiles as well ... most
likely by having two different request processor subclasses and making you
configure the one you need based on whether Tiles is in use or not.  Not quite
as transparent as the old release, but it should be able to work.

Craig

PS:  While nowhere near as cool as the gift of eternal life that we'll be
celebrating tomorrow, please consider this a Christmas gift to all the Struts
developers and users out there :-).


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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-20 Thread Craig R. McClanahan

Quoting [EMAIL PROTECTED]:

> I think that sounds like a good compromise.  In my view, there are really
> two types of "forms" - small ones with one or two parameters, and full
> blown complex input forms.  In the former case, I think combining the form
> and action is a good idea; the latter, probably not so much.
> 
> In WebWork2/XWork, as I understand it, your action can declare JavaBean
> setters which will be automatically populated by the framework.  This
> makes it very easy to unit test and frees the actions from any servlet
> dependencies.  This approach works very well for actions that require a
> couple of parameters, while I might favor the Struts approach for larger
> forms.
> 

JavaServer Faces supports (but does not require) this idiom as well.  The
corresponding backing beans would typically be defined in 
entries in faces-config.xml so that they get automatically instantiated on
demand (the way that Struts 1.x does for form beans).  The managed bean
configuration entry can also cause properties of the instantiated bean to be
set as well.

One thing I particularly like about the way JSF does this is that the backing
bean class doesn't have to extend a framework base class, or implement a
particular interface.  This makes it fairly straightforward to unit test them,
or use them in different contexts.

> To experiment adding these and other WebWork2/XWork features in Struts we
> started the Struts Action Invocation Framework (SAIF) on struts.sf.net 
> The Struts sf site is a great forum for trying out ideas before sticking
> them in Struts core.  To implement the integrated form/action, we "scope"
> actions (request/session/application), then use action interceptors to set
> action JavaBean setters from the request parameters.  While SAIF certainly
> isn't ready to be put in Struts core, the action interceptor idea is
> showing promise and provides a good alternative to the more heavy-handed
> ActionForm for simplier situations.
> 
> Don
> 

Craig


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

JavaServer Faces 1.0 -- Proposed Final Draft Spec and Beta Reference Implementation



I'm pleased to announce that the Proposed Final Draft version of the JavaServer
Faces 1.0 Specification, and a corresponding Beta release of the Reference
Implementation, is now available at:

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

Please send any feedback and comments strictly about JavaServer Faces to
<[EMAIL PROTECTED]>.

I'm also finishing up an update to the Struts-Faces Integration Library, and
will be making it available (via nightly builds) very soon.  Feel free to ask
any questions about how to use Struts and JavaServer Faces here on the
STRUTS-USER list.

Craig McClanahan


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

Re: Why you want to be on the PMC

Quoting Ted Husted <[EMAIL PROTECTED]>:

> Craig R. McClanahan wrote:
> > Presuming a positive vote from the committers, we'd have to make a formal
> > proposal to the ASF Board (like the Ant, Maven, ... communities did, so we
> can
> > use their proposals as a sample) and get it accepted.  Included in the
> proposal
> > would be things like who the PMC members would be, and who we'd suggest as
> the
> > PMC chairperson (because this person becomes an ASF officer, it has to be
> > appointed by the board).
> > 
> > The largest issue around preparing the proposal is likely to be a
> definition of
> > what the scope of the project will be.
> 
> We could dodge the bullet and just follow Cocoon precedent: define the 
> scope of Apache Struts to be Apache Struts :)
> 

So, do we invite the non-Java implementations of the same concept in, or do we
say "nah, we're a Java project?"  I'm not personally much interested in the non
Java solutions, but a cross-language framework would be somewhat unusual.

Craig


>
http://apache.org/foundation/records/minutes/2003/board_minutes_2003_01_22.txt
> 
> Otherwise, any language we come up with is sure to overlap with other 
> Apache offerings, and we end up having to create some type of frameworks 
> project, along the lines of the Database or Web Services projects.
> 
>
http://apache.org/foundation/records/minutes/2002/board_minutes_2002_07_17.txt
> 
>
http://apache.org/foundation/records/minutes/2003/board_minutes_2003_01_22.txt
> 
> If we did decide to do something, I'm not opposed to either course.
> 
> The former would be less work, but the latter might have greater long 
> term benefits. In the latter case, I suppose we'd ask Tapestry and 
> Turbine if they wanted to join us as frameworks.apache.org (or whatever).
> 
> I looked over the Board status reports for db and webservices, but it's 
> hard to tell whether these new umbrellas are working any better than 
> Jakarta. If anyone is involved with the communities, and has something 
> to share, please do.
> 
> On balance, I would lean toward the position that the Struts community 
> is large and robust enough to justify its own TLP, and see if the Board 
> agrees.
> 
> One thing I would like to bring up in the context of a TLP Struts is the 
> idea of also hosting a php implementation of Struts. Several people have 
> been trying to do this (google struts php). Since php is also an Apache 
> product, it would be a natural thing for a top-level ASF Struts project 
> do to. A framework similar to Struts, Maverick, already has a php 
> implementation, which proves it can be done.
> 
> Of course, there is also the matter of JSR 223 
> <http://jcp.org/en/jsr/detail?id=223>.
> 
> There is *alot* of interest in using MVC in php-land, and a Struts 
> implementation could help coalesce that interest into a stable community.
> 
> -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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting [EMAIL PROTECTED]:

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 19, 2003 11:00 AM
> To: Struts Developers List
> Subject: RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> 
> Quoting [EMAIL PROTECTED]:
> 
> > We have a solution for dynamic page content that is component based.
> I
> > wouldn't say that it stands up to JSF but it's similar in concept.
> The
> > content of the page is defined using xml metadata.
> >
> > However, I suppose that you could argue, why not use JSF?  I would be
> > interested in hearing what advantage you would have using struts with
> JSF
> > when JSF handles both the view layer and controller?
> >
> 
> >>Fair question.  In the long run, we (Struts) are definitely going to
> >>have to "compete" with this combination.
> 
> >>The easiest way is to focus on features that are not present in JSF --
> >>one approach would be to build on top of the JSF controller
> >>infrastructure.
> 
> >>Besides the UI components, there are some very useful foundational
> >>things there (such as managed beans, which generalize the way that
> >>Struts auto-creates form beans on demand, fine-grained navigation
> rules, >>and the ability to programmatically evaluate EL-ish
> expressions, >>including the ability to plug in new evaluators for the
> "." operator) >>that would be nice to use in a controller tier.
> 
> I have been struggling to correlate the notion of a struts formbean with a
> jsf UI component.  Under struts, a single action can be associated with
> only one formbean.  If the form is a composition of many components,
> should each component have its own "formbean"?  It sounds as each jsf
> component would pull values on its own behalf from the request parameters
> thru a converter.
> 

In Struts terminology, a JSF UI component relates more to an individual form
bean property than it does to the form bean itself.  However, the type
conversion mechanism *is* built in to the UI components in JSF, so you can have
your "form bean" using native data types without the penalties you'd suffer
doing this with the standard Struts tags.

> To achieve visual component reuse, it sounds like jsf introduces the
> notion of a client id.  We have used an underscore as our component
> delimiter because the beanutils handles the "." for nested components.
> 

Components do have identifiers that are composed based on the "naming container"
components (such as UIForm).  The composition delimiter that JSF chose is the
":" character, primarily to avoid confusion over what "." means in JavaScript.

> It seems that if you had a single form bean to map to a graph of UI
> components, the form bean might get kind of ugly.
> 
>
>  name="aboutForm_BorderLayout_west_dateWidget_selDate"
>type="java.lang.String"/>
>  
name="aboutForm_BorderLayout_center_calendarWidget_GridLayout_B0_yearWidget_year"
>  type="java.lang.String"/>
> 
> 
name="aboutForm_BorderLayout_center_calendarWidget_GridLayout_A0_monthWidget_month"
>  type="java.lang.String"/>
> 
>   
> 
> It would be nice if the behavior of the formbean to an aciton could also
> be associated with a UI component.
> 

If you use the struts-faces integration library, you don't need to change
anything at all about your form bean definitions -- you still use the property
names.  The page author, though, has to prefix the value reference expressions
on each property with the name of the corresponding form bean (because JSF does
not constrain you to a single form bean).

> It sounds like the struts chains will be similar to the jsf component
> tree?  Could a chain command be associated with a individual formbean and
> a command be corrolated to a UI component?
> 

Hmm, I'm not sure I see that connection.  I see the chain used (inside Struts)
to compose the stuff that happens after a form has been submitted -- versus the
hard coded logic inside RequestProcessor -- but you could certainly attach a
different chain to each of the different submit buttons on a given form, for
example.

Craig


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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Mete Kural <[EMAIL PROTECTED]>:

> >If we do things right, IMHO workflow support system(s) should be a layer on
> top
> >of the foundational request handling capability, so you can use it if you
> need
> >it but it doesn't get in the way if you don't.
> 
> I think I agree here. Isn't workflow something that the business tier
> implements in a properly designed application? Since a workflow is based on
> business rules specific to an organization, why should the webapp front-end
> deal with workflow issues, and not leave it up to the business tier?
> 

"Workflow" is one of those wonderful words that means different things to
different people :-).  It makes sense to think about webapp frameworks wanting
to deal with workflows for individual conversations (think of managing a wizard
dialog, which is a very common use case) as well as the higher level stuff with
orchestration and all of that.


> Thanks,
> Mete

Craig


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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Mete Kural <[EMAIL PROTECTED]>:

> Hi Craig,
> 
> >A completely different way to consider using JSF would be to build a
> RenderKit
> >that took input like this and generated the corresponding HTML (or
> whatever)
> >markup, starting from the exact same components as the standard HTML
> RenderKit.
> > In the JSF release, there is the very beginnings of an example how this can
> be
> >done, which uses XUL as the input templating language.  Fleshing something
> like
> >this out could leverage the fact that Mozilla has already popularized this
> as a
> >technology for defining page layout, as well as some amount of
> interactivity.
> 
> I have a question here. I've been thinking of ways of how JSF and XSLT could
> be leveraged together, with or without leveraging JSP. Let's say we have an
> application where the Action classes make lots of calls to SOAP services and
> sometimes receive fairly large XML documents. In the case of large XML
> responses, converting the XML to POJOs may turn out to be unnecessary
> processing, where as you can simply do an XSLT transformation over the XML
> response to generate the final markup output. So what would be an efficient
> way to leverage both JSF and XSLT here? Could this be a good strategy:
> 
> "Implement a RenderKit and JSF components that take XML documents as the
> business object input (instead of JavaBeans, Maps, etc.) and uses XSLT to
> generate the device-specific markup output. Then if you are using JSP as the
> templating system, implement a JSP taglib to call these components. If you're
> using another templating engine, write a tag library specific to that
> templating system and call your components."
> 

One of the interesting things about JSF is that it's a two level API --
components and renderers have a JavaBeans-ish API to be used directly (or from
the templating environment's renderers), and you can build a JSP custom tag
around them to get access from the JSP layer.  For example, doing something
like JSTL's  tag in JSF would be as simple as:

* No new component needed ... leverage the "generic attributes"
  capability of the standard UIOutput component class.  Or, if
  you really want, you can create a component class if you like
  exposing everything as JavaBeans properties.

* Create a new XsltRenderer that uses the "value" property
  of the UIOutput component to point at the XML data to be
  transformed, and (perhaps) an "xslt" attribute to point at
  the stylesheet.  (I'd suggest making the syntax and semantics
  as close as possible to  for maximum familiarity),
  and used JAXP APIs to perform the transformation, followed
  by writing the output to the response.

* Create a JSF component tag that marries the two together
  (about 30 lines of code) and utilizes the Java-level APIs
  underneath.

Hmm, that's about 30 minutes of effort, and you get an XSLT transformation
component that can be used in JSP or any other templating environment supported
by your JSF RenderKit.  I should have some time to play with stuff like this
next week, when Sun shuts down for the Christmas break.

> >Craig
> 
> Mete
> 

Craig

PS:  Of course, if you're using JSP as your rendering technology, nothing stops
you from using tags like  in the same page as your components, if
you want.


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

RE: Why you want to be on the PMC

Quoting David Graham <[EMAIL PROTECTED]>:

> I have some real basic questions:
> 
> 1.  Why is it better to be a top level Apache project rather than part of
> Jakarta.
> 

I've seen comments from Martin and Ted that they're wanting to answer this
question more fully with a proposal, so I'll let them do most of the work.  The
short answer, though, is we will be in charge of our own releases (currently,
the Jakarta PMC is the only body legally recognized to vote on releases of
*any* software under Jakarta).  Additionally, the act of preparing the proposal
will require us to focus on defining the scope of what we think Struts is and
should be, and that's always beneficial.

If we want it (and I think we should), we can get our own top level domain
(struts.apache.org) as well, but that's icing on the cake.

> 2.  What are the requirements for becoming a top level project?
> 

The Incubator Wiki has a few pointers, but this stuff is somewhat in flux:

http://wiki.apache.org/incubator/

I'll see if I can dig up some references from the general@ mailing list, or Ted
or Martin might have something at their fingertips.

> Any URLs/info is appreciated.
> 
> David
> 

Craig


> 
> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> > Quoting James Mitchell <[EMAIL PROTECTED]>:
> > 
> > > On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
> > > 
> > > 
> > > 
> > > > If/when Struts becomes a TLP, I'm going to recommend that we do
> > exactly
> > > what
> > > > Ant, James, and Maven (for example) did:
> > > >
> > > > * Maintain a link on the Jakarta home page under "Related"
> > > >
> > > > * Install a webserver redirect from
> > <http://jakarta.apache.org/struts>
> > > >   to <http://struts.apache.org>.
> > > 
> > > Is there anything holding us back from going TLP?
> > > 
> > > I seem to remember only a few brief discussions on the dev listand
> > > that was quite a ways back.
> > > 
> > 
> > Presuming a positive vote from the committers, we'd have to make a
> > formal
> > proposal to the ASF Board (like the Ant, Maven, ... communities did, so
> > we can
> > use their proposals as a sample) and get it accepted.  Included in the
> > proposal
> > would be things like who the PMC members would be, and who we'd suggest
> > as the
> > PMC chairperson (because this person becomes an ASF officer, it has to
> > be
> > appointed by the board).
> > 
> > The largest issue around preparing the proposal is likely to be a
> > definition of
> > what the scope of the project will be.
> > 
> > > James Mitchell
> > 
> > Craig
> > 
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> __
> Do you Yahoo!?
> Free Pop-Up Blocker - Get it now
> http://companion.yahoo.com/
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




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

Re: Struts apps over classloader boundaries

Quoting "n. alex rupp" <[EMAIL PROTECTED]>:

> Can Struts applications share information and classes between classloaders
> in
> the same VM?

That's primarily a container question.  If you use Tomcat, for example, any
classes in shared/lib or common/lib is indeed shared across webapps (including
things like static variables).

As for sharing struts.jar itself (and the associated commons libraries), the
short answer is that it *might* work for you.  The longer answer (for 1.1 at
least) is in the user guide:

http://jakarta.apache.org/struts/userGuide/configuration.html#config_add

> --
> N. Alex  Rupp ([EMAIL PROTECTED])
> 
> 

Craig


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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting "n. alex rupp" <[EMAIL PROTECTED]>:

> What about including a Dynamic rules-based workflow engine?  One like
> Drools?
> This is great because it abstracts a lot of the operational control of the
> application into the realm of the business person.  It seems to me that IoC
> is a
> good start, but following up with a business rules based control system
> would
> greatly benefit a lot of companies.  When the rules of the business changed,
> they could alter the operation of the web application without having to push
> their changes and requirements through the developers.
> 

If we do things right, IMHO workflow support system(s) should be a layer on top
of the foundational request handling capability, so you can use it if you need
it but it doesn't get in the way if you don't.  A rules-based environment is
certainly one way to do it; so is scripted dialongs with some sort of
continuations (like the Cocoon folks are playing with).

> This implies creating management tools, which breaches the question: can we
> put
> JMX management hooks into Struts 2.0 so that all the different components
> and
> their configurations can be managed at runtime?
> 

Certainly possible, but if you've come from an environment of creating
containers and having full control over class loaders and security managers,
you're going to find yourself somewhat frustrated by the limitations of what
you can do portably *inside* a webapp :-).

> --
> N. Alex  Rupp ([EMAIL PROTECTED])
> 

Craig

PS:  Alex, it's interesting to note that a lot of the webapp framework folks are
all focusing on decomposing their request processors at the same time.  The
idea we've been playing with that is similar to Shocks is the commons-chain
package (in the Jakarta Commons sandbox), and an experimental implementation of
the Struts 1.1 request processor in the "contrib/struts-chain" source
directory.  One thing I'd recommend you think about is decoupling your
execute() API from the servlet request and response objects, so you can reuse
the basic idea inside the business tier as well.


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




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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting [EMAIL PROTECTED]:

> We have a solution for dynamic page content that is component based.  I
> wouldnt say that it stands up to JSF but its similar in concept.  The
> content of the page is defined using xml metadata.
> 
> However, I suppose that you could argue, why not use JSF?  I would be
> interested in hearing what advantage you would have using struts with JSF
> when JSF handles both the view layer and controller?
> 

Fair question.  In the long run, we (Struts) are definitely going to have to
"compete" with this combination.

The easiest way is to focus on features that are not present in JSF -- one
approach would be to build on top of the JSF controller infrastructure. 
Besides the UI components, there are some very useful foundational things there
(such as managed beans, which generalize the way that Struts auto-creates form
beans on demand, fine-grained navigation rules, and the ability to
programmatically evaluate EL-ish expressions, including the ability to plug in
new evaluators for the "." operator) that would be nice to use in a controller
tier.

> Consider the following DTD and XML snippet:
> 
> 
> 
>displayElementId CDATA #REQUIRED
>   type %DisplayElementType; #IMPLIED
>   jspName CDATA #IMPLIED
>   extends CDATA #IMPLIED
>   modelClassname CDATA #IMPLIED
>   roles CDATA #IMPLIED
>   useContainerNaming %Boolean; #IMPLIED
> >
> 
> 
>name CDATA #REQUIRED
>   value CDATA #REQUIRED
> >
> 
> 
>attName CDATA #IMPLIED
>   displayName CDATA #IMPLIED
>   displayElementId CDATA #REQUIRED
>   requiredField %Boolean; #IMPLIED
>   sequence CDATA #REQUIRED
>   roles CDATA #IMPLIED
>   useContainerNaming %Boolean; #IMPLIED
> >
> 
> This is an example of building a change password page.  The
> "changePasswdForm" is the root "component".
> 
> 
> 
> 
> 
>   displayName="message.required.legend" sequence="99"/>
> 
> 
> 
> 
> 
> 
> 
>   
>   
> 
>   
>   
> 
>   
> 
>   
> 
>   
> 
>   
>  
>   
> 
>   
>  
>   
> 
> 
> 
> 
> 
> 
> 
> 
>   displayName="cuPassword.display" sequence="1"
>   requiredField="true">
>   
>   
>   
>
> 
>   displayName="retypePassword.display" sequence="2"
>   requiredField="true">
> 
>   
>   
>   
>
> 
> 
> 

Roll your own templating languages are certainly possible, but it's also nice to
leverage prior art when you can.

A completely different way to consider using JSF would be to build a RenderKit
that took input like this and generated the corresponding HTML (or whatever)
markup, starting from the exact same components as the standard HTML RenderKit.
 In the JSF release, there is the very beginnings of an example how this can be
done, which uses XUL as the input templating language.  Fleshing something like
this out could leverage the fact that Mozilla has already popularized this as a
technology for defining page layout, as well as some amount of interactivity.

Craig


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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> 
> As for PicoContainer, if someone could just show me how you write an 
> external configuration file that wires together objects through their 
> constructors, I might buy it, but it just doesn't seem to match up. 
> As soon as you had one new collaborator that you hadn't planned for, 
> you'd have to rewrite some java code somewhere, wouldn't you?
> 

My understanding is that configuration files are outside the scope of Pico
itself, but that's where things like NanoContainer come into play -- several
implementations of using Pico (including configuration support).

Craig


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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting David Graham <[EMAIL PROTECTED]>:

> 
> If we want IoC inside of Struts we should look at something lighter weight
> like HiveMind.  I'd also like some focused concrete examples of how IoC
> would benefit Struts internals before we decide to go that route.  
> 

Presuming the IP issues around Hivemind get worked out, using it for our IoC
configuration needs would be pretty attractive -- among other things, it'll
already be Apache code, and we'll benefit from the cross fertilization of its
use in Tapestry.

> David

Craig

PS:  By the way, I met Howard Lewis Ship (and his wife Suzy) at ApacheCon.  We
had a great time seeing the StarTrek Experience (in Las Vegas) together,
achieving our goal of getting some of the cast members to laugh with us instead
of following their script when the three of us were the entire audience for the
last show of that evening ... very enjoyable!


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

RE: Why you want to be on the PMC

Quoting James Mitchell <[EMAIL PROTECTED]>:

> On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
> 
> 
> 
> > If/when Struts becomes a TLP, I'm going to recommend that we do exactly
> what
> > Ant, James, and Maven (for example) did:
> >
> > * Maintain a link on the Jakarta home page under "Related"
> >
> > * Install a webserver redirect from <http://jakarta.apache.org/struts>
> >   to <http://struts.apache.org>.
> 
> Is there anything holding us back from going TLP?
> 
> I seem to remember only a few brief discussions on the dev listand
> that was quite a ways back.
> 

Presuming a positive vote from the committers, we'd have to make a formal
proposal to the ASF Board (like the Ant, Maven, ... communities did, so we can
use their proposals as a sample) and get it accepted.  Included in the proposal
would be things like who the PMC members would be, and who we'd suggest as the
PMC chairperson (because this person becomes an ASF officer, it has to be
appointed by the board).

The largest issue around preparing the proposal is likely to be a definition of
what the scope of the project will be.

> James Mitchell

Craig

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Hubert Rabago <[EMAIL PROTECTED]>:

> That's exactly what I meant to say, of course I just didn't articulate it as
> well
> as you did. =)  Form bean details are spread all around, violating the DRY
> principle.  The DTO's can be used to tell Struts how to generate dynamic
> action
> forms that it (and the validator) can work with, without the user having to
> list
> down all the fields in the struts config file.  Also, the conversion from
> ActionForm to app-specific DTO's can mostly be automated.
> 

That turns out to be more intricate than it first appears, and is the reason
that ActionForm existed in the first place (and, why it's part of the *view*
tier, not the model, and why it was originally created as a class and not an
interface, to discourage people from using it as a DTO).

A very important feature of any presentation tier is to be able to reproduce
whatever the user entered, even if they made a mistake (i.e. typed "1a3"
instead of "123" into a field that is backed by an int).  Given the
practicalities of HTTP, that gives you two basic choices:

* A framework that represents input fields on the server side as
  Strings, and then requires post-validation conversion (basically
  the Struts 1.x model).

* A framework where the individual user interface components manage
  their own conversions, and are bound to back-end DTOs or model data
  objects expressed as native data types (JavaServer Faces, Tapestry,
  and several other frameworks work this way).

Interstingly, using JavaServer Faces components in front of Struts ActionForms
will let you work the second way if you want to, and use action forms that have
native data types with no problems.

You'll also find that there is not always (or even often, in my experience) a
1:1 relationship between "the sets of fields on a form" and "the set of model
data objects that provide information to, or accept updates from, that form". 
My feeling is that you're always going to want separate abstractions; the
secret for a framework is to minimize the amount of work required to deal wth
that reality.

Craig


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

RE: Struts EL Distro

Quoting "Karr, David" <[EMAIL PROTECTED]>:

> I don't see a problem with removing the duplicate jars from the lib
> directory, but I disagree with distributing "half-baked" wars.  I like
> the fact that users can deploy sample applications with little effort.
> 

+1

> I have some spare time next week, so I could look at paring out
> unnecessary jars from the lib dir, unless someone else wanted to work on
> this.
> 

With the Java Web Services Developer Pack (JWSDP) releases, we (Sun) solved this
problem by creating an installer that allowed shipping only one copy of each
library in the distribution, but copied them to all the webapps as they were
being installed.  The downside is you have to create and maintain an installer,
which is a real pain, but it does let you have your cake and eat it too.

Craig


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, December 18, 2003 2:04 PM
> To: Struts Developers List
> Subject: Re: Struts EL Distro
> 
> 
> I agree, also each of the *.war files have a copy
> of the .jar files. Would it be acceptable to have a script or ant to gut
> the WEB-INF/lib directory of war files before distribution then reinsert
> them by running another script after they are unpacked by the user? The
> Distro would be less than 4MB if we did that. We could create another
> ant target that never assembles the war files in the first place, and
> another 'ant demo-war' command could package the already compiled
> *.class files of the app into a war.
> 
> 
> -Rob
> 
> > -Original Message-
> > From: David Graham [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, December 18, 2003 09:54 PM
> > To: [EMAIL PROTECTED]
> > Subject: Struts EL Distro
> > 
> > The binary Struts build includes struts-el in the contrib directory.  
> > Why does struts-el/lib include the commons-*.jars and JSTL jars?  The 
> > common jars are already distributed with the standard Struts build and
> 
> > the JSTL jars should be downloaded separately.
> > 
> > Considering the frequency of Struts downloads and our large 21MB 
> > distro size, removing these duplicate jars will save Apache a 
> > considerable amount of bandwidth.
> > 
> > David
> > 
> > __
> > Do you Yahoo!?
> > Free Pop-Up Blocker - Get it now
> > http://companion.yahoo.com/
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Ted Husted <[EMAIL PROTECTED]>:

> Craig R. McClanahan wrote:
> > For all three of the cases, though, we
> > probably want to invent a different term than "form bean" because that
> seems so
> > conceptually tied to presentation only.  Transaction Bean?  Input Bean? 
> Data
> > Transfer Object :-)?
> 
> InputHandler?
> 

That would certainly be an appropriate name for my type (3) form bean (that
included event handling), and perhaps even for a type (2) form bean that
includes some sort of hooks into validation.  It doesn't fit the type (1) style
that contains only data, though.

> -T.
> 
> 

Craig

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

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Mete Kural <[EMAIL PROTECTED]>:

> >I am thinking of fliping sides on FormBean as interface, I am now 
> >leaning against formbeans being an interface. FormBean is a concept 
> >(properties that map to form elements), plus this idea of XML as a 
> >FormBean. It could be a List or String or anything.
> 
> XML as a FormBean! That got my attention...
> 
> Say we want to populate customer information where a user can edit it like in
> an Excel spreadsheet. If the Action accesses a web service and receives a
> SOAP response and some XML objects in the SOAP response, sometimes it is too
> much processing to convert XML to Java objects if it is a lot of XML (for
> example: If the web service returns a list of 50 customers with detailed
> info). In such cases it may make more sense to do an XSLT transformation over
> the XML objects and render the form. Any suggestions on how this could be
> done in Struts 2.0?
> 

The key to this, IMHO, is the expression language used to bind a reference to a
field (say, in a JSP page) to some underlying data object representing the
field's value.

One very simple approach would be to teach BeanUtils and PropertyUtils how to
treat the "." operator differently when the base object is an Element (from the
DOM API) ... it would find a child element with an element name equal to the
"property name".  This would deal directly with any XML document totally based
on elements (as opposed to attributes), in a very simple (and mostly backwards
compatible) way, so it could therefore even be implemented in Struts 1.2.x.

A more comprehensive (but tied to XML) approach would be to support the use of
XPath for referencing elements and attributes in a DOM ... but ideally have a
way to access "trees of JavaBeans" using the same search expressions.  Tools
like commons-jxpath make that pretty easy to do as well.

If you can have pluggability in your binding expressions, you can adapt to
pretty much any internal data representation.  (That's one of the key reasons,
for example, that JavaServer Faces supports pluggable VariableResolver and
PropertyResolver implementations).

> Thanks,
> Mete
> 

Craig


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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Vic Cekvenich <[EMAIL PROTECTED]>:

> 
> 
> Craig R. McClanahan wrote:
> 
> > 
> > One of the things people have said they liked about using a chain to
> decompose
> > RequestProcessor is that you could easily compose your own chains, adding
> your
> > own custom processing stages and so on.  You can do exactly the same thing
> with
> > Filters by making each processXxx method its own filter, and using (say)
> the
> > request attributes to play the role of the Context object in
> commons-chain.
> > 
> > Filters have an additional capability if you're building a
> servlet-specific
> > framework -- they can wrap the actual request and response objects that
> are
> > passed on to the next filter in the chain, so you can implement some
> > interesting things not directly possible with a chain based implementation
> --
> > such as caching or on-the-fly compression of the response.
> > 
> > 
> > 
> > Craig
> 
> I do not get chains, but Hookom posted this link:
>
http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html
> 
> which I sort of get (sort of) and it's my favoirte chain impl.
> 

InterceptingFilter (as presented in the Core J2EE Patterns book) is very similar
to the way standard filters work in Servlet 2.3 (and 2.4).  The primary
difference from the way commons-chain works from the presented "Custom Filter
Strategy" is that a Filter cannot say "I have completed the response -- no need
to do anything more", which is exactly what you'd want for things like a "check
that the user has logged in" mechanism.

Doing chains the way that servlet filters do it (each filter explicitly calls
the next in the chain) would eliminate that problem, but has two potential
disadvantages:

* Somebody has to deal with the complexity of falling off the
  end of the filter chain (i.e. a FilterManager or something)

* You end up with a stack frame per Filter (if you've ever wondered
  why Tomcat's stack traces are so long, it's because the Valve
  architecture inside Catalina follows this same design pattern).

> So if we can use filters or other chain, somone clever could write an 
> "chainRequestProcessor" *interface*, that could be impledented for 
> JSP2.0 filter... and then somone else could later write a JSP 1.2 
> version, even non filter versions.
> 
> ?
> 
> So I like chain as interface, and action as interface.
> 

In commons-chain, the Context, Command, and Chain APIs are all interfaces.  You
can use one of the provided implementations and roll your own.

> I am thinking of fliping sides on FormBean as interface, I am now 
> leaning against formbeans being an interface. FormBean is a concept 
> (properties that map to form elements), plus this idea of XML as a 
> FormBean. It could be a List or String or anything. As long as it itself 
> does not do DAO, and it maps to a form, good. (but do have way to unit 
> test it w/o a container)
> For starters so the JSTL x: tag can be used instead of c:out, plus some 
> Stxx things.
> (Then maybe a way to make HTML tag submit XML Doc, multi row and all).
> 
> .V
> 

There's a couple of variations on the theme that are possible, but I can think
of at least three layers of something that might be called a "form bean" in the
conceptual sense:

(1) A set of typesafe field names and corersponding values
where the application doesn't have to worry about maintaining
values across requests.
- Variation:  dynamically add and remove fields as needed
- Variation:  allow non-typesafe fields
- Variation:  allow fields that can have multiple values (arrays)
- Variation:  represent data hierarchically instead of just
  a name-value map (bean properties, nested expressions,
  XML DOM, what have you)

(2) The above plus a mechanism to define validation rules (correctness
checks) on the field values that are independent of physical
presentation
- Variation:  hard coded logic for validations (i.e. the original
  validate() method in Struts ActionForms.
- Variation:  pointer to a configured set of validation rules
  that is abstracted from presentation considerations.  

(3) All of the above plus event handlers for UI events that change
the state of the field values -- perhaps in the same bean,
perhaps somewhere else.

A type (1) or type (2) form bean is really better thought of as an abstract way
to pass the input data for some sort of business transaction between tiers, or
within tiers.  A type (3) form bean would definitely live in the presentation
tier, and not be used between them.  For all three of the cases, though, we
probably want to invent a different term than "form bean" because that seems so
conceptually tied to presentation only.  Transaction Bean?  Input Bean?  Data
Transfer Object :-)?

Craig

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
> 
> > Quoting Vic Cekvenich <[EMAIL PROTECTED]>:
> >
> > > Craig R. McClanahan wrote:
> > > >
> > > > Regarding 2.x, an important consideration will be base technology
> platforms
> > > --
> > > > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE
> 1.4
> > > (i.e.
> > > > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> > > > presentation technology, etc.).
> > > >
> > >
> > >
> > > JDK 1.4, yes.
> > >
> > > One popular? goal mentioned was:
> > > "Get away from reliance on Servlet API"
> > >
> > > I like being on Tomcat 4.
> > > What does it gain to be Tomcat 5 technically?
> >
> > For the portions of the framework that depend on Servlet 2.4, you get two
> > modest
> > but useful features:
> >
> > * Ability to execute filters on RequestDispatcher.include and
> >   RequestDispatcher.forward calls, which is not possible in 2.3.
> >   This gives you additional degrees of freedom in how you organize
> >   the processing logic of a framework like Struts -- for example,
> >   it would now be technically feasible to implement the controller
> >   as a filter instead of a servlet.
> 
> It would certainly be technically feasible to do that, but are there
> practical advantages to doing so? The only thing I can think of is that
> it's easy to punt on a request and let something else (i.e. another filter
> or a servlet) handle it, but I'm not sure why I would want to do that. Any
> good examples?
> 

One of the things people have said they liked about using a chain to decompose
RequestProcessor is that you could easily compose your own chains, adding your
own custom processing stages and so on.  You can do exactly the same thing with
Filters by making each processXxx method its own filter, and using (say) the
request attributes to play the role of the Context object in commons-chain.

Filters have an additional capability if you're building a servlet-specific
framework -- they can wrap the actual request and response objects that are
passed on to the next filter in the chain, so you can implement some
interesting things not directly possible with a chain based implementation --
such as caching or on-the-fly compression of the response.

> --
> Martin Cooper
> 

Craig

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> I don't think I'm going to articulate this question very clearly, but 
> hopefully my drift will be gotten, so to speak.
> 
> If we're talking about making Struts independent of Servlets, then 
> what part of Struts would depend on either Servlet 2.3 or Servlet 2.4?
> 

Even if the core framework is independent of the presentation tier APIs, you
still need an adapter layer (often called a binding) between the particular
presentation API in use and the fundamental controller capabilities.  As I
pointed out in a previous message, I can see three very obvious bindings (to
servlets, to portlets, and to SOAP) that we'd undoubtedly want to include in
the basic package -- but we know we've succeeded when you can use the same
actions in each of those three environments (to perform the same transaction).

> Rather, how will we partition Struts so that we know our boundaries? 
> Presumably in a chain-like world, you could have Servlet 2.3 
> pre-processing chains and Servlet 2.4 pre-processing chains, and of 
> course we're going to have view post-processors for XSLT, Velocity... 
> so why shouldn't there be JSP 1.2 and JSP 2.0 post-processors?
> 

For servlet 2.3 versus 2.4, one approach to building frameworks would be to
architect the controller as a filter (or set of cooperating filters) rather
than as a servlet.  That is not a practical reality in servlet 2.3 because you
can't interpose filters on a RequestDispatcher call.

It's probably feasible to have a decomposed request processor that can be
implemented as either a set of filters (which, after all, is sort of the CoR
pattern again, just with different APIs) or as a servlet.  In practical terms,
though, it's easier to abstract the layers if we stick with a servlet as the
basic adapatation gadget.

The main reason I'm interested in J2EE 1.4 as the base platform is for JSP 2.0. 
But the choice between JSP 1.2 and JSP 2.0 should have zero impact on the
organization of the request processor -- it should be as totally an independent
decision as possible.  However, if you choose JSP 2.0 for the minimum platform
for JSP-based presentation stuff, you get servlet 2.4 for free to use in the
controller tier if you want.

> I suppose we ought to draft a glossary to make sure we all agree on 
> these various concepts...
> 
> Joe
> 

Craig





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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Vic Cekvenich <[EMAIL PROTECTED]>:

> Craig R. McClanahan wrote:
> > 
> > Regarding 2.x, an important consideration will be base technology platforms
> --
> > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4
> (i.e.
> > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
> > presentation technology, etc.).
> > 
> 
> 
> JDK 1.4, yes.
> 
> One popular? goal mentioned was:
> "Get away from reliance on Servlet API"
> 
> I like being on Tomcat 4.
> What does it gain to be Tomcat 5 technically?

For the portions of the framework that depend on Servlet 2.4, you get two
modest
but useful features:

* Ability to execute filters on RequestDispatcher.include and
  RequestDispatcher.forward calls, which is not possible in 2.3.
  This gives you additional degrees of freedom in how you organize
  the processing logic of a framework like Struts -- for example,
  it would now be technically feasible to implement the controller
  as a filter instead of a servlet.

* Ability to define request lifecycle listeners (like the older
  ones for session and application lifecycle) so you get a
  complete and consistent event handling model.

If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a
very large number of benefits.  The most visible ones are:

* New ***much*** simpler API for building tag classes
  (tag instance pooling is gone, single invocation method
  instead of doStart/doEnd, ability to define a tag that
  takes an arbitrary list of attributes, ...).

* Tag files -- essentially, the ability to write a tag handler
  using JSP code instead of Java, complete with parameter passing.

* EL expressions evaluated everywhere (even template text),
  so you don't need to limit yourself to just tags that implement
  support for it (meaning we don't need struts-el variants).

 What containers support 
> 2.4? How long for users to convert to the new 2.4 containers?
> It'd be limiting.
> 

The timing only matters when we're *done* with Struts 2.0, not now.  Based on
our past history, I'd bet we're talking 12-18 months before a production
quality release of 2.0 would be designed, developed, tested, and evolved to the
point where we were happy enough to call it (and the APIs inside it) "stable."

Because of how long it took for the J2EE 1.4 standards to go final (we were done
with servlet and JSP last summer, but had to wait for the web services
standards to go final), the various app server vendors are already well on the
way towards 1.4 compliance. (Sun's certified server is already available, and
is free for development AND production).  In the open source world, Tomcat 5
already has production quality support, of course, and Jetty at least is not
far behind (Greg is using Jasper2 for the JSP 2.0 stuff, so all he's got to do
is catch up on the servlet 2.4 changes, which are pretty modest).

> If it ends up being interface, so it could be even used from Soap or 
> applications (the discussed interface execute(Context ctx) ; ) it won't 
> matter much.
> 

I agree that execute(Context ctx) is the right sort of method
signature for the low level elements.  Come to think of it, that's already the
signature used in commons-chain :-).

> .V
> 
> ps: I would like light IoC to be considered just a bit more as platform, 
> Pico, Oscar. Not Spring or Avalon.
> 

All of these are interesting, but I think there's two levels of IoC that need to
be thought about:

* How the various pieces of Struts itself glue themselves together.

* How application level services are composed and made available.

It seems to me that different choices are possible at these two levels, and that
(if different) the former should be lighter weight than the latter.  But we
can't really pick particular technologies without having identified the needs
and use cases first.

Craig

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

Re: What about Struts 2.0 and JSF?

Quoting [EMAIL PROTECTED]:

> 
> Guys,
> 
>  I am wondering what is the relation between Struts 2.0 and JSF.

It should certainly be possible to use JavaServer Faces in your view tier of a
Struts 2.0 based app.

> Will Struts be an implementation of JSF specification?

That hasn't been articulated on the list of goals to date.  If we want an Apache
open source implementation of JSF, I would recommend it be done in a separate
project (certainly can be overlapping developers if existing Struts folks are
interested).

The Struts 2.0 design should probably take into account where JSF is going --
watch for additional news in that regard very soon -- so that integration can
happen in response to UI events from a JSF-based UI, but most of what we're
talking about for Struts 2.0 is actually in the controller, not the view.

> Will it be the "Reference
> Implementation" (UHUUU)?
> 

No.

Remember that "reference implementation" has a specific meaning for Java
standards, and the spec lead for a particular JSR is required to deliver the
corresponding RI -- In the case of JavaServer Faces (JSR-127), Sun is
delivering the RI.

There is a (mis)conception, for example, that Tomcat is the RI for the servlet
and JSP APIs.  That is not the case -- the official RI is the "J2EE SDK"
available at .  It happens to
*include* code from Tomcat, but this is the real RI.

> Stutz
> 

Craig


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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>:
[snip]
> > 
> > Although it's not evident from the Jericho DTD, the intention 
> > is to use 
> > a Context object in the signatures, perhaps the Commons Chain 
> > Context, 
> > so as to encapsulate Servlet/Portlet dependencies.
> > 
> 
> So you no longer going to pass in request and response objects
> around, but instead have a context instead. Maybe it would
> be a little inconvenient for every Action to call 
> ``context.getRequest()'' all the time. Perhaps we can keep them
> please. I dont mind losing the form bean. I could live with
> ``context.getForm()'', because for some environments you dont
> need to buffer a user's input. e.g. web services, or even 
> a flat file.
> 
> public ActionForward someStateAction( 
>   org.apache.commons.chain.Context  context,
>   some.generic.request  request,
>   some.generic.response response );
> 
> And for those of us who have subclassed Action, and ActionForm
> to create our own super frameworks, this will be very
> interesting and involved work to say the least/.
> 

If you're going to call context.getRequest() at all, then I think you're losing
most of the benefits of abstracting away the servlet APIs - if you want to be
able to reuse "actions" in the business tier then there *is* no such thing as a
request.  Instead, it would be better for a particular Command (for purposes of
this discussion, I'm assuming we use something like commons-chain as the
plumbing so I use that terminology; it would need to be translated for a
different low level API but the concepts sare still the same) that represents
the concept of an "action" to presume that some previous commands in the chain
have already pulled the presentation tier specific data out of whatever
"request" objects there were, and made it available as context attributes of
the appropriate (framework-specific) types.

For example, assume we created an abstraction of a form (what is now ActionForm)
to represent incoming data from the user.  Copying request parameters into this
abstract form thingie would be the job of a command very early in the chain. 
It's easy to imagine at least three commonly used lead-in actions:

* One that pulls request parameters from an HttpServletRequest (servlet api)

* One that pulls request parameters from a PortletRequest (portlet api)

* One that pulls request parameters from a SOAP request

The key value-add is that, once the lead-in command has performed this
transition for you, no further commands ever need to know that there *was* such
a thing as a "request".  Those commands would never call getRequest(), because
they don't care how the "form thingie" got there; it contains everything they
need to perform their tasks.  Therefore, you can reuse the processing command
in new and interesting ways -- just to whet the appetite, consider:

* In a unit test, where the test case synthesizes a "form thingie"
  with known contents, calls the processing logic, and ensures that
  the correct state changes happened.  No real "request" ever exists.

* In an integration app, where you want to have changes made in
  an existing application also affect data in a separate app.  One
  way to do that would be to synthesize more than one "form" from
  the same actual user input, and do all the necessary updates.
  The business logic for any single transaction has no need to know
  that it's being used in this new way.

* In a batch application (or a messaging appication, or ...) where
  the incoming data is acquired from data files rather than users,
  but you want the same sorts of state changes in your back-end systems.

The hard part (in terms of designing the framework) is to understand how to
factor the reusable concepts, and then what to name them -- on that topic, for
example, even the name "form thingie" might be a little bit to constraining
when imagining how the basic idea can be used in more than one context.

Craig


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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> Just to add a few more off the top of my head:
> 
> * Make the Struts core independent of the Servlets spec and the Portlets
> spec, so that it can be used for both, and more.
> 
> * Separate view-technology-specific code into separate components, so that
> the core is view-technology agnostic. So, for example, all JSP specific
> code, including all of the taglibs, would move to a JSP component.
> 
> * Rework Tiles into two facets, so that the core is independent of the
> Servlets spec and JSP, and the JSP component is part of the view specific
> component described above.
> 
> * Split out file upload handling into a separate pluggable component, with
> its own configuration. I noticed that this is still in the initial Jericho
> DTD, but I think it should not be. The file upload implementation is
> pluggable, and so should be able to have its own config definition.
> 
> I know I have more in notes at home, but just wanted to throw these out.
> 
> A sort of meta-question: When is Struts no longer Struts? I mean, how much
> change can we introduce in Struts 2.0 before it becomes so different that
> it's really a different framework? Do we need to decide on what Struts is,
> and is not, before we go too far down the path of Struts 2.0? Or do we let
> whatever falls out just fall out and deal with it later?
> 

Product names are marketing, not technology.  Struts 2.0 will be Struts if *we*
call it Struts :-).

More seriously, the amount of change between major product versions can be
pretty enormous in some cases (ask classic ASP developers if they think ASP.NET
is really the same environment or not).  Innovation and revolution are
perfectly fine things to do (applying all the lessons we've learned along the
way), but we should also remember that there are thousands of apps based on a
Struts 1.x architecture that need continuing support.  We need to have the
discipline to continue to work evolving a 1.2.x world while we're creating a
new 2.x one.

Regarding 2.x, an important consideration will be base technology platforms --
I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e.
Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the
presentation technology, etc.).

> --
> Martin Cooper
> 

Craig


> 
> On Wed, 17 Dec 2003, Don Brown wrote:
> 
> > Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> > release work. :)  I'll throw out some ideas here, then develop them later
> > in the wiki:
> >
> > - Make Inversion of Control central.  By using an IoC framework to wire
> > Struts together, it makes it really easy to extend or improve Struts not
> > only for future development but for users as well.  I'd recommend Spring's
> > IoC impl as it is small (>100k), really easy to use, and easily
> > extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> > frameworks that let you plug in Pico/Spring/Avalon, etc.
> >
> > - Use XML Schema over DTD's.  Give struts config its own default namespace
> > to make it easier for users to mix in elements of other namespaces.  An
> > example would be adding custom documentation attributes and elements.  Of
> > course the usual arguments for XML Schema over DTD's apply as well.
> >
> > - Replace paths with URL's, allowing for a default protocol.  An action
> > path would look like "action://foo" or a tiles forward would be
> > "tiles://tilesdef"  This would make it easy to plug in handlers to support
> > different presentation engines.  If no protocol is specified, the path is
> > handled as usual.
> >
> > - As Ted said, contine with the wildcard theme.  Struts should do
> > everything possible to cut down configuration.
> >
> > - Also, again totally agreeing with Ted, make everything interface based,
> > have default implementations, and free apps of HTTP.  Ideally, I'd like to
> > see extra effort going into making it easy if not effortless to take a
> > Struts 2.0 app and use the code in a portlet or web service environment.
> > At least in my area, clients are wanting human and machine interfaces,
> > with the human interface generally being behind a portal.
> >
> > Anyways, those are my "brainstorming" thoughts.  If any look interesting,
> > I'll write something up in the wiki.
> >
> > Don
> >
> >
> > -
> > 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: [VOTE] 1.2.0 Release Plan

2003-12-16 Thread Craig R. McClanahan

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> The issue isn't so much with voting on the relesae plan, but voting on the
> release itself. As you say, the HTTPD rules say that anyone can create a
> release. We're not HTTPD, though, and the Jakarta rules are different. As
> long as we're part of Jakarta, we need to abide by the Jakarta rules.
> 
> Under "Decision Making", in the section on "Release Testing", is the
> following statement:
> 
> "Majority approval is required before the release can be made."
> http://jakarta.apache.org/site/decisions.html
> 
> So, we do need to vote on each and every release.
> 

The Tomcat folks do indeed vote on every release -- they just do things in a
little different order:

* Post what amounts to a release candidate and
  announce to a limited audience (dev and user
  lists) asking for testing.

* Testing ensues ...

* Call a vote on the release, with the options
  to call it alpha, beta, stable (that's fine
  with me), or withdraw (if there was some
  bad problem).

* Announce to the world and do the usual process
  of distributing the bits.

The same approach would work for us, and IMHO meets the Jakarta requirements
with one additional wrinkle -- the Jakarta PMC needs the opportunity to vote on
releases as well, to be consistent with the current ASF reqirements.

+1 on the 1.2.0 release plan, by the way.

> --
> Martin Cooper

Craig

> 
> 
> 
> On Tue, 16 Dec 2003, Ted Husted wrote:
> 
> > With this proposal, I took a middle ground. The initial minor release
> > (x.x.0) in a series called for a vote on a plan, but a plan would be
> > optional for additional releases in the same series (1.2.1, 1.2.2, ...).
> > So, we wouldn't have to vote on a plan again until we get to 1.3.0 or
> > 2.0.0.
> >
> > The rationale is that starting a new series (1.2.0 versus 1.1.0) is a
> > decision upon which we should have a formal consensus. After that,
> > issuing additional point releases in the same series can be "business as
> > usual" .
> >
> > Of course, this is just a vote on the plan. Once we roll the release,
> > there would be another vote on whether to take that specific entity from
> > Alpha to Beta and/or General Availability. (Though, personally, I prefer
> > the more common "stable" designation to GA.)
> >
> > Of course, as the HTTPD guidelines point out, under the Apache License,
> > anyone can distribute a release of our codebase. It's just a matter of
> > whether it can be called "Struts" or not. :)
> >
> > -Ted,
> >
> > Martin Cooper wrote:
> > > +1
> > >
> > > I've added myself as an RM, since I'll be available to help. I can take
> on
> > > the tag, roll, sign and announce part, if you like.
> > >
> > > One thing I'd like to point out, because it came up in Commons, is that
> > > the HTTPD process and the Jakarta process are not 100% compatible. In
> > > particular, the Jakarta rules require a vote, while the HTTPD rules do
> > > not. I suspect that this vote may be sufficient, but I'll check when I
> get
> > > a chance.
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > On Tue, 16 Dec 2003, Ted Husted wrote:
> > >
> > >
> > >>I've amended the date on the (now venerable) 1.2.0 release plan for this
> > >>  weekend.
> > >>
> > >>http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html
> > >>
> > >>I believe the release notes are in good shape now. I already marched
> > >>through most of the stale 1.0/1.1 tickets, and can mop up the rest in
> > >>short order. I imagine there will be a few patches that we can apply,
> > >>but I've carved out some time to work on such.
> > >>
> > >>Note that I've left room in the release plan for the idea of multiple
> > >>managers. If someone were up for sheparding the tests, especially the
> > >>example application testing, I'd welcome the help. Someone else could
> > >>also sign up for the final tag, roll, and announce part of the job. Of
> > >>course, if everyone is busy, I'll be happy to muddle through on my own.
> :)
> > >>
> > >>Since this is a x.0 release, the plan calls for a majority vote.
> > >>
> > >>Here's my +1
> > >>
> > >>-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, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 




-
To unsubscr

Re: Test Case Exception Throwing style (Re: Cactus tests)

2003-12-11 Thread Craig R. McClanahan

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> On Thu, 11 Dec 2003, Ted Husted wrote:
> 
> > James Mitchell wrote:
> > > So, for now I just commented out those few lines and now the tests pass
> > > completely under tomcat 4.0, but under 4.1 it fails randomly with:
> >
> > Personally, I am in favor of dropping the tests for TC4.0 and only
> > testing against Tomcat 3.3 and Tomcat 4.1, which are the reigning
> > Reference Implementations for Servlet 2.2/2.3. Even Tomcat itself has
> > relegated 4.0 to the "archives".
> 
> I'd be +0 on dropping Tomcat 4.0 testing.

I'm +1 on that -- 4.0 isn't actively supported any longer by the Tomcat folks.

> However, we might want to start
> testing against Tomcat 5.0, now that a stable release is available:
> 
> http://jakarta.apache.org/site/news.html#20031203.1
> 

I'm definitely +1 on that.

> --
> Martin Cooper
> 

Craig


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

Re: [VOTE] Joe Germuska as a Struts Committer

2003-12-08 Thread Craig R. McClanahan

Quoting Martin Cooper <[EMAIL PROTECTED]>:

> Joe has been involved in the Struts community for some time now, and has
> been a great contributor on the -dev and -user lists, as well as in the
> bug database. I believe Joe would be a great asset to the team, and that
> it's time we invited him to join us as a Struts committer.
> 
> Here's my +1.
> 

+1

Craig

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




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

Re: Maven test run

2003-12-06 Thread Craig R. McClanahan

Quoting Joe Germuska <[EMAIL PROTECTED]>:

> On Nov 28, 2003, at 3:08 AM, Steve Raeburn wrote:
> 
> > I've updated project.xml to reference the validator 1.1.1 jar. You need
> > to manually download it from http://www.apache.org/~rleland/ and place
> > it in your local repository.
> 
> Would it be a good idea to make an alternate JAR repository for Struts  
> so that this step can be automated without depending on the iBiblio  
> managers?  It's trivial to do in Maven -- in fact, now that I look, I  
> see that it's configured in the "project.properties" file, but that  
> line is commented out:
> 
> #maven.repo.remote=http://www.ibiblio.org/maven/,http:// 
> jakarta.apache.org/struts/repo
> 
> Any reason not to set that up so that it works?
> 

FWIW, an Incubator project to set up a formal Apache repository (Ruper) is just
in the startup stages.  Among other things, this will include covering the
policy issues around publishing JARs into such a repository (which, after all,
is effectively a release vehicle and therefore needs the same sort of
management as the release directories do), and the possibility to leverage the
mirrorring architecture.  The initial focus is *not* going to be on tools that
manage the repository, but I'm sure you'll see any necessary changes added to
things like Ant and Maven in short order.

Anyone interested in participating in this effort is encouraged to join the
Incubator related mailling lists (start at http://incubator.apache.org and the
[EMAIL PROTECTED] mailing list).  In the mean time, though, I would
suggest that we *not* try to create a Struts-specific repository that would
quickly become redundant.

If a short term action is needed to avoid dependence on ibiblio, we could pretty
easily document how to set up and populate your own local repository.

> My big project is out the door, so I'll try to sneak in some time  
> catching up with Struts and Maven stuff before things get away from me  
> again...
> 

Your help on the Maven configuration and build scripts is much appreciated!

> Joe
> 

Craig

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

Re: Feedback on the Dec 1 nightly build

2003-12-02 Thread Craig R. McClanahan

Quoting David Graham <[EMAIL PROTECTED]>:

> 
> --- stu robertson <[EMAIL PROTECTED]> wrote:
> > First, thanks for the quick followup last week on the
> > readyness of builds including ValidWhen.  I started
> > testing our application against this build this
> > morning.
> > 
> > The one would-be showstopper for us (although we work
> > around it) is that the current snapshot of
> > commons-collections has a number of serialization
> > bugs.  We're using decorators fairly extensively for
> > type-safety.  Since they're not serializable, they
> > cause NotSerializableException when returned from
> > stateless session EJBs.  We're currently using a
> > collections 3.0 build that we've modified to make
> > these serializable.  But the Struts 1.2 nightly comes
> > with the broken version.
> 
> Why are we distributing nightly builds of commons components that we rely
> on?  IMO, unless we need the very latest features of commons package X we
> should ship nightly Struts builds with the last released version of X.
> 

Historically, we've done this so that active Struts development could have
dependencies on latest-and-greatest (but unreleased) commons code, without
having to wait for a commons package release.  It would be pretty fragile to
try to make a latest-and-greatest versus latest-released choice on each
individual library; it seems a lot more sane to establish a single policy for
all dependencies.  However, I can take a shot at finer-grained decision making
once I get back home (in Europe this week for JavaPolis; a large user group
conference Wednesday and Thursday in Antwerp) this weekend.

AFAICT, neither choice is going to help Stu's situation, because it sounds like
there is no released or nightly version of commons-collections that (yet)
includes his patches.

> David

Craig

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

Re: Stable nightly build including ValidWhen change?

2003-11-25 Thread Craig R. McClanahan

Quoting Ted Husted <[EMAIL PROTECTED]>:

> When we release 1.2.0, it will be the current nightly build,

Except that's still based on non-released versions of the commons packages,
right?  Shouldn't a 1.2.x Struts release be based on the most recent releases
of the commons JARs?

> which we 
> consider stable. Since 1.1, the big items have been removing 
> deprecations, updating the Validator, and wild-card ActionMapping paths.
> 

If we wanted to do things the way that the Tomcat folks do (which seems
reasonable), we'd post it (with limited announcements, probably struts-dev and
struts-user only) as a "test" build, then wait a few days and hold a vote on
what quality ranking to specify (alpha, beta, stable, or withdrawn if it has a
fatal flaw).  Only after that vote would it get posted onto the normal
distribution cycles and Apache mirrors.

Don't forget to copy [EMAIL PROTECTED] on all releases (test or
otherwise).

> -Ted.

Craig

> 
> stu robertson wrote:
> > I'd like to start using the new validator
> > functionality which according to
> > http://jakarta.apache.org/struts/userGuide/dev_validator.html
> > is already in place, awaiting the next release.
> > 
> > Is there a particularly stable/least risky nightly
> > build I should go with?  Are there any significant
> > changes I need to look out for?
> > 
> > Any informed input would be greatly appreciated.
> > 
> > Stu
> > 
> > __
> > Do you Yahoo!?
> > Free Pop-Up Blocker - Get it now
> > http://companion.yahoo.com/
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> -- 
> Ted Husted,
>Junit in Action  - ,
>Struts in Action - ,
>JSP Site Design  - .
> 
> 
> 
> -
> 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: [Nightly Build] Validator

2003-11-25 Thread Craig R. McClanahan

Quoting Robert Leland <[EMAIL PROTECTED]>:

> Craig:
>The Nightly build of Struts(Nov 24th) has a version of Validator from 
> Nov 8th,
>could you update the of commons-validator build to pickup the latest 
> changes?
>These changes deal with not validating disabled fields.
> 
> -Rob
> 

Tonight's nightly should pick up today's builds of the commons packages.

Craig


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

Re: cvs commit: veto

2003-11-13 Thread Craig R. McClanahan

Quoting Ted Husted <[EMAIL PROTECTED]>:

> -1
> 
> The community can make up its own mind on issues regarding an 
> individual's behavior.
> 

Like any commit to change software, other committers can -1 them for valid
reasons.

> I formally ask that any product changes made for the sole purpose of 
> censoring an individual be reversed, with the exception of consultants 
> and powered, which pages can be removed completely as they are obsolete.
> 

My view of Vic's technical judgement and capabilities is probably pretty clear
from prior message threads.  His behavior in other forums recently, and this
time in particular (presuming that an allegation is true without a
determination of the actual facts, and then presenting it as reality instead of
perception) is ethically repugnant to me, and calls his professional judgement
into question.  This is so to the degree that I cannot in good conscience
participate in a project willing to publish links to companies whose principals
behave in such a manner.

To address Ted's (legitimate) concern, I would prefer that we adopt a more
stringent (but one that can be administered based on reasonably objective
criteria) policy on Struts website content -- no advertisements of *any*
commercial resources related to Struts.  Google does a far better job than we
could ever do in making such resources available, and this would avoid the need
for any judgement calls or unfair advantage to some commercial entities over
others.  Announcements about nonprofit activities (user group meetings), freely
available presentations/demos/slides about Struts, or other open source
software that works with Struts, would still be reasonable candidates for
inclusion.

Note that I'm suggesting this approach just for the website (and therefore the
snapshots that get included in the product by virtue of the way we create
struts-documentation.war).  The current policy towards postings on the mailing
lists can remain the same -- the distinction is that it is clear who is
speaking
(presuming it's not an email virus forging the from address :-), and there is
no opportunity for mistakenly assuming endorsement.

Implementing this policy would require a few more excisions to the Struts web
site (and save Ted some work in the long run, since he does most of the
"routine update" work), but not horrendously large amounts.  The most visible
change would probably be the list of books on the front page and the associated
books.html page, since they are all commercial activities.

I agree with Ted on the "consultants" and "powered" pages.

Ted, would this deal with the criteria of your -1?

> -Ted.

Craig


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

Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

2003-11-13 Thread Craig R. McClanahan

Quoting Jonathan Revusky <[EMAIL PROTECTED]>:

> [snip]
> First of all, as regards your statement above in which you refer to 
> "someone else's website", I parse this to mean that you consider the 
> jakarta.apache.org/struts website to be _yours_. As a matter of fact, it 
> is not. It belongs to the Apache Software Foundation, a non-profit 
> entity set up with a certain charter and that has received support from 
> various organizations.

You are parsing the sentence in a manner that was not intended.  That's your
problem, not mine.

However, it's interesting to note that from a legal perspective, the Struts web
site *is* my site, along with Ted Husted and the other 100-odd Members of the
Apache Software Foundation, who jointly own all of the intellectual property,
software, and web content you see at apache.org.  Therefore, if I *had*
intended the interpretation you parsed, it would have been perfectly within my
legal rights to do so.

However, here at Apache, we treat website content like we do any other change to
the software.  In particular, changes are subject to post-commit -1s for
reasonable concerns (and Ted's is -- see next response).

Craig McClanahan
(Among other things) Member, Apache Software Foundation


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

Re: [struts-chain] Where to now?

2003-11-12 Thread Craig R. McClanahan

Quoting Don Brown <[EMAIL PROTECTED]>:

> I added what I gathered was the last missing piece to struts-chain, file
> upload support.  I'm really interested in doing whatever it takes to get
> this up and running as a viable alternative to the RequestProcessor.
> 

Cool!

> >From here, I see the following needs to be done:
> 
>  - Unit tests (big one)

Here is where the chain's nature is going to help -- it's pretty straightforward
to write unit tests for each individual command, call the execute method, and
evaluate the results, because most commands simply perform some transformation
on the information in the Context being passed around.

>  - Tiles support

Definitely going to be needed for a production release.

>  - Portlet implementation

Yep.  In my "copious spare time" :-) I'll try to download Pluto and start
playing with this.

>  - Documentation
> 
> What is the status of commons-chain?  Are there any outstanding issues
> that need to be sewn up?
> 

There are no outstanding bugs that I'm aware of.  Unit test coverage is
currently not all there, and the Portlet and Faces implementations of
WebContext still need to be fleshed out.

> I think I will tackle the unit tests next.  Tiles support should be pretty
> straightforward, some copy/paste.  Craig had some ideas of how to support
> the Portlet API, which I'll leave to him until I can learn more about it.
> The documentation is the least important, at this stage, but it does help
> bring to light rough spots.
> 
> Finally, what is that status on Struts 1.2?  Could an early test version
> be put in for early adopters?
> 

One thing we'd talked about doing early in 1.2 was switching to
commons-resources (which is also currently in the sandbox and would need to be
promoted along with commons-chain).  If we're going to do that (and I think we
should), it should really be before the first 1.2 release.

commons-resources is pretty solid as well, but a JDBC-based resources
implementation included out of the box would be really really handy.

> Don
> 

Craig


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

Re: [struts-chain] Some ideas

Quoting BaTien Duong <[EMAIL PROTECTED]>:

> [snip]
> In fact, that is what we are attempting to do. For any atomic process, i 
> think there are 3 repeatable components: data collection, rule analysis 
> based on collected data, and desion based on the analysis. I am planning 
> to build these re-useable components based on the chain filter. I  hope 
> this will stimulate the interest in the chain of commands.
> 
> I am also looking forward to the chain of commands applied to portlet, 
> especially:
> 1) the modeling of 2 chains: 1 for portlet action and 1 for portlet 
> render using the same context
> 2) the passing of data fron Struts ServletWebContext to 
> PortletWebContext to PortletRequest and PortletResponse that will be 
> used on top of Pluto portlet container.
> 3) the passing from portlet action to the business processor chain 
> so a different business chain is used in the business layer.
> 

If we do things correctly, most commands in the chain will not need to know
whether they are in a servlet or portlet environment.  For example, if you take
advantage of the 'requestScope" property I described earlier in this thread
will hide the distincition -- it gets attributes from an HttpServletRequest if
you're in a servlet based webapp, or PortletRequest if you're in a portlet
based app.

In the same way, the fact that portlet requires two chains instead of one should
be invisible to the individual commands themselves -- that only has to be paid
attention to by the outermost controlling layer.

Providing abstractions (request attributes are just a Map) in the Context object
being passed around is one of the key ways that the chain pattern facilitates
reuse of commands.

> Many promissing uses can be happened.
> 
> BaTien
> DBGROUPS

Craig


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

Re: [struts-chain] Some ideas

Quoting Konstantin Shaposhnikov <[EMAIL PROTECTED]>:

> Thank you for quick response and your ideas about the
> implementation. 
> 
> But can I ask you why I can't use the second
> approach with struts 1.1. I explore struts-chain code once
> again and found that I only need to change 1 Command in
> servlet-standard chain. 
> 

You can certainly customize the chain if you want to use it with Struts 1.1, but
that means you are playing with unreleased code and having to live with
whatever restrictions exist (for instance, file upload is not currently
supported in the existing chain definitions).

I am imagining a day where we'd build the standard RequestProcessor for Struts
1.2 on top of the chain implementation.

> And what means "provided for backwards compatibility with
> Struts 1.1" ? Will the next release replace Actions with
> something else?
> 

One of the key things people would look for from Struts 1.2 is a relatively easy
migration of existing Struts-based apps.  Therefore, it would seem best for us
to be able to call an app's existing Action classes (as the current
struts-chain implementation does).

In a future world solely based on chain, you wouldn't need the idea of an Action
class at all.  Instead, you'd map the  element in struts-config.xml to
the name of a chain, which could either be a single Command or a series of
Commands -- Struts would not care.  In this environment, there would still be a
standard set of commands in the standard chain, to do all the standard stuff
(like populating a form bean, performing validation, and so on).  But the
thinking is that the app's business logic would be built out of chains as well,
which can (of course) be arbitrarily complex in their internal structure.

Among other things, this would allow people to not have to attempt to use
"action chaining", which today causes surprising results.  Instead, you could
build little two-Command chains -- the first would process the form submit, and
the second would do the appropriate setup for the next page to be displayed. 
Because these two behaviors would be separated, you could reuse either or both
of them (for example, cases you need to forward to a particular page from more
than one place, and perform the same setup behavior each time, could share the
second command.

> best regards,
> Konstantin
> 

Craig


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

Re: [struts-chain] Some ideas

Quoting Konstantin Shaposhnikov <[EMAIL PROTECTED]>:

> Hello all.
> 
> If I understand corretly struts-chain package is used for
> modelling struts RequestProcessor using jakarta-commons chain library.
> 

That is definitely *one* use case for the chain of responsibility pattern.

> When I've had heard this name I actually thought that this
> package is for composing struts actions as chain of commands
> and was very surprised when I found something different.
> 
> So I what to know what do you think about described idea
> (define struts actions as chain of commands). I think that
> such functionality can be very usefull. Any comments
> are welcome. 
> 

It certainly makes a lot of sense.  For this purpose, you could do one of the
following:

* In a Struts 1.1 world, create an Action that knows how
  to set up an appropriate WebContext and delegate its work
  to an appropriately named chain.  Such an Action class could
  be parameterized so it was reusable for any chain-based
  definition of the required logic.

* In a Struts 1.2 world (where, presumably, we base the actual
  Struts RequestProcessor on commons-chain), you could customize
  the standard processing chain to insert application specific
  logic anywhere you need it, and/or replace the command that
  executes a "real" Struts Action (provided for backwards
  compatibility with Struts 1.1) with a call to an application
  specific chain instead.

Even outside the web tier, you might find the commons-chain impementation of the
Chain of Responsibility pattern useful as well.

> best regards, 
> Konstantin
> 

Craig


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




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

Re: cvs commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml

Quoting Vic Cekvenich <[EMAIL PROTECTED]>:

> Was that called for Craig?

Yep.

> Maybe putting in the4 context of ... ASF was accused of stealing 
> designs, and Vic decided to presure ASF?
> 
> http://www.mail-archive.com/general%40jakarta.apache.org/msg08432.html
> 

Feel free to go make your case on someone else's website.

Craig

> 
> >   Vic Cekvenich of BaseBeans.com has made it clear in public postings that
> >   he is ashamed of using Struts, and has engaged in an attack on the
> proper
> >   behavior of the Apache Software Foundation's Board of Directors.  In
> these
> >   circumstances, it would be hypocritical for BaseBeans to benefit from
> the
> >   free advertising value of being visible on the Struts web site.  Help
> them
> >   out of this conundrum by removing such references.
> >  
> 
> .V
> 
> 
> 
> -
> 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: Conversion to ToStringBuilder

2003-11-08 Thread Craig R. McClanahan

Quoting David Graham <[EMAIL PROTECTED]>:

> I think we inherit the dependency on commons lang from some other
> component.  Our use of lang's features is very limited and my preference
> is to keep it that way.  Regardless, toString() is easy to implement
> without ToStringBuilder.
> 

Last time I looked, ToStringBuilder was the only  dependency we have on
commons-lang.  I'd much rather do a little more work in our toString() methods
and dump the dependency if that's actually the case, unless there's some
compelling need for any of the other c-l methods.

> David

Craig


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

Re: DO NOT REPLY [Bug 24202] - Javascript validation fails for single radio and single checkbox

2003-10-31 Thread Craig R. McClanahan

[EMAIL PROTECTED] wrote:

I'm having horrible visions of someone doing a query driven voting
application using radio boxes...
 

AHA!  So *that* is how the old communist regimes always got 99.9% 
positive votes in their "elections" ... :-)

Craig



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

Re: JSR-168 and Struts

2003-10-29 Thread Craig R. McClanahan

Don Brown wrote:

Pretty much the only dependency of struts-chain is a recent build of
jakarta-commons-sandbox/chain.  To fully build commons-chain, in addition
to other commons jars, you need the porlet api jar, the servlet jar, and
the latest jsf jar from the sun web services pack 1.3 I believe.  However,
you should be able to build commons-chain with one of these jars missing
if you don't need their related chain classes.
Currently, struts-chain implements most of Struts functionality in the
form of small commands, strung together by chain-config.xml.  For any
commands that would have a use outside servlets, there exist abstract
classes in org.apache.struts.chain in the form of Abstract*.java  which
perform all possible tasks without accessing servlet apis.  The abstract
commands are implemented in o.a.s.c.servlet by servlet specific commands
which handle all direct servlet contact.
To make struts-chain work with the portlet api, a new package will be
created, o.a.s.c.portlet, which will contain implementations of the
abstract classes in o.a.s.chain.  These commands will take the context,
cast it into a PortletContext (I believe that's the name), and access
portlet apis directly just as the servlet commands did.
These commands, particularly the api dependent ones, are very short and
should be very easy to port.  Of course Struts in a portlet context will
use a different chain-config.xml with commands pointing to the porlet
implementations rather than the servlet ones, but it should pretty much be
the same structure and behavior.
 

All of the above will be needed, but there's a couple of additional 
wrinkles to the portlet environment that are going to be interesting:

* Portlet doesn't let you do a RequestDispatcher.forward(), which is
 the normal way that Struts passes final control to the JSP or other
 resource that renders the response.  I suspect we can deal with this
 by using RequestDispatcher.include() instead.
* Portlet divides the lifetime of a request into two phases ("processAction"
 and "render") -- in a Struts world, that roughly corresponds to everything
 before the processForwardConfig() call and the processForwardConfig()
 itself.  I suspect this is probably best modelled as two separate chains
 (but both executing on the same Context instance, so stuff accumulated
 during processAction is available during rendering) but haven't thought it
 all the way through yet.
I'm new to struts-chain, so hopefully this is an accurate description of
the current state of struts-chain and how the portlet api will be
supported.
Don

 

Craig


On Wed, 29 Oct 2003, Mete Kural wrote:

 

Hello Struts and Pluto developers,

There was a thread about developing JSR-168 support into Struts 2.0 in the pluto-dev list and we thought it might be best to continue this thread on both lists, pluto-dev and struts-dev synchronously. Below is the last email in the thread send by Scott Weaver to the pluto-dev list. Please "reply all" so that your emails will go to both groups.

Thanks,
Mete
Scott's message:

-- Original Message --
From: "Weaver, Scott" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date:  Wed, 29 Oct 2003 15:33:03 -0500
Hi Martin,

   

-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 3:16 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Pluto and Struts
On Wed, 29 Oct 2003, Weaver, Scott wrote:

 

Maybe it's just me, but I tried to build the contrib stuff in the CVS
   

for struts a while back as I wanted to start taking a look at.  However, I
could never get it built.  There were deps I had never heard of, nor did I
know were to get them.
If you could let me know what you're having problems with, I'll try to
help you through getting it all built. The chances are that anything you
haven't heard of comes from Jakarta Commons or the Commons Sandbox. (For
example, 'chain' is currently in the sandbox.)
 

I know most of the stuff in commons proper, I don't think that's were my issue lies.  I am pretty sure it was chain that I couldn't find and, at the time, I am not sure it was available, even within commons-sandbox.  I don't remember the specific issues as this was around 2 months ago when I last tried.

   

I was actually having the same problem but from the other side of the
coin, as it were. I need to build 'chain' against the Portlet API, but I
couldn't get Pluto to build, and couldn't figure out the deps for that.
(BTW, since Pluto's build.xml depends on ant-contrib, '-projecthelp'
doesn't work until that's configured, which is quite mysterious until you
look at the build file itself. ;)
 

Try "build driver", there are custom ant tasks that get included when you call the "build" script.

I really don't do much at all with Pluto portal implementation in that my focus, concerning Jetspeed, is the core Pluto container itself.  That is were I spend most of my time in regards to Pluto.

That bein

Re: Session-scoped forms and synchronization...

2003-10-27 Thread Craig R. McClanahan

Bob Lee wrote:

I looked at the latest source and it doesn't appear to synchronize. 
Though you could fix this using a custom RequestProcessor, I think it 
qualifies as a bug.

First, it should synchronize form creation. Right now more than one 
instance of a session-scoped form can be created.
Well, you can get more than one *created*, but only one will actually be 
stored as a session attribute if the attribute name is the same.  
Synchronizing the session.setAttribute() method would be pointless; the 
container guarantees that this won't break anything.  So, exactly what 
portion of the code would you propose to synchronize?

Second, it should synchronize access access to session scoped forms. 
Right now, an action can be working on a session-scoped form while the 
RequestProcessor is populating the same form with properties from a 
concurrent request.

If you guys agree, I will fix the default RequestProcessor and submit 
a patch.

Feel free to submit a patch, but I'm betting the performance cost of 
implementing it will be horrendous.  If you're concerned about multiple 
simultaneous requests, you should really be using request scope form 
beans anyway.

Thanks,
Bob
Craig

Bob Lee wrote:

Does Struts synchronize on session-scoped forms? For example, can I 
assume that Stuts won't modify the fields on a session-scoped form in 
response to one request while an action is still using it?

Someone on the user list says that it does not.

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


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




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

Re: cvs commit: jakarta-struts/contrib/struts-chain/src/java/org/apache/struts/chain/servlet AuthorizeAction.java RequestNoCache.java SelectForward.java SetContentType.java

2003-10-24 Thread Craig R. McClanahan

Don Brown wrote:

On Fri, 24 Oct 2003, Craig R. McClanahan wrote:

 

Welcome to the "Chain Gang" Don!  :-)
   

With a snappy name like that, we should t-shirts printed up :)

 

:-)

I noticed that your implementation of AuthorizeAction does the same
thing that the current Struts RequestProcessor does if authorization
fails -- sends a "Bad Request" (status 400) message back.  One thing we
might consider instead is throwing a Struts-defined authentication
exception, which would allow the exception handling mechanism to decide
what to do instead.
One nice feature of using the chain approach is that the exception
handler (o.a.s.c.ExceptionCatcher) can handle exceptions thrown by
*anything* that executes after it is installed in the chain, not just
exceptions thrown by Actions.  This allows us to use exceptions to
enable application-defined handling of lots of exceptional events from
the framework as well, rather than simply throwing a 400 response.  In
addition, sending a 400 isn't going to be possible in a portlet world
anyway, so we might as well start thinking about what to do instead, and
make it consistent in servlets as well.
What do you think?
   

Good point.  I could have it throw an UnauthorizedException which is
handled by UnauthorizedExceptionHandler in the servlet-exception chain
before ExceptionHandler.  This of course would entail creating
o.a.s.c.AbstractUnauthorizedExceptionHandler,
o.a.s.c.UnauthorizedException, and
o.a.s.c.s.UnauthorizedExceptionHandler which kinda seems like a lot of
code for one line in the case of a servlet environment.
 

I agree that we would need the exception class, but why do we need 
anything other than the standard handler (o.a.s.c.ExceptionCatcher)?  It 
fires off an exception handling chain, and the default handler there 
already looks at your  settings in struts-config.xml to 
figure out what to do for any arbitrary exception class.  It's up to the 
app to handle UnauthorizedException however it wants, just like it's up 
to the app to handle an SQLException (or any other type, for that 
matter) returned from an Action.

While we're at it, there are a few other places where Struts 1.1 returns 
an HTTP error; they should be evaluated for being treated the same way 
in a chain-based request processor.

From how I understand it, as it stands, in a portlet environment, a whole
new chain config would have to be used anyways due to most implementing
classes depending on servlet apis.  Therefore, to handle an unauthorized
case for a portlet, the only addition code would be a different
AuthorizeAction implementation, which would need to be provided anyways.
That said, I think throwing an exception is the more logical choice, but
it does add several more classes with little functional improvement.  Of
course, this is really a trivial part to the whole chain so whatever
you think is best, I'll code it up :)
Don

 

Craig



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

Re: [struts-chain] More actions, but hit a snag

2003-10-24 Thread Craig R. McClanahan

Don Brown wrote:

I've tried to fill in some of the missing pieces in the struts-chain as
described in chain-config.xml.  The new actions have pretty much a
one-to-one relationship with RequestProcessor methods.  Some seemed pretty
trivial, RequestNoCache and SetContentType in particular, so maybe they
could be combined into one controller config action, but for now, I
figured I'll make them their own actions as it is always easier to combine
than explode.
I hit a snag using the example app when logging in.  It seems the
logonForm is getting instantiated somewhere other than CreateActionForm
and doesn't have its servlet property set, throwing an exception in
validation.  Perhaps it's right under my nose, so I'll look into it.
Other than that, it's running smoothly and I am really looking forward
to using the chain. :)
Don

 

I will try to look at this over the weekend.  Did it work for you before 
your recent changes?  It did for me.

Craig



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

Re: cvs commit: jakarta-struts/contrib/struts-chain/src/java/org/apache/struts/chain/servlet AuthorizeAction.java RequestNoCache.java SelectForward.java SetContentType.java

2003-10-24 Thread Craig R. McClanahan

[EMAIL PROTECTED] wrote:

mrdon   2003/10/23 19:35:02

 Modified:contrib/struts-chain/src/conf chain-config.xml
 Added:   contrib/struts-chain/src/java/org/apache/struts/chain
   AbstractAuthorizeAction.java
   AbstractRequestNoCache.java
   AbstractSelectForward.java
   AbstractSetContentType.java
  contrib/struts-chain/src/java/org/apache/struts/chain/servlet
   AuthorizeAction.java RequestNoCache.java
   SelectForward.java SetContentType.java
 Log:
 Adding in some missing pieces.  Pretty much straight one-to-one mappings of
 RequestProcessor methods to chain actions.
 
 

Welcome to the "Chain Gang" Don!  :-)

I noticed that your implementation of AuthorizeAction does the same 
thing that the current Struts RequestProcessor does if authorization 
fails -- sends a "Bad Request" (status 400) message back.  One thing we 
might consider instead is throwing a Struts-defined authentication 
exception, which would allow the exception handling mechanism to decide 
what to do instead.

One nice feature of using the chain approach is that the exception 
handler (o.a.s.c.ExceptionCatcher) can handle exceptions thrown by 
*anything* that executes after it is installed in the chain, not just 
exceptions thrown by Actions.  This allows us to use exceptions to 
enable application-defined handling of lots of exceptional events from 
the framework as well, rather than simply throwing a 400 response.  In 
addition, sending a 400 isn't going to be possible in a portlet world 
anyway, so we might as well start thinking about what to do instead, and 
make it consistent in servlets as well.

What do you think?

Craig



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

Re: [chain] conditionals again

2003-10-22 Thread Craig R. McClanahan

Greg Reddin wrote:

I'm sorry to bring back up a discussion that's been hashed out 
already, but there's something I still don't understand...

I can see why it's better for every command in the chain to be 
executed rather than executing a "sub-chain" based on some condition.  
I can see the correlation of the sub-chain idea to the goto notion.

But this leaves some baggage that I'm still not comfortable with.  Now 
every command after ValidateActionForm has to know about the 
"validKey" attribute.  So far, that's ok.  At least I can readily see 
the chain of execution and there's no variation in it.  But, what if I 
introduce a command of my own that creates some conditions?  Now do I 
have to customize *every* command in the chain after mine just to 
check for my condition?  This also makes it difficult at best to 
change the order of execution if I so desired, but I don't know if 
that's necessarily a bad thing.

If this is the case, how are we any better off with this model than we 
were with a monolithic request processor?  Why should the commands 
have so much inter-dependence now that they are separate objects?  Are 
we better off with them as inter-dependent separate objects than we 
were as one monolithic object?

Now, is there any way to get the best of both worlds -- no gotos, and 
no "state baggage"?  Is it possible that the command could just be 
responsible for executing and not ever be called unless all the 
conditions are in place for it to be executed?  Something at a higher 
level than the command would have to determine whether it should be 
executed?  So, you might have something between the chain and the 
command that determines that.  I'm not sure if that's any better 
because then *that* component would have to know about all the 
commands as well.

Anyway, I hope I'm making sense.  I hate to ask a question and then 
leave the room, but I'll have to take answers in the morning :-)

If you've got tightly connected commands that are already highly 
interdependent (and a chain for replacing RequestProcessor definitely 
fits this description), there is normally so much shared state 
information already that adding tests for conditions isn't going to add 
any coupling that wasn't present already.  If you're wiring together 
commands that are loosely coupled, and don't necessarily want the 
commands to know about each other's state, you're probably better off 
doing the "branch to an alternate chain" trick, based on a decision in a 
command that implements the branch.

Both styles do work, and (in fact) both are still employed in the 
chain-config.xml right now:

* The "servlet-complete" chain selects the appropriate sub-application
 module and branches, giving you the opportunity to plug in
 per-module chains that are completely different and independent,
 without introducing any coupling other than placing the ModuleConfig
 in the right place (i.e. the "servlet-standard" chain expects that as a
 precondition, instead of loading the ModuleConfig at the beginning
 of its own work).
* The "servlet-standard" chain is mostly synchronous, but still has a
 branch for exception handling (required, in this case, because it's
 not caught until the postprocess() method, meaning that the rest
 of the chain has already been executed and someone threw an
 exception).
For any given chain, pick the style that makes the most sense for your 
use case.  But, while we're still experimenting, I tend to play with 
lots of fine-grained chains that are glued together by "smart" commands 
that branch based on conditions, and then look later to see if there is 
enough shared state to collapse those chains into one.

Thanks,
Greg
Craig



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

Re: Struts-chain Behavior Discussion

2003-10-16 Thread Craig R. McClanahan

PILGRIM, Peter, FM wrote:

-Original Message-
From: Jing Zhou [mailto:[EMAIL PROTECTED]
- Original Message - 
From: "PILGRIM, Peter, FM" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Sent: Monday, October 13, 2003 5:39 AM
Subject: RE: Struts-chain Behavior Discussion

*Question of Architecture*

Does this mean that we have solved the hideous Action 

Chaining debate?

In theory an Struts Action could be refactored to be a type of 
``Command'' and therefor Actions could be chained.

Whenever there is a debate and each side seems to be very reasonable
in certain contexts, it is more likely the system itself is 
in-complete or
fails to meet the requirements. We use Controller Delegation Model
and/or Event Handler(s) to deal with such problems.

What are you talking about here? What I am talking about or rather
aiming the ability create common Struts components. 

Suppose team T1 invents a generic web search engine component.
Let say another team T2 wanted to use that component, say
embed it is in own JSP views using say Tiles.
How does the search component forward or transfer control to 
the external component that T2.

One way could be to use an action chain. First, one writes a Struts
Action in such way that it puts a known public bean or put the bean
in the form bean. Whatever. This Output Bean contains contains
your search result or selected object. Second, one can 
generate a dynamic ActionForward that names the second Action
to forward.

But I am thinkgin Craig has given us an alternative option, of maybe
using a Command to do this. But if and only if an Action is refactored
as a Command.

It sort of is in the existing proof of concept (i.e. there is an adapter 
Command that can call an existing Action), but that will be of more 
interest to people with existing code that want to use it in a CoR based 
request processor.  I'm imagining that new code based on such a pattern 
would be constructed out of Commands in the first place.

Commons-chain is not intended to solve that debate topic originally.
Last year, people found when they have two RequestProcessor(s), say
A and B, if they need to design a new RequestProcessor C that has
methods from both A and B, the best they can do is to let C extend
one of them, say A, and then copy the methods (possibly line by line)
from B. So a configurable RequestProcessor is somehow needed
to reuse portions of several RequestProcessor(s). This is what
commons-chain is intended to solve initially.

Ay Ay, Captain! I don't mean to rain on the parade. I was involved
in the composable request processor discussion way way back in the
summer. As the Expresso core committer who integrated Struts 1.1 
I found also a futuristic design issues merging the 
TilesRequestProcessor and our own ExpressoRequestProcessor.
How would you merge the next processor, and the next one, and
the next one after that.

But the problems have not been cleanly solved in regard to 
reusability.
When a Command is deeply coupled with other Command(s) in a
chain through one or more flags/states in Context (say cancel flag,
invalid token flag, invalid validation flag, etc.) its 
reusability in a 
different chain is very low in theory or very difficult to 
use (you need
to configure many flags to get it work and subject to the condition
the new Context offers the same set of flags).

I dont understand the reusability problems. To me having
read the Gang of Four original book, the design of Chain
of Responsibilty and Craig's code and what he has said
to me (to us) on list makes this a non-issue. Actual design
pattern is a linear path. The only difference I can see is 
the context, which I guess you should treat it as opaque 
object any way. 

If you write a Command that need various context setting
that you should declare in the javadoc or documentation.

The code I've written to date illustrates how I propose to reduce 
problems of interdependence between commands.  For every case where your 
command expects an input attribute in the Context (or plans to create an 
output attribute), have a String property on the Command's 
implementation class made up of the attribute name with "Key" on the 
end, that documents the name of the attribute you intend to use.  This 
does several things for you:

* It self documents the appropriate attribute keys if you are
 diligent about applying this design pattern.
* It makes the actual keys to be used configurable (improves
 reusability in different environments).
* It means that your code can *ask* a Command instance where
 it stored something, or plans to store something, instead of
 just assuming.
For example, the Command that selects an appropriate ActionConfig based 
on the input path (the Command version of the processMapping) needs to 
store the ActionConfig it found under an agreed-upon location in order 
for later commands to find it.  Snippets of this class 
(AbstractSelectAction

Re: Nested-EL

2003-10-14 Thread Craig R. McClanahan

[EMAIL PROTECTED] wrote:

Well, even though it isn't important, wanted, needed, etc... would you guys at
least take a look at the work that I have done? Should I just attach a zip in
a mail to the list?

I cannot commit any personal time to this, although I think it
definitely makes sense. The best way to make sure your proposed code
doesn't get lost in the mailing list archives, it's best to create an
enhancement request in the bug tracking system:

http://nagoya.apache.org/bugzilla/

and then add your ZIP to the existing report as an attachment.

I have created the packages:
org.apache.strutsel.taglib.nested
org.apache.strutsel.taglib.nested.html
I did not implement logic and bean since they are both replaced by JSTL. I
need to do the tld and I think this little excursion will be complete.

That would be quite interesting.

Carl

Craig

Quoting "Craig R. McClanahan" <[EMAIL PROTECTED]>:

Edgar P Dollin wrote:

Everyone has preferences but in my opinion JSTL doesn't hold a candle to

the

nested tags, especially customized nested tags.

I do agree however that JSTL for nested tags is not that important. It

does

help in environments where there is ZERO tolerance for JSP expressions

Conveniently ignoring the fact that something like stll contains a "JSP expression" -- just not a
*standard* JSP expression :-).

or
that are running older versions of the servlet container.

Definitely.

Edgar

Craig

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

Re: Nested-EL

2003-10-14 Thread Craig R. McClanahan

Edgar P Dollin wrote:

Everyone has preferences but in my opinion JSTL doesn't hold a candle to the
nested tags, especially customized nested tags.  

I do agree however that JSTL for nested tags is not that important.  It does
help in environments where there is ZERO tolerance for JSP expressions
Conveniently ignoring the fact that something like  stll contains a "JSP expression" -- just not a 
*standard* JSP expression :-).

or
that are running older versions of the servlet container.
 

Definitely.

Edgar
 

Craig



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

Re: Adding to the user guide

2003-10-10 Thread Craig R. McClanahan

James Mitchell wrote:

I can't see why anyone would have a problem with renaming a few
pages...
+1.

...hell, when I get the time, I plan to rewrite the whole thing to
bring it up to 1.1+ standards, demonstrating all the newest, coolest stuff.
 

+1 as well.

--
James Mitchell
Craig



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

Re: Adding to the user guide

2003-10-09 Thread Craig R. McClanahan

Don Brown wrote:

I added a section in the user guide about wildcards in action mappings,
however before I commit it, I'd like to make sure it follows documentation
conventions as this is my first time writing Struts docs.  I've put the
section up here for review:
http://www.twdata.org/dakine/site/userGuide/building_controller.html#action_mapping_wildcards

If I don't hear anything in a day or so, I'll take it as a "thumbs up" and
commit it.  Thanks.
 

+1 ... looks good to me.  The only suggestion I might make is to also 
put a forward reference to this somewhere in the initial description of 
what an action mapping is.

Don

Craig



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

Re: Struts-chain Behavior Discussion

Jing Zhou wrote:

- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 07, 2003 2:22 PM
Subject: Re: Struts-chain Behavior Discussion

You do not need to determine Class4 was always run or not,
actually it is determined at runtime. Its definition is included
in every labeled chain by default.

It is absolutely necessary to understand the control flow if you want to
customize it.  The above would support all of the following flows
(assuming that no command returns true prematurely):
* Class1 - Class2 - Class3 - Class4
* Class1 - Class3 - Class4
* Class1 - Class2 - Class4
Now, if I want to add a new step that has to occur before Class3, but is
ONLY executed if Class3 will be executed, how do I do that?  I have to
change which command gets label L1, which is bad for the same reason
that "goto" in programming languages is bad.

You could easily assign the label L1 to the new command before Class3
in the chain. A chain definition is normally very very small (5-30 lines)
comparing with programs (up to 8000 or more lines). I do not see any
difficulties to manipulate such a small section. Note that the thing we are
dealing with is a config file, not a program (with a "go to" from line 67 to
line 7598 :-)

The idea is that you do not have to define a separate chain else where
if you could re-use a labeled chain in the current chain definition.
You could also ignore  labels if any, just use the chain as is.

If you're going to (potentially) ignore the labels and branches, why
have them in the first place?

In the example, the L1 labeled chain is invoked by Class1 if it returns
false. If you do not need the particular L1 labeled chain in the current
chain definition, you could ignore it. But the label could serve as
an entry point for other chains outside the scope to invoke the L1
labeled chain if they find it useful.

Or, to put it differently, conditional behavior should be a feature of
the Command implementation ("is the world in the correct state for me to
perform this action?").  If the current state is not correct, it should
just return false to let the chain continue.  That's why a change based
on Ted's suggestion:
(1) LookupCommand
(2) ExceptionCatcher
(3) SelectLocale
(4) SelectAction
(5) CreateActionForm
(6) PopulateActionForm
(7) ValidateActionForm (must save state in the Context)
(NEW) SelectInput [skip if validation succeeded]
(8) CreateAction [skip if validation failed]
(9) ExecuteAction [skip if validation failed]
(10) PerformForward
is actually the cleanest overall approach.  The user should not have to
even *know* what conditions the commands care about to determine whether
they are executed.  Thus, you would end up with a clean and simple chain
definition:

Now, if I want to insert something that always happens before
ValidateActionForm, I know exactly where it goes.  I don't have to worry
about whether ValidateActionForm is going to branch or skip, because
it's not ... SelectInput and friends decide for themselves whether they
are relevant.
OK, I've convinced myself that this is the right approach :-).  So I'll
likely be changing struts-chain to this tonight, and adding the
appropriate mechanisms for ValidateActionForm to pass on the success or
failure state information.

I have not been fully convinced by this approach yet. Taking a general
chain definition as follows,

 ...

If I want to add a new command C before C19, I'll have to figure out
who set up a state before C19, even on one does it.
Not true.  You don't care who set up state .. you care only if your 
newly inserted command is relevant or not, since it will always be executed.

Also,
I'll have to figure out where the state is located if any and see if the new
command C honor that state or not (command coupling problem).

Why should you expect any *other* command to decide whether *your* new 
command is relevant or not.  That's *your* problem.

Furthermore, assume the command C3 set up a state, but we could
see any commands between C3 and C19 could set up a second one
or third one. Where the states are stored systematically is another
question (state storage problem).

"State is in the eyes of the beholder" :-).  If you can't decide for 
yourself when your newly inserted command is relevant, then by 
definition you are at fault, because there is no way for your command 
component to be independently testable and reusable.

I could be convinced if I see a possible mechanism that deals with
the command coupling problem and state storage problem.

Jing, it is sounding more and more like what you want is a scripting 
control flow language expressed in XML.  That is absolutely, totally, 
*not* what commons-chain is about.  Feel free to invent

Re: Struts-chain Behavior Discussion

Jing Zhou wrote:

It's not so much about "complexity" as it is readability.
   

The "complexity" in my message refers to the verboseness of the
chain-config.xml file. What I am looking for is a possible
simpler syntax to do the job.
 

If I care what Process Action is then I can see the detail.  Goto's
were deemed dangerous because of the behavior that they hide.  They
obfuscate the flow of the code.  It's not really any different here
either.
   





   

I had a longer response prepared to your other post, but decided it
was too wordy. :)  One example where the obfuscation comes in is that
I had to look at it for a bit before determining that Class4 was 
always run.  If a few more commands are thrown in, it really gets
confusing.
   

You do not need to determine Class4 was always run or not,
actually it is determined at runtime. Its definition is included 
in every labeled chain by default.

It is absolutely necessary to understand the control flow if you want to 
customize it.  The above would support all of the following flows 
(assuming that no command returns true prematurely):
* Class1 - Class2 - Class3 - Class4
* Class1 - Class3 - Class4
* Class1 - Class2 - Class4

Now, if I want to add a new step that has to occur before Class3, but is 
ONLY executed if Class3 will be executed, how do I do that?  I have to 
change which command gets label L1, which is bad for the same reason 
that "goto" in programming languages is bad.

The idea is that you do not have to define a separate chain else where
if you could re-use a labeled chain in the current chain definition.
You could also ignore  labels if any, just use the chain as is.
 

If you're going to (potentially) ignore the labels and branches, why 
have them in the first place?

Or, to put it differently, conditional behavior should be a feature of 
the Command implementation ("is the world in the correct state for me to 
perform this action?").  If the current state is not correct, it should 
just return false to let the chain continue.  That's why a change based 
on Ted's suggestion:

(1) LookupCommand
(2) ExceptionCatcher
(3) SelectLocale
(4) SelectAction
(5) CreateActionForm
(6) PopulateActionForm
(7) ValidateActionForm (must save state in the Context)
(NEW) SelectInput [skip if validation succeeded]
(8) CreateAction [skip if validation failed]
(9) ExecuteAction [skip if validation failed]
(10) PerformForward
is actually the cleanest overall approach.  The user should not have to 
even *know* what conditions the commands care about to determine whether 
they are executed.  Thus, you would end up with a clean and simple chain 
definition:


 
 
 
 
 
 
 
 
 
 
 

Now, if I want to insert something that always happens before 
ValidateActionForm, I know exactly where it goes.  I don't have to worry 
about whether ValidateActionForm is going to branch or skip, because 
it's not ... SelectInput and friends decide for themselves whether they 
are relevant.

OK, I've convinced myself that this is the right approach :-).  So I'll 
likely be changing struts-chain to this tonight, and adding the 
appropriate mechanisms for ValidateActionForm to pass on the success or 
failure state information.

 

-Paul

   

Jing
 

Craig



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

Re: Struts-chain Behavior Discussion

Edgar P Dollin wrote:

Not that I am an expert, nor is this the Command Chain a major issue for me,
but logic in configuration files (xml) is like writing LISP.  For some it is
a rare beauty, for others it foggy at best.
 

It's different from LISP in one important respect, though ... no 
parentheses :-).

More seriously, it's different in a more important respect as well.  
Configuration via XML files is *optional* -- you are completely free to 
assemble your commands and chains in any way that you wish.  You can 
even compile the sources for the chain package where you don't have 
commons-digester (the code used to parse the XML config files) 
available, and the build will obediently skip creating the config 
classes.  Yet the base functionality of chain is still available.

Edgar

Craig



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

Re: Struts-chain Behavior Discussion

Ted Husted wrote:

Craig R. McClanahan wrote:

* The way it's currently implemented -- ValidateActionForm
 conditionally branches to a separate chain on validation
 failure ("servlet-validation-failure" in the current config file),
 and [returns true to] abandon the remainder of the original chain.


The phrase "conditionally *nests* a separate chain" might be more 
accurate. Branch implies the Command loses control, which is not the 
case.

dictionary.com / Computer Science

branch - To relinquish control to another set of instructions or 
another routine as a result of the presence of a branch.
Nitpicking, I know, but ...

From the perspective of the original chain, this is exactly what 
happens -- the original chain relinquishes control, and the remainder of 
the original steps are never actually executed (because 
ValidateActionForm returns true when the alternate chain is finished).

nest - A set of data contained sequentially within another.
You might recall that the original approach to this functionality really 
did nest -- ValidateActionForm was a Chain that conditionally executed 
it's nested commands instead of continuing.  As was pointed out then, 
this was sort of a corruption of the CoR pattern, because the remainder 
of the original chain is *still* abandoned (because the last command in 
the nested chain returns true) -- but you can't tell that from looking 
at a structural diagram of the commands.

It's perfectly reasonable to use nested chains for composing complex 
things out of simple things -- that's why a Chain is-a Command.  But the 
original feedback was correct -- this shouldn't be used as a structure 
for conditional processing; explicity branching is better.

-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: Struts-chain Behavior Discussion

Jing Zhou wrote:

- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 11:26 AM
Subject: Re: Struts-chain Behavior Discussion

Looks like you are asking less while I am asking more :-)

Exactly.  More == Bloat unless you really need it.  And I can't see that
I need it yet.

I did not see it until I was thinking a way to build user interfaces for
Chain.
If labeled commands could be regarded as implicitly defined chains, then
we have a shorter chain-config.xml for the following MAIN chain:

Where each labeld command defined a chain from
that command to the end. Thus the chain L1 contains
two commands and L2 contains one command.
Currently, to achieve the same behaviors, we have to
define two nested chains shown below. Note that the
chain B1 is equivalent to chain L1 and B2 is equivalent
to L2. The execution paths are identical between the
two MAIN chains, as I explained in the other
message. So "More" does not necessarily imply "Bloat"
and it is not my interests to bloat any systems
if not necessary.

I actually think this is better, because you can customize *just* the B1 
path or *just* the B2 path if you want to, without having to mess with 
MAIN at all.

Please build something and show it to us, instead of talking about it.
It won't necessarily be a "chain of responsibility" pattern any more,
but it might well be interesting.  However, you still haven't even shown
me a practical use case where the functionality you're talking about is
required, and you still haven't shown me how you plan to get around the
fragile nature of subscripts.

As I wrote in the other message, it should be exactly the CoR pattern
without skipping commands.
Well, we already have that :-).

Just need to do some feasibility research
before someone could actually build it. Now we learned that
index-based "jump behavior" is fragile. So label-based one seems to
be the right choice.
And, we already have that too, by branching to labelled chains.

The remaining objection I see is to the verboseness of the 
configuration, which (as I mention above) is IMHO an advantage because 
the detailed subchains can be individually customized.

Looking at the possibility to do it without changing
core APIs is my first choice. Looks to me I need to store a label in
context per request thread for Chain.execute(), but what about
for non-web context is not clear to me yet (???) as well as how
I am going to add labeled commands to a chain (???)
Our real needs come from UI design requirements. We try our best
to give end users simple ways to do simple things first, such as
our phased validation model in Carrier. When we move to Chain,
we have to evaluate different UI design options.

UI workflows across requests are not what commons-chain is really for -- 
it's about designing the processing for a particular single request (in 
the case of Struts), or for decomposing the business logic generally in 
the business or persistence tiers.

However, it's also feasible to build branches and labels in by subclass 
CommandBase and ChainBase appropriately, instead of modify Command and 
Chain.  That would be the suggested way to prototype something.

Craig

Craig

Jing
Netspread Carrier
http://www.netspread.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: Struts-chain Behavior Discussion

Paul Speed wrote:

I haven't looked at the implementation yet (I intend to when I have
more than 2 seconds free) but I have been lurking in this 
discussion.

It seems to me that if a command could nest a chain then all things
are possible.  In fact, you wouldn't even need the "jump to last
command" logic since that step would be part of the master chain.
Craig's example might then be like:
(1) LookupCommand 
(2) ExceptionCatcher 
(3) SelectLocale
(4) SelectAction
(5) Process Form
   (a) CreateActionForm
   (b) PopulateActionForm
   (c) ValidateActionForm
(6) CreateAction
(7) ExecuteAction
(8) PerformForward
 

This isn't what you really want ... if validation fails you need:
   SelectInput
   PerformForward
whereas if validation succeeds you want:
   CreateAction
   ExecuteAction
   PerformForward
Note that the last step is the same in either case.

This can be accomplished in two different ways with commons-chain "as is":

* The way it's currently implemented -- ValidateActionForm
 conditionally branches to a separate chain on validation
 failure ("servlet-validation-failure" in the current config file),
 and abandon the remainder of the original chain.
* A change to add SelectInput into the standard chain after
 ValidateActionForm, have ValidateActionForm save the success
 or failure of validation in the Context, have SelectInput return
 false if validation succeeded, have CreateAction return false if
 validation failed, and have ExecuteAction return false if validation
 failed.
In either case, no changes to how commons-chain works are required.

I don't know how easy it would be to run a chain from a command, so
it may not be feasible.  From a processing perspective, it seems
clearer to me.
 

Except that it doesn't do the right thing in case of validation failures 
(i.e. look at the "input" parameter).

-Paul

Craig

Jing Zhou wrote:
 

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, October 04, 2003 1:02 PM
Subject: Re: Struts-chain Behavior Discussion
   

They could indeed be made part of the chain, and "checking the current
state to see if it's appropriate for me to do anything" is certainly
more in the spirit of the original CoR pattern.  However, I worry a
little that creating the need for that state information increases
coupling between commands, and therefore increases the complexity of
reusing commands in alternative chains.
 

Exactly. The index-based jumping creates the need for a command to
recognize a fixed position to jump to. That is why I said
they have a similar problem - coupling between commands. They
have to either honor a state/flag or a fixed position. And such coupling
can be easily destroyed by adding a command in between without
recognizing the state/flag or changing the target position.
   

In the real-life use case we actually have in the CVS repository (the
one in struts-chain, which actually does work :-), the case in question
was to deal with the fact that the Struts request processing lifecycle
has a branch in it, based on whether or not validation succeeds.  The
basic flow goes like this (using the class name of the command
implementation class, and presuming we're all pretty familiar with the
corresponding RequestProcessor behavior):
(1) LookupCommand (analogous to the processPreprocess() hook)
(2) ExceptionCatcher (no direct analog - used to implement exception
mapping behavior)
(3) SelectLocale
(4) SelectAction
(5) CreateActionForm
(6) PopulateActionForm
(7) ValidateActionForm
(8) CreateAction
(9) ExecuteAction
(10) PerformForward
The conditional behavior happens in Step (7) -- if validation fails, an
alternative path is desired:
(7a) SelectInput (uses the "input" attribute on the )
(7b) PerformForward
At the moment, this is implemented as a branch, to a separate chain that
the author of ValidateActionForm need not even know the name of at
design time (it's a configuration property).  If ValidateActionForm
detects a failure, it looks up an alternate chain in the Catalog,
executes this chain, and then returns true (so that steps 8-10 of the
original chain are never executed).  Note that step (10) in the original
chain and step (7b) in the alternate chain share a single Command
implementation instance, because Struts ends up doing the same thing
either way (RequestDispatcher.forward() or redirect based on what
ActionForward it is passed).  Nothing had to be coded twice.
 

My question is whether or not we could find a simpler
syntax in the chain-config.xml and implement "jump behavior".
This is because we could have a lot of "jump to the last command"
or "jump to the second to last command", etc.
It is very easy to relate "branch behavior" and "jump behavior" to
a rule

Re: Struts-chain Behavior Discussion

Jing Zhou wrote:

- Original Message - 
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, October 04, 2003 10:37 AM
Subject: Re: Struts-chain Behavior Discussion

Jing Zhou wrote:

For me, "Simple thing should be simple" is the
top rule that supersedes any programming practices. 

Some of might say that this *is* a programming practice. Some might also 
couch it as start with "the simplest thing that can possibly work", and 
then let practice be your guide.

Only when the experiences they primarily have are coding (there are a lot
of other fields where the same rule is applied to).

* If I have 15 commands that needs to jump to the last one in a chain,
  if the branch way is used, then the last command must be repeatedly
 defined16 times in the config file. It loses the grace in expressions
 (although the sample config file does not reveal this problem).

Each Command can examine the Context to see if it can handle the current 
state. If it can't then it returns false, and processing continues. You 
don't need to "jump", you need a Command to define the appropriate state 
in your Context.

The fundamental problem might be viewing the Chain as the brains of the 
operation. It isn't. The Chain is just a composite of Commands. The 
Context manages state, and so the Context is where any decision making 
occurs.

* The "branch behavior" and "jump behavior" are complementary to
  to each other in theory. Repeatedly executing a set of commands in
  a chain can not be done gracefully in a *extreme* configurable
  chain.

Yes, it's possible that the branch behavior might not be the best way to 
go. I suspect that it might be better if a Command did not call other 
Commands, either directly or through the Catalog. But, I do think we 
should leave that door open so that people can experiment with this 
extension. I know in similar implementations, I often found myself 
having (the equivalent of) Commands calling Commands. But those 
implementations did not have a Chain to work with, and once we have more 
experience working with a real Chains, other strategies may become 
evident. I believe that at some point we may be able to dispense with 
branch behavior, so that very little happens behind the scenes. Or maybe 
not. Practice will dictate.

Looks like you are asking less while I am asking more :-)

Exactly.  More == Bloat unless you really need it.  And I can't see that 
I need it yet.

* If in the end, the fundamental APIs do not want to deal with
  "jump behavior", I still could not successfully implement an
  extended Chain to make up the capability. From the original
  publication about the Chain of Responsibility, it does not
  dictate "jump behavior" is prohibited or "branch behavior" is
  only allowed. In my world view, the three behaviors are
  equally important: "sequence behavior", "branch behavior",
  and "jump behavior" in an extreme configurable chain.

IMHO, these behaviors out of scope for an implementation of the Chain of 
Responsibility pattern. Many implementations don't even return false or 
have the Filter backdoor. These are optimizations Craig made to help 
with resource-intensive operations. In many implementations, every 
Command on the Chain is visited, and there may not even be a guarantee 
that any of the Commands handles the request. I don't see "jump 
behavior" as an essential part of the CoR "world view". The 
boolean/Filter behavior is a stretch as it is, and it is probably as far 
we can go and still call it a GoF CoR.

Neither "sequence behavior" nor "branch behavior" are described
as essential parts of the CoR "world view". Since the three behaviors
are orthogonal to each other and commons-chain implements two
of them, thus in theory, it is *in-complete*. That is the research
direction I would like to point out to the community that we might
be able to complete it some how.
Please build something and show it to us, instead of talking about it.  
It won't necessarily be a "chain of responsibility" pattern any more, 
but it might well be interesting.  However, you still haven't even shown 
me a practical use case where the functionality you're talking about is 
required, and you still haven't shown me how you plan to get around the 
fragile nature of subscripts.

For some applications, just "sequence behavior" is enough as you
mentioned before. But from the research point of view,
it has very little gain than using a single RequestProcessor. Since
commons-chain is also designed to be used in other environments,
for example, in business tiers, the community should put more efforts
to extract maximum possible functionality out of Chain.

Actually, our very own use case (RequestProcessor) is a perfect example 
of why using a chain instead of a base RequestProcessor class -- with 
nothing else -- is still more powerful.  Consider the dilemma I was in 
trying to implement

Re: Struts-chain Behavior Discussion