svn commit: r379038 - /struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java

[craigmcc]

Author: craigmcc
Date: Sun Feb 19 22:51:50 2006
New Revision: 379038

URL: http://svn.apache.org/viewcvs?rev=379038&view=rev
Log:
Call FactoryFinder.releaseFactories() at the end of tearDown() in addition
to the beginning of setUp() in case test methods are playing fast and loose
with JUnit test lifecycle methods.

Modified:

struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java

Modified: 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java?rev=379038&r1=379037&r2=379038&view=diff
==
--- 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java
 (original)
+++ 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java
 Sun Feb 19 22:51:50 2006
@@ -157,6 +157,7 @@
 response = null;
 servletContext = null;
 session = null;
+FactoryFinder.releaseFactories();
 
 }
 



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

Re: Reasons for 1.3 release

[Dakota Jack]

On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
>
> >
> > If I understand correctly, in CoR pattern a client calls the chain
> > head and "the request propagates along the chain until a
> > ConcreteHandler object takes responsibility for handling it." (GoF)
>
>
> That's the most important sentence in the GoF description ... and the one
> that motivated the API design for a Comman in Commons Chain.
>
> 

Craig is sure right that this is the most important sentence.  It is the one
that keeps each link in the chain ignorant of the rest.  Now, go look at
ChainBase in commons and you will see that this is NOT the API design in
commons chain.  The Command, hopefully, but NOT, would be part of a command
pattern.  ChainBase, NOT Command, hopefully, but NOT, would be part of a
chain pattern.


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: Reasons for 1.3 release

[Dakota Jack]

Here is the ChainBase execute method, gentlemen.  If you think that is CoR,
then I have nothing further to say.  This is the real "pattern".  It is not
even OOP.  It merely uses a class as a repository to do C coding.


// Documented in Chain interface
public boolean execute(Context context) throws Exception {

// Verify our parameters
if (context == null) {
throw new IllegalArgumentException();
}

// Freeze the configuration of the command list
frozen = true;

// Execute the commands in this list until one returns true
// or throws an exception
boolean saveResult = false;
Exception saveException = null;
int i = 0;
int n = commands.length;;
for (i = 0; i < n; i++) {
try {
saveResult = commands[i].execute(context);
if (saveResult) {
break;
}
} catch (Exception e) {
saveException = e;
break;
}
}

// Call postprocess methods on Filters in reverse order
if (i >= n) { // Fell off the end of the chain
i--;
}
boolean handled = false;
boolean result = false;
for (int j = i; j >= 0; j--) {
if (commands[j] instanceof Filter) {
try {
result =
((Filter) commands[j]).postprocess(context,
   saveException);
if (result) {
handled = true;
}
} catch (Exception e) {
; // Silently ignore
}
}
}

// Return the exception or result state from the last execute()
if ((saveException != null) && !handled) {
throw saveException;
} else {
return (saveResult);
}

}

On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> Does "MyCommand" represent a chain in MyCatalog?  If so, while I
> wouldn't presume to speak for Craig, it sure seems like it :)  I've
> personally used the "fire a chain from an Action" in the past, but I can
> certainly see where this would be very nice.
>
> Frank
>
> Martin Cooper wrote:
> > On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > 
> >
> > The next step would be to provide customizable chains per Action
> (becoming
> >> even more like how you configure actions in WebWork) -- but you can
> even
> >> do
> >> that today by using an Action that itself executed a chain.
> >
> >
> > Craig, isn't that what we already have with:
> >
> >
> >  > catalog="MyCatalog"
> > command="MyCommand"/>
> >
> > or am I misunderstanding?
> >
> > --
> > Martin Cooper
> >
> >
> > Michael.
> >>
> >> Craig
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: Reasons for 1.3 release

[Craig McClanahan]

On 2/19/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
>
> On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >
> > Does "MyCommand" represent a chain in MyCatalog?
>
>
> Yep.
>
>   If so, while I
> > wouldn't presume to speak for Craig, it sure seems like it :)  I've
> > personally used the "fire a chain from an Action" in the past, but I can
> > certainly see where this would be very nice.
>
>
> This is what I meant when I said earlier (in this thread) that I don't
> have
> any Action classes in my 1.3 app. I don't need 'em any more, even just to
> invoke a chain.


What you describe is indeed possible today, but it has a subtle difference
in implementation requirements:

* What you can do today -- implement your Action logic as a command,
  and build a customized chain that includes it.  (That's what you have
  described as your current solution, so you won't have any migration
issues.)

* What would be nice for migrating 1.2 apps -- support some mechanism
  to customize a per-Action chain that included calling the Action.execute()
  method so it does not need to be re-implemented.

The latter would let you take an existing app and later decorate individual
actions (just like WebWork lets you add intercepters) without requiring any
change to the initial implementation of the Action itself.  That's not the
way I would ever write a new app based on Action 1.3, but it'd sure help
migrating users.

--
> Martin Cooper


Craig

Re: Reasons for 1.3 release

[Dakota Jack]

Why don't you guys just look at the code?  It is fairly simple and
straightforward.

On 2/19/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
>
> On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> > Anyone can quote chapter and verse from the GoF book.  Can you instead
> > explain *why* what's in Struts isn't CoR?  And, perhaps more
> > importantly, explain why, even if it isn't an exact match for the
> > pattern, it matters one bit?
>
> By the way, is Struts CoR actually a CoR? This is not a trick
> question, I am just asking.
>
> If I understand correctly, in CoR pattern a client calls the chain
> head and "the request propagates along the chain until a
> ConcreteHandler object takes responsibility for handling it." (GoF)
>
> In Struts Classic prior to 1.3 a client calls a concrete action (which
> is why I consider Struts Classic to *not* be an implementation of
> Front Controller pattern). It is possible to stick additional
> processing before the action class is called. Though it is not as easy
> as in WebWork, it  is possible. So, Struts Classic implements
> Interceptor pattern, not Chain of Responsibility.
>
> So, how the whole thing works in 1.3? A client still calls a
> particular mapping like in older Struts versions, right? Does this
> mapping define a head of chain (CoR) or an end of chain
> (interceptors)? If it defines the head of chain, is it still possible
> to sneak interceptors into an arbitrary chain?
>
> Michael.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: Reasons for 1.3 release

