Planet Struts Calendar

[Martin Cooper]

Who manages this? I noticed that none of the Struts-related activities
at ApacheCon shows up on it. If anyone actually uses this calendar, we
(the royal "we", that is) should add these.

--
Martin Cooper

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

Re: [S2] Message Resources ExpressionConfigurationSupport

[Brian Pontarelli]

How will this handle key collisions in large projects? Or collisions 
with resources on the classpath that aren't easily modified?


-bp

Ted Husted wrote:

I'm looking at   which
would let us load message resources by designating a package with a
wildcard character, like this

 * webwork.custom.i18n.resources=ApplicationResources, actions/*

in which case all the ".properties"  files in the "actions" package
would be added to the configuration.

One aspect of this idea is that it might let us multiple resource
files, even when there is not a corresponding Action. The lack of an
Action came up in the extended CodeBehind thread, since we might have
a page that doesn't have it's own Action.

There are other features to the patch, like optional recursion support
(which might also play nice with CodeBehind).

My questions are

 * Does this sound like a good idea to everyone?

 * Is this a XWork level patch or something we should apply here?

 * If we apply it here, is it big enough for a CLA?

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

Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification

[Brian Pontarelli]

Okay. The example is in the SmartURLs repository:

http://smarturls-s2.googlecode.com/svn/trunk/apps/crud-example/

It works pretty well. A few things I think could help reduce the overall 
code bloat:


1. Support public fields instead of just getters/setters on actions. 
I've never actually done anything interesting in my action property 
accessors, so removing them in all my cases would be fine.


2. Fix the empty action requirements (the add action is empty for most 
of my apps)


3. If we add the redirect to index convention, 2 annotations will be removed

4. I could collapse add/save and edit/update using a post check like this:

   if (ServletActionContext.getRequest().getMethod().equals("GET")) {

   }

or I could write a variation on Action that is more knowledgable about 
GETs and POSTs and invokes two different methods depending on the method.


Everything (comments, thoughts, mods, etc) is welcome!

-bp


Brian Pontarelli wrote:
I didn't get very far with the example application. But I should be 
able to get that finished today. That application should illustrate 
exactly how I've been doing things lately. The situation you brought 
up is exactly the same one that we hit and I'm sure everyone else does 
eventually. We did about 5 different variations on it and finally 
settled on one approach we thought made the most sense.


To keep the discussion going, here's the overview:

Preparation is only do on the CRUD form using the action tag. This 
removes the hit of preparing if the submission is successful. This 
allows the application to GET add/edit and POST save/update while 
still preparing the form whenever is required since the form controls 
preparation rather than the actions.


I should have the application into the smart URLs repository pretty soon.

-bp

Ted Husted wrote:

The question would be how do we GET add or edit and invoke Prepare,
and then how do we POST to save, update, or delete, and invoke Prepare
if validation fails?

On Nov 2, 2007 3:30 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
 

I think my simple CRUD example will shed a lot of light on my methods,
but here's a rough run down:

Actions

Add - Empty
Edit - Fetch entity by id
Prepare - Prepares selects and other associations for the form
Save - Validates and inserts
Update - Validates and updates
Delete - Deletes entity or multiple entities
Index - Displays the list of entities

Views
--
add.jsp - Header block and includes form.jsp
edit.jsp - Header block and includes form.jsp
form.jsp - The form (uses the Prepare action)
index.jsp - The list page

The form has a cancel button that uses the "redirect-action:index"
syntax. The edit form also has a delete button that uses the action 
syntax.


The only place I use the input result is in the Save and Update classes
for results that go back to the add and edit JSPs. These two classes 
can

also be collapsed into a single class or use a parent class to reduce
overhead. Those two and delete are the only ones with annotations for
different results and redirects.



-
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: Messing around with parameters

[Brian Pontarelli]

Ted Husted wrote:

On Nov 1, 2007 4:10 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
  










Is the use case that these facts are embedded in the page, but not
known to the server-side system? So, since the Action doesn't already
"know" the format is "MM/dd/", it needs to be told?
  
That's correct. The input should dictate the format giving the client 
the ability to become more involved and dynamic.




True to some degree. You still have the issue that some of the
parameters don't map to properties of the JavaBean. If you did this:




You would need to specify that the currencyCode should be excluded,



If all this is going to be placed into a map of attributes anyway,
could we just have a map of attributes?

 
 
  
This is possible, but the same thing that I described and requires that 
you have the attributes Map defined on your action and that just by 
chance it gets populated prior to the Parameters interceptor attempting 
to set the value of subscription.expireDate. The key is that the 
Parameters interceptor need to be modified to do two things differently:


1. Load the attributes prior to setting the value so that the 
TypeConverter will have access to the attributes
2. Ignore the attributes since they aren't values that should be set 
into the Action


I'd like to use some specifier to denote that the attribute isn't a 
value that should be set onto the Action. I like the @ symbol but I'm 
open to others. This solution also benefits for convention with zero 
configuration by the way ;)



I don't know if this is the right syntax or not, or even if we have a
syntax for adding entries to a map property. If we don't, then I'm
thinking that we should solve that general use case, which should
address this specific use case.
  
I agree, but I think that the solution I have is general enough. It 
allows attributes to be specified as long as they have an @ sign. This 
will allow request global attributes:




and parameter local attributes:



These two formats should be capable of handling all cases of requiring 
attributes in the request that aren't set into the Action and are 
accessible via the ValueStack context.



-bp

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

Re: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))

[Ted Husted]

OK, that would be easy enough.

On Nov 5, 2007 12:29 PM, Chris Pratt <[EMAIL PROTECTED]> wrote:
> From what I've seen, the Spring model of creating a "modules"
> sub-directory off the "lib" directory, for all the extra's works
> pretty well.
>   (*Chris*)

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

Re: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))

[Chris Pratt]

On Nov 5, 2007 5:16 AM, Ted Husted <[EMAIL PROTECTED]> wrote:
> On Nov 4, 2007 10:26 PM, Chris Pratt <[EMAIL PROTECTED]> wrote:
> > On Nov 4, 2007 2:58 PM, Don Brown <[EMAIL PROTECTED]> wrote:
> >
> > > As for the problem of so many combinations of plugins, I'm all for the
> > > proliferation of plugins, but do think we need to not ship with two
> > > plugins that solve the same problem.
> >
> > I believe Struts already ships multiple plugins that solve the same
> > problem.  The View and the File Upload problems each have multiple
> > plugins.  I think the whole point is choice, and I don't see any
> > problem with shipping that choice as part of Struts.  Ted has also
> > championed a one-stop, "getting started" file that would contain a
> > single solution to each of the problems (with the exception of the
> > view), which I think takes care of the problem of confusing new users.
> >  But that's just one, non-committer's, opinion.
> >   (*Chris*)
>
>
> The tipping point for a  one-stop JAR might  be whether we break out
> the tags or not. (In my own applications, we've moved to pure Ajax
> front-ends, so the tags really are not an issue for me personally,
> except to the extent that I sometimes train other people to use them.)
>
> I feel that the underlying problem is that we've extended the notion
> of a "lib" folder to include a number of optional JARs, some of which
> overlap, and most of which have additional dependencies that we don't
> bundle. I don't have a problem with the overlap, but we should have a
> standard lib distribution that only includes the JARs that we expect
> that most everyone will need to write a basic application.
>
> My suggestion would be to create a second struts-extras-lib
> distribution that would include all the optional plugin artifacts that
> we maintain, and then reduce the standard struts-lib to just the JARs
> we need to setup a blank application (struts-core, freemarker, ognl,
> xwork, and commons-logging (just in case)).
>

>From what I've seen, the Spring model of creating a "modules"
sub-directory off the "lib" directory, for all the extra's works
pretty well.
  (*Chris*)

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

Re: [PROPOSAL] Merge Able/Code Behind/Zero-Config/SmartURLs into view-behind specification

[Brian Pontarelli]

I didn't get very far with the example application. But I should be able 
to get that finished today. That application should illustrate exactly 
how I've been doing things lately. The situation you brought up is 
exactly the same one that we hit and I'm sure everyone else does 
eventually. We did about 5 different variations on it and finally 
settled on one approach we thought made the most sense.


To keep the discussion going, here's the overview:

Preparation is only do on the CRUD form using the action tag. This 
removes the hit of preparing if the submission is successful. This 
allows the application to GET add/edit and POST save/update while still 
preparing the form whenever is required since the form controls 
preparation rather than the actions.


I should have the application into the smart URLs repository pretty soon.

-bp

Ted Husted wrote:

The question would be how do we GET add or edit and invoke Prepare,
and then how do we POST to save, update, or delete, and invoke Prepare
if validation fails?

On Nov 2, 2007 3:30 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
  

I think my simple CRUD example will shed a lot of light on my methods,
but here's a rough run down:

Actions

Add - Empty
Edit - Fetch entity by id
Prepare - Prepares selects and other associations for the form
Save - Validates and inserts
Update - Validates and updates
Delete - Deletes entity or multiple entities
Index - Displays the list of entities

Views
--
add.jsp - Header block and includes form.jsp
edit.jsp - Header block and includes form.jsp
form.jsp - The form (uses the Prepare action)
index.jsp - The list page

The form has a cancel button that uses the "redirect-action:index"
syntax. The edit form also has a delete button that uses the action syntax.

The only place I use the input result is in the Save and Update classes
for results that go back to the add and edit JSPs. These two classes can
also be collapsed into a single class or use a parent class to reduce
overhead. Those two and delete are the only ones with annotations for
different results and redirects.



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

[WW-2292] Validation annotations v. ActionSupport

[Dave Newton]

https://issues.apache.org/struts/browse/WW-2292

I'm assuming what's happening is that ActionSupport's
validation is enough to use field validator
annotations even if the action doesn't have an
explicit @Validation() annotation (or something else
that leads to the same result).

WW-2292 basically asks if a lack of @Validation()
should mean no validation based on annotations even if
the class extends ActionSupport.

Anyone?

Thanks,
Dave


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

Re: svn commit: r591942 - in /struts/struts2/trunk/apps/portlet: ./ src/main/java/org/apache/struts2/portlet/example/ src/main/resources/ src/main/resources/org/apache/struts2/portlet/example/ src/mai

[Ted Husted]

Maybe my local copy is whacked, but I'm still getting an error on the
StreamResultTest

Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.325 sec
Running org.apache.struts2.dispatcher.mapper.DefaultActionMapperTest
Tests run: 39, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.044 sec

Results :

Failed tests:
  testStreamResultDefault(org.apache.struts2.dispatcher.StreamResultTest)

Tests run: 619, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 37 seconds
[INFO] Finished at: Mon Nov 05 08:11:30 EST 2007
[INFO] Final Memory: 30M/62M
[INFO] 

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

[s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))

[Ted Husted]

On Nov 4, 2007 10:26 PM, Chris Pratt <[EMAIL PROTECTED]> wrote:
> On Nov 4, 2007 2:58 PM, Don Brown <[EMAIL PROTECTED]> wrote:
>
> > As for the problem of so many combinations of plugins, I'm all for the
> > proliferation of plugins, but do think we need to not ship with two
> > plugins that solve the same problem.
>
> I believe Struts already ships multiple plugins that solve the same
> problem.  The View and the File Upload problems each have multiple
> plugins.  I think the whole point is choice, and I don't see any
> problem with shipping that choice as part of Struts.  Ted has also
> championed a one-stop, "getting started" file that would contain a
> single solution to each of the problems (with the exception of the
> view), which I think takes care of the problem of confusing new users.
>  But that's just one, non-committer's, opinion.
>   (*Chris*)


The tipping point for a  one-stop JAR might  be whether we break out
the tags or not. (In my own applications, we've moved to pure Ajax
front-ends, so the tags really are not an issue for me personally,
except to the extent that I sometimes train other people to use them.)

I feel that the underlying problem is that we've extended the notion
of a "lib" folder to include a number of optional JARs, some of which
overlap, and most of which have additional dependencies that we don't
bundle. I don't have a problem with the overlap, but we should have a
standard lib distribution that only includes the JARs that we expect
that most everyone will need to write a basic application.

My suggestion would be to create a second struts-extras-lib
distribution that would include all the optional plugin artifacts that
we maintain, and then reduce the standard struts-lib to just the JARs
we need to setup a blank application (struts-core, freemarker, ognl,
xwork, and commons-logging (just in case)).

If we later decide to create a tags-plugin, then we can just add it to
the struts-lib distribution, instead of the struts-extras-lib.

-Ted.

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

Re: svn commit: r591942 - in /struts/struts2/trunk/apps/portlet: ./ src/main/java/org/apache/struts2/portlet/example/ src/main/resources/ src/main/resources/org/apache/struts2/portlet/example/ src/mai

[Don Brown]

Oh, and thanks for fixing it so quick :)

Don

On 11/5/07, Don Brown <[EMAIL PROTECTED]> wrote:
> The Bamboo messages to go [EMAIL PROTECTED], which you may not
> be on.  As for the port, just pick one, say 8887.
>
> Don
>
> On 11/5/07, Nils-Helge Garli Hegvik <[EMAIL PROTECTED]> wrote:
> > Indeed so it seemsI didn't get an email, that's weird... Anyway,
> > it seems that the port 8080 which  the integration test is running
> > under is taken...obviously (of course I had to pick one of the most
> > commonly used) Which port can I use?
> >
> > Nils-H
> >
> > On Nov 5, 2007 12:50 PM, Don Brown <[EMAIL PROTECTED]> wrote:
> > > Nils, you broke the build: 
> > > http://opensource.bamboo.atlassian.com/browse/STRUTS
> > >
> > > Don
> > >
> > > On 11/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > Author: nilsga
> > > > Date: Mon Nov  5 02:06:31 2007
> > > > New Revision: 591942
> > > >
> > > > URL: http://svn.apache.org/viewvc?rev=591942&view=rev
> > > > Log:
> > > > WW-2296 Added jetty-pluto embedded to the sample application. Also 
> > > > added some new samples and a new integration test.
> > > >
> > > > Added:
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/main/resources/org/apache/struts2/portlet/example/FormExample-formExamplePrg-validation.xml
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/jetty-pluto-web-default.xml
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleInputPrg.jsp
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleSubmitToSelfWithValidation.jsp
> > > > struts/struts2/trunk/apps/portlet/src/test/
> > > > struts/struts2/trunk/apps/portlet/src/test/java/
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/test/java/JettyPlutoLauncher.java
> > > > struts/struts2/trunk/apps/portlet/src/test/java/org/
> > > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/
> > > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/BasePortletTest.java
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
> > > > Modified:
> > > > struts/struts2/trunk/apps/portlet/   (props changed)
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/main/java/org/apache/struts2/portlet/example/FormExample.java
> > > > struts/struts2/trunk/apps/portlet/src/main/resources/struts-view.xml
> > > > 
> > > > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/index.jsp
> > > >
> > >
> > > -
> > > 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: svn commit: r591942 - in /struts/struts2/trunk/apps/portlet: ./ src/main/java/org/apache/struts2/portlet/example/ src/main/resources/ src/main/resources/org/apache/struts2/portlet/example/ src/mai

[Don Brown]

The Bamboo messages to go [EMAIL PROTECTED], which you may not
be on.  As for the port, just pick one, say 8887.

Don

On 11/5/07, Nils-Helge Garli Hegvik <[EMAIL PROTECTED]> wrote:
> Indeed so it seemsI didn't get an email, that's weird... Anyway,
> it seems that the port 8080 which  the integration test is running
> under is taken...obviously (of course I had to pick one of the most
> commonly used) Which port can I use?
>
> Nils-H
>
> On Nov 5, 2007 12:50 PM, Don Brown <[EMAIL PROTECTED]> wrote:
> > Nils, you broke the build: 
> > http://opensource.bamboo.atlassian.com/browse/STRUTS
> >
> > Don
> >
> > On 11/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Author: nilsga
> > > Date: Mon Nov  5 02:06:31 2007
> > > New Revision: 591942
> > >
> > > URL: http://svn.apache.org/viewvc?rev=591942&view=rev
> > > Log:
> > > WW-2296 Added jetty-pluto embedded to the sample application. Also added 
> > > some new samples and a new integration test.
> > >
> > > Added:
> > > 
> > > struts/struts2/trunk/apps/portlet/src/main/resources/org/apache/struts2/portlet/example/FormExample-formExamplePrg-validation.xml
> > > 
> > > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/jetty-pluto-web-default.xml
> > > 
> > > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleInputPrg.jsp
> > > 
> > > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleSubmitToSelfWithValidation.jsp
> > > struts/struts2/trunk/apps/portlet/src/test/
> > > struts/struts2/trunk/apps/portlet/src/test/java/
> > > 
> > > struts/struts2/trunk/apps/portlet/src/test/java/JettyPlutoLauncher.java
> > > struts/struts2/trunk/apps/portlet/src/test/java/org/
> > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/
> > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/
> > > 
> > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/
> > > 
> > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/
> > > 
> > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/BasePortletTest.java
> > > 
> > > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
> > > Modified:
> > > struts/struts2/trunk/apps/portlet/   (props changed)
> > > 
> > > struts/struts2/trunk/apps/portlet/src/main/java/org/apache/struts2/portlet/example/FormExample.java
> > > struts/struts2/trunk/apps/portlet/src/main/resources/struts-view.xml
> > > 
> > > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/index.jsp
> > >
> >
> > -
> > 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: svn commit: r591942 - in /struts/struts2/trunk/apps/portlet: ./ src/main/java/org/apache/struts2/portlet/example/ src/main/resources/ src/main/resources/org/apache/struts2/portlet/example/ src/mai

[Nils-Helge Garli Hegvik]

Indeed so it seemsI didn't get an email, that's weird... Anyway,
it seems that the port 8080 which  the integration test is running
under is taken...obviously (of course I had to pick one of the most
commonly used) Which port can I use?

Nils-H

On Nov 5, 2007 12:50 PM, Don Brown <[EMAIL PROTECTED]> wrote:
> Nils, you broke the build: 
> http://opensource.bamboo.atlassian.com/browse/STRUTS
>
> Don
>
> On 11/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: nilsga
> > Date: Mon Nov  5 02:06:31 2007
> > New Revision: 591942
> >
> > URL: http://svn.apache.org/viewvc?rev=591942&view=rev
> > Log:
> > WW-2296 Added jetty-pluto embedded to the sample application. Also added 
> > some new samples and a new integration test.
> >
> > Added:
> > 
> > struts/struts2/trunk/apps/portlet/src/main/resources/org/apache/struts2/portlet/example/FormExample-formExamplePrg-validation.xml
> > 
> > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/jetty-pluto-web-default.xml
> > 
> > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleInputPrg.jsp
> > 
> > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleSubmitToSelfWithValidation.jsp
> > struts/struts2/trunk/apps/portlet/src/test/
> > struts/struts2/trunk/apps/portlet/src/test/java/
> > struts/struts2/trunk/apps/portlet/src/test/java/JettyPlutoLauncher.java
> > struts/struts2/trunk/apps/portlet/src/test/java/org/
> > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/
> > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/
> > 
> > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/
> > 
> > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/
> > 
> > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/BasePortletTest.java
> > 
> > struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
> > Modified:
> > struts/struts2/trunk/apps/portlet/   (props changed)
> > 
> > struts/struts2/trunk/apps/portlet/src/main/java/org/apache/struts2/portlet/example/FormExample.java
> > struts/struts2/trunk/apps/portlet/src/main/resources/struts-view.xml
> > struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/index.jsp
> >
>
> -
> 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: svn commit: r591942 - in /struts/struts2/trunk/apps/portlet: ./ src/main/java/org/apache/struts2/portlet/example/ src/main/resources/ src/main/resources/org/apache/struts2/portlet/example/ src/mai

[Don Brown]

Nils, you broke the build: http://opensource.bamboo.atlassian.com/browse/STRUTS

Don

On 11/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: nilsga
> Date: Mon Nov  5 02:06:31 2007
> New Revision: 591942
>
> URL: http://svn.apache.org/viewvc?rev=591942&view=rev
> Log:
> WW-2296 Added jetty-pluto embedded to the sample application. Also added some 
> new samples and a new integration test.
>
> Added:
> 
> struts/struts2/trunk/apps/portlet/src/main/resources/org/apache/struts2/portlet/example/FormExample-formExamplePrg-validation.xml
> 
> struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/jetty-pluto-web-default.xml
> 
> struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleInputPrg.jsp
> 
> struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/formExampleSubmitToSelfWithValidation.jsp
> struts/struts2/trunk/apps/portlet/src/test/
> struts/struts2/trunk/apps/portlet/src/test/java/
> struts/struts2/trunk/apps/portlet/src/test/java/JettyPlutoLauncher.java
> struts/struts2/trunk/apps/portlet/src/test/java/org/
> struts/struts2/trunk/apps/portlet/src/test/java/org/apache/
> struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/
> 
> struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/
> 
> struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/
> 
> struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/BasePortletTest.java
> 
> struts/struts2/trunk/apps/portlet/src/test/java/org/apache/struts2/portlet/test/Struts2PortletTest.java
> Modified:
> struts/struts2/trunk/apps/portlet/   (props changed)
> 
> struts/struts2/trunk/apps/portlet/src/main/java/org/apache/struts2/portlet/example/FormExample.java
> struts/struts2/trunk/apps/portlet/src/main/resources/struts-view.xml
> struts/struts2/trunk/apps/portlet/src/main/webapp/WEB-INF/view/index.jsp
>

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