date:20031217

husted  2003/12/17 20:30:08

  Modified:src/share/org/apache/struts/action RequestProcessor.java
  Log:
  Javadoc tweaks only. No functional changes.
  
  Revision  ChangesPath
  1.40  +97 -80
jakarta-struts/src/share/org/apache/struts/action/RequestProcessor.java
  
  Index: RequestProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/RequestProcessor.java,v
  retrieving revision 1.39
  retrieving revision 1.40
  diff -u -r1.39 -r1.40
  --- RequestProcessor.java 15 Nov 2003 23:43:01 -  1.39
  +++ RequestProcessor.java 18 Dec 2003 04:30:08 -  1.40
  @@ -87,8 +87,8 @@
   
   /**
* RequestProcessor contains the processing logic that
  - * the Struts controller servlet performs as it receives each servlet request
  - * from the container.  You can customize the request processing behavior by
  + * the @link(ActionServlet) performs as it receives each servlet request
  + * from the container. You can customize the request processing behavior by
* subclassing this class and overriding the method(s) whose behavior you are
* interested in changing.
*
  @@ -104,16 +104,16 @@
   
   
   /**
  - * The request attribute under which the path information is stored for
  - * processing during a RequestDispatcher.include() call.
  + * The request attribute under which the path information is stored for
  + * processing during a RequestDispatcher.include call.
*/
   public static final String INCLUDE_PATH_INFO =
   "javax.servlet.include.path_info";
   
   
   /**
  - * The request attribute under which the servlet path information is stored
  - * for processing during a RequestDispatcher.include() call.
  + * The request attribute under which the servlet path information is stored
  + * for processing during a RequestDispatcher.include call.
*/
   public static final String INCLUDE_SERVLET_PATH =
   "javax.servlet.include.servlet_path";
  @@ -123,33 +123,36 @@
   
   
   /**
  - * The set of Action instances that have been created and initialized,
  - * keyed by the fully qualified Java class name of the Action class.
  + * The set of Action instances that have been created and
  + * initialized, keyed by the fully qualified Java class name of the
  + * Action class.
*/
   protected HashMap actions = new HashMap();
   
  +
   /**
  - * The ModuleConfiguration we are associated with.
  + * The ModuleConfiguration with which we are associated.
*/
   protected ModuleConfig moduleConfig = null;
   
   
   /**
  - * Commons Logging instance.
  + * Commons Logging instance.
*/
   protected static Log log = LogFactory.getLog(RequestProcessor.class);
   
   
   /**
  - * The controller servlet we are associated with.
  + * The controller servlet we are associated with.
*/
   protected ActionServlet servlet = null;
   
  +
   // - Public Methods
   
   
   /**
  - * Clean up in preparation for a shutdown of this application.
  + * Clean up in preparation for a shutdown of this application.
*/
   public void destroy() {
   
  @@ -167,7 +170,7 @@
   
   
   /**
  - * Initialize this request processor instance.
  + * Initialize this request processor instance.
*
* @param servlet The ActionServlet we are associated with
* @param moduleConfig The ModuleConfig we are associated with.
  @@ -185,6 +188,7 @@
   this.moduleConfig = moduleConfig;
   }
   
  +
   /**
* Process an HttpServletRequest and create the
* corresponding HttpServletResponse.
  @@ -275,8 +279,8 @@
   
   
   /**
  - * Return an Action instance that will be used to process
  - * the current request, creating a new one if necessary.
  + * Return an Action instance that will be used to process
  + * the current request, creating a new one if necessary.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
  @@ -314,8 +318,8 @@
   
   try {
   instance = (Action) RequestUtils.applicationInstance(className);
  -// TODO Maybe we should propagate this exception instead of 
returning
  -// null.
  +// :TODO: Maybe we should propagate this exception
  +// instead of returning null.
   } catch (Exception e) {
   log.error(
   getInternal().getMessage("actionCreate", mapping.getPath()),
  @@ -338,9 +342,10 @@
   
   
   /**
  - * Retrieve and return the ActionForm bean associated with
  - * this mapping, creating and stashi

cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

husted  2003/12/17 19:38:42

  Modified:src/share/org/apache/struts/action ActionServlet.java
  Log:
  Javadoc tweaks only. No functional changes.
  
  Revision  ChangesPath
  1.172 +68 -65
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
  
  Index: ActionServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
  retrieving revision 1.171
  retrieving revision 1.172
  diff -u -r1.171 -r1.172
  --- ActionServlet.java18 Dec 2003 02:59:33 -  1.171
  +++ ActionServlet.java18 Dec 2003 03:38:42 -  1.172
  @@ -115,7 +115,7 @@
   import org.xml.sax.SAXException;
   
   /**
  - * ActionServlet represents the "controller" in the
  + * ActionServlet provides the "controller" in the
* Model-View-Controller (MVC) design pattern for web applications that is
* commonly known as "Model 2".  This nomenclature originated with a
* description in the JavaServerPages Specification, version 0.92, and has
  @@ -123,33 +123,36 @@
*
* Generally, a "Model 2" application is architected as follows:
* 
  - * The user interface will generally be created with JSP pages, which
  - * will not themselves contain any business logic.  These pages represent
  + * The user interface will generally be created with server pages, which
  + * will not themselves contain any business logic. These pages represent
* the "view" component of an MVC architecture.
* Forms and hyperlinks in the user interface that require business logic
  - * to be executed will be submitted to a request URI that is mapped to the
  - * controller servlet.
  - * There will be one instance of this servlet class,
  + * to be executed will be submitted to a request URI that is mapped to this
  + * servlet.
  + * There can be one instance of this servlet class,
* which receives and processes all requests that change the state of
  - * a user's interaction with the application.  This component represents
  - * the "controller" component of an MVC architecture.
  - * The controller servlet will select and invoke an action class to perform
  - * the requested business logic.
  - * The action classes will manipulate the state of the application's
  + * a user's interaction with the application.  The servlet delegates the
  + * handling of a request to a @link(RequestProcessor) object. This component
  + * represents the "controller" component of an MVC architecture.
  + * The RequestProcessor selects and invokes an @link(Action) class 
to perform
  + * the requested business logic, or delegates the response to another 
resource.
  + * The Action classes can manipulate the state of the application's
* interaction with the user, typically by creating or modifying JavaBeans
* that are stored as request or session attributes (depending on how long
  - * they need to be available).  Such JavaBeans represent the "model"
  + * they need to be available). Such JavaBeans represent the "model"
* component of an MVC architecture.
* Instead of producing the next page of the user interface directly,
  - * action classes will generally use the
  - * RequestDispatcher.forward facility of the servlet API
  - * to pass control to an appropriate JSP page to produce the next page
  - * of the user interface.
  + * Action classes generally return an @link(ActionForward) to 
indicate
  + * which resource should handle the response. If the Action
  + * does not return null, the RequestProcessor forwards or
  + * redirects to the specified resource (by utilizing
  + * RequestDispatcher.forward or Response.sendRedirect)
  + * so as to produce the next page of the user interface.
* 
*
  - * The standard version of ActionServlet implements the
  - *following logic for each incoming HTTP request.  You can override
  - *some or all of this functionality by subclassing this servlet and
  + * The standard version of RequestsProcessor implements the
  + *following logic for each incoming HTTP request. You can override
  + *some or all of this functionality by subclassing this object and
*implementing your own version of the processing.
* 
* Identify, from the incoming request URI, the substring that will be
  @@ -157,11 +160,11 @@
* Use this substring to map to the Java class name of the corresponding
* action class (an implementation of the Action interface).
* 
  - * If this is the first request for a particular action class, instantiate
  - * an instance of that class and cache it for future use.
  + * If this is the first request for a particular Action class,
  + * instantiate an instance of that class and cache it for future use.
* Optionally populate the properties of an Acti

cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java

husted  2003/12/17 19:34:58

  Modified:src/share/org/apache/struts/util RequestUtils.java
  Log:
  Remove unused private field.
  
  Revision  ChangesPath
  1.137 +4 -11 
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
  
  Index: RequestUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
  retrieving revision 1.136
  retrieving revision 1.137
  diff -u -r1.136 -r1.137
  --- RequestUtils.java 28 Aug 2003 05:50:32 -  1.136
  +++ RequestUtils.java 18 Dec 2003 03:34:58 -  1.137
  @@ -117,13 +117,6 @@
*/
   protected static Log log = LogFactory.getLog(RequestUtils.class);
   
  -/**
  - * The message resources for this package.
  - */
  -private static MessageResources messages =
  -
MessageResources.getMessageResources("org.apache.struts.util.LocalStrings");
  -
  -
   // - Public Methods
   
   /**
  
  
  

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

cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java

husted  2003/12/17 18:59:33

  Modified:src/share/org/apache/struts/action ActionServlet.java
  Log:
  Javadoc tweaks only. No functional changes.
  
  Revision  ChangesPath
  1.171 +115 -103  
jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java
  
  Index: ActionServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionServlet.java,v
  retrieving revision 1.170
  retrieving revision 1.171
  diff -u -r1.170 -r1.171
  --- ActionServlet.java27 Nov 2003 05:38:53 -  1.170
  +++ ActionServlet.java18 Dec 2003 02:59:33 -  1.171
  @@ -142,7 +142,7 @@
* component of an MVC architecture.
* Instead of producing the next page of the user interface directly,
* action classes will generally use the
  - * RequestDispatcher.forward() facility of the servlet API
  + * RequestDispatcher.forward facility of the servlet API
* to pass control to an appropriate JSP page to produce the next page
* of the user interface.
* 
  @@ -162,10 +162,11 @@
* Optionally populate the properties of an ActionForm bean
* associated with this mapping.
* Call the execute method of this action class, passing
  - * on a reference to the mapping that was used (thereby providing access
  - * to the underlying ActionServlet and ServletContext, as well as any
  - * specialized properties of the mapping itself), and the request and
  - * response that were passed to the controller by the servlet container.
  + * on a reference to the mapping that was used, the relevant form-bean
  + * (if any), and the request and the response that were passed to the
  + * controller by the servlet container (thereby providing access to any
  + * specialized properties of the mapping itself as well as to the
  + * ServletContext).
* 
* 
*
  @@ -173,9 +174,7 @@
* on the following servlet initialization parameters, which you will specify
* in the web application deployment descriptor (/WEB-INF/web.xml)
* for your application.  Subclasses that specialize this servlet are free to
  - * define additional initialization parameters. Several of these were
  - * deprecated between the 1.0 and 1.1 releases. The deprecated parameters
  - * are listed after the nominal parameters.
  + * define additional initialization parameters. 
* 
* config - Comma-separated list of context-relative
* path(s) to the XML resource(s) containing the configuration information
  @@ -204,29 +203,6 @@
* validating - Should we use a validating XML parser to
* process the configuration file (strongly recommended)? [true]
* 
  - * The following parameters may still be used with the Struts 1.1 release but
  - * are deprecated.
  - * 
  - * formBean - The Java class name of the ActionFormBean
  - * implementation to use [org.apache.struts.action.ActionFormBean].
  - * DEPRECATED - Configure this using the "className" attribute
  - * of each  element.
  - * forward - The Java class name of the ActionForward
  - * implementation to use [org.apache.struts.action.ActionForward].
  - * Two convenient classes you may wish to use are:
  - * 
  - * org.apache.struts.action.ForwardingActionForward -
  - * Subclass of org.apache.struts.action.ActionForward
  - * that defaults the redirect property to
  - * false (same as the ActionForward default value).
  - * org.apache.struts.action.RedirectingActionForward -
  - * Subclass of org.apache.struts.action.ActionForward
  - * that defaults the redirect property to
  - * true.
  - * 
  - * DEPRECATED - Configure this using the "className" attribute of
  - * each  element.
  - * 
*
* @author Craig R. McClanahan
* @author Ted Husted
  @@ -241,67 +217,72 @@
   
   
   /**
  - * Comma-separated list of context-relative path(s) to our configuration
  - * resource(s) for the default module.
  + * Comma-separated list of context-relative path(s) to our configuration
  + * resource(s) for the default module.
*/
   protected String config = "/WEB-INF/struts-config.xml";
   
   
   /**
  - * The Digester used to produce ModuleConfig objects from a
  - * Struts configuration file.
  + * The Digester used to produce ModuleConfig objects from a
  + * Struts configuration file.
  + *
* @since Struts 1.1
*/
   protected Digester configDigester = null;
   
   
   /**
  - * The flag to request backwards-compatible conversions for form bean
  - * properties of the Java wrapper class types.
  + * The flag to request backwards-compatible conversions for form bean
  + * properties of the Java wrapper class types.
  + *
* @since Struts 1.1

Struts 2.0 as a Portlet framework

2003-12-17 Thread Mete Kural

Hi All,

A huge Struts 2.0 discussion on the struts-dev list has started. Everybody is putting 
in their ideas of how Struts 2.0 ought to be like. I encourage all Portal/Portlet 
developers to participate in that discussion in struts-dev and provide their insight 
on how Struts 2.0 could become a good portlet framework.

Sorry for the cross-posting. I thought it was substantial news that portal/portlet 
developers may be interested in.

Thanks,
Mete

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

Re: Struts 2.0 Discussion Forum

[EMAIL PROTECTED] wrote:
I favor a evolutionary approach to getting to the
Next Generation of Struts. As apposed to scrapping
every piece of code we have. This would entail aggressively
deprecating functionality.
I believe the plan was to do both. Work can continue on Struts 1.x.x to 
evolve it into an even more useful framework. Meanwhile, work on a new 
codebase for Struts 2.x.x can also proceed.

Of course, when people say "new codebase", I don't think we mean a 
cleanroom implementation. There would be lots of reuse of code that 
already works well.

The relationship between the branches is liable to be synergistic. In 
evolutionary mode, it's sometimes hard to see the forest for the trees, 
and in revolutionary mode is sometimes hard to see the trees for the 
forest :)

In the end, whether Struts 1.x.x evolves into Struts 2.x.x, or whether 
Struts 2.x.x emerges from a revolution, will be up to Darwin. The 
volunteers will elect to spend their time on this or that, and whichever 
approach proves more attractive will win.

In the meantime, it's important to avoid saying whether a given codebase 
will be 2.x.x or not. When the time comes, the community can decide, but 
we'd need a working 2.x.x candidate in front of us first. :)

http://incubator.apache.org/learn/rules-for-revolutionaries.html

-Ted.



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread David Graham


--- Vic Cekvenich <[EMAIL PROTECTED]> wrote:
> 
> And even a simple DAO interface, to be used optionaly be people, so 
> they can go back and forth from iBatis to Hibreante or what ever.

I started the Mapper project in the commons for this exact reason.  It
doesn't belong in Struts.

http://jakarta.apache.org/commons/sandbox/mapper/

David

> 
> And build Struts on top of HiveMind or similar. (IoC and Services... and
> 
> XML).
> 
> If just the MVC interfaces are defined, then several implemenations can 
> ship. One implemtation would be backwards compatible.
> Once could be SOAPActionImpl.
> 
> Action's execute should take a Map as signature argument. This way we do
> 
> not have Req/Resp tie in, but anything comes in.
> Ex: execute(Map arg)  { .. }
> A good 1st step is to have a TilesAction and Action have same signature 
> for execute.
> 
> 
> .V
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

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

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread [EMAIL PROTECTED]

I favor a evolutionary approach to getting to the
Next Generation of Struts. As apposed to scrapping
every piece of code we have. This would entail aggressively
deprecating functionality.

The advantages are we would most likely always have
a working framework, which would encourage user
participation, usage, testing. That means we could use it
in our paying jobs. Some of us may even be able to
justify working on Struts 2.0 on our paying Jobs time.
I am concerned where all the energy, time, code, 
documentation, and testing will come from with a clean start.
I strongly believe one of the reasons Struts is so popular
is that we were big on compatibility between releases,
and so staying up to date with the latest Struts release or
nightly was not very painful. 

The disadvantages are that it might seem like we
would have to do extra work in gradually refactoring
Struts into the next version.

Any code base that starts from scratch has to undergo
the painful process of setting up the initial classes,
tests etc... Again user participation, in usage, testing,
and contributions played a major, no, critical role in 
struts's development, and we'll need that same input again.
However, now days there are many other frameworks with which to
choose.

Bottom line is I believe like you do that we are smarter now and
know better ways to do things. Look up Erick Hatchers comments
he made a few months ago on Struts, and ways to improve it as
an example.

-Rob

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 17, 2003 09:22 PM
> To: 'Struts Developers List'
> Subject: Re: Struts 2.0 Discussion Forum
> 
> Don Brown wrote:
>  > Is there one?  I have several ideas I'd like to toss into the
>  > discussion.
>  >
>  > Don
> 
> There's a Whiteboard page in the Wiki.
> 
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
> 
> I'll be posting more about Jericho, but wanted to get what I had so far 
> (a starter DTD) under CVS.
> 
> One other idea that I've been meaning to bring up in the wake of 
> wildcard Mappings, is the idea of merging context attributes into 
> ActionForward paths. For example, we could do something like
> 
> 
> 
> and have it replace {key} with request.getAttribute("key") (or session 
> if not found).
> 
> -Ted.
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

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

cvs commit: jakarta-struts/contrib project.xml

husted  2003/12/17 17:10:23

  Added:   contrib  project.xml
  Log:
  Base Maven project file for contrib artifacts.
  
  Revision  ChangesPath
  1.1  jakarta-struts/contrib/project.xml
  
  Index: project.xml
  ===
  
  
  
3
struts-contrib-master
Struts Contrib Master Maven POM
1.0
  

  Apache Software Foundation
  http://www.apache.org
  2000
http://jakarta.apache.org/images/jakarta-logo.gif

http://jakarta.apache.org/struts/images/struts.gif
2000
org.apache.struts
jakarta
  

http://jakarta.apache.org/struts/contrib/${pom.artifactId.substring(8)}/index.html
http://nagoya.apache.org/

jakarta.apache.org/struts

/www/jakarta.apache.org/struts/contrib/${pom.artifactId.substring(8)}/

/www/jakarta.apache.org/builds/jakarta-commons-sandbox/${pom.artifactId.substring(8)}/


  scm:cvs:pserver:[EMAIL 
PROTECTED]:/home/cvspublic:jakarta-struts/contrib/${pom.artifactId.substring(8)}
  
http://cvs.apache.org/viewcvs/jakarta-struts/contrib/${pom.artifactId.substring(8)}/

  
  

  Struts User List
  
[EMAIL PROTECTED]
  
  
[EMAIL PROTECTED]
  
  
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=42
  


  Struts Developer List
  
[EMAIL PROTECTED]
  
  
[EMAIL PROTECTED]
  
  
http://nagoya.apache.org/eyebrowse/SummarizeList?listId=41
  

  
  
  

  commons-beanutils
  1.6.1
  http://jakarta.apache.org/commons/beanutils.html
  true

  

  commons-collections
  2.1
  http://jakarta.apache.org/commons/collections.html
  true

  

  commons-digester
  1.5
  http://jakarta.apache.org/commons/digester.html
  true

  

  commons-fileupload
  1.0
  http://jakarta.apache.org/commons/fileupload.html
  true

  

  commons-logging
  1.0.3
  http://jakarta.apache.org/commons/logging.html
  true

  

  

  commons-validator
  1.1.1-dev
  http://jakarta.apache.org/commons/validator.html
  true

  

  oro
  2.0.7
  http://jakarta.apache.org/oro/
  true

  

  xml-apis
  2.0.2
  http://xml.apache.org/commons/
  true

  

  antlr
  antlr
  2.7.2
  true

  

  servletapi
  2.2

  

  jakarta-struts
  1.2-dev
  http://jakarta.apache.org/struts/index.html
  true

  


  junit
  3.8.1
  http://www.junit.org

  

  commons-lang
  2.0
  http://jakarta.apache.org/commons/lang.html

  

  cactus
  cactus
  12-1.4.1
  http://jakarta.apache.org/cactus


  cactus
  cactus-ant
  1.4.1
  http://jakarta.apache.org/cactus

  


xalan
xalan
2.5.1
http://xml.apache.org/xalan

  

  [EMAIL PROTECTED]
  src/java
  src/test
  
  
  
  
  

  **/Test*.java

  
  
  
  
  
  

  **/*.properties

  
  
  
  

  
  
  
  
  

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread [EMAIL PROTECTED]

> > >- Also, again totally agreeing with Ted, make everything interface 
> > >based,
> 
> > a few more hears here ;^)
> 
> > Joe Germuska
> 
> The interface discussion has come up previously and there was some emotion
> tied to it.

I was around for Interface ActionForms in pre Struts 0.5 and it was really ugly, what 
some developers tried to do. This then triggered a number of
email's on the list to help them get it working. In almost all cases
they were trying to break the MVC Model, and pile all the logic into the
ActionForm implementation class they possibly could. 



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Vic Cekvenich

Martin Cooper wrote:

* Make the Struts core independent of the Servlets spec  
Above is my favorite wish!

I would like to be able to call an Action via XML-RPC for it to give me 
a FormBean and for me to give it a FormBean back. (or any other 
SOA). There was a few threads of SOAP Struts some time back.

And... maybe a FormBean is an XML DTD.
(Like .NET stuff, and iBatis 2.0 _sqlMap.getXMLResult())
This way a view can render it (such as core tags X: ) any way it wants. 
Ex: from javascript you call XML-RPC to get a XML (multirow bean)

And even a simple DAO interface, to be used optionaly be people, so 
they can go back and forth from iBatis to Hibreante or what ever.

And build Struts on top of HiveMind or similar. (IoC and Services... and 
XML).

If just the MVC interfaces are defined, then several implemenations can 
ship. One implemtation would be backwards compatible.
Once could be SOAPActionImpl.

Action's execute should take a Map as signature argument. This way we do 
not have Req/Resp tie in, but anything comes in.
Ex: execute(Map arg)  { .. }
A good 1st step is to have a TilesAction and Action have same signature 
for execute.

.V



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

Re: Context attributes (was: Struts 2.0 Discussion Forum)

2003-12-17 Thread gvanmatre


I like the idea of making the parameters/arguments passed between
actions declarative verses programmatic.  This makes it very easy to
define "interfaces" between pages.  The following code shows our
solution using the extendibility of struts metadata but it would be
slick if it was a feature of the baseline.

In the event that the forward is not a redirect, we just stage the data
in request scope for the target page in a Map collection.  This allows
data to be staged in the formbean that was not in the request
parameters. The target action just uses the populate method of beanutils
to move corresponding from the map cached in the request to the target
formbean.  A redirect is easy because the request processor does the
dirty work.  It would be fun if this kind processing could be moved up
in the framework.


Maybe both options of encoding arguments (declarative, programmatic)
could complement each other and both redirect and forward could have
similar behavior?


Gary








 
 




// action execute method stages the form and request.  You might have //
parameters in the form bean not in the request.

if (mapping instanceof IRusttsActionMapping) {
   ((IRusttsActionMapping) mapping).setState(form, request);
}


package com.rustts.action;

import javax.servlet.http.HttpServletRequest;

import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;

/**
 * @author Gary VanMatre
 *
 * Extended the base action mapping to add custom properties
 * use the set-property element in the XML mapping to associate
 * a page with an action.
 */
public class RusttsActionMapping
extends ActionMapping
implements IRusttsActionMapping {

private String pageId = null;

// make sure that these values will not be persisted in a
// distributed deployment.  I believe that struts caches it's
// metadata in application scope which is not replicated (only
session)
private transient ActionForm form = null;
private transient HttpServletRequest request = null;

/**
 * Returns the pageId.
 * @return String
 */
public String getPageId() {
return pageId;
}

/**
 * Sets the pageId.
 * @param pageId The pageId to set
 */
public void setPageId(String pageId) {
this.pageId = pageId;
}

/**
 * This method's purpose is to stage date for the custom action
forward class RusttsForwardAction.
 * The reference should be effective only for the dialog
duration of a method call.
 * The method is invoked by @see
com.rustts.action.RusttsDispatchAction#execute(ActionMapping, ActonForm,
HttpServletRequest, HttpServletResponse).
 */
public void setState(ActionForm form, HttpServletRequest
request) {
this.form = form;
this.request = request;
}

/**
 * This method has been overridden to initiate the propagation
 * of arguments on an action forward.
 * If the mapping class realizes interface
 * IRusttsForwardAction, the specified properties
 * in the struts configuration file will be pulled from the form bean
and
 * staged for the next page.
 * The method of staging depends on if the action forward is a redirect.
*/
public ActionForward findForward(String name) {

ActionForward forward = super.findForward(name);
if ((forward != null)
&& (forward instanceof IRusttsForwardAction)
&& (request != null)
&& (form != null)) {
forward =
   ((IRusttsForwardAction)
forward).stageForward(form, request);
}

return forward;

}

protected void finalize() {
pageId = null;
form = null;
request = null;
}

}