[Dakota Jack]

Responses are following  of your remarks, Frank.


Anyone can quote chapter and verse from the GoF book.  Can you instead
explain *why* what's in Struts isn't CoR?


I assumed you had looked at the code, and in case you had not, encouraged
you to do so and even indicated where the problem was by telling you there
were "Iterations".


And, perhaps more
importantly, explain why, even if it isn't an exact match for the
pattern, it matters one bit?


If you think that there are "exact" and "inexact" "matches" for patterns, as
if this were something like a pattern for making a dress, then I don't have
much to say.  Patterns don't work like that in software development.


Would you deny that that the flexibility of the chain approach,
regardless of it's "correctness" as far as pattern implementation goes,
doesn't make Struts better?  THAT is what I care about, and likely most
other developers would care about.


I in fact said it was flexible.  So are POJOs.  If you don't care if it is
CoR or not and want to call it "CoR" whether it is or not, go ahead.  I
cannot say I would trust a developer much who used basic pattern names
wrong.  But, if you are comfortable not understanding what you say or what
you are talking about, you and your "other developer[]" friends can have at
it.  I work and live in development communities and we damn sure do care
about being precise and knowing what we talk about.


I'm not writing my thesis on why or
why not Struts implements this pattern or that pattern as advertised,
I'm interested in whether it makes my life better, and I for one am
convinced the chain approach does.  If you disagree, that's fine, I
would like to hear why, but with specifics, not by quoting a theoretical
abstraction.


If you have decided that the GoF book is a "theoretical abstraction", then
you and I probably have very little to discuss.  If you don't care if it is
CoR or not, I have no idea why you responded to the note that it is not,
which it is not.  If you think understanding and employing design patterns
in a wise way is an academic "thesis" matter, then you are running in a very
different development crowd than I am.  If you said anything like that where
I work, they would be shocked.  We don't write theses around here.  We write
code.  Good code and we know what patterns we are using.

Actually, the reason Struts has to be tossed is just because it is a mess in
regard to the flexibility and the use of deep level design patterns.  Maybe
it is easy to use, but so are lots of bad ideas.  Had Struts used a Strategy
pattern instead of whatever that is that they have now, it might have had a
chance to use AOP, and other cook features that this code won't help.  It is
easy to code, that is true.  It is flexible as hell in the sense that anyone
with any sense can code it and it is easy to change in the concrete
classes.  There are much deeper problems which it not only does not address
but exascerbates.

Why don't you look at the code and see where there is iteration?  I don't
think I should have to go to the code and show you.  If you insist you don't
want to even look at the code and still defend it, then that's your
perogative.






--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack

DO NOT REPLY [Bug 38711] - MockFacesContext, FaceContext.getCurrentInstance left over

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=38711





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 06:21 ---
Created an attachment (id=17743)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17743&action=view)
one line fix


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 38711] New: - MockFacesContext, FaceContext.getCurrentInstance left over

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=38711

   Summary: MockFacesContext, FaceContext.getCurrentInstance left
over
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


The current faces context is set to null in MockFacesContext.release(), but 
this is not called because there is always a reference to it.  This interferes 
w/ other subsequent tests in a test suites who assume the current context is 
null.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Reasons for 1.3 release

[Gary VanMatre]

>From: "Martin Cooper" <[EMAIL PROTECTED]> 
>
> On 2/19/06, Frank W. Zammetti wrote: 
> > 
> > Does "MyCommand" represent a chain in MyCatalog? 
> 
> 
> Yep. 
> 
> If so, while I 
> > wouldn't presume to speak for Craig, it sure seems like it :) I've 
> > personally used the "fire a chain from an Action" in the past, but I can 
> > certainly see where this would be very nice. 
>

Ya, this is good stuff.  I'm looking forward to the 1.3 version.  We are 
waiting to upgrade from 1.1.  I hope it's cut soon.

 
> 
> This is what I meant when I said earlier (in this thread) that I don't have 
> any Action classes in my 1.3 app. I don't need 'em any more, even just to 
> invoke a chain. 
> 
> -- 
> Martin Cooper 
> 
> 
> Frank 
> > 
> > Martin Cooper wrote: 
> > > On 2/19/06, Craig McClanahan wrote: 
> > > 
> > > 
> > > The next step would be to provide customizable chains per Action 
> > (becoming 
> > >> even more like how you configure actions in WebWork) -- but you can 
> > even 
> > >> do 
> > >> that today by using an Action that itself executed a chain. 
> > > 
> > > 
> > > Craig, isn't that what we already have with: 
> > > 
> > > 
> > > > > > catalog="MyCatalog" 
> > > command="MyCommand"/> 
> > > 
> > > or am I misunderstanding? 
> > > 
> > > -- 
> > > Martin Cooper 
> > > 
> > > 
> > > Michael. 
> > >> 
> > >> Craig 
> > >> 
> > >> 
> > > 
> > 
> > - 
> > To unsubscribe, e-mail: [EMAIL PROTECTED] 
> > For additional commands, e-mail: [EMAIL PROTECTED] 
> > 
> > 
> 

Re: Reasons for 1.3 release

[Martin Cooper]

On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> Does "MyCommand" represent a chain in MyCatalog?


Yep.

  If so, while I
