Re: [Action2] ant new target failed missing intellij and eclipse configuration files

[Patrick Lightbody]

Toby,
We're switching the default build to Maven 2.0.3. Rene is working on fixing up 
the Ant builds, but until he says otherwise, I would consider building with 
Maven instead.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=25249&messageID=50306#50306


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

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Patrick Lightbody]

Jacob,
Perhaps I'm just a big idiot, or perhaps I don't have enough time in the day to 
fully explore this whole idea, but I'm still having the same problem I had last 
time we discussed this issue: "huh?"

I don't _get it_ and I won't really until someone can pony up and at least 
provide some basic sample code that explains through example what the proposed 
change is. Keeping in mind that many of us know next to nothing about JSF, is 
there any way you can show us how this would work?

For example, would web.xml look different? Would a typical action look 
different? How about a JSP? If so, how?

Sorry, but I really can't commit one way or the other or even provide any 
insightful comment until I can see what you're suggesting. Thanks!
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=25519&messageID=50305#50305


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

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Patrick Lightbody]

My entire thoughts on the EL-API thing is this:

I only care about using the EL API if I get the additional tool support. IDEA, 
for example, does some decent code completion when you do ${ ... } in a JSP. It 
doesn't, on the other hand, do anything useful when I type  or use %{ ... } in another WebWork tag. I see very little value, 
other than knowledge transfer of a quite simple language, in using the EL-API 
if we can't also take advantage of these tools.

As I understand it, simply plopping in some other underlying EL such as Jexl or 
Ognl won't get us any closer to that tool support. Is that correct? My hunch 
says that IDEA will, whether it should or not, continue to do code completion 
as if the EL was using the standard implementation.

Again: short of slightly simpler "brain matter migration" with the "${" and "}" 
tokens in our JSPs, what value does using the EL-API provide when using a 
completely different underlying language?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=25519&messageID=50303#50303


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

svn commit: r393148 - in /struts/shale/trunk/core-library/src/java/org/apache/shale: faces/ShaleApplicationFilter.java resources/Bundle.properties view/Constants.java view/faces/ViewViewHandler.java

[craigmcc]

Author: craigmcc
Date: Mon Apr 10 23:09:52 2006
New Revision: 393148

URL: http://svn.apache.org/viewcvs?rev=393148&view=rev
Log:
Migrate the initialization logic for configuring which ViewControllerMapper
instance will be used from ShaleApplicationFiter to ViewViewHandler, since
the org.apache.shale.view package is the only place this is actually used.

Modified:

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

struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties

struts/shale/trunk/core-library/src/java/org/apache/shale/view/Constants.java

struts/shale/trunk/core-library/src/java/org/apache/shale/view/faces/ViewViewHandler.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=393148&r1=393147&r2=393148&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
 Mon Apr 10 23:09:52 2006
@@ -158,16 +158,6 @@
   "org/apache/shale/faces/shale-config.xml";
 
 
-/**
- * The name of the context initialization parameter that defines the
- * fully qualified class name of the [EMAIL PROTECTED] 
ViewControllerMapper} to be
- * used is stored.  If not present, the default value is
- * org.apache.shale.view.DefaultViewControllerMapper.
- */
-public static final String VIEW_CONTROLLER_MAPPER =
-  "org.apache.shale.view.VIEW_CONTROLLER_MAPPER";
-
-
 // -- Instance 
Variables
 
 
@@ -316,8 +306,6 @@
 }
 
 context = config.getServletContext();
-context.setAttribute(Constants.VIEW_MAPPER,
- getViewControllerMapper());
 
 // Initialize the Shale Tiger Extensions (if present)
 initTiger(config);
@@ -391,46 +379,6 @@
 parser.parse(url);
 
 return catalog;
-
-}
-
-
-/**
- * Create and return the [EMAIL PROTECTED] ViewControllerMapper} 
instance
- * we will use for this application
- *
- * @exception ServletException if no instance can be created
- */
-private ViewControllerMapper getViewControllerMapper() throws 
ServletException {
-
-String className = context.getInitParameter(VIEW_CONTROLLER_MAPPER);
-if (className == null) {
-className = 
"org.apache.shale.view.impl.DefaultViewControllerMapper";
-}
-ClassLoader cl = Thread.currentThread().getContextClassLoader();
-if (cl == null) {
-cl = this.getClass().getClassLoader();
-}
-try {
-Class clazz = cl.loadClass(className);
-return (ViewControllerMapper) clazz.newInstance();
-} catch (ClassCastException e) {
-throw new ServletException
-  (messages.getMessage("filter.vcmCast",
-   new Object[] { className }), e);
-} catch (ClassNotFoundException e) {
-throw new ServletException
-  (messages.getMessage("filter.vcmClass",
-   new Object[] { className }), e);
-} catch (IllegalAccessException e) {
-throw new ServletException
-  (messages.getMessage("filter.vcmAccess",
-   new Object[] { className }), e);
-} catch (InstantiationException e) {
-throw new ServletException
-  (messages.getMessage("filter.vcmInstantiate",
-   new Object[] { className }), e);
-}
 
 }
 

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties?rev=393148&r1=393147&r2=393148&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
 Mon Apr 10 23:09:52 2006
@@ -23,16 +23,16 @@
 filter.initException=Exception occurred during init command
 filter.initializing=Initializing Shale Application Filter
 filter.parsingResource=Parsing default resource {0}
-filter.vcmAccess=ViewControllerMapper class {0} does not have a public no-args 
constructor
-filter.vcmCast=Class {0} does not implement ViewControllerMapper
-filter.vcmClass=Cannot find ViewControllerMapper class {0}
-filter.vcmInstantiate=ViewControllerMapper class {0} instance cannot be 
instantiated
 

svn commit: r393147 - /struts/shale/trunk/core-library/src/java/org/apache/shale/remote/

[craigmcc]

Author: craigmcc
Date: Mon Apr 10 23:09:04 2006
New Revision: 393147

URL: http://svn.apache.org/viewcvs?rev=393147&view=rev
Log:
Mark classes in this package as deprecated, with references to using the
functionality in org.apache.shale.remoting instead.

Modified:

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractListCompletions.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractSelectItems.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicListCompletions.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicSelectItems.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/ContextAttributes.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/EvaluateExpression.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/MapEntry.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/RemoteCommand.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/RemoteContext.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/RequestAttributes.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/ResponseWrapper.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/ServletRemoteContext.java

struts/shale/trunk/core-library/src/java/org/apache/shale/remote/package.html

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractListCompletions.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractListCompletions.java?rev=393147&r1=393146&r2=393147&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractListCompletions.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractListCompletions.java
 Mon Apr 10 23:09:04 2006
@@ -30,6 +30,9 @@
  * compared to a set of legal values, and causing the selection of those that
  * match.
  *
+ * @deprecated Use corresponding functionality from the
+ *  org.apache.shale.remoting package
+ *
  * $Id$
  */
 

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractSelectItems.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractSelectItems.java?rev=393147&r1=393146&r2=393147&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractSelectItems.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/AbstractSelectItems.java
 Mon Apr 10 23:09:04 2006
@@ -30,6 +30,9 @@
  * of SelectItem beans, optionally filtered by matching the
  * label against a test String, and rendering the result as an XML 
document.
  *
+ * @deprecated Use corresponding functionality from the
+ *  org.apache.shale.remoting package
+ *
  * $Id$
  */
 

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicListCompletions.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicListCompletions.java?rev=393147&r1=393146&r2=393147&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicListCompletions.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicListCompletions.java
 Mon Apr 10 23:09:04 2006
@@ -24,6 +24,9 @@
  * key to be used may be configured by calling setAttributeKey(),
  * and defaults to the value of the manifest constant 
ATTRIBUTE_KEY.
  *
+ * @deprecated Use corresponding functionality from the
+ *  org.apache.shale.remoting package
+ *
  * $Id$
  */
 

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicSelectItems.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicSelectItems.java?rev=393147&r1=393146&r2=393147&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicSelectItems.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/BasicSelectItems.java
 Mon Apr 10 23:09:04 2006
@@ -25,6 +25,9 @@
  * key to be used may be configured by calling setAttributeKey(),
  * and defaults to the value of the manifest constant 
ATTRIBUTE_KEY.
  *
+ * @deprecated Use corresponding functionality from the
+ *  org.apache.shale.remoting package
+ *
  * $Id$
  */
 

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/remote/ContextAttributes.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/s

DO NOT REPLY [Bug 39141] - Shale tiger extension inside jboss, library path config

