Re: When is the next release?

[Ted Husted]

I've posted a draft release plan. It's not linked but can be found here:

http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html

Since this is a transitional document, I'm not going to call for a vote 
on it this morning, but will do so later, depending on how the comments 
run.

Points of note:

* I set the roll-date for next Sunday, the 17th, which may be ambitious. 
If no one is burning to commit anything revolutionary right now, I'd be 
more comfortable with rolling this on the 24th.

* Initially, the distribution would be announced on struts-dev and not 
posted to the public distribution directory. After voting on the Alpha 
version, we would then post it publicly and announce to the other lists. 
The vote could also promote the distribution to Beta or GA, as the 
Committers deem fit.

* I've set this up as a boilerplate to outline what we need to do for an 
ongoing "point" release versus the initial "minor" release. In terms of 
Bugzilla resolutions, the document suggests that we do for the initial 
minor release (#.#.0) what we have always done. For any other point 
release, we wouldn't require that every ticket be resolved, but would 
still require that all showstoppers and tickets with patches be resolved.

* Since this would be the initial minor release for the 1.2.x series, 
the "high bar" would apply.

* I trimmed the containers to test against to Tomcat 3.3 and Tomcat 4.1, 
being the reigning References Implementations for our target platforms.

* If anyone else wants to do the Release Manager thing for 1.2.0, feel 
free to chime in -- I'm not jealous =:0)

-Ted.



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

Re: RE: SuccessAction (was RE: Addition of two new actions)

[苗启广]

ÔÚ 2003-08-08 21:15:00 ÄúдµÀ£º
>I've created some patches to try this out and attached them to Bugzilla.of you ? 
>Could you tell me ? Thanks~~
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22267
>
>Sorry about the multiple patch files, but WS Studio wouldn't play ball.
>
>I haven't touched Action...yet ;-)
>
>Steve
>
>
>
>> -Original Message-
>> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
>> Sent: August 8, 2003 8:36 PM
>> To: Struts Developers List
>> Subject: RE: SuccessAction (was RE: Addition of two new actions)
>>
>>
>> > I thought the whole point was that there would be only one forward
>> > and the action would always forward to that forward?  In that case,
>> > you could count on using the first one.
>>
>> Just thinking that if an anonymous/default ActionForward were
>> allowed, then
>> it could also be useful for other actions. In any case, it's better not to
>> allow a situation where the behaviour is unspecified.
>>
>> >> You'd probably need to add a method such as getDefaultForward()
>> >> to retrieve it.
>> >
>> > This part seems to be adding complexity to something which was meant
>> > to be very simple.
>>
>> I think it might actually be possible to reduce the visible complexity by
>> doing that. e.g.
>>
>>   >   type="org.apache.struts.actions.SuccessAction">
>>   
>>   
>>
>> SuccessAction may not now be best name, but let's stick with it for the
>> moment.
>>
>> To be really radical, we could absorb the behaviour into Action,
>> and have it
>> check for a default ActionForward and use that, if found. That way there's
>> no need for a SuccessAction at all. Then you could just do:
>>
>>   >   type="org.apache.struts.action.Action">
>>   
>>   
>>
>> If Action actually does something useful, could we go crazy and
>> default the
>> type as well?
>>
>>   
>>   
>>   
>>
>> Now that's simple. Especially if you allow a global default forward...
>>
>>   
>>
>> Probably not quite so useful, but nicely minimal!
>>
>> Steve
>>
>>
>>
>> -
>> 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]
>
>
 mqg

