Re: [VOTE] Accept WebWork 2 Merger Incubator Proposal

[rich]

+1 (sorry for the late reply)

Don Brown wrote:

http://wiki.apache.org/struts/WebWork2Incubator

= PROJECT PROPOSAL =

WebWork 2:  A Java web application development framework

A proposal to merge the WebWork 2 community and codebase into the 
Apache Struts project. The new codebase is slated to become Struts 
Action 2.


= RATIONALE =

The members of the Apache Struts project and the members of the 
OpenSymphony WebWork 2 project would like to work together on a 
next-generation web application framework utilizing an action/request 
architecture. WebWork was initially created by Rickard Oberg to 
improve on the ideas and functionality of the Jakarta Struts 
framework. (Now known as the Apache Struts Action framework.) Since 
then, the WebWork community has continued to extend and refine the 
framework's capabilities through a long series of releases, the latest 
of which, 2.2, brings advanced Ajax, templating, and Java 5 
capabilities to its solid WebWork 2 foundation.  While, to date, the 
WebWork and Struts Action codebases have overlapped, recent movements 
to bring consolidation to the web framework landscape have inspired 
both communities to work together. Apache Struts has recently 
reorganized our codebase into multiple subprojects, two of which, 
Shale and Action, represent two separate but equal web frameworks. 
Struts Shale serves the nascent JSF community, while Struts Action 
serves the established JSP community. The WebWork 2 code would be 
brought into the Action subproject as the 2.x branch.  The WebWork 2 
developers are excited by the prospect of joining the ASF and 
collaborating to solve our common need for a solid, action-based MVC2 
web framework. 
= CRITERIA =


== Meritocracy: ==

The WebWork 2 community is a healthy meritocracy with multiple 
developers who do not share a common employer. The creator of the 
project has already "passed the torch" to another generation of 
developers, who earn commit privileges through their individual 
contributions.


== Community: ==

The WebWork 2 community has a strong following with active mailing 
lists and forums.


https://webwork.dev.java.net/servlets/ProjectMailingListList

== WebWork Developers: ==

The WebWork developers includes individuals who have been with the 
project for a very long time and individuals who have only recently 
earned commit privileges. Contributions come steadily from all 
segments of the community, developer and user alike. Despite being 
used by many well-known corporations, WebWork 2 has not received any 
direct corporate contributions.


http://www.opensymphony.com/webwork/members.action

== Alignment: ==

WebWork and Struts Action are both action-oriented web frameworks, and 
the basic underlying models of the two are similar in many respects. 
Thus both projects strive to serve largely the same community of Java 
web application developers.


== License ==

WebWork 2 is under the OpenSymphony 1.1 license, a modified Apache 
Software License 1.0.


* 2001-2006 http://www.opensymphony.com/webwork/license.action

= AVOIDING THE WARNING SIGNS =

== Orphaned products: ==

WebWork 2 will form the base of Struts Action 2.0 and is under heavy 
active development.


== Inexperience with open source: ==

The WebWork 2 project has been operating as a successful open source 
project for over four years.


== Homogenous developers: ==

The current list of committers includes developers from several 
different companies who are geographically dispersed. The developers 
are experienced with working in a distributed environment, and with 
resolving differences outside the scope of a common employer.


== Reliance on salaried developers: ==

WebWork does not rely on contributions from salaried developers, nor 
have commit privileges been extended based on an individual's employer.


== No ties to other ASF products: ==

The heritage of WebWork yields many close ties with the Apache Struts 
community. Many users have used one framework, then the other, and 
have different projects in the field that use either. The WebWork 2 
codebase also uses several Jakarta Commons libraries.


== A fascination with the ASF brand: ==

After several years of independence, the WebWork developers are ready 
to work within a larger community and expose the WebWork technology to 
a wider audience. The WebWork community is not seeking the ASF brand 
but seeks to collaborate with like minds in the Apache Struts 
projects. Both sets of developers are trying to solve the same 
problems in the same way, and we feel that we can create a stronger 
community and codebase together, than we can working independantly.


= INITIAL SOURCE =

The initial source comes from the WebWork 2 project, which uses CVS 
hosted at java.net.


* http://opensymphony.com/webwork/cvs.action

= RESOURCES TO BE CREATED =

* None. (Struts Action SVN module and build systems already exist.)

