Re: [HI][TAGS] Greetings

2004-10-18 Thread Levieux Cedric
I think there is a misunderstanding between us.

As far as I know there is no scope range for tiles since it uses its own
container. So I can't test if a parameter is present or not in a call of a
tile.

This is this kind of things I propose to add.

Regards,

Cedric

- Original Message - 
From: Martin Cooper [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Friday, October 15, 2004 6:31 PM
Subject: Re: [HI][TAGS] Greetings


 On Fri, 15 Oct 2004 07:45:59 -0500, Joe Germuska [EMAIL PROTECTED] wrote:
  In general, we are advising people to use JSTL tags wherever they
  serve a purpose that overlaps with Struts tags.  It sounds like
  c:if and similar tags would probably serve most of your logic test
  needs.  As for verifying the presence of a request attribute, it
  seems that the Jakarta Taglibs request taglib has a tag which can
  do that.
 
 
http://jakarta.apache.org/taglibs/doc/request-doc/request-1.0/index.html#reference
 

 Or you can use JSTL for this too:

 c:if test=${requestScope.myAttr}
   ...
 /c:if


 --
 Martin Cooper


  Struts tags that have a guaranteed future would be those that encode
  knowledge about things that Struts does uniquely -- for example, the
  logic:messagesPresent tag and the html:messages tag.  Tags that
  do something which could be used in any JSP application, whether or
  not Struts is the controller, don't have many champions.  We
  recommend that those be developed in a way which makes their
  independence from Struts more clear.
 
  Joe
 
 
 
 
  At 11:18 AM +0200 10/15/04, Levieux Cedric wrote:
  Like I said this is only add-ons
  
  For example in the tiles I need to develop for my own purpose a tag
that
  verify if an attribute was set or not during the call of the tile.
  
  It has the same behavior as the logic:present tag but focus on the
tiles.
  
  I also need to develop some add-ons for the bean:message for being
flexible
  with arguments coming from beans or the logic:redirect
  
  Even some times I need to compare two beans with the logic tags.
  
  Cedric
  
  - Original Message -
  From: Joe Germuska [EMAIL PROTECTED]
  To: Struts Developers List [EMAIL PROTECTED]
  Sent: Friday, October 15, 2004 2:33 AM
  Subject: Re: [HI][TAGS] Greetings
  
  
I'm here to see if the struts development community is open for
tags
add-on for the existing struts tagslibs.
  
Depends -- what do you have in mind?
  
Going forward, I think we would only want to add tags that are
specifically focused around Struts functionality.  Tags that don't
depend on Struts don't really belong in the Struts project -- some
might fit into existing Jakarta Taglibs projects, or might be
proposed as new subprojects there, and others might make good
projects on their own, like the displaytag libraries.
  
What do your tag libraries do?
  
Joe
  
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place.
- Carlos Santana
  
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
  --
  Joe Germuska
  [EMAIL PROTECTED]
  http://blog.germuska.com
  In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
  back; I'll know I'm in the wrong place.
 - Carlos Santana
 
  -
  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]



[VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Ted Husted
Our release guidelines page is ambiguous as to whether we need to vote on an Alpha 
classification. (Mea culpa.)

* http://struts.apache.org/releases.html

I believe the original intent was to follow the HTTP server practice where When a 
release is initially created, it automatically becomes alpha quality.

* http://httpd.apache.org/dev/release.html

Our Release Guidelines page needs to be updated in that it does not point to the 
cvs.apache.org are for pre-GA releases and should mention the new 
wiki-checklist-release-plan protocol.

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

As the page is being revised, we might also want to reduce confusion by starting with 
the HTTP server release process and then making whatever modifications we need from 
there.

Here's my +1 for adopting the HTTP server release process, with whatever modifications 
we deem necessary.

-Ted.

On Sun, 17 Oct 2004 21:05:43 -0700, Martin Cooper wrote:
 Actually, it's not Beta (or Alpha or GA) nor is it a Release, until
 we vote on it, in, say, a week from now. At this point, it's just a
 Test Build. Until the community has got used to this new build
 numbering scheme, we need to be very careful about how we label
 each build.

 --
 Martin Cooper


 On Sun, 17 Oct 2004 23:54:02 -0400, James Mitchell
 [EMAIL PROTECTED] wrote:

 The Apache Struts community is pleased to announce the release of
 Struts 1.2.5 (beta). This is primarily a bug fix release.
 Feedback is greatly appreciated.

 After some time has passed to allow for adequate testing, a vote
 will be cast to determine the quality of this release.  At that
 time, if Struts 1.2.5 has no major issues and the committers feel
 it is of good quality, this version will be published to the
 larger community as the next Official Release of Struts
 (General Availability).

 You can download Struts 1.2.5 from:
 http://svn.apache.org/dist/struts/v1.2.5/

 --
 James Mitchell
 Software Engineer / Open Source Evangelist
 EdgeTech, Inc.
 678.910.8017
 AIM: jmitchtx


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



DO NOT REPLY [Bug 31423] - Lazy ActionForms

2004-10-18 Thread bugzilla
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=31423.
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=31423

Lazy ActionForms





--- Additional Comments From [EMAIL PROTECTED]  2004-10-18 08:17 ---
+1 on moving the dependency and adding LazyActionForms.

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



DO NOT REPLY [Bug 31754] New: - XHTML mode must be configurable in struts-config.xml for the entire app, not on page level only

2004-10-18 Thread bugzilla
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=31754.
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=31754

XHTML mode must be configurable in struts-config.xml for the entire app, not on page 
level only

   Summary: XHTML mode must be configurable in struts-config.xml for
the entire app, not on page level only
   Product: Struts
   Version: 1.2.4
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi, everybody.

At this moment one can tell Struts to render tags in xhtml mode only using 
html:html xthml=true or html:xhtml/ tags. This is defined on page level, not 
application level. So that means that if you want your entire application to 
have xhtml style output then you need to put one of these tags in EVERY jsp you 
have.

I believe, that it should be allowed to specify a parameter in application 
config file (say struts-config.xml), that xtml=true and all tags on all pages 
will work in this mode.

Of course html and xtml tags will be extended to be able to override 
application wide behaviour on page level (like: html xthml=false and xhtml 
xhtml=false/), so it's gonna be backward compatible.

As I can see from the source, such a feature is very easy to implement: there is 
a method isXhtml() in TagUtils,

/**
 * Returns true if the custom tags are in XHTML mode.
 */
public boolean isXhtml(PageContext pageContext) {
String xhtml =
(String) pageContext.getAttribute(
Globals.XHTML_KEY,
PageContext.PAGE_SCOPE);

return true.equalsIgnoreCase(xhtml);
}

Which looks only in page scope, so it can also look in application scope, where 
this attribute can be placed during initialization of Struts controller servlet.

I propose to add extra attribute to controller element in struts-config.xml, 
which would look like:

controller xhtml=true/

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



DO NOT REPLY [Bug 31642] - bean:include always include Session id (if any) even for external Urls (href attribute)

2004-10-18 Thread bugzilla
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=31642.
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=31642

bean:include always include Session id (if any) even for external Urls (href 
attribute)





--- Additional Comments From [EMAIL PROTECTED]  2004-10-18 09:57 ---
just had a look at Bug 18032, nop they're not related to each other

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



DO NOT REPLY [Bug 31755] New: - No mention in the doc for default actionConfig scope

2004-10-18 Thread bugzilla
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=31755.
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=31755

No mention in the doc for default actionConfig scope

   Summary: No mention in the doc for default actionConfig scope
   Product: Struts
   Version: 1.2.4
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I couldn't find in the documentation the default value for the scope in
actionConfig. A quick look in the code confirmed me that it was session (which
was causing some problems).
Could somebody alter the javadoc and user guide to specify the default ?
Thanks.

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



Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Joe Germuska
Here's my +1 for adopting the HTTP server release process, with 
whatever modifications we deem necessary.
I agree with this.  I believe we should consider anything a release 
which has gone through the release checklist and had a version number 
assigned and a corresponding tag applied to SVN.  This is a purely 
mechanical definition.  Anything else might involve confusion if a 
version number were reused.

I think only the promotion of a release from alpha should require a vote.
Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn 
back; I'll know I'm in the wrong place.
   - Carlos Santana

DO NOT REPLY [Bug 31754] - XHTML mode must be configurable in struts-config.xml for the entire app, not on page level only

2004-10-18 Thread bugzilla
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=31754.
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=31754

XHTML mode must be configurable in struts-config.xml for the entire app, not on page 
level only

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement

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



DO NOT REPLY [Bug 31761] New: - NullPointerException in ActionServlet

2004-10-18 Thread bugzilla
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=31761.
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=31761

NullPointerException in ActionServlet

   Summary: NullPointerException in ActionServlet
   Product: Struts
   Version: 1.2.4
  Platform: All
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If somebody mistypes the name of a struts-config file (or gives the name of a 
non-existent one) in the web.xml file, a nasty NullPointerException occurs.  
For example:

servlet
  servlet-nameaction/servlet-name
  servlet-classorg.apache.struts.action.ActionServlet/servlet-class

  ...

  init-param
param-nameconfig/path2/param-name
param-value/WEB-INF/strust-config-path2.xml/param-value
  /init-param
/servlet

(notice that I purposely added a mispelling in the param-value), 
ActionServlet.parseModuleConfigFile will throw a NullPointerException without 
much additional information.  When you have a billion different config modules 
(as we do), it can be almost impossible to troubleshoot without stepping into 
the source code.

Propose adding a check to parseModuleConfigFile that will throw a more 
meaningful exception, including the name of the module whose config file it was 
unable to find to aid troubleshooting when this situation occurs.

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



DO NOT REPLY [Bug 31761] - NullPointerException in ActionServlet

2004-10-18 Thread bugzilla
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=31761.
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=31761

NullPointerException in ActionServlet





--- Additional Comments From [EMAIL PROTECTED]  2004-10-18 16:09 ---
Created an attachment (id=13131)
Proposed patch to address this

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



Re: Proposed patch for bug 31761

2004-10-18 Thread James Mitchell
This message did not make it to [EMAIL PROTECTED]  I was hung in
moderation.

1. Make sure you are subscribed from the same address you are sending from.
2. Always attach patches to the bugzilla ticket for which it applies (I see
you've already done that...thanks)



--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 18, 2004 12:06 PM
Subject: Proposed patch for bug 31761


The included patch file addresses a NullPointerException that occurs when a
user mistypes a config-file entry in the struts action servlet config in
web.xml.  See http://issues.apache.org/bugzilla/show_bug.cgi?id=31761 for
more information.



--- src/share/org/apache/struts/action/ActionServlet.java 2004-10-18
11:00:20.087672000 -0500
+++ src/share/org/apache/struts/action/ActionServlet.java 2004-10-18
10:58:16.019270400 -0500
@@ -702,6 +702,13 @@
 InputStream input = null;
 try {
 URL url = getServletContext().getResource(path);
+
+if ( url == null )
+{
+throw new UnavailableException( Module configuration file
' +
+path + ' not found.  Unable to start Struts. );
+}
+
 InputSource is = new InputSource(url.toExternalForm());
 input = getServletContext().getResourceAsStream(path);
 is.setByteStream(input);



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



DO NOT REPLY [Bug 31761] - NullPointerException in ActionServlet

2004-10-18 Thread bugzilla
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=31761.
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=31761

NullPointerException in ActionServlet





--- Additional Comments From [EMAIL PROTECTED]  2004-10-18 16:12 ---
The attached patch proposal has also been submitted to [EMAIL PROTECTED]

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



DO NOT REPLY [Bug 25527] - [fileupload] process lynx linemode browser's multipart form post too!

2004-10-18 Thread bugzilla
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=25527.
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=25527

[fileupload] process lynx linemode browser's multipart form post too!

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|process lynx linemode   |[fileupload] process lynx
   |browser's multipart form|linemode browser's multipart
   |post too!   |form post too!

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



svn commit: rev 55017 - struts/trunk/doc

2004-10-18 Thread jmitchell
Author: jmitchell
Date: Mon Oct 18 09:20:10 2004
New Revision: 55017

Modified:
   struts/trunk/doc/acquiring.xml
Log:
Update for latest dev build

Modified: struts/trunk/doc/acquiring.xml
==
--- struts/trunk/doc/acquiring.xml  (original)
+++ struts/trunk/doc/acquiring.xml  Mon Oct 18 09:20:10 2004
@@ -58,8 +58,7 @@
 Availability status and may be made the Best Available release.
 /p
 p
-With the recent promotion of Struts 1.2.4 to General Availability, there
-are no more recent development builds at this time.
+The current development build is Struts v1.2.5 and is available a 
href=http://cvs.apache.org/dist/struts/v1.2.5/;here/a
 /p
 
 /section

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



svn commit: rev 55018 - struts/trunk/doc

2004-10-18 Thread jmitchell
Author: jmitchell
Date: Mon Oct 18 09:25:00 2004
New Revision: 55018

Modified:
   struts/trunk/doc/releases.xml
Log:
svn == cvs (for now at least)

Modified: struts/trunk/doc/releases.xml
==
--- struts/trunk/doc/releases.xml   (original)
+++ struts/trunk/doc/releases.xml   Mon Oct 18 09:25:00 2004
@@ -17,7 +17,7 @@
 section href=Releases name=Release Guidelines
   pA 
   a href=http://jakarta.apache.org/commons/versioning.html;point release/a 
should be made before and after any product change that is not a fully-compatible 
change (see link). This includes moving a dependency from an internal package to an 
external product, including products distributed through the Jakarta Commons. We 
should place any fully-compatible changes in the hands of the community before 
starting on a change that is only interface or external-interface compatible./p
-  pA fully-compatible point release does not always need a preview beta or 
milestone release. If appropriate, a Release Candidate can be cut, uploaded to the 
development distribution directories on cvs.apache.org 
(/www/cvs.apache.org/dist/struts/ and http://cvs.apache.org/repository/struts/), and 
voted to be released to the general public from there. /p
+  pA fully-compatible point release does not always need a preview beta or 
milestone release. If appropriate, a Release Candidate can be cut, uploaded to the 
development distribution directories on svn.apache.org 
(/www/svn.apache.org/dist/struts/ and http://svn.apache.org/repository/struts/), and 
voted to be released to the general public from there. /p
   pAny release should follow the same general process used by the Jakarta 
Commons and the Apache HTTP Server project./p
   ul
 li

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



svn commit: rev 55019 - struts/trunk/doc

2004-10-18 Thread jmitchell
Author: jmitchell
Date: Mon Oct 18 09:26:19 2004
New Revision: 55019

Modified:
   struts/trunk/doc/acquiring.xml
Log:
oops, forgot one

Modified: struts/trunk/doc/acquiring.xml
==
--- struts/trunk/doc/acquiring.xml  (original)
+++ struts/trunk/doc/acquiring.xml  Mon Oct 18 09:26:19 2004
@@ -58,7 +58,7 @@
 Availability status and may be made the Best Available release.
 /p
 p
-The current development build is Struts v1.2.5 and is available a 
href=http://cvs.apache.org/dist/struts/v1.2.5/;here/a
+The current development build is Struts v1.2.5 and is available a 
href=http://svn.apache.org/dist/struts/v1.2.5/;here/a
 /p
 
 /section

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



Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Martin Cooper
On Mon, 18 Oct 2004 08:07:41 -0500, Joe Germuska [EMAIL PROTECTED] wrote:
 Here's my +1 for adopting the HTTP server release process, with
 whatever modifications we deem necessary.
 
 I agree with this.  I believe we should consider anything a release
 which has gone through the release checklist and had a version number
 assigned and a corresponding tag applied to SVN.  This is a purely
 mechanical definition.  Anything else might involve confusion if a
 version number were reused.

I disagree with the idea of calling anything a Release without voting
on it. What led to our change in process was a desire to move to the
Tomcat way of doing things. Mention of the HTTPD way of doing things
came along later. The Tomcat way has us building Test Builds which we
later vote on to decide if it's a Release of any sort. That is the
process that I followed for 1.2.4, and that is the process that I want
to see us adopt. It was actually my understanding that we had already
done so, which is why I've been following it. If the HTTPD process is
different from that, then I am -1 on adopting that process.

--
Martin Cooper


 
 I think only the promotion of a release from alpha should require a vote.
 
 Joe
 
 --
 Joe Germuska
 [EMAIL PROTECTED]
 http://blog.germuska.com
 In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
 back; I'll know I'm in the wrong place.
- Carlos Santana


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



Re: building struts question

2004-10-18 Thread Craig McClanahan
The Maven-based build scripts are still under development.  The
official method to build struts is still Ant.  You'll need to
configure a build.properties file that points at where you've
downloaded and installed the dependencies -- see
build.properties.sample for a sample of what will be needed.

Craig



On Mon, 18 Oct 2004 17:21:25 +0800, Christopher Lim
[EMAIL PROTECTED] wrote:
 Just checked out struts source code from subversion and issued
 
  maven
 
 got the following errors:
 
 BUILD FAILED
 File.. C:\Projects\OpenSource\struts\maven.xml
 Element... ant:style
 Line.. 29
 Column 28
 Provider org.apache.xalan.processor.TransformerFactoryImpl not found
 Total time: 3 seconds
 Finished at: Mon Oct 18 17:19:58 CST 2004
 
 -
 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: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Joe Germuska
At 9:35 AM -0700 10/18/04, Martin Cooper wrote:
On Mon, 18 Oct 2004 08:07:41 -0500, Joe Germuska [EMAIL PROTECTED] wrote:
 Here's my +1 for adopting the HTTP server release process, with
 whatever modifications we deem necessary.
 I agree with this.  I believe we should consider anything a release
 which has gone through the release checklist and had a version number
 assigned and a corresponding tag applied to SVN.  This is a purely
 mechanical definition.  Anything else might involve confusion if a
 version number were reused.
I disagree with the idea of calling anything a Release without voting
on it. What led to our change in process was a desire to move to the
Tomcat way of doing things. Mention of the HTTPD way of doing things
came along later. The Tomcat way has us building Test Builds which we
later vote on to decide if it's a Release of any sort. That is the
process that I followed for 1.2.4, and that is the process that I want
to see us adopt. It was actually my understanding that we had already
done so, which is why I've been following it. If the HTTPD process is
different from that, then I am -1 on adopting that process.
In my ignorance, I didn't even realize that there was that much 
difference between Tomcat's process and HTTPD's process.

I would formalize my vote as +0 - I don't feel very strongly about 
it, and Martin apparently does.  I had thought we were going to do it 
the way I described, but I don't really think much is lost by adding 
in a test build period.  I do think there would be potential 
confusion if a test build was not voted as a release, but the amount 
of that potential confusion is probably pretty low if we're just 
talking about activity on the dev list.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn 
back; I'll know I'm in the wrong place.
   - Carlos Santana

svn commit: rev 55025 - struts/trunk/conf/share

2004-10-18 Thread craigmcc
Author: craigmcc
Date: Mon Oct 18 10:40:29 2004
New Revision: 55025

Modified:
   struts/trunk/conf/share/struts-config_1_2.dtd
Log:
Document the default value for scope on an action element in the DTD
for a struts-config.xml file (along with all the other documentation).

PR: Bugzilla #31755
Submitted by: Xavier Poinsard (xpoinsard AT openpricer.com)



Modified: struts/trunk/conf/share/struts-config_1_2.dtd
==
--- struts/trunk/conf/share/struts-config_1_2.dtd   (original)
+++ struts/trunk/conf/share/struts-config_1_2.dtd   Mon Oct 18 10:40:29 2004
@@ -8,7 +8,7 @@
-//Apache Software Foundation//DTD Struts Configuration 1.2//EN
http://struts.apache.org/dtds/struts-config_1_2.dtd;
 
- $Id: struts-config_1_2.dtd,v 1.8 2004/04/06 23:30:23 husted Exp $
+ $Id$
 --
 
 
@@ -415,7 +415,7 @@
 
  scope   The context (request or session) that is used to
  access our ActionForm bean, if any.  Optional if name is
- specified, else not valid.
+ specified, else not valid. [session]
 
  suffix  Suffix used to match request parameter names to ActionForm
  bean property names, if any. Optional if name is

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



DO NOT REPLY [Bug 31755] - No mention in the doc for default actionConfig scope

2004-10-18 Thread bugzilla
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=31755.
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=31755

No mention in the doc for default actionConfig scope

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-10-18 17:43 ---
Fixed (documented in the DTD for a struts-config.xml file) in nightly build
20041019.  This fix will also get picked up in any release after 1.2.5.

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



Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Martin Cooper
On Mon, 18 Oct 2004 12:13:10 -0500, Joe Germuska [EMAIL PROTECTED] wrote:
 At 9:35 AM -0700 10/18/04, Martin Cooper wrote:
 On Mon, 18 Oct 2004 08:07:41 -0500, Joe Germuska [EMAIL PROTECTED] wrote:
   Here's my +1 for adopting the HTTP server release process, with
   whatever modifications we deem necessary.
 
   I agree with this.  I believe we should consider anything a release
   which has gone through the release checklist and had a version number
   assigned and a corresponding tag applied to SVN.  This is a purely
   mechanical definition.  Anything else might involve confusion if a
   version number were reused.
 
 I disagree with the idea of calling anything a Release without voting
 on it. What led to our change in process was a desire to move to the
 Tomcat way of doing things. Mention of the HTTPD way of doing things
 came along later. The Tomcat way has us building Test Builds which we
 later vote on to decide if it's a Release of any sort. That is the
 process that I followed for 1.2.4, and that is the process that I want
 to see us adopt. It was actually my understanding that we had already
 done so, which is why I've been following it. If the HTTPD process is
 different from that, then I am -1 on adopting that process.
 
 In my ignorance, I didn't even realize that there was that much
 difference between Tomcat's process and HTTPD's process.
 
 I would formalize my vote as +0 - I don't feel very strongly about
 it, and Martin apparently does.  I had thought we were going to do it
 the way I described, but I don't really think much is lost by adding
 in a test build period.  I do think there would be potential
 confusion if a test build was not voted as a release, but the amount
 of that potential confusion is probably pretty low if we're just
 talking about activity on the dev list.

The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as
it should be - we want releases to be quality builds.

What I feel very strongly about is that nothing should be called a
Release until we vote on it, especially since I believe this is an ASF
requirement. We have said that anyone can build a Test Build (e.g.
1.2.x) at any time, and that's fine. But I don't want to see such a
build viewed as a Release by the community if the developers / PMC
haven't sanctioned it by a vote.

--
Martin Cooper


 
 
 Joe
 
 --
 Joe Germuska
 [EMAIL PROTECTED]
 http://blog.germuska.com
 In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
 back; I'll know I'm in the wrong place.
- Carlos Santana


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



Re: building struts question

2004-10-18 Thread Joe Germuska
Craig is right.  However, I'm kind of curious about what's going on 
here, if you want to help us understand it more.

In order to do the XSL transforms to convert our TLD meta-files into 
true TLD files, the maven.xml  sets the system property to use Xalan 
as the XSLT transformer.

The project.xml file includes Xalan as a dependency, so I don't 
really understand why you would get a not found error, unless you 
are somehow overriding the Xalan dependency.

Joe
At 10:21 AM -0700 10/18/04, Craig McClanahan wrote:
The Maven-based build scripts are still under development.  The
official method to build struts is still Ant.  You'll need to
configure a build.properties file that points at where you've
downloaded and installed the dependencies -- see
build.properties.sample for a sample of what will be needed.
Craig

On Mon, 18 Oct 2004 17:21:25 +0800, Christopher Lim
[EMAIL PROTECTED] wrote:
 Just checked out struts source code from subversion and issued
  maven
 got the following errors:
 BUILD FAILED
 File.. C:\Projects\OpenSource\struts\maven.xml
 Element... ant:style
 Line.. 29
 Column 28
 Provider org.apache.xalan.processor.TransformerFactoryImpl not found
 Total time: 3 seconds
 Finished at: Mon Oct 18 17:19:58 CST 2004
 -
 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]

--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn 
back; I'll know I'm in the wrong place.
   - Carlos Santana

Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Joe Germuska
At 10:55 AM -0700 10/18/04, Martin Cooper wrote:
The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as
it should be - we want releases to be quality builds.
What I feel very strongly about is that nothing should be called a
Release until we vote on it, especially since I believe this is an ASF
requirement. We have said that anyone can build a Test Build (e.g.
1.2.x) at any time, and that's fine. But I don't want to see such a
build viewed as a Release by the community if the developers / PMC
haven't sanctioned it by a vote.
I think ultimately we agree even more than I realized, since, looking 
back at how you describe these events, I realize that my main concern 
- version number confusion - is not at issue.

I simply think of anything with a version number as a release.  I'm 
happy to change that and to describe the first output of the release 
process as a test build instead of an alpha release.

In fact, I'd be +1 to that, given that we have two cases in recent 
memory where the artifact was not really even usable as an alpha 
release.

Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn 
back; I'll know I'm in the wrong place.
   - Carlos Santana

He's baaaaaack....

2004-10-18 Thread James Turner
Hi gang,
  I know it's been a while, but I wanted to let you know that I've sent 
my Apache 2.0 agreement to the magic fax, and assuming it's possible to 
return from emeritus status, I'd like to come back to the fold.

  The last year or so, I had to concentrate on feeding the family in a 
down econonmy, but now I've landed in a stable job (a couple of them, 
actually), and I'll have some time to put into the greater Struts 
collective again.

So, if you'll have me, I'm back.
James
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: He's baaaaaack....

2004-10-18 Thread James Mitchell
Welcome back!!!

I also noticed a few posts recently by another missing soulMr. Eddie
Bush.  Could that be the same Eddie that was once an active contributor to
the Struts community?  If so, then welcome back to you as well!!




--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

- Original Message -
From: James Turner [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Monday, October 18, 2004 3:15 PM
Subject: He's baack


 Hi gang,
I know it's been a while, but I wanted to let you know that I've sent
 my Apache 2.0 agreement to the magic fax, and assuming it's possible to
 return from emeritus status, I'd like to come back to the fold.

The last year or so, I had to concentrate on feeding the family in a
 down econonmy, but now I've landed in a stable job (a couple of them,
 actually), and I'll have some time to put into the greater Struts
 collective again.

 So, if you'll have me, I'm back.
 James


 -
 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: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Craig McClanahan
+1 on the test build then vote to rank approach that Tomcat uses.

As an additional clarification, I presume that we will want the same
release process for any subproject releases?  This is becoming timely
as the opportunity for a 1.0.1 release of struts-faces draws nigh.  It
might be worth mentioning this in the release guidelines as well,
including the explicit requirement that any release vote involve the
entire committer community (with PMC votes binding, as usual) -- not
just the developers who might happen to be working on that subproject.
 After all, the subprojects will still say Struts on them, and we're
all going to care about that reputation.

Craig


On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote:
 At 10:55 AM -0700 10/18/04, Martin Cooper wrote:
 The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as
 it should be - we want releases to be quality builds.
 
 What I feel very strongly about is that nothing should be called a
 Release until we vote on it, especially since I believe this is an ASF
 requirement. We have said that anyone can build a Test Build (e.g.
 1.2.x) at any time, and that's fine. But I don't want to see such a
 build viewed as a Release by the community if the developers / PMC
 haven't sanctioned it by a vote.
 
 I think ultimately we agree even more than I realized, since, looking
 back at how you describe these events, I realize that my main concern
 - version number confusion - is not at issue.
 
 I simply think of anything with a version number as a release.  I'm
 happy to change that and to describe the first output of the release
 process as a test build instead of an alpha release.
 
 In fact, I'd be +1 to that, given that we have two cases in recent
 memory where the artifact was not really even usable as an alpha
 release.
 
 
 
 Joe
 
 --
 Joe Germuska
 [EMAIL PROTECTED]
 http://blog.germuska.com
 In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
 back; I'll know I'm in the wrong place.
 - Carlos Santana


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



Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread James Mitchell
Well, whatever you guys decide is fine with me.  I don't care which path we
take.  I am just trying to help out when and where I can.

Let me know if I need to change something (mail, wiki, whatever).



--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Monday, October 18, 2004 3:06 PM
Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce]
Release of Struts 1.2.5 (beta))


 At 10:55 AM -0700 10/18/04, Martin Cooper wrote:
 The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as
 it should be - we want releases to be quality builds.
 
 What I feel very strongly about is that nothing should be called a
 Release until we vote on it, especially since I believe this is an ASF
 requirement. We have said that anyone can build a Test Build (e.g.
 1.2.x) at any time, and that's fine. But I don't want to see such a
 build viewed as a Release by the community if the developers / PMC
 haven't sanctioned it by a vote.

 I think ultimately we agree even more than I realized, since, looking
 back at how you describe these events, I realize that my main concern
 - version number confusion - is not at issue.

 I simply think of anything with a version number as a release.  I'm
 happy to change that and to describe the first output of the release
 process as a test build instead of an alpha release.

 In fact, I'd be +1 to that, given that we have two cases in recent
 memory where the artifact was not really even usable as an alpha
 release.

 Joe

 --
 Joe Germuska
 [EMAIL PROTECTED]
 http://blog.germuska.com
 In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
 back; I'll know I'm in the wrong place.
 - Carlos Santana



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



Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Ted Husted
How about if we follow the HTTPD protocol but replace the term

Alpha Release

with

Alpha Build

and then refer to a distribution when we could be talking about a Alpha Build or 
Beta Release or GA Release.

* http://httpd.apache.org/dev/release.html

And, yes, I would agree that there should be one release protocol for the project, 
which all subprojects, including the core, would follow.

-Ted.


On Mon, 18 Oct 2004 12:25:32 -0700, Craig McClanahan wrote:
 +1 on the test build then vote to rank approach that Tomcat uses.

 As an additional clarification, I presume that we will want the
 same release process for any subproject releases?  This is becoming
 timely as the opportunity for a 1.0.1 release of struts-faces draws
 nigh.  It might be worth mentioning this in the release guidelines
 as well, including the explicit requirement that any release vote
 involve the entire committer community (with PMC votes binding, as
 usual) -- not just the developers who might happen to be working on
 that subproject. After all, the subprojects will still say Struts
 on them, and we're all going to care about that reputation.

 Craig


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



Re: He's baaaaaack....

2004-10-18 Thread Eddie Bush
Yes, it's me.  Thank you, sir! :-)
I wasn't as thoughtful as James.  I guess I figured the only thing one 
needed to do to return from emeritus status was to become active again.  I 
too would appreciate the opportunity though.

Many of you are aware I left after having some personal issues pop up.  I 
had to go off and find myself again.  I beleive I've done that - and it 
feels good! :-)

Anyhoo .. yeah, I've been sinking my teeth in and looking for things to do. 
My time is a lot more limited than it used to be, but I'm anxious to become 
re-involved if you all would be so gracious as to allow it :-)

