date:20060421

On 4/21/06, Phil Zoio [EMAIL PROTECTED] wrote:
 While mandating support for Java 5 is obviously no
 option for Struts 1.x,

It's probably still too soon to do that for Action 1.3, but it would
certainly be on the table for Action 1.4 or Action 1.5.

We changed the platform from Java 1.2 to Java 1.3 between 1.2 and 1.3,
and we could do that again, without incrementing the major version
number.

The path the follow here would be to:

* See if a community of developers grows around Strecks and Java 5.
* If so, consider whether Strecks should be a standard add-in, as we
did for the EL taglib
* For the Action 1.4 or 1.5 series, consider whether it is time to
increment the platform so that something like Strecks could be part of
the core.

-Ted.

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

Standalone Tiles as TLP

Lately, we've gotten into the habit of talking about Standalone Tiles
as if it were already an Apache Struts subproject. As far as I
remember, there has never been a vote to that effect, and the only
proposal on the wiki positions Tiles as a top-level project, once it
is ready to stand on its own.

* http://wiki.apache.org/struts/TilesTopLevel

IMHO, once Standalone Tiles is ready for a release, we should migrate
the component to a top-level ASF project. When we started this
process, the original intent was to decompose Tiles here, test it in 
Action and Shale, and then move it out when it was ready to stand on
its own.

If anything will make Apache Struts an umbrella, it would be keeping
Tiles here, rather than proposing it as a top-level project.
Standalone Tiles is *not* an application framework. Tiles is a
*component that can be used by any web application, just like
Validator and BeanUtils and everything else we extracted into
standalone versions.

Of course, another alternative would be to propose Tiles as Commons
component or Jakarta subproject. Albeit, I feel that Tiles falls
somewhere between a component and a framework, and that Tiles is rich
enough to warrant its own top-level project.

Thoughts?

-Ted.

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

[Struts Wiki] Update of Shale/JsfResources by AndrewKuzmin

2006-04-21 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Struts Wiki for change 
notification.

The following page has been changed by AndrewKuzmin:
http://wiki.apache.org/struts/Shale/JsfResources