= INITIAL COMMITTERS =

* Jason Carreira (jcarreira at apache.org)
* Don Brown (mrdo

svn commit: r372737 - /struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/LifecycleListenerTestCase.java

[craigmcc]

Author: craigmcc
Date: Thu Jan 26 21:14:20 2006
New Revision: 372737

URL: http://svn.apache.org/viewcvs?rev=372737&view=rev
Log:
Remove spurious comment-outs on a couple of assertions.

Modified:

struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/LifecycleListenerTestCase.java

Modified: 
struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/LifecycleListenerTestCase.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/LifecycleListenerTestCase.java?rev=372737&r1=372736&r2=372737&view=diff
==
--- 
struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/LifecycleListenerTestCase.java
 (original)
+++ 
struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/LifecycleListenerTestCase.java
 Thu Jan 26 21:14:20 2006
@@ -126,7 +126,7 @@
 assertNotNull(config);
 Map mbMap = fcConfig.getManagedBeans();
 assertNotNull(mbMap);
-//assertEquals(4, mbMap.size());
+assertEquals(4, mbMap.size());
 
 ManagedPropertyConfig mpConfig = null;
 
@@ -199,7 +199,7 @@
 assertNull(bean2.getMapEntries());
 Map bean2Map = bean2.getProperties();
 assertNotNull(bean2Map);
-  //  assertEquals(8, bean2Map.size());
+assertEquals(8, bean2Map.size());
 
 mpConfig = bean2.getProperty("byteProperty");
 assertNotNull(mpConfig);



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

svn commit: r372735 - in /struts/shale/trunk: core-library/src/java/org/apache/shale/faces/ test-framework/src/java/org/apache/shale/test/mock/ tiger/ tiger/src/java/org/apache/shale/tiger/faces/ tige

[craigmcc]

Author: craigmcc
Date: Thu Jan 26 21:12:47 2006
New Revision: 372735

URL: http://svn.apache.org/viewcvs?rev=372735&view=rev
Log:
Fix a number of overlapping issues preventing the Shale Tiger Extensions
from working reliably.

* MockServletContext - the initial implementation of getResourcePaths()
  incorrectly recursed through subdirectories, due to a misread of the
  spec language on my part.  Real containers don't recurse -- that is up
  to the application.  Make the mock implementation act that way.

* ShaleVariableResolver - correct the class name of the Tiger Extensions
  replacement resolver.

* ShaleApplicationFilter - refactor the startup of the Shale Tiger
  extensions by calling the contextInitialized() and contextDestroyed()
  methods on LifecycleListener from the filter's init() and destroy()
  methods.  This guarantees that the underlying JSF implementation has
  actually been initialized first, which is a requirement -- I was
  "just lucky" on my original tests of this.


Modified:

struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ShaleApplicationFilter.java

struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ShaleVariableResolver.java

struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockServletContext.java
struts/shale/trunk/tiger/build.xml

struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/Bundle.properties

struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/LifecycleListener.java

struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverImpl.java

struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/LifecycleListenerTestCase.java

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ShaleApplicationFilter.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ShaleApplicationFilter.java?rev=372735&r1=372734&r2=372735&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ShaleApplicationFilter.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/faces/ShaleApplicationFilter.java
 Thu Jan 26 21:12:47 2006
@@ -17,7 +17,10 @@
 package org.apache.shale.faces;
 
 import java.io.IOException;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
 import java.net.URL;
+import javax.faces.FacesException;
 
 import javax.faces.FactoryFinder;
 import javax.faces.lifecycle.Lifecycle;
@@ -26,6 +29,7 @@
 import javax.servlet.FilterChain;
 import javax.servlet.FilterConfig;
 import javax.servlet.ServletContext;
+import javax.servlet.ServletContextEvent;
 import javax.servlet.ServletException;
 import javax.servlet.ServletRequest;
 import javax.servlet.ServletResponse;
@@ -218,6 +222,9 @@
 }
 }
 
+// Finialize the Shale Tiger Extensions (if present)
+destroyTiger();
+
 // Clean up JavaServer Faces integration linkages
 context = null;
 catalog = null;
@@ -312,6 +319,9 @@
 context.setAttribute(Constants.VIEW_MAPPER,
  getViewControllerMapper());
 