I've been working on getting my environment setup for proper development 
here at the house.  I had to bury my Linux box (which is where i used to do 
all my java development) and am still muddling through getting my XP box 
setup to my liking.  That, reviewing the (many!) changes that have 
transpired in my absence, and trying to figure out what I can do to 
contribute are keeping me busy in my down time.  I look forward to 
replacing my Linux box in the future, but, for now, it's simply not 
feasible.

Yep ... that be me, James :-)  Nice to be welcomed and good to be around.
- Original Message - 
From: James Mitchell [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Monday, October 18, 2004 2:23 PM
Subject: Re: He's baack


Welcome back!!!
I also noticed a few posts recently by another missing soulMr. Eddie
Bush.  Could that be the same Eddie that was once an active contributor to
the Struts community?  If so, then welcome back to you as well!!

--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- Original Message -
From: James Turner [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Monday, October 18, 2004 3:15 PM
Subject: He's baack

Hi gang,
   I know it's been a while, but I wanted to let you know that I've sent
my Apache 2.0 agreement to the magic fax, and assuming it's possible to
return from emeritus status, I'd like to come back to the fold.
   The last year or so, I had to concentrate on feeding the family in a
down econonmy, but now I've landed in a stable job (a couple of them,
actually), and I'll have some time to put into the greater Struts
collective again.
So, if you'll have me, I'm back.
James
-
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]