> wouldn't presume to speak for Craig, it sure seems like it :)  I've
> personally used the "fire a chain from an Action" in the past, but I can
> certainly see where this would be very nice.


This is what I meant when I said earlier (in this thread) that I don't have
any Action classes in my 1.3 app. I don't need 'em any more, even just to
invoke a chain.

--
Martin Cooper


Frank
>
> Martin Cooper wrote:
> > On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > 
> >
> > The next step would be to provide customizable chains per Action
> (becoming
> >> even more like how you configure actions in WebWork) -- but you can
> even
> >> do
> >> that today by using an Action that itself executed a chain.
> >
> >
> > Craig, isn't that what we already have with:
> >
> >
> >  > catalog="MyCatalog"
> > command="MyCommand"/>
> >
> > or am I misunderstanding?
> >
> > --
> > Martin Cooper
> >
> >
> > Michael.
> >>
> >> Craig
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Reasons for 1.3 release

[Frank W. Zammetti]

Does "MyCommand" represent a chain in MyCatalog?  If so, while I 
wouldn't presume to speak for Craig, it sure seems like it :)  I've 
personally used the "fire a chain from an Action" in the past, but I can 
certainly see where this would be very nice.


Frank

Martin Cooper wrote:

On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:


The next step would be to provide customizable chains per Action (becoming

even more like how you configure actions in WebWork) -- but you can even
do
that today by using an Action that itself executed a chain.



Craig, isn't that what we already have with:




or am I misunderstanding?

--
Martin Cooper


Michael.


Craig






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

Re: Reasons for 1.3 release

[Martin Cooper]

On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:


The next step would be to provide customizable chains per Action (becoming
> even more like how you configure actions in WebWork) -- but you can even
> do
> that today by using an Action that itself executed a chain.


Craig, isn't that what we already have with:




or am I misunderstanding?

--
Martin Cooper


Michael.
>
>
> Craig
>
>

Re: Reasons for 1.3 release

[Craig McClanahan]

On 2/19/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
>
> On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> > Anyone can quote chapter and verse from the GoF book.  Can you instead
> > explain *why* what's in Struts isn't CoR?  And, perhaps more
> > importantly, explain why, even if it isn't an exact match for the
> > pattern, it matters one bit?
>
> By the way, is Struts CoR actually a CoR? This is not a trick
> question, I am just asking.
>
> If I understand correctly, in CoR pattern a client calls the chain
> head and "the request propagates along the chain until a
> ConcreteHandler object takes responsibility for handling it." (GoF)


That's the most important sentence in the GoF description ... and the one
that motivated the API design for a Comman in Commons Chain.

In Struts Classic prior to 1.3 a client calls a concrete action (which
> is why I consider Struts Classic to *not* be an implementation of
> Front Controller pattern).


Almost, but not quite ... there was always processng going on before and
after the call to the action, and you couldn't bypass it except where Struts
allowed you to explictly configure bypassing it (like turning off
validation).  For someone who doesn't use form beans (like you, Michael? :-)
there isn't a lot actually done there, but it does exist.

It is possible to stick additional
> processing before the action class is called. Though it is not as easy
> as in WebWork, it  is possible. So, Struts Classic implements
> Interceptor pattern, not Chain of Responsibility.


The standard versions of Struts before 1.3 indeed do not use CoR (although
you could use a CoR based implementation of RequestProcessor from the
sandbox in 1.2.x).

So, how the whole thing works in 1.3? A client still calls a
> particular mapping like in older Struts versions, right? Does this
> mapping define a head of chain (CoR) or an end of chain
> (interceptors)? If it defines the head of chain, is it still possible
> to sneak interceptors into an arbitrary chain?


The primary change in 1.3 is to re-implement the standard request processor
pipeline as a chain instead of a monolithic single class (in other words,
promoting the sandbox CoR implementation into the mainstream).  So, the use
of a chain is just an *implementation detail* that does not change the
"Front Controller" nature of the original framework.  But it's now much
easier to customize the framework's behavior for all requests, by adjusting
the definition of the standard chain and/or utilizing optional call-outs to
applicaton defined chains.

The next step would be to provide customizable chains per Action (becoming
even more like how you configure actions in WebWork) -- but you can even do
that today by using an Action that itself executed a chain.

Michael.


Craig

svn commit: r378996 - /struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java

[craigmcc]

Author: craigmcc
Date: Sun Feb 19 17:13:21 2006
New Revision: 378996

URL: http://svn.apache.org/viewcvs?rev=378996&view=rev
Log:
Create an empty TestSuite instead of one that analyzes AbstractJsfTestCase
for test methods (there will not be any).

Modified:

struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java

Modified: 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java?rev=378996&r1=378995&r2=378996&view=diff
==
--- 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java
 (original)
+++ 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/base/AbstractJsfTestCase.java
 Sun Feb 19 17:13:21 2006
@@ -138,7 +138,7 @@
 // Return the tests included in this test case.
 public static Test suite() {
 
-return (new TestSuite(AbstractJsfTestCase.class));
+return (new TestSuite());
 
 }
 



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

Re: Weird ClassCastException

[Craig McClanahan]

On 2/19/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> One other thing.  I believe we should change the suite() method in
> AbstractJsfTestCase to return new TestSuite().
>
> I had an abstract test class of my own that extended
> AbstractJsfTestCase but I didn't have the suite method thinking - hey
> this is abstract anyways so what is there to test.  Well maven2 threw
> an assertion error that there were no test methods in the class.  I
> only had this with maven2.  When running in the IDE - no problems.
>
> I believe Shale will have the same problem when it eventually switches
> to maven2 for the build.  An empty TestSuite seems to do the trick
> though.


Makes sense ... this will show up in nightly build 20060220.

Sean


Craig