- SOUVENIR --- .
| Souvenir of China |
| A Good Place for You  |
`--> http://www.souvenirchina.com -'
mailto:[EMAIL PROTECTED]




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

Re: Decomposing RequestProcessor -- Some Code To Play With

[Paul Smith]

Hey guys, this is exactly what pageflow does, though it does more as well.
Oh well Im working on a white paper which describes the functionality. How
would I go about getting something into the contrib folder?


- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 11, 2003 12:23 AM
Subject: Decomposing RequestProcessor -- Some Code To Play With


> During the "Decomposing RequestProcessor" thread a while back, I hinted
> that I'd been working on some code to propose for this purpose, but had
> never had time to polish it enough to check in.  Well, I actually took a
> bunch of time this weekend for precisely that purpose, and have checked in
> two chunks of code for your viewing and toying pleasure:
>
> * A new jakarta-commons/sandbox package called "chain" that implements
>   the GoF Chain of Responsibility pattern, in a way that lets you compose
>   arbitrarily complex processing chains out of very simple classes,
>   in a variety of different contexts.  If you're familiar with Cocoon,
>   think of the "site map" pattern but without the requirement that every
>   dynamic step be an XSLT transformation.  If you're familiar with Axis,
>   think of the way you can compose Handler chains, but without the
>   restriction that it is only useful in implementing a web service.
>   Nightly builds of this package should start showing up tonight at:
>
>   http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-chain/
>
> * A new contrib package in the Struts workspace called "struts-chain"
>   that is the beginnings of a decomposition of the RequestProcessor
>   processing pipeline, but allows the overall chain to be customzied in
>   much more powerful manners than the way that subclassing
>   RequestProcessor supports.  You'll need to grab the CVS source to
>   play with this one.  None of the code actually works yet -- it is very
>   definitely a work in progress -- but I *think* we'll be able to end up
>   with something that can be added on to a Struts 1.1 distro.
>
> I won't personally have huge amounts of time to work on this over the next
> few months, but I will definitely participate in discussions and
> improvements to this code.  If it all works out, I'm going to propose
> something like this as a foundational architecture for a Struts 2.x series
> that will leverage this design pattern to support extreme customization.
>
> 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]

cvs commit: jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html ELHtmlTag.java

[dmkarr]

dmkarr  2003/08/09 17:50:47

  Modified:contrib/struts-el/src/share/org/apache/strutsel/taglib/html
ELHtmlTag.java
  Log:
  Reverting fix for compile errors.
  
  Revision  ChangesPath
  1.9   +7 -7  
jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELHtmlTag.java
  
  Index: ELHtmlTag.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELHtmlTag.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- ELHtmlTag.java9 Aug 2003 19:29:30 -   1.8
  +++ ELHtmlTag.java10 Aug 2003 00:50:47 -  1.9
  @@ -158,9 +158,9 @@
   Boolean bool= null;
   String  string  = null;
   
  -if ((string = EvalHelper.evalString("lang", getLangExpr(),
  -this, pageContext)) != null)
  -setLangExpr(string);
  +if ((bool = EvalHelper.evalBoolean("lang", getLangExpr(),
  +   this, pageContext)) != null)
  +setLang(bool.booleanValue());
   
   if ((bool = EvalHelper.evalBoolean("locale", getLocaleExpr(),
  this, pageContext)) != null)
  
  
  

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

Re: When is the next release?

[Ted Husted]

AFAIK, the consensus is that our releases should follow the same general 
process used by the Jakarta Commons and the Apache HTTP Server project.

So, for reference, I'm following

http://httpd.apache.org/dev/release.html

and

http://jakarta.apache.org/commons/releases/

but observing the HTTPD numbering system.

Right now, I intend to post a Release Plan for majority approval, either 
late tonight or early tomorrow. This Plan would include when we plan to 
roll the initial Alpha release. (I may even decided just to roll a 
release and post that along with the Plan.) We'd then vote whether to 
upgrade 1.2.1 from Alpha to Beta or General Availability (GA).

Since there are any burning reasons to ship this instantly, I'm taking 
it as a foregone conclusion that this first roll will be at least a 
Beta. I'm confident that there are not any "serious problems that 
prohibits its use", so I don't believe it will not remain an Alpha. But, 
I do suspect that there may be "problems with this release that prohibit 
its widespread adoption" -- even if it simply documenting "what to do 
now that X is deprecated". So, I was calling it a Beta release.

Once we have cleaned up the 1.2.1 roll (which I wager will only be a 
Beta), we can roll 1.2.2. Hopefully, the 1.2.2 release will merit the 
General Availability stamp. Of course, nobody knows until the vote.

Heretofore, we have rolled several version of the same "release" and 
then suffixed them B1, B2, and so forth. Moving forward (as I understand 
it), we of these releases get their own integer. If the release does not 
make it to GA, it dies on the vine, we and go onto the next number.

In practice, you often get a odd/even pattern, where the odd was the 
"beta" or "development" version and even is the stable release. Some 
communities, like Linux, Perl, and Emacs, codify this pattern. When the 
odd-beta is sufficiently patched to make it release-worthy, they roll it 
over to the next even number and release that for general availability

AFAIK, we're not enforcing the odd/even pattern or a formal "patch 
level". So, if we roll 1.2.2 and it fails to get the votes for a GA, 
we'd go on to 1.2.3, and if that passes, it becomes the next "stable" 
release, odd or not.

Of course, it would even be possible for 1.2.1 to pass a GA vote, if 
someone called for one. Personally, I think that unlikely, if only for 
documentation issues. But, others could out-vote me if the consensus 
feels differently.

The core idea is that when any of us feel brave enough to roll a 
release, we can tag CVS with the next integer, and have at it. The 
instant we tag and roll it, it's automatically an Alpha. To upgrade the 
status from Alpha to Beta, or from Alpha to GA, we need a Majority Vote 
of the Committers (At least three committers have voted positively for a 
status and that there were more positive than negative votes (three is 
our working quorum for a binding vote)).

To prevent any confusion with the CVS tags and so forth, the releases 
are immutable. Once it's rolled, it's rolled. If there's an issue that 
keeps a release from being upgraded, you either patch it, or tag and 
roll another release.

To ensure that two us don't start rolling a release at once, it's 
prudent to announce your intentions first. Depending on how formal you 
want to be, that announcement might be dubbed a "Release Plan". But the 
only thing that matters is whether the release you roll passes a 
Majority Vote to move it from Alpha to Beta or GA.

At least that's how I understand it =:0)

Since this release is not backwardly compatible with 1.1.x, having 
removed all those deprecations, we are moving to the 1.2.x release 
series. Until something compels us to go on to the 1.3.x series, we can 
make be as many "General Available" releases in this series as we need.

The current GA for Tomcat 4.1, for example, is now 4.1.27. I'm not sure, 
but I believe the GA release before .27 was .24: .25 and .26 didn't make 
the GA cut.

One point I'm fuzzy on is whether we should do 1.2.0 or 1.2.1 first. I 
had thought it would be 1.2.0, but Martin and Craig seem to be saying we 
should start with 1.2.1. Being a geek, my natural inclination was to 
start with zero. =:0)

-Ted.

Steve Raeburn wrote:

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: August 9, 2003 8:57 PM
To: Struts Developers List
Subject: Re: When is the next release?
That was my understanding as well -- we agreed to switch to the x.y.z
style that Apache HTTPD and Tomcat are using, where you post the bits and
then call for a vote on stability (alpha/beta/general availability).  It's
perfectly reasonable to have a series of "general availability" releases
with new features in the 1.2.x series, as long as we continue to maintain
backwards compatibility within it.
Therefore the first release would be 1.2.1 and we'd keep going from there.


-
To unsubscrib

DO NOT REPLY [Bug 22086] - update note on VelocityStruts in resources doc

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

update note on VelocityStruts in resources doc

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-12 00:21 ---
I updated the link and description before I noticed this bug report.  Let me
know if you'd rather use the description in the patch.

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

RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)

[Steve Raeburn]

Internationalisation doesn't/can't apply to the naming of classes.
We'd have to rewrite the whole framework for each language.

Ted raised the issue in regard to naming of the action forward, but also
addressed that point himself.

Steve

> -Original Message-
> From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED]
> Sent: August 9, 2003 3:13 AM
> To: Struts Developers List
> Subject: Re: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of
> two new actions)
>
>
> Steve Raeburn wrote:
> > I *think* we agreed to add this action. Pick a name.
> >
> > [ ] ParameterDispatchAction
> > [ ] MappingDispatchAction
> > [ ] ConfigDispatchAction
> >
> > Steve
> >
>
> What happens if English is not your mother language.
> Are you suggesting we have?
>
> ErfolgreichAction -- German
>
> ExitosAction -- Spanish
>
> If we have Global.SUCCESS_FORWARD and Global.FAILURE_FORWARD
> to represent common ActionForward names it might help.
> Ted Husted suggests such naming in his book, but if program
> your variables with name that are non-english then you
> may not agree this.
>
> --
> Peter Pilgrim
> __ _ _ _
>/ //__  // ___// ___/   +  Serverside Java
>   / /___/ // /__ / /__ +  Struts
>  / // ___// ___// ___/ +  Expresso Committer
>   __/ // /__ / /__ / /__   +  Independent Contractor
>  /___///////   +  Intrinsic Motivation
> On Line Resume
> ||
> \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.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]

cvs commit: jakarta-struts/doc/resources views.xml

[mrdon]

mrdon   2003/08/11 16:38:33

  Modified:doc/resources views.xml
  Log:
  Added Cocoon Plugin link and description
  
  Revision  ChangesPath
  1.5   +1 -0  jakarta-struts/doc/resources/views.xml
  
  Index: views.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/resources/views.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- views.xml 11 Aug 2003 23:33:19 -  1.4
  +++ views.xml 11 Aug 2003 23:38:33 -  1.5
  @@ -17,6 +17,7 @@
   http://xsltgenerator.sourceforge.net/";>Struts XSLT Code 
Generator by Shengmeng Liu - An XSLT based code generator for Struts, 
completely based on the XSLT transformation and a set of stylesheet files. Ideally, 
users can customize the stylesheet for each type of Struts files  to have templates of 
their own without having to access the source code and recompile it.
   http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html";>Boost 
Struts with XSLT and XML By Julien Mercay and Gilbert Bouzeid.
   http://jakarta.apache.org/velocity/tools/struts/";>VelocityStruts by 
the http://jakarta.apache.org/velocity";>Velocity Team. The VelocityStruts 
sub-project of http://jakarta.apache.org/velocity/tools";>Velocity Tools 
integrates Velocity with Struts and enables the use of velocity templates 
interchangeably with JSP pages for the view layer.
  +http://struts.sf.net";>Cocoon Plugin by Don Brown.  
Integrates http://cocoon.apache.org";>Apache Cocoon into the Struts 1.1+ 
framework.  Struts forwards can be passed to Cocoon to be rendered in Cocoon XML 
pipelines.  Works alongside traditional Struts forwards.
   
   
   
  
  
  

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

DO NOT REPLY [Bug 22327] New: - Action attribute of link tags does not rewrite properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Action attribute of link tags does not rewrite properly

   Summary: Action attribute of link tags does not rewrite properly
   Product: Struts
   Version: 1.1 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When action paths contain periods, the action attribute appends the .do after 
the first period.

so an action path of:  /document.get

with an 

DO NOT REPLY [Bug 21614] - RequestUtils.getActionMappingName(String) should recognize anchor

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

RequestUtils.getActionMappingName(String) should recognize anchor





--- Additional Comments From [EMAIL PROTECTED]  2003-08-11 21:40 ---
Created an attachment (id=7759)
Adds code to remove a substring starting form a pound (#) sign to the end of an Action 
pathname.

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

RE: ActionForwards, et al (was SuccessAction)

[Mike Jasnowski]

>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.

Not sure if this comment belongs in the context of here, but I'll throw it
out. We use Tiles and Tiles Controllers heavily, and one thing I dislike
about forwarding to a TileDefinition is that I cannot then easily figure out
which Action I'm forwarding to ( The path names a definition which is the
same for each view in my case).

I'm currently appending information via an extension to the ActionForward,
this extra info is then used in my controller to prepare the appropriate
data for that view.  If there was some more transparent way to do this that
would be good.

I currently have one controller per definition, which may encompass several
related views.

> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thing.




-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2003 9:47 AM
To: Struts Developers List
Subject: Re: ActionForwards, et al (was SuccessAction)


--- Ted Husted <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> > What I think we're seeing here
> > is that we've outgrown our ActionForward declarations and need some
> new
> > ones.  I'm fine with adding a SuccessAction but would really like to
> see
> > us discuss future possibilities in this area.
>
> This may not be what you meant, but I've been thinking that
> ActionForward could use a class extension point, same as ActionMapping.
>
> The idea would be to give ActionForward a type property for a Java
> class. If the property is specified, instead of just taking the path as
> it stands, the Controller would call a "prepare" method on the class,
> passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse.

This may be a good time to add an ActionContext interface instead of
passing all these individual pieces.  This would also slightly remove the
dependence on Servlet to allow us more flexibility when we look at the
Portlet API.

>
> The prepare method would return a String that the Controller would use
> for the path.
>
> This allows the ActionForward to act as a Page Controller for the path.
> If the particular page referenced by the path needs any special "chrome"
>
> the Page Controller can set that up. Or, if the path needs to be
> adjusted for Locale or device (PDA, browser, et al), then the Page
> Controller could adjust the path before returning it.
>
> If it were a virtual page, like an dynamic image, merge file, or PDF,
> the Page class could also render the Response, rather than have the
> Action do it.
>
> Right now, the Action is doing double duty. It first acts as a
> Dispatcher that acquires business resources and selects the logical
> view. But, in real life, many pages often need special runtime resources
>
> of their own. So, the Action also serves as a Page Controller for the
> page it selects. Many of us consider that a mixing of concerns, and so
> we start to use some Actions as Dispatchers and others as Page
> Controllers. Tiles also fills this gap and is essentially a hybrid of a
> Compositive View and a Page Controller framework.
>
> I'm thinking that, architecturally, the ActionForward represents some
> resource available to the application, of any type, that can be reached
> by the application's protocol. In an http environment, it's the job of a
>
> Resource object to provide a URI that the Controller can use the reach
> the actual resource. (And, in  another environment, perhaps the path
> would not be a URI.)
>
> The Action, in its purest form, represents a Dispatcher. It's the job of
>
> a Dispatcher to select which (logical) Resource will handle the
> response. When we talk about selecting between "success", "failure", or
> "glockenspiel", we're talking about dispatching.
>
> But, in real life, we often can't just dispatch to a page. The page
> needs certain resources to render, often to fill UI controls like select
>
> lists.
>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.
>
> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thin

DO NOT REPLY [Bug 22307] - Add encoding attribute to

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Add encoding attribute to 

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Enhancement
Summary|org.struts.bean.IncludeTag  |Add encoding attribute to
   |encoding|

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

Re: RE: SuccessAction (was RE: Addition of two new actions)

[苗启广]

ÔÚ 2003-08-08 21:15:00 ÄúдµÀ£º
>I've created some patches to try this out and attached them to Bugzilla.of you ? 
>Could you tell me ? Thanks~~
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22267
>
>Sorry about the multiple patch files, but WS Studio wouldn't play ball.
>
>I haven't touched Action...yet ;-)
>
>Steve
>
>
>
>> -Original Message-
>> From: Steve Raeburn [mailto:[EMAIL PROTECTED]
>> Sent: August 8, 2003 8:36 PM
>> To: Struts Developers List
>> Subject: RE: SuccessAction (was RE: Addition of two new actions)
>>
>>
>> > I thought the whole point was that there would be only one forward
>> > and the action would always forward to that forward?  In that case,
>> > you could count on using the first one.
>>
>> Just thinking that if an anonymous/default ActionForward were
>> allowed, then
>> it could also be useful for other actions. In any case, it's better not to
>> allow a situation where the behaviour is unspecified.
>>
>> >> You'd probably need to add a method such as getDefaultForward()
>> >> to retrieve it.
>> >
>> > This part seems to be adding complexity to something which was meant
>> > to be very simple.
>>
>> I think it might actually be possible to reduce the visible complexity by
>> doing that. e.g.
>>
>>   >   type="org.apache.struts.actions.SuccessAction">
>>   
>>   
>>
>> SuccessAction may not now be best name, but let's stick with it for the
>> moment.
>>
>> To be really radical, we could absorb the behaviour into Action,
>> and have it
>> check for a default ActionForward and use that, if found. That way there's
>> no need for a SuccessAction at all. Then you could just do:
>>
>>   >   type="org.apache.struts.action.Action">
>>   
>>   
>>
>> If Action actually does something useful, could we go crazy and
>> default the
>> type as well?
>>
>>   
>>   
>>   
>>
>> Now that's simple. Especially if you allow a global default forward...
>>
>>   
>>
>> Probably not quite so useful, but nicely minimal!
>>
>> Steve
>>
>>
>>
>> -
>> 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]
>
>
 mqg

- SOUVENIR --- .
| Souvenir of China |
| A Good Place for You  |
`--> http://www.souvenirchina.com -'
mailto:[EMAIL PROTECTED]




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