---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0442-3, 10/15/2004
Tested on: 10/18/2004 6:37:06 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com

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


Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))

2004-10-18 Thread Eddie Bush
When you say test build, do you mean alpha release?  The two terms are 
synonymous in my mind, so voting on an alpha isn't something I'd ever think 
of as that's what I view the nightly builds to be.

I do believe we should be voting on Beta and up though.  Beta should 
(hopefully) be bug-free -- a build we anticipate to be the major release. 
Perhaps my thinking is flawed :-)

- Original Message - 
From: Craig McClanahan [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Monday, October 18, 2004 2:25 PM
Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] 
Release of Struts 1.2.5 (beta))


+1 on the test build then vote to rank approach that Tomcat uses.
As an additional clarification, I presume that we will want the same
release process for any subproject releases?  This is becoming timely
as the opportunity for a 1.0.1 release of struts-faces draws nigh.  It
might be worth mentioning this in the release guidelines as well,
including the explicit requirement that any release vote involve the
entire committer community (with PMC votes binding, as usual) -- not
just the developers who might happen to be working on that subproject.
After all, the subprojects will still say Struts on them, and we're
all going to care about that reputation.
Craig
On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote:
At 10:55 AM -0700 10/18/04, Martin Cooper wrote:
The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as
it should be - we want releases to be quality builds.

What I feel very strongly about is that nothing should be called a
Release until we vote on it, especially since I believe this is an ASF
requirement. We have said that anyone can build a Test Build (e.g.
1.2.x) at any time, and that's fine. But I don't want to see such a
build viewed as a Release by the community if the developers / PMC
haven't sanctioned it by a vote.
I think ultimately we agree even more than I realized, since, looking
back at how you describe these events, I realize that my main concern
- version number confusion - is not at issue.
I simply think of anything with a version number as a release.  I'm
happy to change that and to describe the first output of the release
process as a test build instead of an alpha release.
In fact, I'd be +1 to that, given that we have two cases in recent
memory where the artifact was not really even usable as an alpha
release.

Joe 

---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0442-3, 10/15/2004
Tested on: 10/18/2004 6:39:44 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com

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