package com.rustts.action;

import java.net.URLEncoder;
import java.util.Iterator;
import java.util.Map;
import java.util.TreeMap;
import java.util.TreeSet;

import javax.servlet.http.HttpServletRequest;

import org.apache.commons.beanutils.BeanUtils;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;

/**
 * @author Gary VanMatre
 *
 */
public class RusttsForwardAction
extends ActionForward
implements IRusttsForwardAction {

private String[] args = new String[10];

/**
 * Returns the arg0.
 * @return String
 */
public String getArg0() {
return args[0];
}


/**
 * Returns the arg1.
 * @return String
 */
public String getArg1() {
return args[1];
}

/**
 * Returns the arg10.

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Martin Cooper wrote:
* Split out file upload handling into a separate pluggable component, with
its own configuration. I noticed that this is still in the initial Jericho
DTD, but I think it should not be. The file upload implementation is
pluggable, and so should be able to have its own config definition.
Feel free to amend that if you like. I've so far managed to avoid file 
uploading in Struts applications, and so remain blissfully ignorant of 
the grittier details.

A sort of meta-question: When is Struts no longer Struts? I mean, how much
change can we introduce in Struts 2.0 before it becomes so different that
it's really a different framework? Do we need to decide on what Struts is,
and is not, before we go too far down the path of Struts 2.0? Or do we let
whatever falls out just fall out and deal with it later?
Legally, I'd say that Strut is whatever the Struts Community says it is. 
It's a brand that belongs to the ASF, which we manage on the 
Foundation's behalf.

Technically, I'd say that Struts (or any framework) is an aggregation of 
its components. In Struts 1.0, we had mainly Form, Forward, Mapping, 
Action, and Messaging components. In Struts 1.1, we added Exception, 
Validation, Composite (or Tile), and PlugIn components.

So long as Struts 2.x retains the same hallmark components in a 
recognizable form, I'd say it's still Struts. :)

Overall, it's my feeling that Struts does all the right things, it's 
just that we don't do them in all the right places. :) Being able to 
extend elements is one example. Encapsulating paths is another.

My own goal for Struts 2.x is to consistently apply all our best 
practices and eliminate inconsistent and legacy practices. We've got a 
good thing here; we just need to make it even better. :)

In terms of new functionality, the three biggest fish I'd like to fry 
are Workflow, SSL, and Unit Testing. Towards that end, I'd like to 
consider integrating LivingLogic's Workflow, ssl-ext, and Struts 
TestCase into the Struts 2.x development stream. We may also want to 
consider adding these as standard options to Struts 1.x, so as to blaze 
a trail.

Although it's not evident from the Jericho DTD, the intention is to use 
a Context object in the signatures, perhaps the Commons Chain Context, 
so as to encapsulate Servlet/Portlet dependencies.

-Ted.



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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

I think this might be a "that was then, this is now" issue. Once upon a 
time, people were trying to do nutty things like use Entity Beans for 
ActionForms. But people are older and wiser now, and more importantly, 
we have DynaActionForms and tools like XDoclet to mitigate the 
maintenance issues.

In fact, I'd like to merge the ValidatorForm with the DynaActionForm 
configuration, so we'd have a central place to define everything the 
framework wants to know about a form.

On the topic of form processing, I'd also like to add a populate method 
that the Request Processor could call, instead of doing it externally, 
so a form could populate itself.

-Ted.

Don Brown wrote:
Hmm...I'm not familiar with that discussion, but I don't see why general
form functionality couldn't be defined in an interface, but the ActionForm
left how it is.  Of course we also have a chance to do what Craig said
he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and
actions.  WebWork2/XWork seems to have done well with that approach.
Again, just throwing ideas out there :)

Don

On Wed, 17 Dec 2003, Edgar P Dollin wrote:


And you're really going to have to break both of my arms and/or kick me
out of Struts development if you want ActionForm *ever* changed to an
interface again -- in *any* future Struts release.  I think it's an
absolutely horrible idea, for reasons that have been documented way too
many times to count.

Craig McClanahan



- Also, again totally agreeing with Ted, make everything interface
based,

a few more hears here ;^)

Joe Germuska
The interface discussion has come up previously and there was some emotion
tied to it.
Edgar

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



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



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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Hmm...I'm not familiar with that discussion, but I don't see why general
form functionality couldn't be defined in an interface, but the ActionForm
left how it is.  Of course we also have a chance to do what Craig said
he'd change about Struts (at JavaOne 2003 JSF BOF) and combine forms and
actions.  WebWork2/XWork seems to have done well with that approach.

Again, just throwing ideas out there :)

Don

On Wed, 17 Dec 2003, Edgar P Dollin wrote:

> > And you're really going to have to break both of my arms and/or kick me
> > out of Struts development if you want ActionForm *ever* changed to an
> > interface again -- in *any* future Struts release.  I think it's an
> > absolutely horrible idea, for reasons that have been documented way too
> > many times to count.
>
> > Craig McClanahan
>
>
>
> > >- Also, again totally agreeing with Ted, make everything interface
> > >based,
>
> > a few more hears here ;^)
>
> > Joe Germuska
>
> The interface discussion has come up previously and there was some emotion
> tied to it.
>
> Edgar
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Sgarlata Matt

Sorry about that!

You are right, the license is ASF.  It says so both on the SourceForge site
and in the license included in Milestone 3.  I don't know where I got the
idea that it was LGPL.

Matt
- Original Message - 
From: "Don Brown" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 17, 2003 5:20 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)


> Nope, Spring is Apache-style, I just checked.  You had me worried there
> for a minute :)
>
> Don
>
> On Wed, 17 Dec 2003, Sgarlata Matt wrote:
>
> > - Original Message -
> > From: "Joe Germuska" <[EMAIL PROTECTED]>
> > To: "Struts Developers List" <[EMAIL PROTECTED]>
> > Sent: Wednesday, December 17, 2003 5:04 PM
> > Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
> >
> >
> > > So then, with specific frameworks,  I don't understand how Pico's
> > > orientation towards constructors works in an environment where beans
> > > need to be dynamically instantiated, but perhaps I just haven't
> > > thought about it hard enough.  Avalon seems too heavy, which leaves
> > > us (or me at least) with Spring and HiveMind.  I haven't developed
> > > with either but so far the docs for Spring give me a warm fuzzy
> > > feeling while the HiveMind docs kind of scare me.
> >
> > I agree with your assessment of frameworks 100%.  However, Spring is
under
> > an LGPL license, so Struts can't use Spring unless either Struts
switches to
> > LGPL or Spring switches to ASF, right?  It would be kind of silly for
Struts
> > to stay under ASF in this case, since the Spring license would force the
> > undesirable LGPL clauses on any projects that were based on Struts.  Am
I
> > right?
> >
> > Matt
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Nope, Spring is Apache-style, I just checked.  You had me worried there
for a minute :)

Don

On Wed, 17 Dec 2003, Sgarlata Matt wrote:

> - Original Message -
> From: "Joe Germuska" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, December 17, 2003 5:04 PM
> Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
>
>
> > So then, with specific frameworks,  I don't understand how Pico's
> > orientation towards constructors works in an environment where beans
> > need to be dynamically instantiated, but perhaps I just haven't
> > thought about it hard enough.  Avalon seems too heavy, which leaves
> > us (or me at least) with Spring and HiveMind.  I haven't developed
> > with either but so far the docs for Spring give me a warm fuzzy
> > feeling while the HiveMind docs kind of scare me.
>
> I agree with your assessment of frameworks 100%.  However, Spring is under
> an LGPL license, so Struts can't use Spring unless either Struts switches to
> LGPL or Spring switches to ASF, right?  It would be kind of silly for Struts
> to stay under ASF in this case, since the Spring license would force the
> undesirable LGPL clauses on any projects that were based on Struts.  Am I
> right?
>
> Matt
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Martin Cooper

Just to add a few more off the top of my head:

* Make the Struts core independent of the Servlets spec and the Portlets
spec, so that it can be used for both, and more.

* Separate view-technology-specific code into separate components, so that
the core is view-technology agnostic. So, for example, all JSP specific
code, including all of the taglibs, would move to a JSP component.

* Rework Tiles into two facets, so that the core is independent of the
Servlets spec and JSP, and the JSP component is part of the view specific
component described above.

* Split out file upload handling into a separate pluggable component, with
its own configuration. I noticed that this is still in the initial Jericho
DTD, but I think it should not be. The file upload implementation is
pluggable, and so should be able to have its own config definition.

I know I have more in notes at home, but just wanted to throw these out.

A sort of meta-question: When is Struts no longer Struts? I mean, how much
change can we introduce in Struts 2.0 before it becomes so different that
it's really a different framework? Do we need to decide on what Struts is,
and is not, before we go too far down the path of Struts 2.0? Or do we let
whatever falls out just fall out and deal with it later?

--
Martin Cooper

On Wed, 17 Dec 2003, Don Brown wrote:

> Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
> release work. :)  I'll throw out some ideas here, then develop them later
> in the wiki:
>
> - Make Inversion of Control central.  By using an IoC framework to wire
> Struts together, it makes it really easy to extend or improve Struts not
> only for future development but for users as well.  I'd recommend Spring's
> IoC impl as it is small (>100k), really easy to use, and easily
> extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> frameworks that let you plug in Pico/Spring/Avalon, etc.
>
> - Use XML Schema over DTD's.  Give struts config its own default namespace
> to make it easier for users to mix in elements of other namespaces.  An
> example would be adding custom documentation attributes and elements.  Of
> course the usual arguments for XML Schema over DTD's apply as well.
>
> - Replace paths with URL's, allowing for a default protocol.  An action
> path would look like "action://foo" or a tiles forward would be
> "tiles://tilesdef"  This would make it easy to plug in handlers to support
> different presentation engines.  If no protocol is specified, the path is
> handled as usual.
>
> - As Ted said, contine with the wildcard theme.  Struts should do
> everything possible to cut down configuration.
>
> - Also, again totally agreeing with Ted, make everything interface based,
> have default implementations, and free apps of HTTP.  Ideally, I'd like to
> see extra effort going into making it easy if not effortless to take a
> Struts 2.0 app and use the code in a portlet or web service environment.
> At least in my area, clients are wanting human and machine interfaces,
> with the human interface generally being behind a portal.
>
> Anyways, those are my "brainstorming" thoughts.  If any look interesting,
> I'll write something up in the wiki.
>
> Don
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

On Wed, 17 Dec 2003, Joe Germuska wrote:

> >- Make Inversion of Control central.  By using an IoC framework to wire
> >Struts together, it makes it really easy to extend or improve Struts not
> >only for future development but for users as well.  I'd recommend Spring's
> >IoC impl as it is small (>100k), really easy to use, and easily
> >extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
> >frameworks that let you plug in Pico/Spring/Avalon, etc.
>
> Personally I suspect that a meta framework is more trouble than it's
> worth, although I haven't really looked at any too closely.  (Have
> any pointers)
>
> So then, with specific frameworks,  I don't understand how Pico's
> orientation towards constructors works in an environment where beans
> need to be dynamically instantiated, but perhaps I just haven't
> thought about it hard enough.  Avalon seems too heavy, which leaves
> us (or me at least) with Spring and HiveMind.  I haven't developed
> with either but so far the docs for Spring give me a warm fuzzy
> feeling while the HiveMind docs kind of scare me.

HiveMind, from what I've read, is more service-oriented.  I've been using
Spring for a few months now and totally loving it.  It completely stays
out of your way, leaving your code with little or no Spring dependencies.
Furthermore, it supports both javabean and constructor-style dependency
resolution.

> >- Use XML Schema over DTD's.  Give struts config its own default namespace
> >to make it easier for users to mix in elements of other namespaces.  An
> >example would be adding custom documentation attributes and elements.  Of
> >course the usual arguments for XML Schema over DTD's apply as well.
>
> XML Schema?!  Naw, RelaxNG!!!  After all, it is "now an international
> standard"
> (http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html)

Doesn't matter to me as long as I get namespace support :)

> >- Replace paths with URL's, allowing for a default protocol.  An action
> >path would look like "action://foo" or a tiles forward would be
> >"tiles://tilesdef"  This would make it easy to plug in handlers to support
> >different presentation engines.  If no protocol is specified, the path is
> >handled as usual.
>
> I'm a little sketched out about assigning schemes of our own.  I see
> the motivation, and think the goal is good.  Wonder if we could find
> another mechanism.

Well, I've seen it used particularly in Forrest to good effect.  The key
is keeping the number of "protocols" to a small number, but allowing the
user to develop more if they feel the need.

Don

>
> >- As Ted said, contine with the wildcard theme.  Struts should do
> >everything possible to cut down configuration.
>
> hear, hear! (, hear, hear, hear!!)
>
> >- Also, again totally agreeing with Ted, make everything interface based,
>
> a few more hears here ;^)
>
>
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
>   "We want beef in dessert if we can get it there."
>-- Betty Hogan, Director of New Product Development, National
> Cattlemen's Beef Association
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread BaTien Duong

Are we on something revolutionary here? I am looking forward to this.

BaTien
DBGROUPS
Don Brown wrote:

Is there one? I have several ideas I'd like to toss into the discussion.

Don

On 17 Dec 2003 [EMAIL PROTECTED] wrote:

husted 2003/12/17 12:49:28

Added: contrib/struts-jericho README.txt project.properties
project.xml
Log:
Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
Revision ChangesPath
1.1 jakarta-struts/contrib/struts-jericho/README.txt
Index: README.txt
===
Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x.
Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal until the Community comes to a consensus.

This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture. Jericho proposes to open-up Struts by

* Declaring interfaces for all core components.

* Providing working base implementations for all core components.

* Encapsulating alll path references within "Location" objects (fka ActionForwards)and referring only to Locations from all other objects.

* Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized.

* Providing "POJO" signatures that encapsulate HTTP classes so that applications can be freed of HTTP semantics, if so desired.

* Retain optional access to HTTP objects so that applications can be free to do whatever they need to do.

-Backward Compatibility-

Jericho is a revolution and backward compatability with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practible, so that Jericho is available to the widest community possible.

_DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.

A second alternative to explore is to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.

_Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to provided. These classes will provide the Struts 1.2.x behavior but also implement the Struts Jericho interfaces, so that the framework can use them interchangeably.

These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.

###

1.1 jakarta-struts/contrib/struts-jericho/project.properties

Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S
# ---
compile.debug = on
compile.optimize = off
compile.deprecation = off
maven.linkcheck.enable=true

# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html

1.1 jakarta-struts/contrib/struts-jericho/project.xml

Index: project.xml
===

../project.xml
Jericho
struts-jericho
0.1-dev
2003
Struts Jericho 2.x Whiteboard

Jericho is a whiteboard proposal describing one possible implementation of
Struts 2.x.
Since Struts 2.x is slated as a "revolution", the Apache practice is to assign
a codename to a proposal
until the Community comes to a consensus.
This proposal is called "Jericho" since it tries to tear-down the walls within
the Struts architecture.

Ted Husted
husted
[EMAIL PROTECTED]

**/*Test.java

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

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

RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Edgar P Dollin

> And you're really going to have to break both of my arms and/or kick me
> out of Struts development if you want ActionForm *ever* changed to an
> interface again -- in *any* future Struts release.  I think it's an
> absolutely horrible idea, for reasons that have been documented way too
> many times to count.

> Craig McClanahan



> >- Also, again totally agreeing with Ted, make everything interface 
> >based,

> a few more hears here ;^)