RE: ActionForwards, et al (was SuccessAction)

[Mike Jasnowski]

>This may be a good time to add an ActionContext interface instead of
>passing all these individual pieces.  This would also slightly remove the
>dependence on Servlet to allow us more flexibility when we look at the
>portlet API.

As an outside observer I would like to see something like this added. We've
already added something like you
describe to our application.

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2003 9:47 AM
To: Struts Developers List
Subject: Re: ActionForwards, et al (was SuccessAction)


--- Ted Husted <[EMAIL PROTECTED]> wrote:
> David Graham wrote:
> > What I think we're seeing here
> > is that we've outgrown our ActionForward declarations and need some
> new
> > ones.  I'm fine with adding a SuccessAction but would really like to
> see
> > us discuss future possibilities in this area.
>
> This may not be what you meant, but I've been thinking that
> ActionForward could use a class extension point, same as ActionMapping.
>
> The idea would be to give ActionForward a type property for a Java
> class. If the property is specified, instead of just taking the path as
> it stands, the Controller would call a "prepare" method on the class,
> passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse.

This may be a good time to add an ActionContext interface instead of
passing all these individual pieces.  This would also slightly remove the
dependence on Servlet to allow us more flexibility when we look at the
Portlet API.

>
> The prepare method would return a String that the Controller would use
> for the path.
>
> This allows the ActionForward to act as a Page Controller for the path.
> If the particular page referenced by the path needs any special "chrome"
>
> the Page Controller can set that up. Or, if the path needs to be
> adjusted for Locale or device (PDA, browser, et al), then the Page
> Controller could adjust the path before returning it.
>
> If it were a virtual page, like an dynamic image, merge file, or PDF,
> the Page class could also render the Response, rather than have the
> Action do it.
>
> Right now, the Action is doing double duty. It first acts as a
> Dispatcher that acquires business resources and selects the logical
> view. But, in real life, many pages often need special runtime resources
>
> of their own. So, the Action also serves as a Page Controller for the
> page it selects. Many of us consider that a mixing of concerns, and so
> we start to use some Actions as Dispatchers and others as Page
> Controllers. Tiles also fills this gap and is essentially a hybrid of a
> Compositive View and a Page Controller framework.
>
> I'm thinking that, architecturally, the ActionForward represents some
> resource available to the application, of any type, that can be reached
> by the application's protocol. In an http environment, it's the job of a
>
> Resource object to provide a URI that the Controller can use the reach
> the actual resource. (And, in  another environment, perhaps the path
> would not be a URI.)
>
> The Action, in its purest form, represents a Dispatcher. It's the job of
>
> a Dispatcher to select which (logical) Resource will handle the
> response. When we talk about selecting between "success", "failure", or
> "glockenspiel", we're talking about dispatching.
>
> But, in real life, we often can't just dispatch to a page. The page
> needs certain resources to render, often to fill UI controls like select
>
> lists.
>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.
>
> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thing.