[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=39141





--- Additional Comments From [EMAIL PROTECTED]  2006-04-11 06:43 ---
(In reply to comment #1)
> (In reply to comment #0)
> > How can i change default maping ?
> > 
> 
> This kind of question is better asked on the user mailing list, so everyone 
> can
> benefit from the answer.  But the current answer is to have your application
> startup code store, as an application scope attribute under key
> Constants.VIEW_MAPPER, an instance of some class that implements
> ViewControllerMapper.  If there is no such instance installed, an instance of
> org.apache.shale.view.impl.DefaultViewControllerMapper is used.
> 
> Yes, it would be more friendly to provide a context init parameter to define 
> the
> implementation class to use.  Will look at doing that too -- but the method
> described above will work.

Late breaking news ... there already is a context init parameter for this
(org.apache.shale.view.VIEW_CONTROLLER_MAPPER).  The value is the fully
qualified class name of a class that implements ViewControllerMapper that you
want to use for performing the mappings.

Leaving this RFE open for implementing the optional parent class loader search
described in the answer to question 1.


> 
> > 
> > Cristi
> 
> 



-- 
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: Maven 2 build working, more to come

[Wendy Smoak]

On 4/10/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

> I think it's just about ready for 1.3.2.  Since I haven't ever
> released with Maven 2, I wasn't quite ready to try it against the
> Struts repo without seeing it once through somewhere else.

I got the the 'mvn release:prepare' command to work, but I haven't
made it all the way through release:perform yet.  No major problems,
just user error, missing configuration, and Cygwin svn not playing
nicely with the TortoiseSVN cache.  (I also noticed a few urls are
still pointing at repos/asf instead of repos/test, and I want to fix
those first.)

Brett mentioned that he's going to be working on the release plugin,
so we should see some improvements there.  It's hard to keep up with
Maven-- just use -U regularly to pick up changes. :)

Speaking of... Maven 2.0.4 is available:  http://maven.apache.org/download.html
If you're using 2.0.3, please upgrade when you have a chance.

--
Wendy

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

DO NOT REPLY [Bug 39141] - Shale tiger extension inside jboss, library path config

[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=39141





--- Additional Comments From [EMAIL PROTECTED]  2006-04-11 06:39 ---
(In reply to comment #0)
> Inside JBOSS server the library location is not only WEB-INF/lib.
> Maybe init parameter to change lib search location will be very good.

Are all of the alternate locations somewhere in a parent class loader?  If so,
it might be better to search up through the class loader hierarchy.  If a
URLClassLoader is found, then the individual JAR files can be examined for the
existence of a META-INF/faces-config.xml resource.

However, to avoid making startup performance substantially worse, this kind of
search should probably be turned off by default, but enabled by an init 
parameter.

> 
> In the View annotation class , why you not asign the value of view id ?
> and bean name for view ?
> something like @View(viewId="/sec/test.jsp",name="sec$test") or more extended
> @Views( [EMAIL PROTECTED](...),@View{...}} ? 
> 

The class that implements ViewController has no reason that it needs to know
what view identifier it is associated with -- the dependency relationship is one
directional.  Such a declaration would also reduce possibilities for reuse. 
Further, using a mapper is a use of the "convention over configuration" strategy
-- one of the things that environments like Ruby on Rails uses to reduce the
amount of explicit configuration needed.



> How can i change default maping ?
> 

This kind of question is better asked on the user mailing list, so everyone can
benefit from the answer.  But the current answer is to have your application
startup code store, as an application scope attribute under key
Constants.VIEW_MAPPER, an instance of some class that implements
ViewControllerMapper.  If there is no such instance installed, an instance of
org.apache.shale.view.impl.DefaultViewControllerMapper is used.

Yes, it would be more friendly to provide a context init parameter to define the
implementation class to use.  Will look at doing that too -- but the method
described above will work.

> 
> Cristi



-- 
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: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Dakota Jack]

Wasn't there an agreement that the tangents would indicate what they were in
posts, like [SHALE] or [JSF].  It is difficult enough around here to figure
out what is going on without this sort of discussion going on as if it were
struts.

On 4/10/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
> On 4/10/06, Don Brown <[EMAIL PROTECTED]> wrote:
> >
> > Jacob Hookom wrote:
> > > The NavigationHandler has that default behavior. But much like WebWork
> > > allows the pluggable ActionMapper, all parts of JSF are pluggable in
> > > that manner.  Seam and SWF are two examples of plugging in alternate
> > > logic for navigation handling.  So the emphasis is put on the API, not
> > > the implementation.
> >
> > I guess what I'm saying is the navigation is already the way we want
> > it.  What would reimplementing it as a
> > NavigationHandler bring to the table?
> >
> > > I've been trying to get everyone behind the EL-API.  The 'traditional'
> > > EL implementation provided in the spec is, again, only one
> > > implementation.  The JEXL implementation of the EL-API would be a
> piece
> > > of cake, OGNL wouldn't be that hard either if they would use JavaCC
> with
> > > the visitor=true when compiling the grammar.
> >
> > Ok, I was under the impression that the Unified EL was tightly coupled
> to
> > the implementation.  If the API is abstract
> > enough to handle different implementations such as OGNL, then this is
> good
> > news.  This might be the abstraction we were
> > looking for to ensure Action 2 isn't tied to one EL.  Of course,
> deciding
> > to implement the EL API by OGNL is one thing,
> > finding someone with the time and expertise to do it is another :)
> >
> > Do you know of an alternate implementation of the EL API and/or more
> > documentation about it?  In my research, everywhere
> > I saw it mentioned it didn't make the distinction, and comments,
> > particularly on TSS, seemed to indicate the features I
> > previously mentioned were explicitly rejected (method invocation, for
> > example).
> >
>
> In JSF 1.1, the APIs for the EL were indeed tightly bound.  But that's no
> longer the case with JSF 1.2.  The javadocs for the EL are formally still
> part of the JSP 2.1 spec, but are implementable separately.  You can grab
> the spec documents (JSP and EL, bundled in one download) and the javadocs
> (again, bundled), at:
>
>   http://jcp.org/aboutJava/communityprocess/pfd/jsr245/index2.html
>
> These are in the "Proposed Final Draft 2" state, in JCP terms, so I
> wouldn't
> expect to see much, if any, change before they go final.
>
>
> Ok, so we can walk away with saying we might be able to collaborate on the
> > EL API, provided someone steps up and ports
> > OGNL or an EL with a similar set of capabilities to it.  I'm still not
> > convinced implementing WebWork as a Lifecycle
> > implementation would bring any value for 95% of the applications,
> however,
> > at some point, I am planing on porting Struts
> > Faces to Action 2 for the edge case of a WebWork app that wants to take
> > advantage of JSF components, the real draw of
> > JSF IMO, for certain pages.  At which time, I'll look more into
> different
> > integration approaches like this one.
>
>
> That (porting Struts-Faces) is a reasonable thing to do.  Not only does it
> help the developer who just needs a few pages with JSF components (but
> wants
> to keep their existing overall architecture), it also helps those who are
> trying to migrate.
>
> I guess the bottom line I think our best bet is to focus on discrete
> > problems like EL, validation, annotations, etc. for
> > integration.  From a framework developer perspective, sharing APIs is
> > interesting, but not so for the end user, who
> > could probably care less.  I guess I'm trying to see what advantages
> this
> > would bring to the end user.  The one
> > capability of JSF that I'd like to use in an Action 2 application, as an
> > end user, is its stateful components,
> > particularly complex, out-of-the-box components.  I'd be interested to
> > hear of more capabilities an Action 2 developer
> > would get out of such a hybrid.
>
>
> A strategy on my TODO list for Shale is to actually go in the other
> direction, by using JSF extension points to add in the processing of XWork
> interceptor chains.  The two places this makes sense are:
>
> * Overriding the default ActionListener, which actually calls the
>   action method.  This corresponds to when an action framework
>   invokes the "execute" or whatever method on the selected action.
>   This takes care of per-action pipeline customizations.
>
> * Supporting the use of an XWork interceptor stack in the application
>   controler filter part of Shale (as an alternative to the current
> mechanism,
>   which lets you customize a Commons Chain command chain).  This
>   takes care of global pipeline customization.
>
> The first scenario seems pretty straightforward.  I don't know XWork well
> enough to know whether the second strate

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Jacob Hookom]

Gary VanMatre wrote:

>From: [EMAIL PROTECTED]
>
> So again, at it's core for JSF 2.0, we refactor FacesContext to 
instead have a

> ProcessingContext (shorter name?) instead of a UIViewRoot. The
> lifecycle/interceptors instead inter rogate the ProcessingContext 
for alternate
> behavior while allowing those interceptors to pass a visitor to 
flexibly

> processing a whole composition of delegate concerns within the request.
>
 
Why is the UIViewRoot not a registered component in the faces-config? 
It seems like there are several hooks in the view root that could be 
overridden
for this type of behavior since the lifecycle starts each phase at 
the view root.
This is what I'm doing for JSF Avatar such that a custom UIViewRoot is 
used to act as a mediator to filtered subsets of the component tree for 
partial processing over AJAX.  UIViewRoot is registered as a component 
type and is overridable, but global to the application because it falls 
under the same 'laws' as any other UIComponent.


Contractually, I believe we want something similar to UIViewRoot moving 
forward, but simplified such that it hopefully becomes much easier for 
other frameworks to implement alternate types of requests.  I believe 
this would cascade through the rest of the UIComponent API such that it 
would be more conceivable to have a non UIComponent be a parent of 
something like an ActionComponent or ValidationComponent, retaining the 
(naked) compositional nature of JSF.


So it just comes down to the fact that UIViewRoot is a UIComponent where 
it would be more flexible to say that a UIComponent would implement a 
simpler interface (which anyone could-- without being bound to the laws 
of UIComponents).  Overall, the concepts of JSF are *very* simple, we 
just need to boil the contracts down such that the API becomes much more 
accessible to other request life cycles, supported by a flexible 
controller within the spec.
 

> Fundamentally, this is very similar to what we've done with the 
EL-API-- Seam,
> Shale, and Spring can all provide behavior from different contexts, 
coordinated
> by vistors in the form of ELResolvers which provides a *very* 
flexible way of
> mapping back to models within MVC. Now lets do the same for MVC 
controllers.

>
> -- Jacob
>
> >Jacob Hookom wrote:
> >> The NavigationHandler has that default behavior. But much like 
WebWork

> >> allows the pluggable ActionMapper, all parts of JSF are pluggable in
> >> that manner. Seam and SWF are two examples of plugging in alternate
> >> logic for navigation handling. So the emphasis is put on the API, 
not

> >> the implementation.
> >
> >I guess what I'm saying is the navigation is already the way we 
want it. What

> >would reimplementing it as a
> >NavigationHandler bring to the table?
> >
> >> I've been trying to get everyone behind the EL-API. The 
'traditional'

> >> EL implementation provided in the spec is, again, only one
> >> implementation. The JEXL implementation of the EL-API would be a 
piece
> >> of cake, OGNL wouldn't be that hard either if they would use 
JavaCC with

> >> the visitor=true when compiling the grammar.
> >
> >Ok, I was under the impression that the Unified EL was tightly 
coupled to the

> >implementation. If the API is abstract
> >enough to handle different implementations such as OGNL, then this 
is good

> >news. This might be the abstraction we were
> >looking for to ensure Action 2 isn't tied to one EL. Of course, 
deciding to

> >implement the EL API by OGNL is one thing,
> >finding someone with the time and expertise to do it is another :)
> >
&g t; >Do you know of an alternate implementation of the EL API and/or 
more