--
 * [http://myfaces.apache.org MyFaces Project] - JSF implementation, 
components, mailing lists, and more
 * [http://www.jamesholmes.com/JavaServerFaces James Holmes' JSF Resources] 
- Extensive listing of articles, components, FAQs, presentations, tutorials, 
etc.
 * [http://jsfcentral.com JSFCentral.com] - Huge catalog of articles, FAQs, 
tutorials, samples
+* [http://www.java201.com/resources/browse/72-all.html JSF Related 
Resources] - Collection of links about JSF resources. Includes articles, books, 
presentations, tutorials and more.
  

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

Re: Standalone Tiles as TLP

2006-04-21 Thread Sean Schofield

So you are suggesting Tiles be decoupled from Struts Action and Shale
so that it can be compiled independent of these modules?  Definite +1
and this was my impression all along as well.

As for top level project, I agree that Tiles probably belongs here but
I'm not opposed.  For me the main thing is that Tiles should be
decoupled from the Action framework.  MyFaces Tomahawk currently
requires the full struts jar in order to provide Tiles support.

Sean

On 4/21/06, Ted Husted [EMAIL PROTECTED] wrote:
 Lately, we've gotten into the habit of talking about Standalone Tiles
 as if it were already an Apache Struts subproject. As far as I
 remember, there has never been a vote to that effect, and the only
 proposal on the wiki positions Tiles as a top-level project, once it
 is ready to stand on its own.

 * http://wiki.apache.org/struts/TilesTopLevel

 IMHO, once Standalone Tiles is ready for a release, we should migrate
 the component to a top-level ASF project. When we started this
 process, the original intent was to decompose Tiles here, test it in
 Action and Shale, and then move it out when it was ready to stand on
 its own.

 If anything will make Apache Struts an umbrella, it would be keeping
 Tiles here, rather than proposing it as a top-level project.
 Standalone Tiles is *not* an application framework. Tiles is a
 *component that can be used by any web application, just like
 Validator and BeanUtils and everything else we extracted into
 standalone versions.

 Of course, another alternative would be to propose Tiles as Commons
 component or Jakarta subproject. Albeit, I feel that Tiles falls
 somewhere between a component and a framework, and that Tiles is rich
 enough to warrant its own top-level project.

 Thoughts?

 -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: Standalone Tiles as TLP

2006-04-21 Thread Greg Reddin



On Apr 21, 2006, at 8:41 AM, Sean Schofield wrote:


As for top level project, I agree that Tiles probably belongs here but
I'm not opposed.  For me the main thing is that Tiles should be
decoupled from the Action framework.  MyFaces Tomahawk currently
requires the full struts jar in order to provide Tiles support.


That's only because Tomahawk is using Struts Tiles instead of  
Standalone Tiles, right?


Greg


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

RE: Standalone Tiles as TLP

2006-04-21 Thread Matthias Wessendorf

 That's only because Tomahawk is using Struts Tiles instead of 
 Standalone Tiles, right?

right,

Shale's TilesViewHandler.java requires the following clazzes of
tile-core.jar

snip
import org.apache.tiles.ComponentContext;
import org.apache.tiles.ComponentDefinition;
import org.apache.tiles.DefinitionsFactoryException;
import org.apache.tiles.NoSuchDefinitionException;
import org.apache.tiles.TilesUtil;
/snip


-Matthias



 Greg
 
 
 -
 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: Standalone Tiles as TLP

2006-04-21 Thread Matthias Wessendorf

think so too,that there is no public tiles-core.jar on any m2 repo,
IMO

-Matthias 

 -Original Message-
 From: Sean Schofield [mailto:[EMAIL PROTECTED] 
 Sent: Friday, April 21, 2006 4:20 PM
 To: Struts Developers List
 Subject: Re: Standalone Tiles as TLP

 Right but there hasn't been a release of stand alone tiles 
 yet has there?  If there are maven jars for standalone then 
 we'll switch now.

 Sean

 On 4/21/06, Greg Reddin [EMAIL PROTECTED] wrote:

  On Apr 21, 2006, at 8:41 AM, Sean Schofield wrote:

   As for top level project, I agree that Tiles probably 
 belongs here 
   but I'm not opposed.  For me the main thing is that Tiles 
 should be 
   decoupled from the Action framework.  MyFaces Tomahawk currently 
   requires the full struts jar in order to provide Tiles support.

  That's only because Tomahawk is using Struts Tiles instead of 
  Standalone Tiles, right?

  Greg

 -
  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: Standalone Tiles as TLP

2006-04-21 Thread Greg Reddin



On Apr 21, 2006, at 7:56 AM, Ted Husted wrote:


IMHO, once Standalone Tiles is ready for a release, we should migrate
the component to a top-level ASF project. When we started this
process, the original intent was to decompose Tiles here, test it in
Action and Shale, and then move it out when it was ready to stand on
its own.



I agree with your points about Tiles not being an application  
framework, etc.  My only concern about making it a TLP is developer  
support.  Granted, this could be an issue no matter where Tiles  
lives.  But there are not throngs of people jumping in to help with  
the refactoring efforts.  I wonder if there are enough people  
interested in developing Tiles to support its own TLP.


Greg


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

Re: [action2] Confluence migration


+1 You guys are the experts, go for it.

--
James Mitchell




On Apr 20, 2006, at 5:11 PM, Don Brown wrote:

The confluence migration is one of the remaining issues before  
Incubator graduation, and here is the plan:


 1. Export the data from OpenSymphony
 2. Lock the OS WW wiki down to only the dev team for minor changes
 3. Stand up a confluence instance, probably on my personal server,  
with the exported data

 4. Migrate the content over to the new Struts Action 2 name
 5. Export the data and import into a new ASF confluence instance  
when it is available


Patrick and I plan to start the plan this weekend.

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: Bugzilla to JIRA migration


+1

--
James Mitchell




On Apr 20, 2006, at 6:22 PM, Don Brown wrote:

With our JIRA instance stood up, it is time to revisit our earlier  
decision to migration our Struts Bugzilla tickets to JIRA.


http://issues.apache.org/struts

I believe most of this work can be done without bothering  
infrastructure, as the import can be done through JIRA's web admin  
interface.  Most of the committers don't have accounts, so please  
create one and let me know so I can give you the proper access.


I propose we do the migration this weekend.  Any comments/objections?

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: [shale] Maven 2 build (was Re: [action1] Which webapp dtds to include in struts-core.jar?)

Copying from a separate threadcause I thought I had deleted this  
thread -- doh!



After thinking about this a little more, would it make sense to test  
this under our svn so that the commit msgs are sent as usual and we  
can keep an eye things.  The term 'subversion shelves' comes to mind  
[0].


I remember as Wendy (and others?) were working on the one over in the  
test repository, there was no way to know (other than updating from  
svn) what was changing.  A simple mail filter will eliminate the  
commit msgs if people consider it spam.


Your thoughts?


[0] http://blogs.vertigosoftware.com/teamsystem/archive/2006/01/18/ 
Shelving_and_Branching.aspx



--
James Mitchell




On Apr 20, 2006, at 10:58 AM, James Mitchell wrote:

We should probably do this over in a test repository and make sure  
it will do what we want.  Similar to what was done for MyFaces and  
Action1.


Your thoughts?

--
James Mitchell




On Apr 19, 2006, at 10:35 PM, Sean Schofield wrote:


I'd love to see Shale move to M2.  I'll try to help with the limited
Maven knowledge that I have gleaned from the MyFaces experience.  I'd
recommend starting out with a proposed hierarchy and set of  
artifiacts

as a starting point.  See if we can get the basics squared away first
before sweating the javadocs.

Sean

On 4/15/06, Craig McClanahan [EMAIL PROTECTED] wrote:

On 4/15/06, Brett Porter [EMAIL PROTECTED] wrote:


are the apis with the other javadoc going to be in a separate  
module?
This should make it easy to produce javadoc from there, and then  
go on

to produce the aggregated javadoc for the others.



Ideally not.  It's already going to be painful to split up the  
core-library
package (which now produces several JAR files) into separate  
modules solely

because Maven likes one artifact per module.

Shale publishes information on API stability (
http://struts.apache.org/struts-shale/api-stability.html) that  
also includes

a column describing who should be using the APIs in each package ...
application developers or those wanting to extend the framework.   
That is
the basis on which I would want to split the javadocs, but they  
would also
be based on combining back together all the application-related  
APIs and all

the framework-related APIs back together again.

- Brett


Craig


On 4/16/06, Wendy Smoak [EMAIL PROTECTED] wrote:

On 4/15/06, James Mitchell [EMAIL PROTECTED] wrote:

Craig wrote
I'll want to experiment with ways to get combined javadocs  
out of

these artifacts (although probably two sets ...


Can we do this with custom assemblies?


Without trying it, I don't think so, because it's more than just
copying files around.  The Javadoc tool needs to create the  
frames and

indexes so that everything is linked together.

I think it will need two reportSets, so the Javadoc plugin runs
twice with different configuration.  Maybe something like this,  
which

runs both the regular Javadoc doclet and the UMLGraph one:
   http://wiki.wsmoak.net/cgi-bin/wiki.pl?UMLGraph

And here's a link to some work that I did last year, which  
includes
pom.xml files and a script to rearrange Shale into Maven 2's  
preferred
structure.  I stopped in late November, so it doesn't include  
Shale

Tiger or anything after that.
   http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleMaven2#build

--
Wendy

-- 
---

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




--- 
--

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







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




-
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: Building Faces with Maven 2

Ok, I'm a dumbass.  That was supposed to say [shale], not 'Faces'.   
Regardless, I've moved my comments back over to the thread that it  
was supposed to apply to.  I either need more sleep or more  
coffeeI'm no good in dead mans land :)




--
James Mitchell




On Apr 20, 2006, at 2:41 PM, James Mitchell wrote:

After thinking about this a little more, would it make sense to  
test this under our svn so that the commit msgs are sent as usual  
and we can keep an eye things.  The term 'subversion shelves' comes  
to mind [0].


I remember as Wendy (and others?) were working on the one over in  
the test repository, there was no way to know (other than updating  
from svn) what was changing.  A simple mail filter will eliminate  
the commit msgs if people consider it spam.


Your thoughts?


[0] http://blogs.vertigosoftware.com/teamsystem/archive/2006/01/18/ 
Shelving_and_Branching.aspx



--
James Mitchell





-
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: Standalone Tiles as TLP

2006-04-21 Thread Nathan Bubna

On 4/21/06, Ted Husted [EMAIL PROTECTED] wrote:
 Lately, we've gotten into the habit of talking about Standalone Tiles
 as if it were already an Apache Struts subproject. As far as I
 remember, there has never been a vote to that effect, and the only
 proposal on the wiki positions Tiles as a top-level project, once it
 is ready to stand on its own.

 * http://wiki.apache.org/struts/TilesTopLevel

 IMHO, once Standalone Tiles is ready for a release, we should migrate
 the component to a top-level ASF project. When we started this
 process, the original intent was to decompose Tiles here, test it in
 Action and Shale, and then move it out when it was ready to stand on
 its own.

 If anything will make Apache Struts an umbrella, it would be keeping
 Tiles here, rather than proposing it as a top-level project.
 Standalone Tiles is *not* an application framework. Tiles is a
 *component that can be used by any web application, just like
 Validator and BeanUtils and everything else we extracted into
 standalone versions.

 Of course, another alternative would be to propose Tiles as Commons
 component or Jakarta subproject. Albeit, I feel that Tiles falls
 somewhere between a component and a framework, and that Tiles is rich
 enough to warrant its own top-level project.

 Thoughts?

Do we need to be discussing this now?  I kinda feel like this should
wait until Tiles is ready to stand alone.

If there is sufficient interest/support from developers, then i don't
see any problem with having Tiles be a top level project.  But to be
honest, i don't think we have that at this, or if we do, then it is a
surprise to me.  And i'll point the finger at myself on that one too. 
The time i have available for open source work is very limited lately
and Velocity is my priority there.  I'd like to jump in and help with
Tiles, but the time isn't there.

Right now, it is easier for me to envision Tiles staying on as a
Struts subproject.   As for jumping over to Jakarta, that wouldn't
bother me, but i'm not sure i understand why.  Just because it's not a
full framework on the level of Struts 1.x, Shale, and SAF 2?  That's
not a reason that motivates me a lot.

 -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: svn commit: r395664 - in /struts: STATUS.txt action/trunk/build/STATUS.txt

The best place would be at the base of a nomal checkout, so that it
would be next to the nightly.sh, but I didn't know how to do that.

On 4/21/06, James Mitchell [EMAIL PROTECTED] wrote:
 Not sure if you say this...

 Should this be under 'current', so it will be at the base of the
 normal checkout?

 --
 James Mitchell

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

Re: Standalone Tiles as TLP

On 4/21/06, Nathan Bubna [EMAIL PROTECTED] wrote:
 Do we need to be discussing this now?  I kinda feel like this should
 wait until Tiles is ready to stand alone.

In another thread, Don pointed out that we need to be more forthcoming
with the project's roadmap. Right now, the Tiles roadmap is not clear
to me. I thought our intention was to propose it as a subproject, but
people have gradually come to speak of it as a Struts subproject.

 If there is sufficient interest/support from developers, then i don't
 see any problem with having Tiles be a top level project.  But to be
 honest, i don't think we have that at this, or if we do, then it is a
 surprise to me.  And i'll point the finger at myself on that one too.
 The time i have available for open source work is very limited lately
 and Velocity is my priority there.  I'd like to jump in and help with
 Tiles, but the time isn't there.

We need the same level of support for Tiles regardless of whether it
is TLP or a subproject. If Tiles has become a one-developer show, then
we have deeper problems that we need to fix now.

 Right now, it is easier for me to envision Tiles staying on as a
 Struts subproject.   As for jumping over to Jakarta, that wouldn't
 bother me, but i'm not sure i understand why.  Just because it's not a
 full framework on the level of Struts 1.x, Shale, and SAF 2?  That's
 not a reason that motivates me a lot.

Shale does for JSF what Action does for JSP, and I believe it make
sense to develop it here. Eventually, we may find a way to merge
Action and Shale back together again, but for now, no one has figured
out a way to do that. But, we may yet.

Standalone Tiles is not dependant on either Shale or Action. Tiles is
a component that they both *can* use, the same way they both use
BeanUtils. When we extracted all the other components, we gave them
lives of their own in the Commons. We should pay Tiles the same
courtesy.

-Ted.

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

Re: svn commit: r395664 - in /struts: STATUS.txt action/trunk/build/STATUS.txt


That's part of the magic that I love about svn...

$svn mv https://svn.apache.org/repos/asf/struts/STATUS.txt https:// 
svn.apache.org/repos/asf/struts/current/



--
James Mitchell




On Apr 21, 2006, at 11:52 AM, Ted Husted wrote:


The best place would be at the base of a nomal checkout, so that it
would be next to the nightly.sh, but I didn't know how to do that.

On 4/21/06, James Mitchell [EMAIL PROTECTED] wrote:

Not sure if you say this...

Should this be under 'current', so it will be at the base of the
normal checkout?

--
James Mitchell


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




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

svn commit: r395947 - in /struts: STATUS.txt current/STATUS.txt

2006-04-21 Thread husted

Author: husted
Date: Fri Apr 21 09:56:18 2006
New Revision: 395947

URL: http://svn.apache.org/viewcvs?rev=395947view=rev
Log:
Move STATUS under current

Added:
struts/current/STATUS.txt
  - copied unchanged from r395946, struts/STATUS.txt
Removed:
struts/STATUS.txt


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

I'm with Ted on this - Tiles really should be standalone and out on its own, lest Struts just be an umbrella project.
It is the odd man out next to Shale and Action, and would benefit from a wider audience. Either Tiles as a TLP, Jakarta
project or Jakarta Commons would fit to me. The lack of developer support is worrisome, though, regardless what we do
with it.

Don

Ted Husted wrote:

On 4/21/06, Nathan Bubna [EMAIL PROTECTED] wrote:

Do we need to be discussing this now? I kinda feel like this should
wait until Tiles is ready to stand alone.

In another thread, Don pointed out that we need to be more forthcoming
with the project's roadmap. Right now, the Tiles roadmap is not clear
to me. I thought our intention was to propose it as a subproject, but
people have gradually come to speak of it as a Struts subproject.

If there is sufficient interest/support from developers, then i don't
see any problem with having Tiles be a top level project. But to be
honest, i don't think we have that at this, or if we do, then it is a
surprise to me. And i'll point the finger at myself on that one too.
The time i have available for open source work is very limited lately
and Velocity is my priority there. I'd like to jump in and help with
Tiles, but the time isn't there.

We need the same level of support for Tiles regardless of whether it
is TLP or a subproject. If Tiles has become a one-developer show, then
we have deeper problems that we need to fix now.

Right now, it is easier for me to envision Tiles staying on as a
Struts subproject. As for jumping over to Jakarta, that wouldn't
bother me, but i'm not sure i understand why. Just because it's not a
full framework on the level of Struts 1.x, Shale, and SAF 2? That's
not a reason that motivates me a lot.

Shale does for JSF what Action does for JSP, and I believe it make
sense to develop it here. Eventually, we may find a way to merge
Action and Shale back together again, but for now, no one has figured
out a way to do that. But, we may yet.

Standalone Tiles is not dependant on either Shale or Action. Tiles is
a component that they both *can* use, the same way they both use
BeanUtils. When we extracted all the other components, we gave them
lives of their own in the Commons. We should pay Tiles the same
courtesy.

-Ted.

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

[Struts Wiki] Update of RoughSpots by Bob Lee

2006-04-21 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Struts Wiki for change 
notification.

The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots

The comment on the change is:
Posting comments on behalf of Hani.

--
  * [plightbo] As Gabe said, we already discussed this. And the last post 
on the subject was that we should do it. We still should.
  * [Gabe] I've created an XWork JIRA for a solution to the same use case 
here. [http://jira.opensymphony.com/browse/XW-387] I'd be happy to contribute 
the code.
  
+   1. Allow paths in action names. For example `action 
name=reports/myreport`.
+ 
+   1. Enable Java package import in configuration so you don't have to repeat 
the same package name over and over (like WW1 does).
+ 
+   1. The ajax support is pitiful. Have a look at how stripes does it. Ajax 
for validation is trivial and not that impressive, but people are going to want 
to do real ajax work, and webwork does absolutely nothing to help in that 
regard. I'd like to for example be able to easily invoke actions and get at 
some kind of result to display, and have webwork provide at least some of the 
wiring
+ 
+   1. The default theme for the ui tags should be simple. The current stuff is 
too dumb to get right on the first go, which gives an awful impression. It's 
NOT intuitive to write: {{{
+ table
+ ww:textfield label=Enter blah /
+ /table
+ }}}
+ 
+   1. File upload should support progress notification. Have a look at 
webwork-multipart on java.net, it's based on the pell parser but has a progress 
API.
+ 
+   1. Better error checking for UI tags. The freemarker error message, while 
great for freemarker users, look like gibberish. People should not be forced to 
learn freemarker. So in such cases, the tags themselves should check the 
parameters and report back sane messages, even if that check is duplicated in 
the templates
+ 
+   1. Defaults should be JSP all the way. People know it and like it, despite 
all the limitations. Allow for other view technologies, but don't force people 
to learn stuff they don't want to. Learning ww is enough of a pain as it is
+ 
+   1. Get rid of the validation framework. it's stupid and pointless, validate 
methods are good enough.
+ 
+   1. Ditch xwork as a separate project, nobody uses it or cares about it
+ 
+   1. Add java5 support to ognl. It's silly that it still doesn't handle enums 
(that I know of).
+ 
+   1. Clean up documentation. Focus on quality not quantity.
+ 
  == Patrick's issues ==
  
  My concerns aren't as detailed as Bob's, but I would like to see these 
general themes promoted by the framework:
@@ -160, +186 @@

1. Address the confusing issue of the validation/workflow lifecycle and 
different methods (this is mentioned in more detail above, but it is something 
that is problematic). Right now we sort of hack it by making the input method 
a special case in webwork-default.xml.
   * [jcarreira] +1 : Carlos at G**gle had some good ideas for this... 
basically stuff like if your action method is foo() then you'd have 
prepareFoo() and validateFoo(), but then I added that the prepare() and 
validate() methods should be the defaults that we call for all action methods.
   * [crazybob] Interesting idea. Might be overkill (i.e. at that point, 
the user should probably create another action class).
+  * [hani] No magic method names. If you want to do that, use annotations 
so you have a good chance of IDE support dealing with it. For example 
@Validate/@Prepare etc, with parameters to indicate what request you'd like it 
involved for, in the case where you need multiples of them
1. Don't encourage lots of interceptor stacks. Ideally the normal user 
should never need to deal with them. It is better to have a larger stack that 
has optional features that could be turned on through annotations or marker 
interfaces than to encourage users to build their own stacks.
  
   * [jcarreira] I think we should have some pre-defined ones for standard 
things: view vs. CRUD vs. action - do somthing that's not CRUD. We should 
then use annotations to make it where you can declaratively associate a 
particular action method with a stereotype which is mapped to an interceptor 
stack, etc.

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

Re: Standalone Tiles as TLP

2006-04-21 Thread Gary VanMatre

From: Greg Reddin [EMAIL PROTECTED] 

 
 On Apr 21, 2006, at 12:03 PM, Don Brown wrote: 
 
  The lack of developer support is worrisome, though, regardless what 
  we do with it. 
 
 I think there's a lot of impression that Tiles is done. From what 
 I can tell it pretty much fulfills 80% of the use cases and there are 
 workarounds for others. Most of the innovations I can think of 
 overlap with the portlet or JSF spaces enough that I'm not sure if 
 they are worth doing. When we started refactoring it I questioned 
 whether it was really a worthwhile effort or if it would have a 
 limited lifespan. I still question that at every step along the 
 way :-) Should we just make the bare minimum changes to get Tiles 
 out of the sandbox or is it worth it to do major surgery? 
 

+1

 There are a few other technologies I want to spend time looking at 
 once we get a release of Tiles. I'd like to see how it compares to 
 Facelets, Clay, and Sitemesh, as well as how much relevance Tiles has 
 in a portlet environment. Those things may help to determine the 
 future of Tiles. 
 

In the JSF front, Tiles provides JSP composition.  Facelets and Clay provide
page composition from templates but not JSP template fragments.  Clay can
be used in a JSP page but cannot include a JSP fragment in it's composition.


 Those are just my thoughts. 
 Greg 

Gary

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

Re: Standalone Tiles as TLP

2006-04-21 Thread Sean Schofield

 Should we just make the bare minimum changes to get Tiles
 out of the sandbox or is it worth it to do major surgery?

+1

Tiles is pretty mature and I don't sense a lot of interest in
perfecting it.  It would be nice to have it stand on its own
(dependency wise) but I'm not volunteering.  Tiles needs a home and it
already lives in Struts.  Lets leave it alone and move on to more
interesting things.

 Greg

Sean

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

DO NOT REPLY [Bug 39378] New: - [shale] Clay outputLink definition missing target attribute

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39378.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: [shale] Clay outputLink definition missing target
attribute
   Product: Struts
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


Currently the outputLink definition in clay just extends the baseOutput
component.  An attribute needs to be added so that the target attribute can be 
used.

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

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

DO NOT REPLY [Bug 36152] - action field is blank in using html:form

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36152.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |




--- Additional Comments From [EMAIL PROTECTED]  2006-04-21 19:26 ---
I am facing the same problem and I am able to reproduce it with a test case. 

Attachment follows... 


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

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

DO NOT REPLY [Bug 36152] - action field is blank in using html:form

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36152.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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





--- Additional Comments From [EMAIL PROTECTED]  2006-04-21 19:32 ---
Created an attachment (id=18149)
 -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18149action=view)
Problem Demonstration with Struts-Example Application.doc

Problem Demonstration with Struts-Example Application.doc

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

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

DO NOT REPLY [Bug 36152] - action field is blank in using html:form

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36152.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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





--- Additional Comments From [EMAIL PROTECTED]  2006-04-21 19:45 ---
Hi Don,
This problem is causing a lot of 404 page not found errors in our production 
box. It took a long time just to narrow it down to this point. I would really 
appreciate if you would look into the problem. 

I have a WAR file project demonstrating the problem, but its about 9MB and I 
cant seem to attach it to the bug. Is there any other place where I can put it?

Thanks

Stephen

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

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

[Struts Wiki] Update of RoughSpots by JasonCarreira

2006-04-21 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Struts Wiki for change 
notification.

The following page has been changed by JasonCarreira:
http://wiki.apache.org/struts/RoughSpots

--
  * [Gabe] I've created an XWork JIRA for a solution to the same use case 
here. [http://jira.opensymphony.com/browse/XW-387] I'd be happy to contribute 
the code.
  
1. Allow paths in action names. For example `action 
name=reports/myreport`.
+ * [jcarreira] Why do you want this? Isn't this part of the namespace of 
the action?
  
1. Enable Java package import in configuration so you don't have to repeat 
the same package name over and over (like WW1 does).
+ * [jcarreira] +1 if it can be made sane... It can get confusing. It also 
makes tool support worse (i.e. IDEA can find it as a fully qualified class name)
  
1. The ajax support is pitiful. Have a look at how stripes does it. Ajax 
for validation is trivial and not that impressive, but people are going to want 
to do real ajax work, and webwork does absolutely nothing to help in that 
regard. I'd like to for example be able to easily invoke actions and get at 
some kind of result to display, and have webwork provide at least some of the 
wiring
+ * [jcarreira] Well, that's a relatively simple usecase, and I think it IS 
supported... at least we use it at work?
  
1. The default theme for the ui tags should be simple. The current stuff is 
too dumb to get right on the first go, which gives an awful impression. It's 
NOT intuitive to write: {{{
  table
  ww:textfield label=Enter blah /
  /table
  }}}
+ * [jcarreira] That depends on whether you're using the form tag or not, 
but agreed... the XHTML theme should be cleaned up and made the default.
  
1. File upload should support progress notification. Have a look at 
webwork-multipart on java.net, it's based on the pell parser but has a progress 
API.
+ * [jcarreira] We've implemented this at work with WebWork fileupload + 
DWR + a class that looks at the file as it's uploading to see how big it is on 
disk
  
1. Better error checking for UI tags. The freemarker error message, while 
great for freemarker users, look like gibberish. People should not be forced to 
learn freemarker. So in such cases, the tags themselves should check the 
parameters and report back sane messages, even if that check is duplicated in 
the templates
  
1. Defaults should be JSP all the way. People know it and like it, despite 
all the limitations. Allow for other view technologies, but don't force people 
to learn stuff they don't want to. Learning ww is enough of a pain as it is
  
1. Get rid of the validation framework. it's stupid and pointless, validate 
methods are good enough.
+ * [jcarreira] -1 I take offense at this... It's neither stupid NOR 
pointless, and we use it extensively. It's the best validation framework I've 
seen out there, and NO, validate methods are NOT enough. For instance, we 
define reusable validations for our domain models and use them for both the web 
front end as well as web services and batch imports. 
  
1. Ditch xwork as a separate project, nobody uses it or cares about it
+ * [jcarreira] You're kidding, right? We've discussed this already 
  
1. Add java5 support to ognl. It's silly that it still doesn't handle enums 
(that I know of).
+ * [jcarreira] +1 this is biting us right now
  
1. Clean up documentation. Focus on quality not quantity.
+ * [jcarreira] Didn't you read the book? ;-)
  
  == Patrick's issues ==
  
@@ -187, +196 @@

   * [jcarreira] +1 : Carlos at G**gle had some good ideas for this... 
basically stuff like if your action method is foo() then you'd have 
prepareFoo() and validateFoo(), but then I added that the prepare() and 
validate() methods should be the defaults that we call for all action methods.
   * [crazybob] Interesting idea. Might be overkill (i.e. at that point, 
the user should probably create another action class).
   * [hani] No magic method names. If you want to do that, use annotations 
so you have a good chance of IDE support dealing with it. For example 
@Validate/@Prepare etc, with parameters to indicate what request you'd like it 
involved for, in the case where you need multiples of them
+ * [jcarreira] I think RoR has shown that convention over configuration is 
liked by lots of people... these should be straightforward to figure out 
without annotations.
+ 
1. Don't encourage lots of interceptor stacks. Ideally the normal user 
should never need to deal with them. It is better to have a larger stack that 
has optional features that could be turned on through annotations or marker 
interfaces than to encourage users to build their own stacks.
  
   * [jcarreira] I think we should have some pre-defined ones for standard 
things: view vs. CRUD vs. action - do

Re: [Struts Wiki] Update of RoughSpots by Bob Lee

2006-04-21 Thread Jason Carreira

Who did this edit? It says by Bob Lee but one of the comments is tagged as 
hani
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=26827messageID=52884#52884


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

Re: [Struts Wiki] Update of RoughSpots by Bob Lee

2006-04-21 Thread Bob Lee

Like I said in the update comment, I passed along some comments on
behalf of Hani (I also removed dups and clarified a couple).

I'm working on refactoring the list. It makes better sense to break
the issues down by category, not the person who submitted them.

Bob

On 4/21/06, Jason Carreira [EMAIL PROTECTED] wrote:
 Who did this edit? It says by Bob Lee but one of the comments is tagged as 
 hani
 -
 Posted via Jive Forums
 http://forums.opensymphony.com/thread.jspa?threadID=26827messageID=52884#52884


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



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

svn commit: r396020 - /struts/current/STATUS.txt

2006-04-21 Thread husted

Author: husted
Date: Fri Apr 21 15:16:40 2006
New Revision: 396020

URL: http://svn.apache.org/viewcvs?rev=396020view=rev
Log:
Update list of PMC members, post April Status report, and update roster of 
recent votes,

Modified:
struts/current/STATUS.txt

Modified: struts/current/STATUS.txt
URL: 
http://svn.apache.org/viewcvs/struts/current/STATUS.txt?rev=396020r1=396019r2=396020view=diff
==
--- struts/current/STATUS.txt (original)
+++ struts/current/STATUS.txt Fri Apr 21 15:16:40 2006
@@ -7,6 +7,8 @@
 Source Code: http://svn.apache.org/viewcvs.cgi/struts/
 Announcements: http://struts.apache.org/announce.html
 
+WebWork2 Incubation Status: 
http://svn.apache.org/repos/asf/incubator/webwork2/STATUS.txt
+
 PMC Members
 
 * Craig R. McClanahan  (craigmcc at apache.org)
@@ -24,14 +26,14 @@
 * Hubert Rabago (hrabago at apache.org)
 * Wendy Smoak (wsmoak at apache.org)
 * Gary VanMatre (gvanmatre at apache.org)
+* Sean Schofield (schof at apache.org)
+* Greg Reddin (greddin at apache.org)
 
 Other Active Committers
 
 * Eddie Bush  (ekbush at apache.org)
 * James Turner (turner at blackbear.com)
 * David Geary (dgeary at apache.org)
-* Sean Schofield (schof at apache.org)
-* Greg Reddin (greddin at apache.org)
 * Laurie Harper (laurieh at apache.org)
 * Richard Feit  (rich at apache.org)
 * Jason Carreira (jcarreira at apache.org)
@@ -60,6 +62,27 @@
 2006 Board Reports 
 
 
+April 2006 
+
+The Struts community has been a busy one this last quarter. In terms of
+releases, we released Struts 1.2.9, primarily to fix a reported
+vulnerability, and Shale 1.0.2 Alpha. We also made available Struts Action
+1.3.1 Test Build, the first completed build in the Struts Action 1.3 line.
+
+After voting to accept WebWork 2, we have made progress towards removing
+external dependencies with non-compatible licenses, and migrating the code
+base from OpenSymphony to Struts.
+
+We have decided to move all of the Struts components to JIRA for issue
+tracking, and to Maven 2 for our build system. There has been much
+discussion of splitting the user mailing list into multiple lists, based
+on sub-project, but no consensus has been reached.
+
+On the people front, we added Gary VanMatre to the PMC, and five new
+committers (Alexandru Popescu, Rene Gielen, Rainer Hermanns, Toby Jee, and
+Ian Roughley) as part of bringing WebWork 2 into the fold.
+
+
 January 2006
 
 The last quarter has been an eventful one in the Struts community. In
@@ -182,8 +205,17 @@
 
 2006 PROJECT VOTES
 
+Sean Schofield for PMC
+* [17 Apr 2006] Tally 8 +1 (binding)
+
+Greg Reddin for PMC
+* [15 Apr 2006] Tally 7 +1 (binding)
+
+Multiple User Lists 
+* [24 Mar 2006] Tally 3 +1 (binding), 5 +1 (non-binding); 4 0 (binding); 5 -1 
(binding);
+
 Struts Shale v1.0.2 Quality
-* [23 Mar 2006] (Pending) Tally +2 alpha (binding)
+* [23 Mar 2006] Tally +3 alpha (binding)
 
 Struts Shale v1.0.1 Quality
 * [19 Mar 2006] Tally +1 alpha (binding); -1 alpha (binding)



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

Re: svn commit: r396020 - /struts/current/STATUS.txt

2006-04-21 Thread Martin Cooper

On 4/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Author: husted
 Date: Fri Apr 21 15:16:40 2006
 New Revision: 396020

 URL: http://svn.apache.org/viewcvs?rev=396020view=rev
 Log:
 Update list of PMC members


This is actually a little premature. Recall that our new PMC nominees are
not actually PMC members until 72 hours after a board ack. That ack is only
a couple of hours old. ;-)

--
Martin Cooper


, post April Status report, and update roster of recent votes,

 Modified:
 struts/current/STATUS.txt

 Modified: struts/current/STATUS.txt
 URL:
 http://svn.apache.org/viewcvs/struts/current/STATUS.txt?rev=396020r1=396019r2=396020view=diff

 ==
 --- struts/current/STATUS.txt (original)
 +++ struts/current/STATUS.txt Fri Apr 21 15:16:40 2006
 @@ -7,6 +7,8 @@
 Source Code: http://svn.apache.org/viewcvs.cgi/struts/
 Announcements: http://struts.apache.org/announce.html

 +WebWork2 Incubation Status:
 http://svn.apache.org/repos/asf/incubator/webwork2/STATUS.txt
 +
 PMC Members

  * Craig R. McClanahan  (craigmcc at apache.org)
 @@ -24,14 +26,14 @@
  * Hubert Rabago (hrabago at apache.org)
  * Wendy Smoak (wsmoak at apache.org)
  * Gary VanMatre (gvanmatre at apache.org)
 +* Sean Schofield (schof at apache.org)
 +* Greg Reddin (greddin at apache.org)

 Other Active Committers

  * Eddie Bush  (ekbush at apache.org)
  * James Turner (turner at blackbear.com)
  * David Geary (dgeary at apache.org)
 -* Sean Schofield (schof at apache.org)
 -* Greg Reddin (greddin at apache.org)
  * Laurie Harper (laurieh at apache.org)
  * Richard Feit  (rich at apache.org)
  * Jason Carreira (jcarreira at apache.org)
 @@ -60,6 +62,27 @@
 2006 Board Reports


 +April 2006
 +
 +The Struts community has been a busy one this last quarter. In terms of
 +releases, we released Struts 1.2.9, primarily to fix a reported
 +vulnerability, and Shale 1.0.2 Alpha. We also made available Struts
 Action
 +1.3.1 Test Build, the first completed build in the Struts Action 1.3line.
 +
 +After voting to accept WebWork 2, we have made progress towards removing
 +external dependencies with non-compatible licenses, and migrating the
 code
 +base from OpenSymphony to Struts.
 +
 +We have decided to move all of the Struts components to JIRA for issue
 +tracking, and to Maven 2 for our build system. There has been much
 +discussion of splitting the user mailing list into multiple lists, based
 +on sub-project, but no consensus has been reached.
 +
 +On the people front, we added Gary VanMatre to the PMC, and five new
 +committers (Alexandru Popescu, Rene Gielen, Rainer Hermanns, Toby Jee,
 and
 +Ian Roughley) as part of bringing WebWork 2 into the fold.
 +
 +
 January 2006

 The last quarter has been an eventful one in the Struts community. In
 @@ -182,8 +205,17 @@

 2006 PROJECT VOTES

 +Sean Schofield for PMC
 +* [17 Apr 2006] Tally 8 +1 (binding)
 +
 +Greg Reddin for PMC
 +* [15 Apr 2006] Tally 7 +1 (binding)
 +
 +Multiple User Lists
 +* [24 Mar 2006] Tally 3 +1 (binding), 5 +1 (non-binding); 4 0 (binding);
 5 -1 (binding);
 +
 Struts Shale v1.0.2 Quality
 -* [23 Mar 2006] (Pending) Tally +2 alpha (binding)
 +* [23 Mar 2006] Tally +3 alpha (binding)

 Struts Shale v1.0.1 Quality
 * [19 Mar 2006] Tally +1 alpha (binding); -1 alpha (binding)



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

DO NOT REPLY [Bug 36152] - action field is blank in using html:form

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36152.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |critical
 OS/Version|Linux   |AIX
   Priority|P2  |P1
Version|1.2.4   |1.1 Final




--- Additional Comments From [EMAIL PROTECTED]  2006-04-21 23:09 ---
I am setting the Priority to 'P1' and severity to 'Critical' as this is 
causing a frequent '404 Page Not Found' errors in the production box. 

CAUSE OF THE ERROR: 
When a RequestDispatcher.forward is being executed by the server, and at the 
same time if any other user session is rendering a JSP page with html:form 
tag in it - then the tag's action value gets left out in the HTML output. The 
user session ends up getting a HTML form with partial or no value for the 
form's action parameter. And when the user submits that page he is sure to get 
a '404 page not found' error or unexpected behavior since the action value is 
incorrect. 

The test case I have demonstrates this problem very clearly but I cant seem to 
find a place to put it in. 

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

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

DO NOT REPLY [Bug 36152] - action field is blank in using html:form

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36152.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2006-04-21 23:28 ---
Thanks for the detailed report, but I'm still stumped.  Could you try to
reproduce this with the latest Struts 1.3 nightly or SVN build?  This would at
least help us determine if it is still an issue or was inadvertently fixed.

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

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

Re: Struts BOF at JavaOne?

2006-04-21 Thread Gary VanMatre

From: Don Brown [EMAIL PROTECTED] 

 To help bring this flurry of ideas and directions to a head, I think we 
 should 
 have an unofficial Struts BOF at JavaOne 
 next month. I envision a setting conducive to discussion, design, and 
 planning 
 (good beer is a definite plus :)) with 
 the goal of exploring a roadmap for where we see Struts going in the next 
 year. 
 
 My first thought was trying to secure a side conference room at Moscone, but 
 I 
 don't have a clue on how to get one. We 
 could also just meet in a hotel lobby or a quiet bar/restaurant somewhere 
 near 
 by. 
 
 Any ideas? 


I don't have any suggestions on the logistics, but my employer, Wyant Data 
Systems (www.wyantdata.com), has offered an initial $200 for beer.  Now the 
'good' part is dependent on which type of brew you choose ;-)

 
 Don 
 

Gary

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

Re: Struts BOF at JavaOne?

2006-04-21 Thread Martin Cooper

On 4/21/06, Gary VanMatre [EMAIL PROTECTED] wrote:

 From: Don Brown [EMAIL PROTECTED]
 
  To help bring this flurry of ideas and directions to a head, I think we
 should
  have an unofficial Struts BOF at JavaOne
  next month. I envision a setting conducive to discussion, design, and
 planning
  (good beer is a definite plus :)) with
  the goal of exploring a roadmap for where we see Struts going in the
 next year.
 
  My first thought was trying to secure a side conference room at Moscone,
 but I
  don't have a clue on how to get one. We
  could also just meet in a hotel lobby or a quiet bar/restaurant
 somewhere near
  by.
 
  Any ideas?
 

 I don't have any suggestions on the logistics, but my employer, Wyant Data
 Systems (www.wyantdata.com), has offered an initial $200 for beer.


Each? ;-) (Well, it *is* Friday!)

--
Martin Cooper


  Now the 'good' part is dependent on which type of brew you choose ;-)


  Don
 

 Gary

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

DO NOT REPLY [Bug 39381] - [shale] Missing binding attribute in clay-config.xml

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39381.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[shale] |[shale] Missing binding
   ||attribute in clay-config.xml




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

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

Re: Struts BOF at JavaOne?