> Joe Germuska

The interface discussion has come up previously and there was some emotion
tied to it.

Edgar


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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Sgarlata Matt

- Original Message - 
From: "Joe Germuska" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, December 17, 2003 5:04 PM
Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

> So then, with specific frameworks,  I don't understand how Pico's
> orientation towards constructors works in an environment where beans
> need to be dynamically instantiated, but perhaps I just haven't
> thought about it hard enough.  Avalon seems too heavy, which leaves
> us (or me at least) with Spring and HiveMind.  I haven't developed
> with either but so far the docs for Spring give me a warm fuzzy
> feeling while the HiveMind docs kind of scare me.

I agree with your assessment of frameworks 100%.  However, Spring is under
an LGPL license, so Struts can't use Spring unless either Struts switches to
LGPL or Spring switches to ASF, right?  It would be kind of silly for Struts
to stay under ASF in this case, since the Spring license would force the
undesirable LGPL clauses on any projects that were based on Struts.  Am I
right?

Matt

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

Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

2003-12-17 Thread Joe Germuska

- Make Inversion of Control central. By using an IoC framework to wire
Struts together, it makes it really easy to extend or improve Struts not
only for future development but for users as well. I'd recommend Spring's
IoC impl as it is small (>100k), really easy to use, and easily
extendable. If we wanted to remain more "agnostic", there are "meta" IoC
frameworks that let you plug in Pico/Spring/Avalon, etc.
Personally I suspect that a meta framework is more trouble than it's
worth, although I haven't really looked at any too closely. (Have
any pointers)