> >documentation about it? In my research, everywhere
> >I saw it mentioned it didn't make the distinction, and comments, 
particularly

> >on TSS, seemed to indicate the features I
> >previously mentioned were explicitly rejected (method invocation, for
> >example).
> >
> >Ok, so we can walk away with saying we might be able to collaborate 
on the EL

> >API, provided someone steps up and ports
> >OGNL or an EL with a similar set of capabilities to it. I'm still not
> >convinced implementing WebWork as a Lifecycle
> >implementation would bring any value for 95% of the applications, 
however, at

> >some point, I am planing on porting Struts
> >Faces to Action 2 for the edge case of a WebWork app that wants to 
take

> >advantage of JSF components, the real draw of
& gt; >JSF IMO, for certain pages. At which time, I'll look more into 
different

> >integration approaches like this one.
> >
> >I guess the bottom line I think our best bet is to focus on 
discrete problems

> >like EL, validation, annotations, etc. for
> >integration. From a framework developer perspective, sharing APIs is
> >interesting, but not so for the end user, who
> >could probably care less. I guess I'm trying to see what advantages 
this

> >would bring to the end user. The one
> >capability of JSF that I'd like to use in an A

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Gary VanMatre]

>From: [EMAIL PROTECTED] 
>
> Great, it sounds like there's an overlap of ideas here :-) 
> 
> Fundamentally, my approach to JSF 2.0 is to continue the CoR patterns with 
> the 
> various application handlers, while sticking to the 5 phases of MVC, allowing 
> other interceptors to provide intermediate processing within those 5 distinct 
> phases. 
> 
> Secondly, brining in the concept of a ProcessingContext into JSF such that 
> stateful UIComponent requests are only one implementation of the 
> ProcessingContext. The idea of a ProcessingContext with JSF was originally 
> brought up with JSF Avatar, such that a single view/tree could be processed 
> in 
> part or in whole, but the fact that the JSF API was tied to a UIViewRoot 
> object 
> somewhat limited the flexability here. 
> 
> So, if we provide this facade that the controller/listeners/interceptors 
> operate 
> on, much like a WebWork ActionContext, then we can say that JSF and WW are 
> both 
> client implementations that coexist via CoR/interceptors within a single 
> controller. 
> 
> Martin brought up the need for the visitor pattern which could be used in 
> conjunction with phaselisteners/interceptors to introduce additional 
> processing. 
> Now, if we play heavy emphasis on composition within this new 
> ProcessingContext 
> facade, then controller participants can operate, via visitor, on a single 
> node 
> (only a WW Action) or a whole tree of them as with JSF. From the 30,000 foot 
> view, that's what JSF is-- a tree of coordinated Actions instead of a single 
> node, much more powerful IMHO, but adds a bit more overhead. 
> 
> So again, at it's core for JSF 2.0, we refactor FacesContext to instead have 
> a 
> ProcessingContext (shorter name?) instead of a UIViewRoot. The 
> lifecycle/interceptors instead interrogate the ProcessingContext for 
> alternate 
> behavior while allowing those interceptors to pass a visitor to flexibly 
> processing a whole composition of delegate concerns within the request. 
> 

Why is the UIViewRoot not a registered component in the faces-config?  
It seems like there are several hooks in the view root that could be overridden 
for this type of behavior since the lifecycle starts each phase at the view 
root.

I was thinking about trying to mix view types.  Have you looked at allowing 
Facelets to include a JSP fragment?  I was looking at it for clay but it's just
not an area that's standardized.  My thought was swapping out the view root
before the JSP was included and then swapping it back and merging children.
Maybe this could be done with a customized ViewRoot?  Another use of
the ProcessingContext you described.


> Fundamentally, this is very similar to what we've done with the EL-API-- 
> Seam, 
> Shale, and Spring can all provide behavior from different contexts, 
> coordinated 
> by vistors in the form of ELResolvers which provides a *very* flexible way of 
> mapping back to models within MVC. Now lets do the same for MVC controllers. 
> 
> -- Jacob 
> 
> >Jacob Hookom wrote: 
> >> The NavigationHandler has that default behavior. But much like WebWork 
> >> allows the pluggable ActionMapper, all parts of JSF are pluggable in 
> >> that manner. Seam and SWF are two examples of plugging in alternate 
> >> logic for navigation handling. So the emphasis is put on the API, not 
> >> the implementation. 
> > 
> >I guess what I'm saying is the navigation is already the way we want it. 
> >What 
> >would reimplementing it as a 
> >NavigationHandler bring to the table? 
> > 
> >> I've been trying to get everyone behind the EL-API. The 'traditional' 
> >> EL implementation provided in the spec is, again, only one 
> >> implementation. The JEXL implementation of the EL-API would be a piece 
> >> of cake, OGNL wouldn't be that hard either if they would use JavaCC with 
> >> the visitor=true when compiling the grammar. 
> > 
> >Ok, I was under the impression that the Unified EL was tightly coupled to 
> >the 
> >implementation. If the API is abstract 
> >enough to handle different implementations such as OGNL, then this is good 
> >news. This might be the abstraction we were 
> >looking for to ensure Action 2 isn't tied to one EL. Of course, deciding to 
> >implement the EL API by OGNL is one thing, 
> >finding someone with the time and expertise to do it is another :) 
> > 
> >Do you know of an alternate implementation of the EL API and/or more 
> >documentation about it? In my research, everywhere 
> >I saw it mentioned it didn't make the distinction, and comments, 
> >particularly 
> >on TSS, seemed to indicate the features I 
> >previously mentioned were explicitly rejected (method invocation, for 
> >example). 
> > 
> >Ok, so we can walk away with saying we might be able to collaborate on the 
> >EL 
> >API, provided someone steps up and ports 
> >OGNL or an EL with a similar set of capabilities to it. I'm still not 
> >convinced implementing WebWork as a Lifecycle 
> >implementation would bring any val

DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript

[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=39121





--- Additional Comments From [EMAIL PROTECTED]  2006-04-11 03:37 ---
I put in a patch to support validator 1.3 in the 20060411 shale nightly.  It 
covers more ground but the validation methods are not wrappered like the 
FieldChecks in Struts action.  The FieldChecks gives a standard method 
signature for new validation messages.  As it is currently implemented in 
Shale, there is a convention for determining the parameters passed to the 
validator methods and message formation which might discourage creating custom 
rules.  

I expanded the CommonsValidatorTestCase adding cases for all rule types 
including use of the ValidatorScript component to render the associated 
javascript.

I'm open for ideas on standardizing the validator rules signatures.
I'll keep this ticket open for a few days for feedback.


-- 
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: [Action2] StreamResult Patch

[James Mitchell]

Any chance you could attach this to a jira ticket?  That's the normal  
process, so that your contribution won't be forgotten.  If you can't,  
I'll try add it to jira tomorrow.


Thanks for your help.

--
James Mitchell




On Apr 10, 2006, at 2:37 AM, Eric Molitor wrote:


This patch allows the parameters for the stream result to be read from
the stack. I seem to be having issues running the unit tests so none
are included. (I'll probably work on some later). Precedence is given
to values on the stack over values in the XML file.

I plan to use the patch as follows

In xwork.xml I create a global stream result..


Then in my actions I create getter methods for the various parameters
(probably just contentDisposition, contentType, and contentLength) and
then just return "stream" as the result of my execute method.

Cheers,
   Eric

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

svn commit: r393130 [2/2] - in /struts/shale/trunk: ./ build/ clay-plugin/src/test/org/apache/shale/clay/config/ core-library/ core-library/src/conf/ core-library/src/java/org/apache/shale/component/

[gvanmatre]

Modified: 
struts/shale/trunk/core-library/src/test/org/apache/shale/validator/CommonsValidatorTestCase.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/test/org/apache/shale/validator/CommonsValidatorTestCase.java?rev=393130&r1=393129&r2=393130&view=diff
==
--- 
struts/shale/trunk/core-library/src/test/org/apache/shale/validator/CommonsValidatorTestCase.java
 (original)
+++ 
struts/shale/trunk/core-library/src/test/org/apache/shale/validator/CommonsValidatorTestCase.java
 Mon Apr 10 18:43:42 2006
@@ -16,11 +16,23 @@
 
 package org.apache.shale.validator;
 
+import java.io.StringWriter;
+import java.util.Iterator;
+
+import javax.faces.application.FacesMessage;
+import javax.faces.component.UIComponent;
+import javax.faces.component.UIForm;
+import javax.faces.component.UIInput;
+import javax.faces.component.UIViewRoot;
+import javax.faces.component.html.HtmlForm;
+import javax.faces.component.html.HtmlInputText;
+import javax.faces.context.ResponseWriter;
+
 import junit.framework.Test;
 import junit.framework.TestSuite;
 
 import org.apache.commons.validator.ValidatorAction;
-
+import org.apache.shale.component.ValidatorScript;
 import org.apache.shale.test.base.AbstractJsfTestCase;
 
 
@@ -30,6 +42,44 @@
 public class CommonsValidatorTestCase extends AbstractJsfTestCase {
 
 
+
+protected static final Object[] COMPONENTS = {
+new String[] {"javax.faces.HtmlInputText", 
"javax.faces.component.html.HtmlInputText"},
+new String[] {"org.apache.shale.ValidatorScript", 
"org.apache.shale.component.ValidatorScript"},
+new String[] {"javax.faces.HtmlForm", 
"javax.faces.component.html.HtmlForm"},
+
+};
+
+// load the mock component config data
+protected void loadComponents() {
+   for (int i = 0; i < COMPONENTS.length; i++) {
+  application.addComponent(((String[])COMPONENTS[i])[0], 
((String[])COMPONENTS[i])[1]);
+   }
+}
+
+  
+protected static final Object[] CONVERTERS = {
+   new String[] {"javax.faces.DateTime", 
"javax.faces.convert.DateTimeConverter"}
+};
+
+protected void loadConverters() {
+for (int i = 0; i < CONVERTERS.length; i++) {
+   application.addConverter(((String[])CONVERTERS[i])[0], 
((String[])CONVERTERS[i])[1]);
+}
+}
+
+public static final Object[] VALIDATORS = {
+new String[] {"org.apache.shale.CommonsValidator", 
"org.apache.shale.validator.CommonsValidator"}
+}; 
+
+protected void loadValidators() {
+for (int i = 0; i < VALIDATORS.length; i++) {
+   application.addValidator(((String[])VALIDATORS[i])[0], 
((String[])VALIDATORS[i])[1]);
+}
+}
+   
+
+   
 //  
Constructors
 
 
@@ -51,6 +101,10 @@
  Globals.DEFAULT_VALIDATOR_RULES +
  ", /org/apache/shale/validator/custom-rules.xml");
 
+
+loadComponents();
+loadConverters();
+loadValidators();
 }
 
 
@@ -78,26 +132,1087 @@
 
 // Test access to the 'required' validation rule
 public void testRequired() {
-
+
 ValidatorAction va = CommonsValidator.getValidatorAction("required");
 assertNotNull(va);
-assertEquals("required",va.getName());
+assertEquals("required", va.getName());
 assertEquals("org.apache.shale.validator.CommonsValidator",
 va.getClassname());
 assertEquals("isSupplied",va.getMethod());
+
 
 }
 
+
+//test validation rule
+public static boolean isValid(String value) {
+if (value != null && value.equals("blue") ||
+value.equals("red"))
+   return true;
+else
+   return false;
+}
+
 // Test access to a custom validation rule
 public void testCustom() {
 
+application.setMessageBundle("org.apache.shale.validator.messages");
+
+
 ValidatorAction va = CommonsValidator.getValidatorAction("testRule");
 assertNotNull(va);
-assertEquals("testRule",va.getName());
-assertEquals("com.example.myapp.CustomRules",
+assertEquals("testRule", va.getName());
+assertEquals("org.apache.shale.validator.CommonsValidatorTestCase",
 va.getClassname());
-assertEquals("isValid",va.getMethod());
+assertEquals("isValid", va.getMethod());
+
+
+// find the view root
+UIViewRoot root = facesContext.getViewRoot();
+assertNotNull(root);
+
+//create a form 1
+UIComponent form1 = this.createForm("test1", root);
+ 
+//create a dummy component 1
+HtmlInputText component1 = createInputText("testRule", form1);
+component1.setRequired(true);
+   
+//create a required field/server rule

DO NOT REPLY [Bug 39264] New: - Validation allows java script injection

[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=39264

   Summary: Validation allows java script injection
   Product: Struts
   Version: 1.2.9
  Platform: All
OS/Version: other
Status: NEW
  Keywords: ErrorMessage
  Severity: normal
  Priority: P2
 Component: Action
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


If a validation error message contains the input fields that should be shown in
the message, it is possible to inject java script as the parameter and this will
be executed on the client. There is no escaping of the characters to inhibit
this. E.g. error message "Error in parameter {0}" with the parameter
%3cscript%3ealert%28%22Show+this49%22%29%3b%3c%2fscript%3e, a popup box will
appear with the text "Show this".

-- 
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 39263] New: - [shale] Implement support for a global XWork chain

[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=39263

   Summary: [shale] Implement support for a global XWork chain
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


Shale provides an application controller (implemented as a filter) that
processes all requests to the application.  It currenty supports the ability to
customize the actual processing via a Commons Chain command chain.

Implement an optional enhancement to this controller that supports using an
XWork interceptor chain to provide customized processing on all requests to the 
app.

-- 
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 39262] New: - [shale] Implement support for XWork chains by replacing default ActionListener

[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=39262

   Summary: [shale] Implement support for XWork chains by replacing
default ActionListener
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


JSF provides an extension point for replacing the default ActionListener
implementation that actually invokes the action method when an ActionEvent is
fired, say, for a form submit.  This corresponds to the point at which an action
oriented framework would invoke the "execute" (or whatever) method on the
selected action instance.

Implement an optional replacement for the default ActionListener that would
invoke an XWork interceptor chain around the invocation of the execute method. 
This would allow per-action customization of the actual processing.

-- 
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: [action2] Maven 2 migration

[Rene Gielen]

FYI: Trying to get an overview on the changes right now (too bad the 
commit mail did not get through). Trying to fix ant build asap.


Regards,
Rene

Patrick Lightbody schrieb:


There has been a semi-working build for maven 2 included with WebWork for a few 
months, but I'd like to make that build the default build for action 2. Some of 
the WebWork guys have expressed a desire to keep an Ant build around too. In 
fact, Rene has offered to maintain it. I will start the work this weekend and 
then work with Rene to keep the Ant build in sync.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=25166&messageID=49147#49147


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




--
Rene Gielen  | http://it-neering.net/
Aachen   | PGP-ID: BECB785A
Germany  | gielen at it-neering.net


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

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Craig McClanahan]

On 4/10/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> Jacob Hookom wrote:
> > The NavigationHandler has that default behavior. But much like WebWork
> > allows the pluggable ActionMapper, all parts of JSF are pluggable in
> > that manner.  Seam and SWF are two examples of plugging in alternate
> > logic for navigation handling.  So the emphasis is put on the API, not
> > the implementation.
>
> I guess what I'm saying is the navigation is already the way we want
> it.  What would reimplementing it as a
> NavigationHandler bring to the table?
>
> > I've been trying to get everyone behind the EL-API.  The 'traditional'
> > EL implementation provided in the spec is, again, only one
> > implementation.  The JEXL implementation of the EL-API would be a piece
> > of cake, OGNL wouldn't be that hard either if they would use JavaCC with
> > the visitor=true when compiling the grammar.
>
> Ok, I was under the impression that the Unified EL was tightly coupled to
> the implementation.  If the API is abstract
> enough to handle different implementations such as OGNL, then this is good
> news.  This might be the abstraction we were
> looking for to ensure Action 2 isn't tied to one EL.  Of course, deciding
> to implement the EL API by OGNL is one thing,
> finding someone with the time and expertise to do it is another :)
>
> Do you know of an alternate implementation of the EL API and/or more
> documentation about it?  In my research, everywhere
> I saw it mentioned it didn't make the distinction, and comments,
> particularly on TSS, seemed to indicate the features I
> previously mentioned were explicitly rejected (method invocation, for
> example).
>

In JSF 1.1, the APIs for the EL were indeed tightly bound.  But that's no
longer the case with JSF 1.2.  The javadocs for the EL are formally still
part of the JSP 2.1 spec, but are implementable separately.  You can grab
the spec documents (JSP and EL, bundled in one download) and the javadocs
(again, bundled), at:

  http://jcp.org/aboutJava/communityprocess/pfd/jsr245/index2.html

These are in the "Proposed Final Draft 2" state, in JCP terms, so I wouldn't
expect to see much, if any, change before they go final.


Ok, so we can walk away with saying we might be able to collaborate on the
> EL API, provided someone steps up and ports
> OGNL or an EL with a similar set of capabilities to it.  I'm still not
> convinced implementing WebWork as a Lifecycle
> implementation would bring any value for 95% of the applications, however,
> at some point, I am planing on porting Struts
> Faces to Action 2 for the edge case of a WebWork app that wants to take
> advantage of JSF components, the real draw of
> JSF IMO, for certain pages.  At which time, I'll look more into different
> integration approaches like this one.


That (porting Struts-Faces) is a reasonable thing to do.  Not only does it
help the developer who just needs a few pages with JSF components (but wants
to keep their existing overall architecture), it also helps those who are
trying to migrate.

I guess the bottom line I think our best bet is to focus on discrete
> problems like EL, validation, annotations, etc. for
> integration.  From a framework developer perspective, sharing APIs is
> interesting, but not so for the end user, who
> could probably care less.  I guess I'm trying to see what advantages this
> would bring to the end user.  The one
> capability of JSF that I'd like to use in an Action 2 application, as an
> end user, is its stateful components,
> particularly complex, out-of-the-box components.  I'd be interested to
> hear of more capabilities an Action 2 developer
> would get out of such a hybrid.


A strategy on my TODO list for Shale is to actually go in the other
direction, by using JSF extension points to add in the processing of XWork
interceptor chains.  The two places this makes sense are:

* Overriding the default ActionListener, which actually calls the
  action method.  This corresponds to when an action framework
  invokes the "execute" or whatever method on the selected action.
  This takes care of per-action pipeline customizations.

* Supporting the use of an XWork interceptor stack in the application
  controler filter part of Shale (as an alternative to the current
mechanism,
  which lets you customize a Commons Chain command chain).  This
  takes care of global pipeline customization.

The first scenario seems pretty straightforward.  I don't know XWork well
enough to know whether the second strategy can actually be implemented the
way I think it should (it would be necessary to split the "before" and
"after" parts of the interceptor chain), but that'll become obvious when it
gets attempted :-).

The gain for the end user is to be able to reuse (or migrate) existing
interceptors without having to rewrite everything.

This is a good discussion, and I hope it can continue and be a benefit to
> both communities.
>
> Don


Craig

Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[jacob]

Great, it sounds like there's an overlap of ideas here :-)

Fundamentally, my approach to JSF 2.0 is to continue the CoR patterns with the 
various application handlers, while sticking to the 5 phases of MVC, allowing 
other interceptors to provide intermediate processing within those 5 distinct 
phases.

Secondly, brining in the concept of a ProcessingContext into JSF such that 
stateful UIComponent requests are only one implementation of the 
ProcessingContext.  The idea of a ProcessingContext with JSF was originally 
brought up with JSF Avatar, such that a single view/tree could be processed in 
part or in whole, but the fact that the JSF API was tied to a UIViewRoot object 
somewhat limited the flexability here.

So, if we provide this facade that the controller/listeners/interceptors 
operate on, much like a WebWork ActionContext, then we can say that JSF and WW 
are both client implementations that coexist via CoR/interceptors within a 
single controller.

Martin brought up the need for the visitor pattern which could be used in 
conjunction with phaselisteners/interceptors to introduce additional 
processing.  Now, if we play heavy emphasis on composition within this new 
ProcessingContext facade, then controller participants can operate, via 
visitor, on a single node (only a WW Action) or a whole tree of them as with 
JSF.  From the 30,000 foot view, that's what JSF is-- a tree of coordinated 
Actions instead of a single node, much more powerful IMHO, but adds a bit more 
overhead.

So again, at it's core for JSF 2.0, we refactor FacesContext to instead have a 
ProcessingContext (shorter name?) instead of a UIViewRoot.  The 
lifecycle/interceptors instead interrogate the ProcessingContext for alternate 
behavior while allowing those interceptors to pass a visitor to flexibly 
processing a whole composition of delegate concerns within the request.

Fundamentally, this is very similar to what we've done with the EL-API-- Seam, 
Shale, and Spring can all provide behavior from different contexts, coordinated 
by vistors in the form of ELResolvers which provides a *very* flexible way of 
mapping back to models within MVC.  Now lets do the same for MVC controllers.

-- Jacob

>Jacob Hookom wrote:
>> The NavigationHandler has that default behavior. But much like WebWork 
>> allows the pluggable ActionMapper, all parts of JSF are pluggable in 
>> that manner.  Seam and SWF are two examples of plugging in alternate 
>> logic for navigation handling.  So the emphasis is put on the API, not 
>> the implementation.
>
>I guess what I'm saying is the navigation is already the way we want it.  What 
>would reimplementing it as a 
>NavigationHandler bring to the table?
>
>> I've been trying to get everyone behind the EL-API.  The 'traditional' 
>> EL implementation provided in the spec is, again, only one 
>> implementation.  The JEXL implementation of the EL-API would be a piece 
>> of cake, OGNL wouldn't be that hard either if they would use JavaCC with 
>> the visitor=true when compiling the grammar.
>
>Ok, I was under the impression that the Unified EL was tightly coupled to the 
>implementation.  If the API is abstract 
>enough to handle different implementations such as OGNL, then this is good 
>news.  This might be the abstraction we were 
>looking for to ensure Action 2 isn't tied to one EL.  Of course, deciding to 
>implement the EL API by OGNL is one thing, 
>finding someone with the time and expertise to do it is another :)
>
>Do you know of an alternate implementation of the EL API and/or more 
>documentation about it?  In my research, everywhere 
>I saw it mentioned it didn't make the distinction, and comments, particularly 
>on TSS, seemed to indicate the features I 
>previously mentioned were explicitly rejected (method invocation, for 
>example).
>
>Ok, so we can walk away with saying we might be able to collaborate on the EL 
>API, provided someone steps up and ports 
>OGNL or an EL with a similar set of capabilities to it.  I'm still not 
>convinced implementing WebWork as a Lifecycle 
>implementation would bring any value for 95% of the applications, however, at 
>some point, I am planing on porting Struts 
>Faces to Action 2 for the edge case of a WebWork app that wants to take 
>advantage of JSF components, the real draw of 
>JSF IMO, for certain pages.  At which time, I'll look more into different 
>integration approaches like this one.
>
>I guess the bottom line I think our best bet is to focus on discrete problems 
>like EL, validation, annotations, etc. for 
>integration.  From a framework developer perspective, sharing APIs is 
>interesting, but not so for the end user, who 
>could probably care less.  I guess I'm trying to see what advantages this 
>would bring to the end user.  The one 
>capability of JSF that I'd like to use in an Action 2 application, as an end 
>user, is its stateful components, 
>particularly complex, out-of-the-box components.  I'd be interested to hear of 
>more 

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Don Brown]