+// Initialize the Shale Tiger Extensions (if present)
+initTiger(config);
+
 // Look up the "shale" catalog and ensure "standard" is defined
 try {
 catalog = getCatalog();
@@ -420,6 +430,96 @@
 throw new ServletException
   (messages.getMessage("filter.vcmInstantiate",
new Object[] { className }), e);
+}
+
+}
+
+
+/**
+ * The servlet context "listener" object for the Shale Tiger
+ * Extensions library, if it is present.  This object is accessed
+ * only via reflection, to avoid classpath problems if the
+ * shale-tiger.jar archive is not included.
+ */
+private Object tiger = null;
+
+
+/**
+ * Finalize the Shale Tiger Extensions (if present).
+ */
+private void destroyTiger() {
+
+// If we have a tiger "listener" instance, send the contextDestroyed 
event
+if (tiger != null) {
+ServletContextEvent event = new ServletContextEvent(context);
+try {
+Method method =
+  tiger.getClass().getMethod("contextDestroyed",
+ new Class[] { 
ServletContextEvent.class });
+method.invoke(tiger, new Object[] { event });
+} catch (InvocationTargetException e) {
+Throwable cause = e.getCause();
+if (cause instanceof RuntimeException) {
+throw (RuntimeException) cause;
+} else {
+throw new FacesException(cause);
+}
+} catch (RuntimeException e) {
+throw e;
+} catch (Exception e)

svn commit: r372732 - in /struts/shale/trunk/clay-plugin/src: java/org/apache/shale/clay/config/beans/ java/org/apache/shale/clay/parser/ test/org/apache/shale/clay/config/ test/org/apache/shale/clay/

[gvanmatre]

Author: gvanmatre
Date: Thu Jan 26 20:56:58 2006
New Revision: 372732

URL: http://svn.apache.org/viewcvs?rev=372732&view=rev
Log:
Fixes for two bugs reported by Richard Wallace.  The html parser was truncating 
the text of a node when the last node was not a markup tag.  The symbols were 
not consistently handling case insensitive.

Modified:

struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/config/beans/ComponentBean.java

struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/parser/NodeTokenizer.java

struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/config/address-config.xml

struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/parser/ParserTestCase.java

Modified: 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/config/beans/ComponentBean.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/config/beans/ComponentBean.java?rev=372732&r1=372731&r2=372732&view=diff
==
--- 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/config/beans/ComponentBean.java
 (original)
+++ 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/config/beans/ComponentBean.java
 Thu Jan 26 20:56:58 2006
@@ -215,7 +215,7 @@
 /**
  * The replacement symbol table for the component meta-data.
  */
-private Map symbols = new TreeMap();
+private Map symbols = new Attributes();
 
 
 

Modified: 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/parser/NodeTokenizer.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/parser/NodeTokenizer.java?rev=372732&r1=372731&r2=372732&view=diff
==
--- 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/parser/NodeTokenizer.java
 (original)
+++ 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/parser/NodeTokenizer.java
 Thu Jan 26 20:56:58 2006
@@ -222,7 +222,7 @@
 }
 
 if ((buffer.length()) > s + 1) {
-TokenOffset offset = new TokenOffset(s + 1, (buffer.length() - 1), 
lineNumber, lineBeginOffset);
+TokenOffset offset = new TokenOffset(s, (buffer.length()), 
lineNumber, lineBeginOffset);
 tokenIndex.add(offset);
 
 if (log.isDebugEnabled()) {

Modified: 
struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/config/address-config.xml
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/config/address-config.xml?rev=372732&r1=372731&r2=372732&view=diff
==
--- 
struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/config/address-config.xml
 (original)
+++ 
struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/config/address-config.xml
 Thu Jan 26 20:56:58 2006
@@ -263,7 +263,7 @@

   
   
- 
+ 
   



Modified: 
struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/parser/ParserTestCase.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/parser/ParserTestCase.java?rev=372732&r1=372731&r2=372732&view=diff
==
--- 
struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/parser/ParserTestCase.java
 (original)
+++ 
struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/parser/ParserTestCase.java
 Thu Jan 26 20:56:58 2006
@@ -639,6 +639,38 @@
 
 }
 
+//parse document ending in text
+public void testPlainText() {
+   
+Parser p = new Parser();
+StringBuffer doc = new StringBuffer();
+
+doc.append("test");
+
+List nodes = p.parse(doc);
+assertTrue("Plain text, 2 node", nodes.size() == 2);
+
+Node root = (Node) nodes.get(1);
+assertNotNull("last node", root);
+
+assertEquals("node raw text", root.getToken().getRawText(), "test");
+
+
+doc.setLength(0);
+doc.append("This is a test.");
+
+nodes = p.parse(doc);
+assertTrue("Plain text, 1 node", nodes.size() == 1);
+
+root = (Node) nodes.get(0);
+assertNotNull("first node", root);
+
+assertEquals("node raw text", root.getToken().getRawText(), 
doc.toString());
+
+
+}
+
+
 /**
  * Test parsing a DOCTYPE Tag.
  */



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

Re: svn commit: r372715 - /struts/shale/trunk/build/test-framework/project.xml

[Wendy Smoak]

On 1/26/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

> I can see why these two have to be declared, since the Shale code directly
> depends on them.  But HtmlUnit itself ships with a bunch of other jars that
> it requires at runtime.  Do these have to be declared also, or are they
> picked up transitively from whatever the htmlunit pom entry says?

As you noted, I just added enough to get the test framework classes to
compile.  Maven 1 doesn't have transitive dependencies, so anyone who
is using HtmlUnit would have to declare it and all of its dependencies
in his own project.xml file.

(The Maven 2 pom will list HtmlUnit as an optional dependency, which
will prevent it from being transitive.  Again, the user would declare
it if he wants it, at which point m2's transitive dependency mechanism
would kick in.)

--
Wendy

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

Re: svn commit: r372715 - /struts/shale/trunk/build/test-framework/project.xml

[Craig McClanahan]

On 1/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Author: wsmoak
> Date: Thu Jan 26 19:25:11 2006
> New Revision: 372715
>
> URL: http://svn.apache.org/viewcvs?rev=372715&view=rev
> Log:
> Added optional htmlunit and commons-httpclient dependencies.
> See changes to build.xml in r371850.


Wendy,

I can see why these two have to be declared, since the Shale code directly
depends on them.  But HtmlUnit itself ships with a bunch of other jars that
it requires at runtime.  Do these have to be declared also, or are they
picked up transitively from whatever the htmlunit pom entry says?

Craig

svn commit: r372715 - /struts/shale/trunk/build/test-framework/project.xml

[wsmoak]

Author: wsmoak
Date: Thu Jan 26 19:25:11 2006
New Revision: 372715

URL: http://svn.apache.org/viewcvs?rev=372715&view=rev
Log:
Added optional htmlunit and commons-httpclient dependencies.  
See changes to build.xml in r371850.

Modified:
struts/shale/trunk/build/test-framework/project.xml

Modified: struts/shale/trunk/build/test-framework/project.xml
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/build/test-framework/project.xml?rev=372715&r1=372714&r2=372715&view=diff
==
--- struts/shale/trunk/build/test-framework/project.xml (original)
+++ struts/shale/trunk/build/test-framework/project.xml Thu Jan 26 19:25:11 2006
@@ -70,6 +70,22 @@
   shale-core
   1.0.1-SNAPSHOT
 
+
+  htmlunit
+  htmlunit
+  1.6
+  
+true
+  
+
+
+  commons-httpclient
+  commons-httpclient
+  3.0
+  
+true
+  
+
   
 
 



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

Re: Validation Security Hole?

[Paul Benedict]

>> OK, let's make it "isCancellable" then and have it implement the 
>> "IsCancelled" method that we
already have. As I understand it, this would be in line with the way most 
interceptors are
implemented. 

In case this was missed on the dev boards, I did put out a proposed solution 
before today's new
discussion came up:

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

It's for Struts 1.2.x. Is there a different approach that we should seriously 
consider? Please say
so, and I will contribute a patch for this.

The reason  was chosen is because it's identical to having a 
parameter listed in the
DTD, functionaly speaking, except for DTD autocompletion.

Paul



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: svn commit: r372389 - /struts/scripting/trunk/project.xml

[Sean Schofield]

I know it seems weird but once you get used to it its not that bad ;-)

On 1/25/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> On 1/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: mrdon
> > Date: Wed Jan 25 17:25:11 2006
> > New Revision: 372389
> >
> > URL: http://svn.apache.org/viewcvs?rev=372389&view=rev
> > Log:
> > Changing version number to 1.0.2-dev
>
> 1.0.2-SNAPSHOT, please... it's a Maven thing. :)
>
> (It's a keyword which makes Maven go check for an updated version of
> the jar.  Anything else and the artifact will only be downloaded once.
>  It won't really affect people who build from source, but it will
> cause a problem if we deploy this to the snapshot repository, say, for
> use with an archetype.)
>
> Thanks,
> --
> Wendy
>
> -
> 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 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-01-26 19:05 ---
I still don't think you've addressed Niall's concern about breaking the 
contract of the RequestProcessor, 
especially with regards to code in doInclude() that relies on something that 
happens earlier in the 
RequestProcessor chain of events.  The RequestProcessor is meant to be executed 
as a whole.  The hooks 
are plugin points for applications to override specific steps in the process.  
IMO, it's not a good idea to 
start using that API in other parts of the framework.  

To me part 1 of your patch is a workaround to expose part of the API that was 
not meant to be exposed.  I 
would personally be very hestant to stretch the 1.2.x API in this manner.

-- 
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: Validation Security Hole?

[Ted Husted]

On 1/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> Its probably worth consulting the ww developers on
> whether they think its desirable to have this feature and the best way
> to implement it in ww/action2.

In WW2/Action2, it's easy to specify another method (or Action) to
handle the cancel case from the tag itself, and so the special-case
doesn't need to be built into the Action.

See http://tinyurl.com/e3p89 for some coding examples.

If we want to support things like a special-case cancel button in an
Action2 compatability layer, then I think the solution there is going
to be a standard WW2 interceptor/interface combo. Then, only the
Actions needing cancel-handling, and calling isCancelled, would
specify the interceptor.

-Ted.

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

Re: Validation Security Hole?

[Ted Husted]

On 1/26/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> If the plan is to design for ww/action2, then more thought needs to go
> into the interface design - whether its simply a marker interface or
> includes some behaviour (e.g. a cancel() method) since getting it
> wrong is going to both be a pain for Struts 1.x and a legacy burden
> for Action 2. Its probably worth consulting the ww developers on
> whether they think its desirable to have this feature and the best way
> to implement it in ww/action2.

OK, let's make it "isCancellable" then and have it implement the
"IsCancelled" method that we already have. As I understand it, this
would be in line with the way most interceptors are implemented. This
would also leave room for another "Cancellable" implementation if
someone wanted to get into new development.

For good measure, we could deprecate the "isCancelled" method on the
Action class, so that people can start implementing the interface
instead. The idea being we would remove isCancelled from the Action
class in Struts Action 1.4, should there be one. In a 1.4 series, we
could then change the default to TRUE, since anyone who is calling
isCancelled should have resolved the deprecation warning and
implemented the interface instead.

IMHO, the key issue is that we let people who care disable the
special-case handling for the cancel token. We can work toward making
"opt-in" the default behavior for the cancel handling, but I don't
think it is such a burning issue that we have to do it in one fell
swoop. We can stick to the usual deprecate-replace-remove strategy.

Whether this is an API oversight or a security issue is debatable, and
so the important thing is that we provide a fix for applications where
the special-case handling might be an issue.

-Ted.

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

Re: Confirmation for being Struts Developer

[Martin Cooper]

On 1/26/06, Thulasiram G <[EMAIL PROTECTED]> wrote:
>
> Greetings,
>
> I would love to volunteer as a developer for Struts Action
> Framework.Kindlytreat this as the confirmation for the same and
> oblige.


Volunteers are always welcome! Our "How to Help" FAQ should help you get
started:

http://struts.apache.org/helping.html

--
Martin Cooper


Regards,
> GT
>
>

Re: Validation Security Hole?

[Michael Jouravlev]

On 1/26/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> To repeat my past analogy, this
> would be like Microsoft releasing a patch for a security hole but leaving
> the hole open by default until a developer flips a switch to close it.

They do this all the time, only by default they have a hole closed.

Michael.

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

Re: Validation Security Hole?

[Michael Jouravlev]

On 1/26/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 1/24/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
> > - add a Cancelable interface which an Action must implement to get
> > cancel processing; ignore the cancel param if the interface isn't
> > implemented
>
> I'd lean toward the interface approach, since that's the sort of thing
> that WW2/Action2 does/will do. Duty now for the future!

I thought that change was proposed for Struts 1.x

> * Add an optional "Cancellable" marker interface for Actions.
>
> * When cancel signal is present, a RP command checks for the interface
> and throws an exception if Cancellable is not implemented.
>
> * For Action 1.3, add a Controller attribute "ObserveCancellable" with
> the default value FALSE, that the RP command would check before
> throwing an Exception. (Instead, it might just log a DEBUG-level
> warning.)
>
>   ** To enable the interface, a developer can set the Controller
> attribute to TRUE. Otherwise, we break backward compatiblity, and we
> would need to increment the major version number.

The problem is not in the Cancel button, the problem is
autopopulation. I don't see how Cancel event differs from other events
and don't see the point to make a separate use case out of it.
Instead, make population explicit, this works especially well with
dispatch actions. In this case it would not matter cancel or not,
because I can choose whether to populate form or not explicitly. One
line of code in my event handler is not a big deal but it makes things
much simpler.

Why having a bad solution and then trying to counter-balance it with
interfaces and such, if we can remove the bad solution
(auto-population) altogether?

Maybe we can have both: no autopopulation and cancel mapping/iterface
for legacy apps.

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-01-26 17:31 ---
All patches, originally designed for version 1.2.7 of Struts, can be applied 
safely to version 1.2.8 as well as the impacted classes (TilesRequestProcessor, 
TilesUtilStrutsImpl and TilesUtilStrutsModuleImpl) didn't change between the 2 
releases.

-- 
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: Validation Security Hole?

[Frank W. Zammetti]

On Thu, January 26, 2006 10:05 am, Ted Husted said:
>   ** To enable the interface, a developer can set the Controller
> attribute to TRUE. Otherwise, we break backward compatiblity, and we
> would need to increment the major version number.
>
> * Like many other things, if we rolled the major version number on
> this codebase, we'd change the default to TRUE to enforce the
> preferred behavior. But, for a minor release, we shouldn't force
> everyone to change perfectly good actions that already check
> isCancelled.

IMO, *any* solution which does not change the default behavior is
pointless.  As I've said before, we are talking about something that is a
security concern, to whatever degree (and the degree is debatable, as
we've seen in this thread).  Not changing the default behavior does not
address that concern as far as I can see.  To repeat my past analogy, this
would be like Microsoft releasing a patch for a security hole but leaving
the hole open by default until a developer flips a switch to close it.

I realize changing the default behavior breaks backwards-compatibility,
but backwards-compatibility should never trump security.  I also realize
this has implications for version numbers and even implications for what
happens in the future, but I think these are sacrifices that need to be
made in the name of plugging a potential security hole.

Also, I just want to be sure everyone is on-board not only with fixing
this in 1.3 but in the 1.2.x branch as well.  Much of the discussions
about the solution that I've seen look to revolve around 1.3, and I just
want to be sure no one is dismissing patching the 1.2.x branch as well.

> -Ted.

Frank

-
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-01-26 17:27 ---
Created an attachment (id=17511)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17511&action=view)
third part of the patch (TilesUtilStrutsModuleImpl)

third part of the patch (TilesUtilStrutsModuleImpl)

Removed doInclude() and doForward() methods so it makes use of parent class
(TilesUtilStrutsImpl) implementation (which in turn calls TilesRequestProcessor
doInclude() and doForward() methods, see patch' second part).

The differentiation is made through a different implementation of
getRequestProcessor() for module-aware applications.


-- 
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 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-01-26 17:21 ---
Created an attachment (id=17510)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17510&action=view)
second part of the patch (TilesUtilStrutsImpl)

1) doInclude() and doForward() methods rely on TilesRequestProcessor
corresponding methods
2) Added getRequestProcessor() 