DO NOT REPLY [Bug 38482] - [shale] clay enhancement - reusable clay components

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=38482





--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 01:51 ---
(In reply to comment #14)
> No longer dependent on myfaces.  Includes almost all of the same 
functionality 
> except for data scrolling. Example web app shown working with sun reference 
> impl. 

I believe that we are just waiting on Ryan Wynn to complete the Individual 
Contributor License Agreement (http://www.apache.org/licenses/icla.txt) before 
pulling this in as a Clay example.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37615] - Clay attributes are not using xml namespaces

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=37615


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37800] - Loading full view XML templates on startup

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=37800


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 01:43 ---
This support was added 20051230.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37792] - Two symbols cannot share the same 'prefix'

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=37792


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 38593] - [shale] ValidatorScript does not find validators in facets

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=38593


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-02-20 01:33 ---
Fix for this will be in the 20060220 nightly build.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r378988 - /struts/shale/trunk/core-library/src/java/org/apache/shale/component/ValidatorScript.java

[gvanmatre]

Author: gvanmatre
Date: Sun Feb 19 16:32:17 2006
New Revision: 378988

URL: http://svn.apache.org/viewcvs?rev=378988&view=rev
Log:
Fix for bug# 38593 - ValidatorScript does not find validators in facets.

Modified:

struts/shale/trunk/core-library/src/java/org/apache/shale/component/ValidatorScript.java

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/component/ValidatorScript.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/component/ValidatorScript.java?rev=378988&r1=378987&r2=378988&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/component/ValidatorScript.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/component/ValidatorScript.java
 Sun Feb 19 16:32:17 2006
@@ -132,11 +132,12 @@
  }
   }
 
-  List children = c.getChildren();
-  for (int i = 0; i < children.size(); i++) {
- UIComponent child = (UIComponent) children.get(i);
+  Iterator childrenIterator = c.getFacetsAndChildren();
+  while (childrenIterator.hasNext()) {
+ UIComponent child = (UIComponent) childrenIterator.next();
  findCommonsValidators(child, context);
-  }  
+  }  
+  childrenIterator = null;
}
 
 



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

DO NOT REPLY [Bug 38542] - [shale] clay not handling binding attribute correctly

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=38542


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Bug report for Struts [2006/02/19]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 5739|Opn|Enh|2002-01-08|Struts fails silently in too many places  |
| 5937|New|Enh|2002-01-21|[taglib] html:form trims all extensions   |
| 6847|New|Enh|2002-03-04|Multiple file upload not possible due to MultiPart|
| 7902|Opn|Enh|2002-04-10|The exception handling declaration in the DTD does|
| 8240|Ver|Min|2002-04-18|Data-Source configuration in examples is outdated |
| 9088|Opn|Enh|2002-05-15|FormTag.getActionMappingURL() assumes 1 servlet ma|
| 9616|New|Enh|2002-06-05|Some more Struts docs |
| 9748|New|Enh|2002-06-10|[taglib] attribute labelKeyProperty for Options ta|
|10550|New|Enh|2002-07-08|Delegate path-management to ActionForwards|
|10552|New|Enh|2002-07-08|create helper objects in struts-config|
|10867|Opn|Enh|2002-07-16|[taglib] Add indexedProperty attribute in html tag|
|11154|Opn|Enh|2002-07-25|[taglib] html:link tag extension for multiple para|
|11733|Opn|Enh|2002-08-15|Make error keys more specific |
|12170|Opn|Enh|2002-08-29|Added functionality when extending another definit|
|12301|Opn|Enh|2002-09-04|[taglib] nested:messages Tag does not work as expe|
|12600|New|Enh|2002-09-12|[taglib] html:form tag always prepends context pat|
|13125|Opn|Enh|2002-09-30|[taglib] Lack of character-set while using   forwardPattern should support differe|
|16708|New|Enh|2003-02-03|I18N on ActionForwards|
|16764|Opn|Enh|2003-02-04|No inheritance of html:html xhtml="true" in includ|
|16792|Ass|Enh|2003-02-05|Migrate to commons-resources for message resources|
|16814|New|Enh|2003-02-05|Add a generalized utililty class to expose informa|
|16946|Opn|Enh|2003-02-10|SwitchAction not setting context properly for tile|
|16971|New|Enh|2003-02-11|[taglib] "multiple" attribute on select tag should|
|17368|Opn|Enh|2003-02-25|[taglib]  multiple does not populate |
|17449|New|Enh|2003-02-26|[taglib] Allow relative URL in action attribute of|
|17473|New|Enh|2003-02-27|[taglib] Problem to include a jsp into an iterate |
|17530|New|Enh|2003-02-28|RequestUtils.computeURL should use the session ass|
|17559|New|Enh|2003-03-01|[tiles] key attribute for tiles (put & item)  |
|17600|New|Enh|2003-03-03|[taglib] key property for html:optionsCollection t|
|17698|Opn|Enh|2003-03-05|The value(key) form name pattern doesn't work with|
|18015|Opn|Enh|2003-03-14|[taglib] New  custom tag to write form|
|18017|Opn|Enh|2003-03-14|[tiles] extends fails in JSP-based Definitions|
|18022|New|Enh|2003-03-14|HttpSessionBindingListener.valueUnbound() called o|
|18032|Opn|Enh|2003-03-16|[taglib]  tag appending session doesn't |
|18194|Opn|Enh|2003-03-20|[resources] Enhance MessageResources to enable sev|
|18237|Opn|Enh|2003-03-21|[tiles] excessive memory usage|
|18293|New|Enh|2003-03-24|Loading language files does not use Resource Bundl|
|18788|New|Enh|2003-04-07|Multiple input hook for multipage forms in process|
|18981|New|Enh|2003-04-13|[upload] File upload maximum size validator   |
|19346|New|Enh|2003-04-26|Errors and Messages should be easier to manage|
|19539|New|Enh|2003-05-02|Add checks for List and Map-backed properties in D|
|19631|New|Enh|2003-05-04|Enhancements to RequestUtils tests|
|19812|New|Enh|2003-05-10|[taglib] BaseFieldTag don't use ConvertUtils as St|
|19903|New|Enh|2003-05-13|Field considered valid if no ActionError created  |
|19925|New|Enh|2003-05-14|Server side solution for DispatchAction and : Make value optional when id|
|21508|New|Enh|2003-07-11|[tiles]  element too restrictive|
|21512|New|Enh|2003-07-11|exception tag's path attribute accepts only web re|
|21514|New|Enh|2003-07-11|[taglib] html:form focus function could be more po|
|21517|New|Enh|2003-07-11|[tiles] definition's put tag works in non-standard|
|21575|New|Enh|2003-07-14|RequestProcessor : Populating non-String Bean fiel|
|21624|Opn|Enh|2003-07-15|Extend TokenProcessor to handle a list of tra

