from:"Craig R. McClanahan"

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: 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: 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: 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 it is something that I
 would personally like to work towards -- once we have our existing code
 rationalized. (First things

Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)

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: 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 better connotations?

I'm also very willing to defer any decision to migrate to SVN ... CVS, for all
its warts,

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) 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:

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: 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: 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: 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 http://jcp.org.

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

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]

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 bean:struts
  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 s:loadMessages 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 f:loadBundle 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%22defaultField=subjectSearch=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]

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: 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: [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:

  property file=${user.home}/build.properties/

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 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: 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??? 
 
 shakes head and sighs/
 
 snip
 My preference would be for leveraging code that is in a logical place (ala
 commons-lang) and documenting the dependencies.
 /snip
 +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: [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
===
?xml version='1.0' encoding=UTF-8?
!DOCTYPE hibernate-configuration
PUBLIC -//Hibernate/Hibernate Configuration DTD//EN
http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd;
 
hibernate-configuration
 
session-factory
 
!-- database connection --
property
 name=hibernate.dialectnet.sf.hibernate.dialect.MySQLDialect.java/propert
 y
property
 name=hibernate.connection.driver_classorg.gjt.mm.mysql.Driver/property
property
 name=hibernate.connection.urljdbc:mysql://localhost/resources/property
property
 name=hibernate.connection.usernameresourcesTest/property
property
 name=hibernate.connection.passwordresourcesTest/property
property name=hibernate.connection.pool_size4/property
property name=hibernate.statement_cache.size100/property
property name=hibernate.show_sqltrue/property
property name=hibernate.jdbc.batch_size0/property
property
 name=hibernate.cglib.use_reflection_optimizertrue/property
 
mapping
 resource=org/apache/commons/resources/impl/HibernateBasicMessage.hbm.xml/
 
/session-factory
 
/hibernate-configuration
 
 
 
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

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: [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: 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: @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 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: @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: [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 managed-bean
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]

RE: Why you want to be on the PMC

Quoting James Mitchell [EMAIL PROTECTED]:

 On Thu, 18 Dec 2003, Craig R. McClanahan wrote:
 
 snip/
 
  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 [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:
 
 
 !ELEMENT display-element (attribute*, set-property*)
 !ATTLIST display-element
   displayElementId CDATA #REQUIRED
   type %DisplayElementType; #IMPLIED
   jspName CDATA #IMPLIED
   extends CDATA #IMPLIED
   modelClassname CDATA #IMPLIED
   roles CDATA #IMPLIED
   useContainerNaming %Boolean; #IMPLIED
 
 
 !ELEMENT set-property (#PCDATA)
 !ATTLIST set-property
   name CDATA #REQUIRED
   value CDATA #REQUIRED
 
 
 !ELEMENT attribute (set-property*)
 !ATTLIST attribute
   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.
 
 !-- The crudForm definition serves as a base layout for an add or
  update page --
 
 display-element displayElementId=crudForm 
 !-- will always be placed on the bottom of the form, sequence=99 --
attribute displayElementId=Message
   displayName=message.required.legend sequence=99/
 /display-element
 
 
 !-- The changePasswdForm definition only allows you to change your
  password. It inherits the required message legend from
  the crudForm --
 
 display-element displayElementId=changePasswdForm extends=crudForm 
 
   !-- include the user password fields also used by the addUserWidget --
   attribute displayElementId=userPasswdWidget sequence=1/
 
   !-- The rest of the user information is cached in the html form
  allowing the update handler to be reused for the change password
  page --
   attribute attName=cmManagerId displayElementId=Text sequence=10
 set-property name=isHidden value=true/
   /attribute
 
   attribute attName=cmFname displayElementId=Text sequence=11
 set-property name=isHidden value=true/
   /attribute
 
   attribute attName=cmMname displayElementId=Text sequence=12
  set-property name=isHidden value=true/
   /attribute
 
   attribute attName=cmLname displayElementId=Text sequence=13
  set-property name=isHidden value=true/
   /attribute
 
 /display-element
 
 
 
 !-- The userPasswordWidget is included by the userAddWidget and
  The changePasswdForm. --
 display-element displayElementId=userPasswdWidget
 
attribute attName=cuPassword displayElementId=Text
   displayName=cuPassword.display sequence=1
   requiredField=true
   set-property name=size value=15/
   set-property name=maxlength value=15/
   set-property name=isPassword value=true/
/attribute
 
attribute attName=retypePassword displayElementId=Text
   displayName=retypePassword.display sequence=2
   requiredField=true
 
   set-property name=size value=15/
   set-property name=maxlength value=15/
   set-property name=isPassword value=true/
/attribute
 
 /display-element
 

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 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 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: 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:
   
   snip/
   
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 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 x:transform 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 x:transform 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 x:transform in the same page as your components, if
you want.


-
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 [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.

form-bean name=AboutForm type=com.rustts.action.DynaRusttsForm 
  form-property
name=aboutForm_BorderLayout_west_dateWidget_selDate
type=java.lang.String/
  form-property

name=aboutForm_BorderLayout_center_calendarWidget_GridLayout_B0_yearWidget_year
  type=java.lang.String/

 form-property  

name=aboutForm_BorderLayout_center_calendarWidget_GridLayout_A0_monthWidget_month
  type=java.lang.String/

   /form-bean

 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: 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 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: 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: 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 http://java.sun.com/j2ee/1.4/download-dr.html.  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 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: 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 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 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 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 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 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 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: [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 unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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: [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: 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  - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design  - http://www.amazon.com/exec/obidos/ISBN=1861005512.
 
 
 
 -
 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

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: 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: [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: 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: [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: [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 action 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 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: 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 being said, there

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

[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: [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

Don Brown wrote:

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

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 exception 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: [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

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 nested:write 
property=foo.bar/ 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

[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 nested:write 
property=foo.bar/ 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]
   





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

2003-10-07 Thread Craig R. McClanahan

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

2003-10-07 Thread Craig R. McClanahan

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.
   

command jumpLabel=L1 className=Class1 /
command jumpLabel=L2 className=Class2 /
command label=L1 className=Class3 /
command label=L2 className=Class4 /
   

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:

chain id=request-processor
 command class=LookupCommand/
 command class=ExceptionCatcher/
 command class=SelectLocale/
 command class=SelectAction/
 command class=CreateActionForm/
 command class=PopulateActionForm/
 command class=ValidateActionForm/
 command class=SelectInput/
 command class=CreateAction/
 command class=ExecuteAction/
 command class=PerformForward/
/chain
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

2003-10-07 Thread Craig R. McClanahan

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:
chain id=request-processor
 command class=LookupCommand/
 command class=ExceptionCatcher/
 command class=SelectLocale/
 command class=SelectAction/
 command class=CreateActionForm/
 command class=PopulateActionForm/
 command class=ValidateActionForm/
 command class=SelectInput/
 command class=CreateAction/
 command class=ExecuteAction/
 command class=PerformForward/
/chain
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,
chain
 command class=C1/
 command class=C2/
 command class=C3/
 ...
 command class=C19/
 command class=C20/
/chain
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

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

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.
 

Running a command from a chain is trivial.  In fact, that's what the 
ValidateActionForm code (quoted below) already does.  In this case, it's 
done for conditional behavior, but that is not required.  You can 
actually nest chains inside other chains (remember that Chain *extends* 
Command) for arbitrarily complex straight through processing flows.

-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 action)
(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 engine or workflow engine, so people might get me wrong
in the early reactions.
Although we use the term branch behavior and jump behavior
in a chain, we should not see the if and go to statements in the
chain-config.xml file. So a chain is still a fully connected chain
(no skipping by definition).
The if statement is simulated by commands which
provide branch behavior by terminating the current chain and
invoking a nested chain.
Could we simulate the go to statement without breaking the chain?
Note that the chain's execution path should be remained connected
because we need to do post processing in the reversed order.
The answer, I deeply believe, is yes. We know that index-based
jumping is flawed, so we should use label-based jumping. When
a command is added to a chain, an optional label could be
specified which must be unique within the chain.
For example,
chains
 chain name=servlet-standard
 command className

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 the struts-faces library:

* I needed to

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 action)
(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 engine or workflow engine, so people might get me wrong
in the early reactions.
Although we use the term branch behavior and jump behavior
in a chain, we should not see the if and go to statements in the
chain-config.xml

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:
  chains
chain name=MAIN
   command jumpLabel=L1 className=Class1 /
   command jumpLabel=L2 className=Class2 /
   command label=L1 className=Class3 /
   command label=L2 className=Class4 /
/chain
  /chains
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.
  chains
chain name=MAIN
   command className=Class1 branchCommand=B1 /
   command className=Class2 branchCommand=B2 /
   command className=Class3 /
   command className=Class4 /
/chain
chain name=B1
   command className=Class3 /
   command className=Class4 /
/chain
chain name=B2
command className=Class4 /
/chain
  /chains

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

2003-10-04 Thread Craig R. McClanahan

Ted Husted wrote:

Craig R. McClanahan wrote:

In terms of the chain implementation of the request processing 
lifecycle, this is just an unconditional command in the chain (it's 
implemented in o.a.s.c.servlet.PerformForward).  No skipping or 
stepping is requried.  See

 contrib/struts-chain/src/conf/chain-config.xml

for the entire definition.  You'll note that it requires no skipping 
-- just the conditional behavior on validation failures, which is 
modelled as a branch to a separately named command.


I wonder if even these conditionals could be made part of the chain. As
an alternative to branching, the Command could update the state of the
Context and return false. What is now a conditional Command could be the
next link the Chain. The conditional would check to see if the state
calls for it to execute, and if so, do its business and return true.
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.

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 action)
(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.

What would this look like if we merged it into a single chain?  Probably 
something like this, with additional state-dependent checking indicated 
in [square brackets]

(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
So, implementing this as a single chain would require ValidateActionForm 
to the success/failure state of the validation into the Context -- easy 
to do -- and three commands must now (inside their implementation -- the 
Chain does not know anything about this) surround their current behavior 
in an if statement, which means that they have to know the location of 
the state information that was saved (slight increase in coupling), and 
they get processed by the Chain even if they are not relevant (very 
minor performance impact; almost never enough of a concern to worry 
about).  But it would definitely work.

As Jing points out, the JavaServer Faces request processing lifecycle is 
slightly more complex, because there are more go to the end 
branchpoints (one after each processing phase) -- but again, either 
design pattern will work.  In that case, conditional execution is 
actually easier because the relevant state (has 
FacesContext.renderResponse() been called yet?) is visible directly as 
part of the FacesContext that would be passed along anyway).

I think we're going to find that both approaches have applicability.  
You'll tend to choose the branch approach when the alternative 
behavior is completely different based on the branch conditions (think 
of a request processor for a SOAP request, which chooses the correct 
chain to execute based on the contents of the SOAP-Action header or 
other data in the request), while conditionals based on state will 
probably be better when the branches merge later on (i.e. the 
conditional stuff is in the middle of the chain

Re: Struts-chain Behavior Discussion

2003-10-03 Thread Craig R. McClanahan

Jing Zhou wrote:

It looks to me that I threw a disturbing idea. Now I change
the subject for more discussions of different opinions.
Craig mentioned the go to statement in programming
languages and hinted it could be an evil if Chain implement
the semantics of go to (I just called it jump behavior).
If we recognize Chain as a high level pattern regulator,
I would not agree such a comparison is appropriate
unless someone could convince me the following
observations are questionable.
* I studied several workflow engines (not page flow stuff, they
 manage persisted workload for people) They all implement,
 one way or another, the jump behavior. I could not see
 they violate the OO design principles as high level
 regulators.
 

You seem to be assuming that commons-chain is, or is intended to be, a 
workflow engine.  It's not.  It's fundamental plumbing that might or 
might not be used in the creation of a workflow engine, but would 
certainly not be the only API exposed to users.

* Struts itself, as a MVC pattern regulator in its core, 
 implements the go to semantics when Action returns a
 ForwardConfig. It does a go to the next page, right? -:)

In terms of the chain implementation of the request processing 
lifecycle, this is just an unconditional command in the chain (it's 
implemented in o.a.s.c.servlet.PerformForward).  No skipping or stepping 
is requried.  See

 contrib/struts-chain/src/conf/chain-config.xml

for the entire definition.  You'll note that it requires no skipping -- 
just the conditional behavior on validation failures, which is modelled 
as a branch to a separately named command.

In another word, IMHO, low level language principles
may not be applicable to high level pattern/structure
regulators. Hope people re-think it.
I also recognize the facts that we do not want to overgrow
Chain into an xml based rule engine. It should be just chain.
But for such a simple requirement, one way is to model it
as a if decision (Craig way), another way is to model it
as a pseudo controller (Ted way). They are kind of 
cumbersome to use. It violates the Simple thing should
be simple principle - a principle that supercedes other
programming principles. The Filter thing could offer a
simple solution, but I haven't looked it in details yet.
 

Note that even the notion of if is not built in to the fundamental 
chain APIs, because it doesn't belong there. It is not part of the 
fundamental pattern (which was modelled on the description from the GoF 
book).

Filter is there because one model of using a chain is to have early 
commands in the chain look up some resources (say, grab a JDBC 
connection from a connection pool), expose it in the context, and then 
return false so that the chain continues.  However, you want to make 
sure that you can return the connection to the pool when you're done, so 
the Chain you are running promises to call your postprocess() method on 
the way back out of the chain.  So, a pseudocode model of a Command to 
expose a connection might look something like this:

   public class AllocateConnection implements Filter {

   public boolean execute(Context context) throws Exception {
   DataSource ds = ... look up your DataSource via JNDI or 
whatever ...
   Connectoin conn = ds.getConnection();
   context.put(connection, connection);
   return (false); // continue the chain
   }

   public void postprocess(Context context, Exception exception) {
   Connection conn = (Connection) context.remove(connection);
   conn.close(); // Return it to the pool
   }
   }

This is a nicely encapsulated resource allocation command that can be 
reused in any application chain that needs database connections.  The 
subsequent commands that *use* the connection don't have any clue how it 
got there; they just assume that one will be made available in the 
context under an agreed-upon key.

Thus, Filter doesn't help you deal with control flow.

The jump behavior requirement is very obvious in 
Java Server Faces Specification too. When the 
renderResponse() is called on FacesContext, the control
is transferred to the Render Response phase after
the current phase. This is another evidence of the
jump behavior in high level pattern regulators.
 

In terms of how you would implement it in a chain, its exactly the same 
as the Struts case -- no skipping or start at this index is required.  
Simply model the Render Response phase as a separately named chain, 
and execute it conditionally (just as I did in the Struts lifecycle for 
what happens on input validation failure) from each of the places where 
you can branch to Render Response.

I would like people to open mind and think, if we
add a method in Chain that allows us to execute
the chain starting with a given index (currently
the starting index is 0). Will that make the thing simple?
Or the idea is still disturbing somewhere?
 

It's not just an issue of simplicity, it's an issue of

Re: [struts-chain] Writing a command to process a Tiles Definition

2003-10-02 Thread Craig R. McClanahan

Jing Zhou wrote:

- Original Message - 
From: Craig R. McClanahan [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Wednesday, October 01, 2003 11:24 AM
Subject: Re: [struts-chain] Writing a command to process a Tiles Definition

There's a conditional behavior use case in the existing code as well;
when validation fails, we want to redisplay the input form.  Originally,
I modelled this command as a Chain that conditionally executed its child
commands, but that seemed a little hokey.  Now, this command definition
says:
   command

className=org.apache.struts.chain.servlet.ValidateActionForm

 failureCommand=servlet-validation-failure/

so I'm declaring the name of another chain to go execute if validation
fails.  The actual code that does the conditional execution looks like
this (in the abstract base class):
   // Call the environment-specific protected validate() method in our
implementation class
   ActionErrors errors = validate(context, actionConfig, actionForm);
   // If there were no errors, proceed normally
   if ((errors == null) || (errors.isEmpty()) {
   return (false); // Proceed with the main chain
   }
   // Execute the specified validation failure command
   try {
   Catalog catalog = (Catalog)
 context.get(getCatalogKey());
   Command command = catalog.getCommand(getFailureCommand());
   command.execute(context);
   } catch (Exception e) {
   ... deal with exception ...
   }
   return (true); // Terminate the main chain
This approach seems more scalable -- for example, you can have several
different conditional options, you aren't binding all the behavior
definitions into a single chain definition, and you can decide based on
your needs whether to return false or true from the main command (which
dictates whether the owning chain thinks processing is complete or not).
Craig

I am wondering how I could implement a jump behavior in the main
chain. The use case for a jump behavior is that the main chain should
continue with several commands skipped over. For example, I would like
to jump to the last command in the main chain after the current command.
Any ideas?
Jing

Didn't your O-O programming classes explain to you the evils of the 
goto statement? :-)

More seriously, if I was faced with that choice, I would refactor it 
into an if decision rather than a skip decision, just like I would 
refactor any code where a goto seemed like the right answer to use an 
if instead.  Just because we're talking about scripting languages 
(which is what we're doing when we talk about using chain definitions as 
the definition of control flows) does not change the use of correct 
design principles.

Craig

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

Re: The Forrest Option

Don Brown wrote:

I know the discussion on whether to use Forrest or Maven to generate the
Struts website was a few weeks back, but unfortunately, at the time, I was
too busy to participate.  I'd like to lay out a case for Forrest, not to
insist Struts uses it, but rather to make sure the decision is made with
all the available information.
In short, Forrest offers these benefits over Maven's website generation:

- Multiple output formats including PDF and HTML
- SVG to PNG rendering
- Built for handling and aggregating multiple XML sources like RRS (soon
wiki and Docbook)
- Power and features of Cocoon including charting, web services
integration, scripting support, etc.
Further, deciding between Forrest and Maven isn't an either/or situation.
There exists a Forrest plugin for Maven and it would be easy to integrate
Maven's reports into a Forrest site build.
To me, the key feature of Forrest is the first one listed, multiple
outputs.  This is especially useful for documentation as PDF is much
better than HTML for printing for the many users that like hard copies.
Finally, Forrest content is built to be presented in not only multiple
output formats, but multiple skins.  To demonstrate this, I've quickly
redone the Struts site into Forrest format (which is very similiar to the
current format thanks to the xhtml work of late).  I've only converted the
menu and the main page, which should be sufficient.
Please note, this examples are not polished and only serve to demonstrate
the skinability of Forrest.
Krysalis style:   http://www.twdata.org/dakine/site/
Avalon/Tigris style:  http://www.twdata.org/dakine/site1/
Forrest/XML Apache style: http://www.twdata.org/dakine/site2/
If we did decide to go with Forrest, I'm willing to convert the old site
over and help handle any integration.  I'm most definately not an expert
at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty
easy.
 

Looking at the potential here, I'm inclined to suggest we accept Don's 
offer to help set this up -- although perhaps at first in a standalone 
directory structure that can be undone if we discover that we don't like 
it.  One advantage is that we can do it without having to migrate the 
build system to Maven first.

As for skins, I sure like the Avalon/Tigris or Krysalis examples, and 
sure wonder why the Forrest developers chose the native style they ship 
with, when they could do something as nice looking as either of these.  
But, if I understand what you're saying, skins is essentially a runtime 
(when you're generating the HTML) choice; we don't have to make an 
irrevocable decision at any point in time.

Don
 

Craig



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

Re: [struts-chain] Writing a command to process a Tiles Definition

Greg Reddin wrote:

I'm trying to write a Command or set of Commands that will process a 
Tiles definition to help complete the 1.x-compatible chained request 
processor.  I've got something working, but I would like some 
community input before I submit it.

First, I created another subclass of AbstractPerformForward that looks 
like this:

// Resolve module-relative paths
if (forwardPath.startsWith(/)) {
uri = RequestUtils.forwardURL(swcontext.getRequest(),
  forwardConfig);
} else {
if (processTilesDefinition(context, forwardConfig)) {
return;
} else {
uri = forwardPath;
}
}
// Perform redirect or forward
if (forwardConfig.getRedirect()) {
if (uri.startsWith(/)) {
uri = swcontext.getRequest().getContextPath() + uri;
}
swcontext.getResponse().sendRedirect
(swcontext.getResponse().encodeRedirectURL(uri));
} else {
RequestDispatcher rd =
swcontext.getContext().getRequestDispatcher(uri);
rd.forward(swcontext.getRequest(), swcontext.getResponse());
}
You'll notice that's the same code as the other PerformForward class 
with the exception that I call processTilesDefinition().  The 
processTilesDefinition() method does the same thing as 
processTilesDefinition() in TilesRequestProcessor except that it adds 
the init() code that ensures a DefinitionsFactory is in place.  If 
processTilesDefinition() returns true we exit the command, otherwise 
we perform the standard forward logic.

There's a few problems I have with the way this is written.

First, I would like to make processTilesDefinition() its own command 
because it will be inserted here and in the replacement for 
processForward() if/when that gets supported.  But I can't make it a 
Command because it is only inserted here conditionally.  So either 1) 
PerformForward will need to be broken up into multiple commands so 
logic such as Tiles can be inserted, 2) processTilesDefinition should 
be placed in a util class so it can be called from anywhere, or 3) I 
take a different approach with Tiles and not extend 
AbstractPerformForward at all.  Maybe there's another approach.  Any 
suggestions?
There's a conditional behavior use case in the existing code as well; 
when validation fails, we want to redisplay the input form.  Originally, 
I modelled this command as a Chain that conditionally executed its child 
commands, but that seemed a little hokey.  Now, this command definition 
says:

   command className=org.apache.struts.chain.servlet.ValidateActionForm
 failureCommand=servlet-validation-failure/
so I'm declaring the name of another chain to go execute if validation 
fails.  The actual code that does the conditional execution looks like 
this (in the abstract base class):

   // Call the environment-specific protected validate() method in our 
implementation class
   ActionErrors errors = validate(context, actionConfig, actionForm);

   // If there were no errors, proceed normally
   if ((errors == null) || (errors.isEmpty()) {
   return (false); // Proceed with the main chain
   }
   // Execute the specified validation failure command
   try {
   Catalog catalog = (Catalog)
 context.get(getCatalogKey());
   Command command = catalog.getCommand(getFailureCommand());
   command.execute(context);
   } catch (Exception e) {
   ... deal with exception ...
   }
   return (true); // Terminate the main chain
This approach seems more scalable -- for example, you can have several 
different conditional options, you aren't binding all the behavior 
definitions into a single chain definition, and you can decide based on 
your needs whether to return false or true from the main command (which 
dictates whether the owning chain thinks processing is complete or not).

Secondly, there's a lot of stuff in processTilesDefinition() that 
could and probably should go into an abstract base class with a 
standard implementation like all the other commands.  Would it be 
preferable to create another abstract extension of 
AbstractPerformForward or just go down a different path altogether 
(i.e. AbstractPerformTilesForward extends AbstractPerformForward vs. 
AbstractPerformTilesForward implements Command)?  Again, it's kind of 
a problem because the Tiles functionality is executed conditionally.  
If certain conditions are not met, the standard processing occurs.  
The Command interface doesn't support if-else logic and I don't 
think that's a shortcoming.  I'd just assume write my if-else logic in 
Java as opposed to XML.
Or, factor it into separate commands that can be looked up and executed 
at the appropriate times.  Then, you're building your conditional logic 
in Java, but only the if-then-else statement itself; the actual 
straight line processing is

Re: [struts-chain] Writing a command to process a Tiles Definition

Greg Reddin wrote:

There's a conditional behavior use case in the existing code as 
well; when validation fails, we want to redisplay the input form.  
Originally, I modelled this command as a Chain that conditionally 
executed its child commands, but that seemed a little hokey.  Now, 
this command definition says:

   command 
className=org.apache.struts.chain.servlet.ValidateActionForm
 failureCommand=servlet-validation-failure/

so I'm declaring the name of another chain to go execute if 
validation fails.  The actual code that does the conditional 
execution looks like this (in the abstract base class):


I should've seen that, but didn't look hard enough.  That's pretty 
cool.  I guess, due to the way digester works, it doesn't have to be 
called failureCommand for my case.  For Tiles, I could provide any 
number of attributes like that, right?
Yes ... the attribute names just have to match up with the JavaBeans 
property names on your Command implementation classes (we're using 
Digester's Set Property Rule).


I suspect there is a lot of useful refactoring to be had in order to 
employ chain underneath something like Tiles; 


I bet you're right.  For now, I'm just pasting existing functionality 
inline to make sure I understand how it works and what it's doing. 
That's why I'm reluctant to submit it yet.  I'd hate to submit 
something that gets committed and locks us into an approach when 
refactoring would produce something better.  I'll look at it some more.
I've found that experimenting has worked a lot better once I started 
doing it in the open :-).

Seriously, as long as we play in the contrib/struts-chain directory, 
people will understand that this is an actively developing idea, not a 
stable framework on which to build apps -- at least not yet.  We're all 
learning how to apply the chain concepts, and working out what design 
patterns and idioms make the most sense.  It'll go better for everyone 
if we share that learning experience; and it's more fun to boot.

That's a long winded way of saying I'd welcome the work you're doing 
being part of the contrib/struts-chain package, if you'd like.


perhaps the best approach for development might be to go ahead and 
let TilesPlugIn configure things the way it wants, but add your own 
plugin (running after the Tiles one) to replace the configured 
RequestProcessor for executing your chain(s) instead.


The problem is that TilesPlugin throws an exception and doesn't 
configure anything if your RequestProcessor is not a 
TilesRequestProcessor.  So we'd really have to replace it with 
something that doesn't do that.

Thanks for the suggestions -- especially on the conditional processing 
thing.  I'll take a good look at that.

Greg
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: The Forrest Option