Jacob Hookom wrote:
The NavigationHandler has that default behavior. But much like WebWork 
allows the pluggable ActionMapper, all parts of JSF are pluggable in 
that manner.  Seam and SWF are two examples of plugging in alternate 
logic for navigation handling.  So the emphasis is put on the API, not 
the implementation.


I guess what I'm saying is the navigation is already the way we want it.  What would reimplementing it as a 
NavigationHandler bring to the table?


I've been trying to get everyone behind the EL-API.  The 'traditional' 
EL implementation provided in the spec is, again, only one 
implementation.  The JEXL implementation of the EL-API would be a piece 
of cake, OGNL wouldn't be that hard either if they would use JavaCC with 
the visitor=true when compiling the grammar.


Ok, I was under the impression that the Unified EL was tightly coupled to the implementation.  If the API is abstract 
enough to handle different implementations such as OGNL, then this is good news.  This might be the abstraction we were 
looking for to ensure Action 2 isn't tied to one EL.  Of course, deciding to implement the EL API by OGNL is one thing, 
finding someone with the time and expertise to do it is another :)


Do you know of an alternate implementation of the EL API and/or more documentation about it?  In my research, everywhere 
I saw it mentioned it didn't make the distinction, and comments, particularly on TSS, seemed to indicate the features I 
previously mentioned were explicitly rejected (method invocation, for example).