Re: Reasons for 1.3 release

[Michael Jouravlev]

On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Anyone can quote chapter and verse from the GoF book.  Can you instead
> explain *why* what's in Struts isn't CoR?  And, perhaps more
> importantly, explain why, even if it isn't an exact match for the
> pattern, it matters one bit?

By the way, is Struts CoR actually a CoR? This is not a trick
question, I am just asking.

If I understand correctly, in CoR pattern a client calls the chain
head and "the request propagates along the chain until a
ConcreteHandler object takes responsibility for handling it." (GoF)

In Struts Classic prior to 1.3 a client calls a concrete action (which
is why I consider Struts Classic to *not* be an implementation of
Front Controller pattern). It is possible to stick additional
processing before the action class is called. Though it is not as easy
as in WebWork, it  is possible. So, Struts Classic implements
Interceptor pattern, not Chain of Responsibility.

So, how the whole thing works in 1.3? A client still calls a
particular mapping like in older Struts versions, right? Does this
mapping define a head of chain (CoR) or an end of chain
(interceptors)? If it defines the head of chain, is it still possible
to sneak interceptors into an arbitrary chain?

Michael.

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

DO NOT REPLY [Bug 35703] - [tiles] TilesUtilImpl doInclude() should call TilesRequestProcessor doInclude()... but it doesn't

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35703