So then, with specific frameworks, I don't understand how Pico's
orientation towards constructors works in an environment where beans
need to be dynamically instantiated, but perhaps I just haven't
thought about it hard enough. Avalon seems too heavy, which leaves
us (or me at least) with Spring and HiveMind. I haven't developed
with either but so far the docs for Spring give me a warm fuzzy
feeling while the HiveMind docs kind of scare me.

- Use XML Schema over DTD's. Give struts config its own default namespace
to make it easier for users to mix in elements of other namespaces. An
example would be adding custom documentation attributes and elements. Of
course the usual arguments for XML Schema over DTD's apply as well.
XML Schema?! Naw, RelaxNG!!! After all, it is "now an international
standard"
(http://blogs.codehaus.org/people/bob/archives/000505_standards_are_great_everyone_should_have_one.html)

- Replace paths with URL's, allowing for a default protocol. An action
path would look like "action://foo" or a tiles forward would be
"tiles://tilesdef" This would make it easy to plug in handlers to support
different presentation engines. If no protocol is specified, the path is
handled as usual.
I'm a little sketched out about assigning schemes of our own. I see
the motivation, and think the goal is good. Wonder if we could find
another mechanism.

- As Ted said, contine with the wildcard theme. Struts should do
everything possible to cut down configuration.
hear, hear! (, hear, hear, hear!!)

- Also, again totally agreeing with Ted, make everything interface based,
a few more hears here ;^)