-- 
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: Validation Security Hole?

[Niall Pemberton]

On 1/26/06, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 1/24/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
> > - add a Cancelable interface which an Action must implement to get
> > cancel processing; ignore the cancel param if the interface isn't
> > implemented
>
> I'd lean toward the interface approach, since that's the sort of thing
> that WW2/Action2 does/will do. Duty now for the future!

If the plan is to design for ww/action2, then more thought needs to go
into the interface design - whether its simply a marker interface or
includes some behaviour (e.g. a cancel() method) since getting it
wrong is going to both be a pain for Struts 1.x and a legacy burden
for Action 2. Its probably worth consulting the ww developers on
whether they think its desirable to have this feature and the best way
to implement it in ww/action2.

Niall

-
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-01-26 17:19 ---
Agree with Niall's comments on updating the patch.
I finally add some time to work on it (sorry for the delay).

It's now made of 3 parts:
- first part remains identical (patch to TilesRequestProcessor already 
submitted) to allow TilesRequestProcessor doInclude() method to be called on 
TilesRequestProcessor subclasses (if any)
- second part is a patch for TilesUtilStrutsImpl to rely on the 
TilesRequestProcessor doInclude() and doForward() methods
- third part is for TilesUtilStrutsImpl (for module-aware applications) to rely 
on the TilesRequestProcessor doInclude() and doForward() methods