Ok, so we can walk away with saying we might be able to collaborate on the EL API, provided someone steps up and ports 
OGNL or an EL with a similar set of capabilities to it.  I'm still not convinced implementing WebWork as a Lifecycle 
implementation would bring any value for 95% of the applications, however, at some point, I am planing on porting Struts 
Faces to Action 2 for the edge case of a WebWork app that wants to take advantage of JSF components, the real draw of 
JSF IMO, for certain pages.  At which time, I'll look more into different integration approaches like this one.


I guess the bottom line I think our best bet is to focus on discrete problems like EL, validation, annotations, etc. for 
integration.  From a framework developer perspective, sharing APIs is interesting, but not so for the end user, who 
could probably care less.  I guess I'm trying to see what advantages this would bring to the end user.  The one 
capability of JSF that I'd like to use in an Action 2 application, as an end user, is its stateful components, 
particularly complex, out-of-the-box components.  I'd be interested to hear of more capabilities an Action 2 developer 
would get out of such a hybrid.


This is a good discussion, and I hope it can continue and be a benefit to both 
communities.

Don

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

Re: [Action2] Freemarker and Velocity Tag prefix

[Don Brown]

Yeah, go ahead and change the prefixes.  Thanks,

Don

tm jee wrote:
Thanks for the reply Don. 

The prefix for Velocity and Freemarker is not as flexible as jsp tags. They are sort of like a key used in the model for like freemarker for example. It could be overriden but that would need user to extends and override some methods in FreemarkerManager for example. 

If there's no objection, I could changed them to saf as voted. 


Thx. guys  :-)


- Original Message 
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Monday, 10 April, 2006 2:32:10 AM
Subject: Re: [Action2] Freemarker and Velocity Tag prefix

I've been using a: but saf: is fine too, if that is the preferred 
prefix.  It really is only important to be consistent in our apps and 
docs, since the end user can make it whatever they want.


Don

tm jee wrote:

Hi guys,

Just want to ask a bit about the freemarker and velocity prefix for SAF2.0. 
Currently for freemarker, the Freemarker transform and Velocity prefix used is 
ww

in freemarker, it will be @ww.url  @ww.a ...   @ww.textfieldetc 
in velocity, it will be @wwurl  @wwa   @wwtextfield   etc.


I think we should changed it to saf, is that right? I bumped into this while 
trying to changing some of the jsp/ftl files used in showcase example. Thx.

regards


  



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








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

Re: [Action2] Jira not accessible

[Don Brown]

tm jee wrote:

Hi,

1] Just wondering if we are using http://issues.apache.org/struts for SAF2.0 
bug tracking instead of OpenSymphony's.
Just tried to access it but it seems to be down.


Yes, please use the Apache instance, but unfortunately, it is down.  Anyone know the procedure for this?  Do I just 
notify infra each time it goes down, or can we restart it ourselves?



2] In STATUS.txt, it says that 
https://svn.apache.org/repos/asf/struts/sandbox/trunk/action2/ is the 
repository which if
not mistaken should instead be 
https://svn.apache.org/repos/asf/incubator/webwork2/ if not mistaken, or is it 
that
https://svn.apache.org/repos/asf/incubator/webwork2/ is just a temporary one.


The sandbox repo is where some experimental action2 code is going, including some Action 1 migration code and converted 
Action 1 webapp examples.  The repository for the WebWork code is indeed in the incubator repo.  I've updated the main 
status page, http://incubator.apache.org/projects/webwork2.html, with the correct information.


Don



Thx in advance. :-)

regards





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

[OT] JBoss acquired?

[James Mitchell]

http://www.jboss.com/redhat


--
James Mitchell





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

[Action2] Jira not accessible

[tm jee]

Hi,

1] Just wondering if we are using  http://issues.apache.org/struts for SAF2.0 
bug tracking instead of OpenSymphony's. Just tried to access it but it seems to 
be down.

2] In STATUS.txt, it says that 
https://svn.apache.org/repos/asf/struts/sandbox/trunk/action2/  is the 
repository which if not mistaken should instead be  
https://svn.apache.org/repos/asf/incubator/webwork2/  if not mistaken, or is it 
that  https://svn.apache.org/repos/asf/incubator/webwork2/ is just a temporary 
one.

Thx in advance. :-)

regards

Re: [Action2] Freemarker and Velocity Tag prefix

[tm jee]

Thanks for the reply Don. 

The prefix for Velocity and Freemarker is not as flexible as jsp tags. They are 
sort of like a key used in the model for like freemarker for example. It could 
be overriden but that would need user to extends and override some methods in 
FreemarkerManager for example. 

If there's no objection, I could changed them to saf as voted. 

Thx. guys  :-)


- Original Message 
From: Don Brown <[EMAIL PROTECTED]>
To: Struts Developers List 
Sent: Monday, 10 April, 2006 2:32:10 AM
Subject: Re: [Action2] Freemarker and Velocity Tag prefix

I've been using a: but saf: is fine too, if that is the preferred 
prefix.  It really is only important to be consistent in our apps and 
docs, since the end user can make it whatever they want.

Don

tm jee wrote:
> Hi guys,
>
> Just want to ask a bit about the freemarker and velocity prefix for SAF2.0. 
> Currently for freemarker, the Freemarker transform and Velocity prefix used 
> is ww
>
> in freemarker, it will be @ww.url  @ww.a ...   @ww.textfieldetc 
> in velocity, it will be @wwurl  @wwa   @wwtextfield   etc.
>
> I think we should changed it to saf, is that right? I bumped into this while 
> trying to changing some of the jsp/ftl files used in showcase example. Thx.
>
> regards
>
>
>   


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

[OT] Re: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[James Mitchell]

Maybe someone should combine everything just to make us happy!!!

shwatt (SHale/Wicket/Action2/Tapestry/Tiles) - It's about choice!

strapon4j (STRipes/Action2/PythON) - Not for the timid!



--
James Mitchell

P.S.  Sorry - Friday was too long of a wait!


On Apr 9, 2006, at 2:59 PM, Dakota Jack wrote:

Why would we want the Action/Shale frameworks closer.  I thought  
you guys
were into diversity, not just trying to sell JSF?  Lord, if you  
bring Shale
to WebWorks, then you will truly have destroyed any hope of Struts  
survival

in any form, even WebWorks.



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