--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association

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

Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)

Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x
release work. :)  I'll throw out some ideas here, then develop them later
in the wiki:

- Make Inversion of Control central.  By using an IoC framework to wire
Struts together, it makes it really easy to extend or improve Struts not
only for future development but for users as well.  I'd recommend Spring's
IoC impl as it is small (>100k), really easy to use, and easily
extendable.  If we wanted to remain more "agnostic", there are "meta" IoC
frameworks that let you plug in Pico/Spring/Avalon, etc.

- Use XML Schema over DTD's.  Give struts config its own default namespace
to make it easier for users to mix in elements of other namespaces.  An
example would be adding custom documentation attributes and elements.  Of
course the usual arguments for XML Schema over DTD's apply as well.

- Replace paths with URL's, allowing for a default protocol.  An action
path would look like "action://foo" or a tiles forward would be
"tiles://tilesdef"  This would make it easy to plug in handlers to support
different presentation engines.  If no protocol is specified, the path is
handled as usual.

- As Ted said, contine with the wildcard theme.  Struts should do
everything possible to cut down configuration.

- Also, again totally agreeing with Ted, make everything interface based,
have default implementations, and free apps of HTTP.  Ideally, I'd like to
see extra effort going into making it easy if not effortless to take a
Struts 2.0 app and use the code in a portlet or web service environment.
At least in my area, clients are wanting human and machine interfaces,
with the human interface generally being behind a portal.