Patrick

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #15655|0   |1
is obsolete||




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

Confirmation for being Struts Developer

[Thulasiram G]

Greetings,

I would love to volunteer as a developer for Struts Action
Framework.Kindlytreat this as the confirmation for the same and
oblige.

Regards,
GT

Re: Validation Security Hole?

[Ted Husted]

On 1/24/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
> - add a Cancelable interface which an Action must implement to get
> cancel processing; ignore the cancel param if the interface isn't
> implemented

I'd lean toward the interface approach, since that's the sort of thing
that WW2/Action2 does/will do. Duty now for the future!

* Add an optional "Cancellable" marker interface for Actions.

* When cancel signal is present, a RP command checks for the interface
and throws an exception if Cancellable is not implemented.

* For Action 1.3, add a Controller attribute "ObserveCancellable" with
the default value FALSE, that the RP command would check before
throwing an Exception. (Instead, it might just log a DEBUG-level
warning.)

  ** To enable the interface, a developer can set the Controller
attribute to TRUE. Otherwise, we break backward compatiblity, and we
would need to increment the major version number.

* Like many other things, if we rolled the major version number on
this codebase, we'd change the default to TRUE to enforce the
preferred behavior. But, for a minor release, we shouldn't force
everyone to change perfectly good actions that already check
isCancelled.