I've had similar composition problems and agree that a separation makes
sense.  Tiles Controllers can be used to setup page data but that doesn't
always work (especially if you're not using Tiles :-) so I end up chaining
actions.  None of the action chaining is due to bus. logic as that's
properly factored into a Service layer; it has to do purely with setting
up page data.

Tiles Controllers are one of the major reasons I use Tiles and I think
it's appropriate to move that concept into the Struts core.

David

>
> The "gotcha" is that, to do its job, the ActionForward type may also
> need to interact with the business layer. It doesn't seem right that the
>
> Page Controller should try to branch to another page, like an Action
> might, if there's an error. But the declarative exception handling might
>
> be able to step in here.
>
> -Ted.
>
> --
> Ted Husted,
>Junit in Action  - 

RE: When is the next release?

[Edgar Dollin]

The users of struts can understand 1.2.1 w/o 1.2.0, most of use are also
using tomcat as well and most of us skip releases.  If it takes extra
time for no other benefit than to keep things neet, it is probably not
worth the effort.

Edgar

> -Original Message-
> From: Steve Raeburn [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, August 09, 2003 11:12 PM
> To: 'Struts Developers List'
> Subject: RE: When is the next release?
> 
> 
> 
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> > Sent: August 9, 2003 8:57 PM
> > To: Struts Developers List
> > Subject: Re: When is the next release?
> >
> > That was my understanding as well -- we agreed to switch to 
> the x.y.z 
> > style that Apache HTTPD and Tomcat are using, where you 
> post the bits 
> > and then call for a vote on stability (alpha/beta/general 
> > availability).  It's perfectly reasonable to have a series 
> of "general 
> > availability" releases with new features in the 1.2.x 
> series, as long 
> > as we continue to maintain backwards compatibility within it.
> >
> > Therefore the first release would be 1.2.1 and we'd keep going from 
> > there.
> 
> I think it would be strange to go directly to a 1.2.1 
> release, which I suspect is why Ted was talking about a beta. 
> Tomcat has a 4_1_0 tag in CVS, but I don't know if that was 
> released as such.
> 
> It's not my intention to reopen an old discussion, but I 
> would like to confirm exactly what version this will be.
> 
> Steve
> 
> >
> >
> > 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]

DO NOT REPLY [Bug 22252] New: - Locale ignored on MessageResources.getMessage(String arg0)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

Locale ignored on MessageResources.getMessage(String arg0)

   Summary: Locale ignored on MessageResources.getMessage(String
arg0)
   Product: Struts
   Version: 1.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


protected MessageResources messages =
MessageResources.getMessageResources("SomeResource.properties");

messages.getMessage(title); // delivers NO localized result but
messages.getMessage(title, null); // works fine!

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

DO NOT REPLY [Bug 19420] - BaseHandlerTag should use its getter methods

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

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

BaseHandlerTag should use its getter methods

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-07 00:52 ---
In most cases the accessors were already being used but I cleaned up the 
remaining direct references.

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

cvs commit: jakarta-struts/src/share/org/apache/struts/plugins DigestingPlugIn.java

[dgraham]

dgraham 2003/08/06 21:01:41

  Added:   src/share/org/apache/struts/plugins DigestingPlugIn.java
  Log:
  Added DigestingPlugIn from PR# 18127.
  
  Revision  ChangesPath
  1.1  
jakarta-struts/src/share/org/apache/struts/plugins/DigestingPlugIn.java
  
  Index: DigestingPlugIn.java
  ===
  /*
   * $Header$
   * $Revision$
   * $Date$
   *
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 2003 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Struts", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   */
  
  package org.apache.struts.plugins;
  
  import java.io.File;
  import java.io.IOException;
  import java.net.URL;
  
  import javax.servlet.ServletException;
  
  import org.apache.commons.digester.Digester;
  import org.apache.commons.digester.RuleSet;
  import org.apache.commons.digester.xmlrules.DigesterLoader;
  import org.apache.commons.logging.Log;
  import org.apache.commons.logging.LogFactory;
  import org.apache.struts.action.ActionServlet;
  import org.apache.struts.action.PlugIn;
  import org.apache.struts.config.ModuleConfig;
  import org.apache.struts.util.RequestUtils;
  import org.xml.sax.SAXException;
  
  /**
   * An implementation of PlugIn which
   * can be configured to instantiate a graph of objects
   * using the Commons Digester and place the root object
   * of that graph into the Application context.
   * 
   * @author Joe Germuska
   * @author David Graham
   * @version $Revision$
   * @see PlugIn
   */
  public class DigestingPlugIn implements PlugIn {
  
  /**
   * Commons Logging instance.
   */
  private static Log log = LogFactory.getLog(DigestingPlugIn.class);
  
  protected static final String SOURCE_CLASSPATH = "classpath";
  
  protected static final String SOURCE_FILE = "file";
  
  protected static final String SOURCE_SERVLET = "servlet";
  
  protected String configPath = null;
  
  protected String configSource = null;
  
  protected String digesterPath = null;
  
  protected String digesterSource = null;
  
  protected String key = null;
  
  protected ModuleConfig moduleConfig = null;
  
  protected String ruleSets = null;
  
  protected ActionServlet servlet = null;
  
  protected boolean push = false;
  
  /**
   * Constructor for DigestingPlugIn.
   */