Anyways, those are my "brainstorming" thoughts.  If any look interesting,
I'll write something up in the wiki.

Don


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

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread Martin Cooper

On Wed, 17 Dec 2003, Don Brown wrote:

> Is there one?  I have several ideas I'd like to toss into the discussion.

Yep. This is it.

--
Martin Cooper


>
> Don
>
> On 17 Dec 2003 [EMAIL PROTECTED] wrote:
>
> > husted  2003/12/17 12:49:28
> >
> >   Added:   contrib/struts-jericho README.txt project.properties
> > project.xml
> >   Log:
> >   Create whiteboard directory for Struts-Jericho, a working proposal for Struts 
> > 2.x.
> >
> >   Revision  ChangesPath
> >   1.1  jakarta-struts/contrib/struts-jericho/README.txt
> >
> >   Index: README.txt
> >   ===
> >   Jericho is a whiteboard proposal describing one possible implementation of 
> > Struts 2.x.
> >
> >   Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a 
> > codename to a proposal until the Community comes to a consensus.
> >
> >   This proposal is called "Jericho" since it tries to tear-down the walls within 
> > the Struts architecture. Jericho proposes to open-up Struts by
> >
> >   * Declaring interfaces for all core components.
> >
> >   * Providing working base implementations for all core components.
> >
> >   * Encapsulating alll path references within "Location" objects (fka 
> > ActionForwards)and referring only to Locations from all other objects.
> >
> >   * Providing additional extension points from core components so that the 
> > "Inversion of Control" pattern is fully realized.
> >
> >   * Providing "POJO" signatures that encapsulate HTTP classes so that applications 
> > can be freed of HTTP semantics, if so desired.
> >
> >   * Retain optional access to HTTP objects so that applications can be free to do 
> > whatever they need to do.
> >
> >   -Backward Compatibility-
> >
> >   Jericho is a revolution and backward compatability with prior versions of Struts 
> > is not the prime consideration. However, care is being taken to create a clear 
> > migration path, where practible, so that Jericho is available to the widest 
> > community possible.
> >
> >   _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the 
> > Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow 
> > a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
> >
> >   A second alternative to explore is to provide an alternate configuration loader 
> > that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
> >
> >   _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
> > provided. These classes will provide the Struts 1.2.x behavior but also implement 
> > the Struts Jericho interfaces, so that the framework can use them interchangeably.
> >
> >   These same techniques may be applied to provide adaptors for other frameworks, 
> > so as to make Struts Jericho available to the widest community possible.
> >
> >   ###
> >
> >
> >   1.1  jakarta-struts/contrib/struts-jericho/project.properties
> >
> >   Index: project.properties
> >   ===
> >   # ---
> >   # P R O J E C T  P R O P E R T I E S
> >   # ---
> >
> >   compile.debug = on
> >   compile.optimize = off
> >   compile.deprecation = off
> >
> >   maven.linkcheck.enable=true
> >
> >   # documentation properties
> >   maven.xdoc.date=left
> >   maven.xdoc.version=${pom.currentVersion}
> >   maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
> >
> >
> >
> >   1.1  jakarta-struts/contrib/struts-jericho/project.xml
> >
> >   Index: project.xml
> >   ===
> >   
> >
> >   
> > ../project.xml
> > Jericho
> > struts-jericho
> > 0.1-dev
> > 2003
> > Struts Jericho 2.x Whiteboard
> > 
> > Jericho is a whiteboard proposal describing one possible implementation of 
> > Struts 2.x.
> > Since Struts 2.x is slated as a "revolution", the Apache practice is to 
> > assign a codename to a proposal
> > until the Community comes to a consensus.
> > This proposal is called "Jericho" since it tries to tear-down the walls 
> > within the Struts architecture.
> > 
> > 
> >   
> > Ted Husted
> > husted
> > [EMAIL PROTECTED]
> > 
> >   
> > 
> >
> > 
> >   
> > 
> >   **/*Test.java
> > 
> >   
> > 
> >
> >   
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> -
> To unsubscribe, e-mail:

Re: Context attributes (was: Struts 2.0 Discussion Forum)

2003-12-17 Thread Hubert Rabago

What about allowing Action objects to add the parameters themselves?  It adds a
great deal of flexibility, and doesn't limit the set of parameters that can be
used, nor does it require using the request or session attributes.

ActionForward forward = mapping.findForward("lookup");
forward.addParameter("param1","value1");
forward.addParameter("param2",2);
forward.addParameter("param3",3.0);
return forward;

Or maybe support for both (merge and addParameter).
This will also make bug 866 go away.

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Don Brown wrote:
>  > Is there one?  I have several ideas I'd like to toss into the
>  > discussion.
>  >
>  > Don
> 
> There's a Whiteboard page in the Wiki.
> 
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard
> 
> I'll be posting more about Jericho, but wanted to get what I had so far 
> (a starter DTD) under CVS.
> 
> One other idea that I've been meaning to bring up in the wake of 
> wildcard Mappings, is the idea of merging context attributes into 
> ActionForward paths. For example, we could do something like
> 
> 
> 
> and have it replace {key} with request.getAttribute("key") (or session 
> if not found).
> 
> -Ted.
> 


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

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

Re: Struts 2.0 Discussion Forum

Don Brown wrote:
> Is there one?  I have several ideas I'd like to toss into the
> discussion.
>
> Don
There's a Whiteboard page in the Wiki.

http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsWhiteboard

I'll be posting more about Jericho, but wanted to get what I had so far 
(a starter DTD) under CVS.

One other idea that I've been meaning to bring up in the wake of 
wildcard Mappings, is the idea of merging context attributes into 
ActionForward paths. For example, we could do something like

and have it replace {key} with request.getAttribute("key") (or session 
if not found).

-Ted.

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

Re: Struts 2.0 Discussion Forum

2003-12-17 Thread James Mitchell

On Wed, 17 Dec 2003, Don Brown wrote:

> Is there one?  I have several ideas I'd like to toss into the discussion.

I'm +1 for keeping it here on the dev list. (if that's what you meant)



>
> Don
>
> On 17 Dec 2003 [EMAIL PROTECTED] wrote:
>
> > husted  2003/12/17 12:49:28
> >
> >   Added:   contrib/struts-jericho README.txt project.properties
> > project.xml
> >   Log:
> >   Create whiteboard directory for Struts-Jericho, a working proposal for Struts 
> > 2.x.
> >
> >   Revision  ChangesPath
> >   1.1  jakarta-struts/contrib/struts-jericho/README.txt
> >
> >   Index: README.txt
> >   ===
> >   Jericho is a whiteboard proposal describing one possible implementation of 
> > Struts 2.x.
> >
> >   Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a 
> > codename to a proposal until the Community comes to a consensus.
> >
> >   This proposal is called "Jericho" since it tries to tear-down the walls within 
> > the Struts architecture. Jericho proposes to open-up Struts by
> >
> >   * Declaring interfaces for all core components.
> >
> >   * Providing working base implementations for all core components.
> >
> >   * Encapsulating alll path references within "Location" objects (fka 
> > ActionForwards)and referring only to Locations from all other objects.
> >
> >   * Providing additional extension points from core components so that the 
> > "Inversion of Control" pattern is fully realized.
> >
> >   * Providing "POJO" signatures that encapsulate HTTP classes so that applications 
> > can be freed of HTTP semantics, if so desired.
> >
> >   * Retain optional access to HTTP objects so that applications can be free to do 
> > whatever they need to do.
> >
> >   -Backward Compatibility-
> >
> >   Jericho is a revolution and backward compatability with prior versions of Struts 
> > is not the prime consideration. However, care is being taken to create a clear 
> > migration path, where practible, so that Jericho is available to the widest 
> > community possible.
> >
> >   _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the 
> > Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow 
> > a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
> >
> >   A second alternative to explore is to provide an alternate configuration loader 
> > that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
> >
> >   _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
> > provided. These classes will provide the Struts 1.2.x behavior but also implement 
> > the Struts Jericho interfaces, so that the framework can use them interchangeably.
> >
> >   These same techniques may be applied to provide adaptors for other frameworks, 
> > so as to make Struts Jericho available to the widest community possible.
> >
> >   ###
> >
> >
> >   1.1  jakarta-struts/contrib/struts-jericho/project.properties
> >
> >   Index: project.properties
> >   ===
> >   # ---
> >   # P R O J E C T  P R O P E R T I E S
> >   # ---
> >
> >   compile.debug = on
> >   compile.optimize = off
> >   compile.deprecation = off
> >
> >   maven.linkcheck.enable=true
> >
> >   # documentation properties
> >   maven.xdoc.date=left
> >   maven.xdoc.version=${pom.currentVersion}
> >   maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
> >
> >
> >
> >   1.1  jakarta-struts/contrib/struts-jericho/project.xml
> >
> >   Index: project.xml
> >   ===
> >   
> >
> >   
> > ../project.xml
> > Jericho
> > struts-jericho
> > 0.1-dev
> > 2003
> > Struts Jericho 2.x Whiteboard
> > 
> > Jericho is a whiteboard proposal describing one possible implementation of 
> > Struts 2.x.
> > Since Struts 2.x is slated as a "revolution", the Apache practice is to 
> > assign a codename to a proposal
> > until the Community comes to a consensus.
> > This proposal is called "Jericho" since it tries to tear-down the walls 
> > within the Struts architecture.
> > 
> > 
> >   
> > Ted Husted
> > husted
> > [EMAIL PROTECTED]
> > 
> >   
> > 
> >
> > 
> >   
> > 
> >   **/*Test.java
> > 
> >   
> > 
> >
> >   
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --

Struts 2.0 Discussion Forum

Is there one?  I have several ideas I'd like to toss into the discussion.

Don

On 17 Dec 2003 [EMAIL PROTECTED] wrote:

> husted  2003/12/17 12:49:28
>
>   Added:   contrib/struts-jericho README.txt project.properties
> project.xml
>   Log:
>   Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
>
>   Revision  ChangesPath
>   1.1  jakarta-struts/contrib/struts-jericho/README.txt
>
>   Index: README.txt
>   ===
>   Jericho is a whiteboard proposal describing one possible implementation of Struts 
> 2.x.
>
>   Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a 
> codename to a proposal until the Community comes to a consensus.
>
>   This proposal is called "Jericho" since it tries to tear-down the walls within the 
> Struts architecture. Jericho proposes to open-up Struts by
>
>   * Declaring interfaces for all core components.
>
>   * Providing working base implementations for all core components.
>
>   * Encapsulating alll path references within "Location" objects (fka 
> ActionForwards)and referring only to Locations from all other objects.
>
>   * Providing additional extension points from core components so that the 
> "Inversion of Control" pattern is fully realized.
>
>   * Providing "POJO" signatures that encapsulate HTTP classes so that applications 
> can be freed of HTTP semantics, if so desired.
>
>   * Retain optional access to HTTP objects so that applications can be free to do 
> whatever they need to do.
>
>   -Backward Compatibility-
>
>   Jericho is a revolution and backward compatability with prior versions of Struts 
> is not the prime consideration. However, care is being taken to create a clear 
> migration path, where practible, so that Jericho is available to the widest 
> community possible.
>
>   _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the 
> Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow a 
> tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
>
>   A second alternative to explore is to provide an alternate configuration loader 
> that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
>
>   _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
> provided. These classes will provide the Struts 1.2.x behavior but also implement 
> the Struts Jericho interfaces, so that the framework can use them interchangeably.
>
>   These same techniques may be applied to provide adaptors for other frameworks, so 
> as to make Struts Jericho available to the widest community possible.
>
>   ###
>
>
>   1.1  jakarta-struts/contrib/struts-jericho/project.properties
>
>   Index: project.properties
>   ===
>   # ---
>   # P R O J E C T  P R O P E R T I E S
>   # ---
>
>   compile.debug = on
>   compile.optimize = off
>   compile.deprecation = off
>
>   maven.linkcheck.enable=true
>
>   # documentation properties
>   maven.xdoc.date=left
>   maven.xdoc.version=${pom.currentVersion}
>   maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
>
>
>
>   1.1  jakarta-struts/contrib/struts-jericho/project.xml
>
>   Index: project.xml
>   ===
>   
>
>   
> ../project.xml
> Jericho
> struts-jericho
> 0.1-dev
> 2003
> Struts Jericho 2.x Whiteboard
> 
> Jericho is a whiteboard proposal describing one possible implementation of 
> Struts 2.x.
> Since Struts 2.x is slated as a "revolution", the Apache practice is to 
> assign a codename to a proposal
> until the Community comes to a consensus.
> This proposal is called "Jericho" since it tries to tear-down the walls 
> within the Struts architecture.
> 
> 
>   
> Ted Husted
> husted
> [EMAIL PROTECTED]
> 
>   
> 
>
> 
>   
> 
>   **/*Test.java
> 
>   
> 
>
>   
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

cvs commit: jakarta-struts/contrib/struts-jericho/src/conf struts-jericho-config_2_0.dtd

husted  2003/12/17 12:50:35

  Added:   contrib/struts-jericho/src/conf
struts-jericho-config_2_0.dtd
  Log:
  Initial, working draft DTD for Struts-Jercho proposal. Still rough.
  
  Revision  ChangesPath
  1.1  
jakarta-struts/contrib/struts-jericho/src/conf/struts-jericho-config_2_0.dtd
  
  Index: struts-jericho-config_2_0.dtd
  ===
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

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

cvs commit: jakarta-struts/contrib/struts-jericho/src/conf - New directory

husted  2003/12/17 12:49:42

  jakarta-struts/contrib/struts-jericho/src/conf - New directory

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

cvs commit: jakarta-struts/contrib/struts-jericho/src - New directory

husted  2003/12/17 12:49:35

  jakarta-struts/contrib/struts-jericho/src - New directory

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

cvs commit: jakarta-struts/contrib/struts-jericho README.txt project.properties project.xml

husted  2003/12/17 12:49:28

  Added:   contrib/struts-jericho README.txt project.properties
project.xml
  Log:
  Create whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x.
  
  Revision  ChangesPath
  1.1  jakarta-struts/contrib/struts-jericho/README.txt
  
  Index: README.txt
  ===
  Jericho is a whiteboard proposal describing one possible implementation of Struts 
2.x.
  
  Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a 
codename to a proposal until the Community comes to a consensus.
  
  This proposal is called "Jericho" since it tries to tear-down the walls within the 
Struts architecture. Jericho proposes to open-up Struts by
  
  * Declaring interfaces for all core components.
  
  * Providing working base implementations for all core components.
  
  * Encapsulating alll path references within "Location" objects (fka 
ActionForwards)and referring only to Locations from all other objects.
  
  * Providing additional extension points from core components so that the "Inversion 
of Control" pattern is fully realized.
  
  * Providing "POJO" signatures that encapsulate HTTP classes so that applications can 
be freed of HTTP semantics, if so desired.
  
  * Retain optional access to HTTP objects so that applications can be free to do 
whatever they need to do.
  
  -Backward Compatibility-
  
  Jericho is a revolution and backward compatability with prior versions of Struts is 
not the prime consideration. However, care is being taken to create a clear migration 
path, where practible, so that Jericho is available to the widest community possible.
  
  _DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the Struts 
1.2 DTD. The elements are different but still similar. Our goal is to allow a tool, 
such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
  
  A second alternative to explore is to provide an alternate configuration loader that 
would map the Struts 1.2 elements to Struts Jericho objects at initialization.
  
  _Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to 
provided. These classes will provide the Struts 1.2.x behavior but also implement the 
Struts Jericho interfaces, so that the framework can use them interchangeably.
  
  These same techniques may be applied to provide adaptors for other frameworks, so as 
to make Struts Jericho available to the widest community possible.
  
  ###
  
  
  1.1  jakarta-struts/contrib/struts-jericho/project.properties
  
  Index: project.properties
  ===
  # ---
  # P R O J E C T  P R O P E R T I E S
  # ---
  
  compile.debug = on
  compile.optimize = off
  compile.deprecation = off
  
  maven.linkcheck.enable=true 
  
  # documentation properties
  maven.xdoc.date=left
  maven.xdoc.version=${pom.currentVersion}
  maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
  
  
  
  1.1  jakarta-struts/contrib/struts-jericho/project.xml
  
  Index: project.xml
  ===
  
  
  
../project.xml
Jericho
struts-jericho
0.1-dev
2003
Struts Jericho 2.x Whiteboard

Jericho is a whiteboard proposal describing one possible implementation of 
Struts 2.x.
Since Struts 2.x is slated as a "revolution", the Apache practice is to assign 
a codename to a proposal
until the Community comes to a consensus.
This proposal is called "Jericho" since it tries to tear-down the walls within 
the Struts architecture.


  
Ted Husted
husted
[EMAIL PROTECTED]

  

  

  

  **/*Test.java

  

  
  
  
  
  

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

cvs commit: jakarta-struts/contrib/struts-jericho - New directory