--- Additional Comments From [EMAIL PROTECTED]  2006-02-19 19:20 ---
(In reply to comment #17)
> I appreciate that you've taken the trouble to do the patch and provide a 
> sample webapp, but I am still against your proposal.

No problem, glad to bring my 2 cents, especially for something that I believe 
is 
worth it.

> As I said in comment #5 IMO these tiles "util" classes should not call the 
> RequestProcessor.

Remember that comment #5 was regarding putting the fix in TilesUtil which was 
wrong - I agreed with that. And this was fixed in a second release of the patch 
(see comment #6).

> Also as I said in comment #5 you can override the tiles util implementation 
> used to provide your own custom processing to resolve this.

It just won't work because of a broken link in current Tiles/Struts integration.
This is documented in Test Phase 1 in comment #16.
TilesRequestProcessor would need to be patched (first part of the proposed 
patch) for that to work.

Re-assuming it in a few words: 
take a Struts web application using a custom RequestProcessor which overrides 
doInclude() and bring Tiles into it. Then, your implementation of doInclude() 
will never get called any more for any of your tiles.
Is that ok with you ?
Well it isn't with me.

> I still think we should close this as WONTFIX.
Sorry for being such a pain keeping on insisting on that one, but since this is 
a blocking issue in current Tiles/Struts integration WONTFIX isn't an answer.
If we come up with a better solution than the proposed patch that's fine for 
me. 
But in any case we do need to come up with a proper solution and I'm not giving 
up until we do.

Tx 
Patrick

P.S.: to be honest I still don't understand why you don't like the idea of 
putting the fix in TilesUtilStrutsImpl and TilesUtilStrutsModuleImpl as a 
default behaviour, everyone being free to change this default behaviour by 
overriding these classes, rather than forcing everyone to implement something 
to 
get this to work!

The above 2 classes are already there to make the glue between Tiles and 
Struts, 
as a default implementation, so I don't see the point of not using them for 
what 
they were originally meant for (again look at the Javadoc comments in 
TilesUtilStrutsModuleImpl).


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r378934 - /struts/shale/trunk/xdocs/features-reusable-views.xml

[gvanmatre]

Author: gvanmatre
Date: Sun Feb 19 10:03:05 2006
New Revision: 378934

URL: http://svn.apache.org/viewcvs?rev=378934&view=rev
Log:
Updated a couple sections on clay options and reuse features.

Modified:
struts/shale/trunk/xdocs/features-reusable-views.xml

Modified: struts/shale/trunk/xdocs/features-reusable-views.xml
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/xdocs/features-reusable-views.xml?rev=378934&r1=378933&r2=378934&view=diff
==
--- struts/shale/trunk/xdocs/features-reusable-views.xml (original)
+++ struts/shale/trunk/xdocs/features-reusable-views.xml Sun Feb 19 10:03:05 
2006
@@ -288,89 +288,200 @@
sophisticated symbol replacement than the managed bean example 
discussed above.

 
-  
-  
-
-There are three options for creating the Clay component subtree.
-
-
-The Clay subtree can be formed by strictly using a XML 
configuration
-that resembles JSF/JSP tags.  The meta-data used to define a
-component is similar to Tiles. It provides composition and allows
-for inheritance relationships.  Clay's approach is unique. The
-granularity is targeted at the declaration of JSF components versus
-composition of JSP fragments.
-
-
-
-The subtree can be formed using a Tapestry like HTML layout.  HTML
-elements are bound to corresponding JSF components using a
-jsfid attribute. This attribute binds the HTML mock-up
-with a component declared in the Clay view configuration files.
-Some HTML elements, such as the FORM element,
-have an implied mapping to a JSF component.  If the mapping is
-not explicitly declared using the jsfid attribute and
-there is not an assumed mapping, the default mapping is to the 
-standard verbatim (ouputText) component.
-This combines the first option's component definitions
-with the flexibility of using HTML for layout. 
-
-
-
-The subtree can also be defined at runtime.  The Clay component
-provides a postback validation method event,
-shapeValidator, that can be bound to the associated
-ViewController. The event is fired on the
-ViewController when the subtree is first created.
-Responding to this event, the view controller will construct a
-graph of objects used by the Clay component to build the
-subcomponent tree.   The object's graph is representative of
-the first two declarative approaches.
-
-
-
-
-
-Each of these options is demonstrated in the Shale Use Cases
-example application.  The Clay "Rolodex" is shown below:
-
-
+
+
+
+There are four options for creating the Clay component subtree.
+
+   The Clay subtree can be formed by strictly using a XML configuration 
that resembles JSF/JSP 
+  tags. The XML configuration provides the maximum reuse. The 
meta-data used to define a component 
+  is similar to Tiles. There can be multiple files defined but there 
is always a default loaded from 
+  within the shale clay java archive.  It provides composition and 
allows for inheritance relationships. 
+  Clay's approach is unique. The granularity is targeted at the 
declaration of JSF components 
+  versus composition of JSP fragments.  
 
-
-  
-
-  
-  
-
-The Clay XML configuration data is a replacement for the JSF/JSP 
tags.
-A base configuration file is provided in the META-INF directory of the
-shale-clay.jar archive.  The configuration document 
-type definitions have similarities to the JSP tags, but are designed
-to be more generic.  The same node structure is used to define a
-variety of resources.
- 
-A component is a "top-level" element.  In the 
-http://struts.apache.org/dtds/shale-clay-config/1_0/"; 
target="_blank">DTD,
-a component can represent a JSF component, converter,
-validator, action listener or value change listener.  Only
-"top-level" elements can be the root of a clay subtree.  The
-componentType attribute defines the association
-to the face's resource.  The jsfid attribute is a
-logical unique identifier.
-
-
+
+
+  
+   
+   The subtree can be formed using a Tapestry like HTML layout.  The 
benefit of using HTML 
+  layout composition is that it allows you to use standard HTML tools. 
 It also promotes 
+  more rapped dev

svn commit: r378932 - /struts/site/trunk/xdocs/volunteers.xml

[gvanmatre]

Author: gvanmatre
Date: Sun Feb 19 09:58:15 2006
New Revision: 378932

URL: http://svn.apache.org/viewcvs?rev=378932&view=rev
Log:
Fixed typo.

Modified:
struts/site/trunk/xdocs/volunteers.xml

Modified: struts/site/trunk/xdocs/volunteers.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/volunteers.xml?rev=378932&r1=378931&r2=378932&view=diff
==
--- struts/site/trunk/xdocs/volunteers.xml (original)
+++ struts/site/trunk/xdocs/volunteers.xml Sun Feb 19 09:58:15 2006
@@ -1077,7 +1077,7 @@
 found myself
 looking for work and feeling like a real "tool". An empty,
 dust free
-self was just the right size for the proprietary
+shelf was just the right size for the proprietary
 distributed object
 solution once called Forté.
 



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

Re: Reasons for 1.3 release

[Frank W. Zammetti]

Dakota Jack wrote:
? I am not interested in

"hooking" anyone, by the way, and so you don't need to "bite".  I guess
saying you'll "bite" is like saying I am "fishing" for bullshit. That is not
true.  


Isn't it interesting how you always managed to read into comments like 
that some derisive connotation?  I was simply saying I was interested in 
your conjecture, nothing more.  Is there some Freudian realization going 
on there I wonder?



Anyway, the actual design goes as follows.  Please notice that none
of the iterations in Struts CoR are present, for good reason.

Chain of Responsibility


-snip-

Anyone can quote chapter and verse from the GoF book.  Can you instead 
explain *why* what's in Struts isn't CoR?  And, perhaps more 
importantly, explain why, even if it isn't an exact match for the 
pattern, it matters one bit?


Would you deny that that the flexibility of the chain approach, 
regardless of it's "correctness" as far as pattern implementation goes, 
doesn't make Struts better?  THAT is what I care about, and likely most 
other developers would care about.  I'm not writing my thesis on why or 
why not Struts implements this pattern or that pattern as advertised, 
I'm interested in whether it makes my life better, and I for one am 
convinced the chain approach does.  If you disagree, that's fine, I 
would like to hear why, but with specifics, not by quoting a theoretical 
abstraction.


Frank

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

Re: Weird ClassCastException

[Sean Schofield]

One other thing.  I believe we should change the suite() method in
AbstractJsfTestCase to return new TestSuite().

I had an abstract test class of my own that extended
AbstractJsfTestCase but I didn't have the suite method thinking - hey
this is abstract anyways so what is there to test.  Well maven2 threw
an assertion error that there were no test methods in the class.  I
only had this with maven2.  When running in the IDE - no problems.

I believe Shale will have the same problem when it eventually switches
to maven2 for the build.  An empty TestSuite seems to do the trick
though.

Sean

On 2/18/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 2/18/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> >
> > I believe the problem I was not running the entire test suite of
> > myfaces tests in my IDE.  When I ran them in Maven, I believe an
> > earlier test was calling the get method for the RenderKitFactory and
> > therefore loading the default one into memory.  Apparently you are not
> > allowed to set a new one (as the setup in the AbstractJsfTestCase
> > attempts to do) once the getter is called.
> >
> > I changed the struts code to releaseFactories() in the setup method to
> > ensure you are able to set the factories as anticipated.
>
>
> +1.
>
> That's also something that might make sense as an application shuts down, in
> order to prevent potential memory leaks.  I'll take a look at that.
>
> Sean
> >
> > ps. Nice work on this test stuff.  I think we are going to convert all
> > of the MyFaces tests to use it!
>
>
> Cool!  I'm glad it's helpful.
>
> Craig
>
>

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

svn commit: r378917 - in /struts/site/trunk/xdocs: helping.fml index.xml kickstart.fml

[husted]

Author: husted
Date: Sun Feb 19 08:15:52 2006
New Revision: 378917

URL: http://svn.apache.org/viewcvs?rev=378917&view=rev
Log:
Kickstart, Helping, and Welcome
* Tweaks and typos. 

Modified:
struts/site/trunk/xdocs/helping.fml
struts/site/trunk/xdocs/index.xml
struts/site/trunk/xdocs/kickstart.fml

Modified: struts/site/trunk/xdocs/helping.fml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/helping.fml?rev=378917&r1=378916&r2=378917&view=diff
==
--- struts/site/trunk/xdocs/helping.fml (original)
+++ struts/site/trunk/xdocs/helping.fml Sun Feb 19 08:15:52 2006
@@ -123,13 +123,11 @@
 
 Before joining any Apache mailing list, please be sure to
 read the
-Mailing List Guidelines
-.
+Mailing List Guidelines.
 If you have read and understood these guidelines, you are
 welcome to
 join the Struts mailing
-lists
-.
+lists.
 
 
 
@@ -179,8 +177,7 @@
 patch
 or unit test,
 and
-add the patch or test
-.
+add the patch or test.
 Please note that we do not use @author tags in our
 JavaDocs and
 documentation.
@@ -200,11 +197,9 @@
 it's up to you to step up with the tests and fixes that
 get a release out
 the door.
-(
 http://jakarta.apache.org/site/contributing.html";>
-Like Craig
-McClanahan did for Tomcat.
-)
+(Like Craig
+McClanahan did for Tomcat.)
 
 
 
@@ -212,8 +207,7 @@
 involved by turning your
 war stories into FAQs and how-tos that we can make part of
 the
-documentation
-.
+documentation.
 The mailing list is very active and
 trundling through the archives is no picnic.
 We can always use volunteers who can reduce the best
@@ -340,9 +334,8 @@
 How to Report Bugs Effectively
 and report it to
 http://issues.apache.org/bugzilla";>
-Bugzilla
+Bugzilla.
 
-.
 
 
 
@@ -375,8 +368,7 @@
 
 Feature suggestions are also maintained in the
 http://issues.apache.org/bugzilla";>Bugzilla
-database
-.
+database.
 
 
 
@@ -608,8 +600,7 @@
 
 
 You can also post documentation to the
-Struts Wiki
-.
+Struts Wiki.
 
 
 
@@ -714,8 +705,7 @@
 and test it against your own applications.
 Report any and all issues or suspected issues to
 http://issues.apache.org/bugzilla";>
-Bugzilla
-.
+Bugzilla.
 The sooner we resolve any problems, the fewer
 betas or
 release candidates
@@ -728,9 +718,8 @@
 
 
 Contribute
-unit tests
+unit tests.
 
-.
 The closer we get to a release, the more we worry
 about breaking something.
 The more tests we have, the more confident we can
@@ -749,8 +738,7 @@
 
 Review the list of issues
 at
-Bugzilla
-.
+Bugzilla.
 If there are any to which you can respond, please
 do.
 If there any patches posted, feel free to test
@@ -762,8 +750,7 @@
 
 
 Confirm an issue's category and
-status
-.
+status.
 Newbies often post feature suggestions or
 help-desk
   

Re: Reasons for 1.3 release

[Dakota Jack]

Have you looked at the actual code?  And have you looked at what a CoR
pattern is?  The actual code is not a CoR pattern.  I am not interested in
"hooking" anyone, by the way, and so you don't need to "bite".  I guess
saying you'll "bite" is like saying I am "fishing" for bullshit. That is not
true.  Anyway, the actual design goes as follows.  Please notice that none
of the iterations in Struts CoR are present, for good reason.

Chain of Responsibility

Avoid coupling the sender of a request to its receiver by giving more than
one object a chance to handle the request. Chain the receiving objects and
pass the request along the chain until an object handles it.

There is a potentially variable number of "handler" objects and a stream of
requests that must be handled. Need to efficiently process the requests
without hard-wiring handler relationships and precedence, or
request-to-handler mappings.

The pattern chains the receiving objects together, and then passes any
request messages from object to object until it reaches an object capable of
handling the message. The number and type of handler objects isn't known a
priori, they can be configured dynamically. The chaining mechanism uses
recursive composition to allow an unlimited number of handlers to be linked.


Chain of Responsibility simplifies object interconnections. Instead of
senders and receivers maintaining references to all candidate receivers,
each sender keeps a single reference to the head of the chain, and each
receiver keeps a single reference to its immediate successor in the chain.

Make sure there exists a "safety net" to "catch" any requests which go
unhandled.

Do not use Chain of Responsibility when each request is only handled by one
handler, or, when the client object knows which service object should handle
the request. [
http://www.cs.huji.ac.il/labs/parallel/Docs/C++/DesignPatterns/chain.html.]

The Chain of Responsibility pattern avoids coupling the sender of a request
to the receiver by giving more than one object a chance to handle the
request. Mechanical coin sorting banks use the Chain of Responsibility.
Rather than having a separate slot for each coin denomination coupled with a
receptacle for the denomination, a single slot is used. When the coin is
dropped, the coin is routed to the appropriate receptacle by the mechanical
mechanisms within the bank. [Michael Duell, "Non-software examples of
software design patterns", Object Magazine, Jul 97, p54]

Chain of Responsibility, Command, Mediator, and Observer, address how you
can decouple senders and receivers, but with different trade-offs. Chain of
Responsibility passes a sender request along a chain of potential receivers.

Chain of Responsibility can use Command to represent requests as objects.
[GOF, p349]

Chain of Responsibility is often applied in conjunction with Composite.
There, a component's parent can act as its successor. [GOF, p232]

-


 On 2/18/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>
> Dakota Jack wrote:
> > The flexibility is clear.  But, from what I can see the pattern is not
> CoR.
>
> Ok, I'll bite... can you explain that?
>
> Frank
>
> > On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >> Craig McClanahan wrote:
> >>> This pattern, of course, can be used today in a Struts 1.x action ...
> or
> >> in
> >>> the "action" equivalent of any other framework too (JSF, WebWork,
> >>> whatever).  And, it's not even web specific ... you can design your
> >> whole
> >>> business logic layer out of chains.
> >> Having done this recently in a behavioral analysis application that was
> >> not web-based, I know exactly what your saying.  I can't tell you how
> >> thrilled the business was in a meeting a few weeks ago when they said
> >> "well, what happens when we want to add a rule between C and D in this
> >> processing flow" and I was able to do it in about 1 minute right before
> >> their eyes.  They flipped!  CoR makes that flexibility very easy to do.
> >>
> >>> Craig
> >> Frank
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > --
> > "You can lead a horse to water but you cannot make it float on its
> back."
> > ~Dakota Jack~
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

svn commit: r378911 - in /struts/site/trunk/xdocs: index.xml kickstart.fml

[husted]

Author: husted
Date: Sun Feb 19 07:30:40 2006
New Revision: 378911

URL: http://svn.apache.org/viewcvs?rev=378911&view=rev
Log:
Kickstart FAQ 
* Add entries about choosing a technology for new development 

Modified:
struts/site/trunk/xdocs/index.xml
struts/site/trunk/xdocs/kickstart.fml

Modified: struts/site/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/index.xml?rev=378911&r1=378910&r2=378911&view=diff
==
--- struts/site/trunk/xdocs/index.xml (original)
+++ struts/site/trunk/xdocs/index.xml Sun Feb 19 07:30:40 2006
@@ -76,34 +76,36 @@
 ,
 our development community chose to "make new friends but
 keep the old".
-Some of us want (or need) to stick with the original
-request-based framework.
-Others are ready to switch to an component-based framework
+Some of us want to stick with a request-based framework.
+Others are ready to switch to a component-based framework
 that builds on JavaServer Faces.
 We offer both frameworks because we have volunteers to
 create and maintain both frameworks.
 
 
 
-If you are starting a new project, you might want to
-consider our Shale
-Framework. Some people feel that JSF and Shale is the
-quickest way to
-write new Java web applications. Others, however, prefer
-the URL
-mapping style of a request framework. No matter what your
-preference
-is, we offer an actively developed framework for you. If
-you are not
-sure which to use, go ahead and try them both out.
-
-
-
 If you have mature Action Framework applications in
 production, don't worry,
 we are still here, same as ever.
 After all, we have our share of mature application in
 production too.
+
+
+
+If you are starting a new project using new technology,
+don't worry, we are still blazing trails, same as ever.
+For new JavaServer Faces project, we offer the Shale
+Framework.
+For new JSP projects, we offer the original Action 
framework.
+Soon, we will also offer a new Action 2 framework, based on
+WebWork
+technology.
+
+
+
+Whether you are staying the course, or ready to leap 
forward,
+the Apache Struts project is here to help you do what you 
want
+to do.
 
 
 

Modified: struts/site/trunk/xdocs/kickstart.fml
URL: 
http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/kickstart.fml?rev=378911&r1=378910&r2=378911&view=diff
==
--- struts/site/trunk/xdocs/kickstart.fml (original)
+++ struts/site/trunk/xdocs/kickstart.fml Sun Feb 19 07:30:40 2006
@@ -241,6 +241,11 @@
 Ti has become a proposal to put the WebWork wheel back on
 the Struts axle.
 
+
+At this point, the Ti codename is being dropped,
+and we are referring to the incoming WebWork codebase as 
Action
+2.
+
 
 
 
@@ -279,24 +284,6 @@
 
 
 
-
-Does Ti mean there will be three frameworks?
-
-
-There will be the
-Action 1
-framework that is currently
-in production and usually refered to as "Struts".
-When released, Ti will become the
->
-Action 2 framework.
-Shale will remain a separate but equal framework
-that focuses on JavaServer Faces rather than
-conventional server pages.
-
-
-
-
 
 What about OverDrive or Struts Nexus?
 
@@ -325,6 +312,175 @@
 
 
 
+
+Which Apache Struts Framework should I use on my next
+project?
+
+
+
+First, you should decide which user interface technology 
you
+would like to use:
+http://java.sun.com

DO NOT REPLY [Bug 38707] - provide better error message for "No valid collection specified for size tag"

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=38707





--- Additional Comments From [EMAIL PROTECTED]  2006-02-19 13:30 ---
Created an attachment (id=17740)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17740&action=view)
SizeTag.java.patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 38707] New: - provide better error message for "No valid collection specified for size tag"

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=38707

   Summary: provide better error message for "No valid collection
specified for size tag"
   Product: Struts
   Version: 1.2.8
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Taglibs
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


javax.servlet.jsp.JspException: No valid collection specified for size tag
at org.apache.struts.taglib.bean.SizeTag.doStartTag(SizeTag.java:165)
 ...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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