* For extra credit, update the ModuleConfigVerifier plugin to check to
see if Actions are implementing Cancellable when the RP attribute is
FALSE.

-Ted.

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

Re: Validation Security Hole?

[Joe Germuska]

On 1/22/06, Craig McClanahan wrote:


 I doubt there is any clean backwards-compatible approach to dealing with
 this ... the best thing I can think of is to switch the default behavior to
 not listening to the cancel button *unless* a context init parameter is set,
 which says (in effect) "this application knows how to deal with cancel
 semantics in *all* of its actions".  But I think we should do *something*
 about it.


IMO we should at a minimum do Craig's suggestion of a global option to
turn this behaviour on/off. If we then also want to provide more fine
grained control, then my preference is the first option in Laurie's
list - add a new attritbute to the action mapping.


My understanding of this approach is that you get both for one.  If 
you make the default value for the new action mapping attribute 
"don't allow cancelling" then you have globally turned it off until 
any action mappings have that attribute set..


An additional, independent parameter to turn it off just seems like 
it will be confusing.


Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com


"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
-- Robert Moog

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

Re: Validation Security Hole?

[Niall Pemberton]

On 1/25/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
>
> I believe we have several proposed solutions:
>
> - add an action-mapping config option to enable cancel processing, and
> ignore the cancel request parameter if the action mapping isn't
> configured to use it
>
> - add an Action.canceled() method which would be called instead of
> Action.execute() if the cancel parameter is included in the request, and
> make the default implementation return an error response
>
> - add a Cancelable interface which an Action must implement to get
> cancel processing; ignore the cancel param if the interface isn't
> implemented


On 1/22/06, Craig McClanahan wrote:
>
> I doubt there is any clean backwards-compatible approach to dealing with
> this ... the best thing I can think of is to switch the default behavior to
> not listening to the cancel button *unless* a context init parameter is set,
> which says (in effect) "this application knows how to deal with cancel
> semantics in *all* of its actions".  But I think we should do *something*
> about it.

IMO we should at a minimum do Craig's suggestion of a global option to
turn this behaviour on/off. If we then also want to provide more fine
grained control, then my preference is the first option in Laurie's
list - add a new attritbute to the action mapping.

Niall

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