Re: svn commit: r392870 - /struts/action/trunk/apps/mailreader/src/main/resources/

[Wendy Smoak]

On 4/9/06, Martin Cooper <[EMAIL PROTECTED]> wrote:

> Hmm, is this a temporary thing? Maven 2 likes to find resources under
> 'resources', rather than in the source tree (meaning that's the default).
> That happens to be my preference too. ;-)

Right now we have some things in the source tree, some in conf/java, 
some in src/conf,  (and not always arranged in the directory structure
they will have in the jar).  The  section for core is
pretty bad:
   http://svn.apache.org/repos/asf/struts/action/trunk/core/pom.xml

To reduce the amount of configuration, I'd like to convert conf/java
and src/conf into src/main/resources eventually, but I wasn't planning
to move anything that is currently stored in the source tree.

--
Wendy

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

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Adam Winer]

On 4/9/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> Don Brown wrote:
> > Yeah, I read that post, and while interesting, I'm not sure it would
> > hold much value, particularly for Action 2 applications.
> >
> > Basically, the approach intercepts the usual Faces processing at the
> > start, turning the lifecycle into one used by Action 1.  Action 2,
> > based on WebWork, doesn't have a predefined workflow process, leaving
> > that job up to interceptor chains.  This allows you to customize the
> > completely workflow for a single action or groups of actions (called
> > packages).  In fact, you could argue that perhaps JSF should be
> > implemented as Action 2 interceptors :)
> That's one of the things that I wish the original JSF 1.0 API would've
> done instead of before/after.  Probably just a continuation of the JSP
> stuff that no one likes (which also screwed up JSF's UIComponent API).
> Hopefully in JSF 2.0, we can move to the filter/interceptor pattern with
> phaselisteners (equiv WebWork interceptors).

Trivia/history: the reason JSF didn't use a filter approach was
the inability of JEE 1.3 filters to execute in response to a forward.

> > The two advantages mentioned, navigation and EL, are debatable.
> > Action 2 uses Results, allowing for each action to specify one or more
> > results which could be a simple JSP forward, a Velocity template, or
> > even a Jasper reports.  As I understand JSF navigation, the results
> > are simple request dispatches, harking back to Action 1-type
> > functionality.
> The NavigationHandler has that default behavior. But much like WebWork
> allows the pluggable ActionMapper, all parts of JSF are pluggable in
> that manner.  Seam and SWF are two examples of plugging in alternate
> logic for navigation handling.  So the emphasis is put on the API, not
> the implementation.

Exactly - and this is an example of an area where JSF could
benefit from WebWork - an alternative NavigationHandler
that supports all of the alternative, not-just-a-RequestDispatcher-call
capabilities there.

> > Using EL, on the other hand, I personally don't see as a great
> > benefit.  The new unified EL lacks many of the key features that makes
> > EL and OGNL in particular, so attractive.  For example, OGNL supports
> > method invocation, type conversion, and projection, features, AFAICT,
> > aren't supported by EL and won't ever be.  Still, one of our goals in
> > Action 2 is to make the EL pluggable, so in the future, developers can
> > choose between the unified EL and OGNL, and perhaps other options.
> I've been trying to get everyone behind the EL-API.  The 'traditional'
> EL implementation provided in the spec is, again, only one
> implementation.  The JEXL implementation of the EL-API would be a piece
> of cake, OGNL wouldn't be that hard either if they would use JavaCC with
> the visitor=true when compiling the grammar.
>
> So when you say '... aren't supported by EL and won't ever be.' that's a
> lot of smoke up   Anyways, the EL-API is what counts here and just
> like JSE 6 has that Script API, JEE has the EL API with semantics that
> fit event based frameworks, such as UIs.  MethodExpressions are a great
> example, along with EL's pluggable ELResolver system such that any
> custom type, converter, logic, etc, can be plugged in to resolve the
> behavior of a.b or a[b].  In terms of OGNL or JEXL, you can go one step
> further and produce a OgnlExpressionFactory or JexlExpressionFactory, as
> so *many* frameworks can take advantage of a common API.  There's also
> talk of having an EL JSR that will roll in everything else people are
> looking for.

I agree with Jacob - an OGNL implementation of an ExpressionFactory
would be an excellent thing.  I'm kinda tired of hearing how a webapp
framework is great or awful because the underlying EL it uses is great
or awful, when the EL implementation should be decoupled from the
framework.

-- Adam


> >
> > The only advantage I can see of this approach is to allow developers
> > to write backing beans, using the same FacesContext as other pages
> > that fully use JSF, but even then, Action 2 actions are POJO's and
> > support arbitrary method invocation already, so the remaining
> > advantage would be the FacesContext consistency.
> >
> > I'm not a JSF expert, so perhaps I'm missing something big.  I still
> > see the areas ripe for collaboration are annotations and efforts to
> > make JSF backing beans and Action 2 Actions useable in both
> > frameworks.  Also, I was only half kidding about implementing JSF as
> > Action 2 Interceptors... ;)
> That's exactly what I'm hoping for with the EL API-- such that we can
> share ELResolvers for handling common validation/converter metadata.
> I'll agree that if JSF's controller wasn't bound to the concept of a
> stateful component model, that it would make a lot more sense as a
> common platform for frameworks.  In JSF 2.0, I hope to introduce the
> idea of a common controller that will support mode

Re: [action1] Mailreader DAO test creating a file where it shouldn't

[James Mitchell]

Ok, I added some code to remove the file on tearDown (this will  
impact a few of my extensions, but I'll worry about those later).


--
James Mitchell




On Apr 10, 2006, at 11:27 AM, James Mitchell wrote:

That's created as part of the tests that get run on mailreader-dao,  
I'll look at it.


--
James Mitchell




On Apr 10, 2006, at 3:32 AM, Wendy Smoak wrote:


Every time I run mvn install, I get a file called 'test-database.xml'
created in the current directory.  Usually current/struts/action,
assuming I'm installing from the top.

$ grep -r "test-database" .
./mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/ 
impl/memory/Memo

ryUserDatabaseTest.java:protected String defaultPathName =
"test-database.xml";

This file is causing a problem with the 'mvn release:prepare' goal,
which sees that file as a local modification and refuses to continue
with the release process.

If someone has time to take a look at this, I'd appreciate it.

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]




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

svn commit: r392968 - /struts/action/trunk/mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUserDatabaseTest.java

[jmitchell]

Author: jmitchell
Date: Mon Apr 10 08:37:02 2006
New Revision: 392968

URL: http://svn.apache.org/viewcvs?rev=392968&view=rev
Log:
Clean up the test-database.xml file, with the option to keep it for debugging 
purposes

Modified:

struts/action/trunk/mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUserDatabaseTest.java

Modified: 
struts/action/trunk/mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUserDatabaseTest.java
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUserDatabaseTest.java?rev=392968&r1=392967&r2=392968&view=diff
==
--- 
struts/action/trunk/mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUserDatabaseTest.java
 (original)
+++ 
struts/action/trunk/mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/impl/memory/MemoryUserDatabaseTest.java
 Mon Apr 10 08:37:02 2006
@@ -18,6 +18,8 @@
 
 package org.apache.struts.apps.mailreader.dao.impl.memory;
 
+import java.io.File;
+
 import org.apache.struts.apps.mailreader.dao.BaseTestUserDatabase;
 import org.apache.struts.apps.mailreader.dao.Subscription;
 import org.apache.struts.apps.mailreader.dao.User;
@@ -28,8 +30,15 @@
 public class MemoryUserDatabaseTest extends BaseTestUserDatabase {
 
 protected String defaultPathName = "test-database.xml";
+private boolean deleteDatabaseFile = true;
 
-protected UserDatabase getNewUserDatabase(){
+public boolean isDeleteDatabaseFile() {
+   return deleteDatabaseFile;
+   }
+   public void setDeleteDatabaseFile(boolean deleteDatabaseFile) {
+   this.deleteDatabaseFile = deleteDatabaseFile;
+   }
+   protected UserDatabase getNewUserDatabase(){
 // using default impl
 MemoryUserDatabase memoryUserDatabase = new MemoryUserDatabase();
 memoryUserDatabase.setPathname(defaultPathName);
@@ -49,5 +58,12 @@
 super.setUp();
 // force write to disk
 userDatabase.close();
+}
+protected void tearDown() throws Exception {
+   super.tearDown();
+   if (isDeleteDatabaseFile()){
+   File file = new File(defaultPathName);
+   file.delete();
+   }
 }
 }



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

Re: [action1] Mailreader DAO test creating a file where it shouldn't

[James Mitchell]

That's created as part of the tests that get run on mailreader-dao,  
I'll look at it.


--
James Mitchell




On Apr 10, 2006, at 3:32 AM, Wendy Smoak wrote:


Every time I run mvn install, I get a file called 'test-database.xml'
created in the current directory.  Usually current/struts/action,
assuming I'm installing from the top.

$ grep -r "test-database" .
./mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/ 
impl/memory/Memo

ryUserDatabaseTest.java:protected String defaultPathName =
"test-database.xml";

This file is causing a problem with the 'mvn release:prepare' goal,
which sees that file as a local modification and refuses to continue
with the release process.

If someone has time to take a look at this, I'd appreciate it.

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]

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Don Brown]

Sorry, I meant to type Stripes, not Wicket.

Don

Michael Jouravlev wrote:

On 4/9/06, Don Brown <[EMAIL PROTECTED]> wrote:

OGNL is used by Action 2/WebWork, Tapestry, Wicket, and several others.
It is the most advanced EL with the most features, however some of those
aren't well documented.


Wicket guys switched from OGNL to their own implementation, they say
it is much faster though more limited.

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





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

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Michael Jouravlev]

On 4/9/06, Don Brown <[EMAIL PROTECTED]> wrote:
> OGNL is used by Action 2/WebWork, Tapestry, Wicket, and several others.
> It is the most advanced EL with the most features, however some of those
> aren't well documented.

Wicket guys switched from OGNL to their own implementation, they say
it is much faster though more limited.

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

Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[Jacob Hookom]

Don Brown wrote:
Yeah, I read that post, and while interesting, I'm not sure it would 
hold much value, particularly for Action 2 applications.


Basically, the approach intercepts the usual Faces processing at the 
start, turning the lifecycle into one used by Action 1.  Action 2, 
based on WebWork, doesn't have a predefined workflow process, leaving 
that job up to interceptor chains.  This allows you to customize the 
completely workflow for a single action or groups of actions (called 
packages).  In fact, you could argue that perhaps JSF should be 
implemented as Action 2 interceptors :)
That's one of the things that I wish the original JSF 1.0 API would've 
done instead of before/after.  Probably just a continuation of the JSP 
stuff that no one likes (which also screwed up JSF's UIComponent API).  
Hopefully in JSF 2.0, we can move to the filter/interceptor pattern with 
phaselisteners (equiv WebWork interceptors).




The two advantages mentioned, navigation and EL, are debatable.  
Action 2 uses Results, allowing for each action to specify one or more 
results which could be a simple JSP forward, a Velocity template, or 
even a Jasper reports.  As I understand JSF navigation, the results 
are simple request dispatches, harking back to Action 1-type 
functionality.
The NavigationHandler has that default behavior. But much like WebWork 
allows the pluggable ActionMapper, all parts of JSF are pluggable in 
that manner.  Seam and SWF are two examples of plugging in alternate 
logic for navigation handling.  So the emphasis is put on the API, not 
the implementation.
Using EL, on the other hand, I personally don't see as a great 
benefit.  The new unified EL lacks many of the key features that makes 
EL and OGNL in particular, so attractive.  For example, OGNL supports 
method invocation, type conversion, and projection, features, AFAICT, 
aren't supported by EL and won't ever be.  Still, one of our goals in 
Action 2 is to make the EL pluggable, so in the future, developers can 
choose between the unified EL and OGNL, and perhaps other options.
I've been trying to get everyone behind the EL-API.  The 'traditional' 
EL implementation provided in the spec is, again, only one 
implementation.  The JEXL implementation of the EL-API would be a piece 
of cake, OGNL wouldn't be that hard either if they would use JavaCC with 
the visitor=true when compiling the grammar.


So when you say '... aren't supported by EL and won't ever be.' that's a 
lot of smoke up   Anyways, the EL-API is what counts here and just 
like JSE 6 has that Script API, JEE has the EL API with semantics that 
fit event based frameworks, such as UIs.  MethodExpressions are a great 
example, along with EL's pluggable ELResolver system such that any 
custom type, converter, logic, etc, can be plugged in to resolve the 
behavior of a.b or a[b].  In terms of OGNL or JEXL, you can go one step 
further and produce a OgnlExpressionFactory or JexlExpressionFactory, as 
so *many* frameworks can take advantage of a common API.  There's also 
talk of having an EL JSR that will roll in everything else people are 
looking for.


The only advantage I can see of this approach is to allow developers 
to write backing beans, using the same FacesContext as other pages 
that fully use JSF, but even then, Action 2 actions are POJO's and 
support arbitrary method invocation already, so the remaining 
advantage would be the FacesContext consistency.


I'm not a JSF expert, so perhaps I'm missing something big.  I still 
see the areas ripe for collaboration are annotations and efforts to 
make JSF backing beans and Action 2 Actions useable in both 
frameworks.  Also, I was only half kidding about implementing JSF as 
Action 2 Interceptors... ;)
That's exactly what I'm hoping for with the EL API-- such that we can 
share ELResolvers for handling common validation/converter metadata.  
I'll agree that if JSF's controller wasn't bound to the concept of a 
stateful component model, that it would make a lot more sense as a 
common platform for frameworks.  In JSF 2.0, I hope to introduce the 
idea of a common controller that will support model 1 and model 2 by 
putting the view/state into a facade.  This facade can be implemented as 
a Action in WW terms or a UIComponent tree in JSF terms.  Even if we do 
correct the model 1 in a hybrid implementation, there will always be a 
need for true model 2 support, it's just a matter of how efficiently we 
can integrate the two into a common mind share within JEE.


-- Jacob



Don


Sean Schofield wrote:

[Moving this aspect of the discussion from myfaces to struts list ...]

On 4/7/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
 

Covered here a bit:

http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html 




@Jacob:

Great blog entry!

@ Struts Dev:

I recommend you check this out.  Jacob outlines how its possible to
create a simple action oriented framework on top of the JSF API
without fussing

[action1] Mailreader DAO test creating a file where it shouldn't

[Wendy Smoak]

Every time I run mvn install, I get a file called 'test-database.xml'
created in the current directory.  Usually current/struts/action,
assuming I'm installing from the top.

$ grep -r "test-database" .
./mailreader-dao/src/test/org/apache/struts/apps/mailreader/dao/impl/memory/Memo
ryUserDatabaseTest.java:protected String defaultPathName =
"test-database.xml";

This file is causing a problem with the 'mvn release:prepare' goal,
which sees that file as a local modification and refuses to continue
with the release process.

If someone has time to take a look at this, I'd appreciate it.

Thanks,
--
Wendy

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

Re: Maven 2 build working, more to come

[Wendy Smoak]

On 4/6/06, Don Brown <[EMAIL PROTECTED]> wrote:

> We'll get out a unified Action 1 release yet :)

I think it's just about ready for 1.3.2.  Since I haven't ever
released with Maven 2, I wasn't quite ready to try it against the
Struts repo without seeing it once through somewhere else.

I'm practicing release:prepare against an import of struts-action in
the ASF test repo:
   https://svn.apache.org/repos/test/struts/struts-action/trunk/
and with a "test" Maven repository:
   http://cvs.apache.org/builds/struts/maven/test-repo/

The struts-action-parent pom has been modified (,
, and ) to point at those
locations rather than the usual snapshot and svn repos:
   https://svn.apache.org/repos/test/struts/struts-action/trunk/pom.xml

So far it looks good, except that the first time I tried it, I didn't
create a 'tags' directory in the right place, so release:prepare died
when it tried to do the tag.  After moving things around I couldn't
get back to where I started, so I had to re-import.

The code in the ASF test repo is ready to try again if someone else
would like to pick this up, or if you're comfortable enough with the
process to do it against the Struts repo, that's also an option. :)

I do know that Maven is going to completely reformat all the poms the
first time we do this, so be prepared for a big diff when it's really
only changing the version numbers.

I'm still not sure how we're going to create the 'assembly' for the
distribution and make sure that the jars in it are exactly the same as
the ones that got deployed to the repo.  I think checking out the tag
and running 'mvn -P pre-assembly assembly:assembly' will do it,
because the artifacts will have been installed locally when they were
deployed.  (Just don't 'mvn install' from the tag, or you'll overwrite
and potentially change them.)

Here are my notes on the process so far:
 * http://wiki.wsmoak.net/cgi-bin/wiki.pl?Maven/Release

And the Struts Wiki page where I'll hope we'll come up with a
procedure, plus the Maven guide to releasing:
 * http://wiki.apache.org/struts/StrutsMavenRelease
 * http://maven.apache.org/guides/mini/guide-releasing.html

--
Wendy

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