[EMAIL PROTECTED]: Project struts-tiles (in module struts) failed

2005-09-27 Thread Stefan Bodewig 
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-tiles has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- struts-tiles :  Model 2 Model-View-Controller framework for Servlets and 
JSP


Full details are available at:
http://vmgump.apache.org/gump/public/struts/struts-tiles/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [struts-tiles-27092005.jar] identifier set to project name
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/struts/tiles/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /usr/local/gump/public/workspace/struts/tiles/project.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/struts/struts-tiles/gump_work/build_struts_struts-tiles.html
Work Name: build_struts_struts-tiles (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/struts/tiles]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/struts/tiles/target/classes:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-27092005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/struts/core/dist/struts-core-27092005.jar
-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

You are working offline so the build will continue, but 
commons-validator-SNAPSHOT.jar may be out of date!
The build cannot continue because of the following unsatisfied dependency:

maven-taglib-plugin-1.4.jar (try downloading from 
http://maven-taglib.sourceforge.net)

Total time: 2 seconds
Finished at: Tue Sep 27 04:38:36 PDT 2005

-

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/struts/struts-tiles/rss.xml
- Atom: http://vmgump.apache.org/gump/public/struts/struts-tiles/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2127092005, vmgump.apache.org:vmgump-public:2127092005
Gump E-mail Identifier (unique within run) #32.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

[EMAIL PROTECTED]: Project struts-tiles (in module struts) failed

2005-09-27 Thread Stefan Bodewig 
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project struts-tiles has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- struts-tiles :  Model 2 Model-View-Controller framework for Servlets and 
JSP


Full details are available at:
http://vmgump.apache.org/gump/public/struts/struts-tiles/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [struts-tiles-27092005.jar] identifier set to project name
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/struts/tiles/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /usr/local/gump/public/workspace/struts/tiles/project.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/struts/struts-tiles/gump_work/build_struts_struts-tiles.html
Work Name: build_struts_struts-tiles (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/struts/tiles]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/struts/tiles/target/classes:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-27092005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/struts/core/dist/struts-core-27092005.jar
-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

You are working offline so the build will continue, but 
commons-validator-SNAPSHOT.jar may be out of date!
The build cannot continue because of the following unsatisfied dependency:

maven-taglib-plugin-1.4.jar (try downloading from 
http://maven-taglib.sourceforge.net)

Total time: 2 seconds
Finished at: Tue Sep 27 04:38:36 PDT 2005

-

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/struts/struts-tiles/rss.xml
- Atom: http://vmgump.apache.org/gump/public/struts/struts-tiles/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2127092005, vmgump.apache.org:vmgump-public:2127092005
Gump E-mail Identifier (unique within run) #32.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

svn commit: r291918 - in /struts/core/trunk/xdocs: index.xml learning.xml milestones.xml userGuide/building_controller.xml userGuide/preface.xml

2005-09-27 Thread husted 
Author: husted
Date: Tue Sep 27 05:01:56 2005
New Revision: 291918

URL: http://svn.apache.org/viewcvs?rev=291918&view=rev
Log:
Per suggestions made by Christian Meder
* fix Jakarta-style href's that used "./" for relative references. 
* substitute Struts with Core or Struts Core as appropriate
* minor grammatical changes
* remove MailReader caveat, since we are fixing it
* replace some tabs with space characters, per our guidelines
* update DTD references to 1.3
Note that the Controller page needs additional work to cover the Struts Chain 
Request Processor

Modified:
struts/core/trunk/xdocs/index.xml
struts/core/trunk/xdocs/learning.xml
struts/core/trunk/xdocs/milestones.xml
struts/core/trunk/xdocs/userGuide/building_controller.xml
struts/core/trunk/xdocs/userGuide/preface.xml

Modified: struts/core/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/xdocs/index.xml?rev=291918&r1=291917&r2=291918&view=diff
==
--- struts/core/trunk/xdocs/index.xml (original)
+++ struts/core/trunk/xdocs/index.xml Tue Sep 27 05:01:56 2005
@@ -40,7 +40,7 @@
 http://db.apache.org/ojb/";>Object Relational Bridge.
 For the View, Core works well with
 http://java.sun.com/products/jsp/";>JavaServer Pages,
-including JSTL and JSF,
+including JSTL and JSF,
 as well as
 http://jakarta.apache.org/velocity/tools/struts/";>Velocity 
Templates,
 http://stxx.sourceforge.net/";>XSLT,
@@ -119,8 +119,8 @@
 ]]>
 
 
-There are several other resources you can specify in an Apache
-Struts configuration file.
+There are several other resources you can specify in an Struts
+Core configuration file.
 You can specify validations for the ActionForms in an XML descriptor,
 using the Struts Validator.
 A standard extension, Tiles,
@@ -135,7 +135,7 @@
 set-property feature.
 This is one reason why there are so many
 http://wiki.apache.org/struts/StrutsResources/";>contributor
-extensions for Struts.
+extensions for Struts Core.
 Core provides a base framework, but you can still write your
 application your way.
  
@@ -161,7 +161,7 @@
 But, if you are writing a more complicated application,
 with dozens of pages,
 that need to be maintained over time, then Struts Core can help.
-For more about whether Model 1 or or MVC/Model 2 is right for you, see
+For more about whether Model 1 or MVC/Model 2 is right for you, see
 http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html";>
 Understanding JavaServer Pages Model 2 architecture and
 http://www.scioworks.net/devnews/articles/struts_adoption_issues/index.html";>

Modified: struts/core/trunk/xdocs/learning.xml
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/xdocs/learning.xml?rev=291918&r1=291917&r2=291918&view=diff
==
--- struts/core/trunk/xdocs/learning.xml (original)
+++ struts/core/trunk/xdocs/learning.xml Tue Sep 27 05:01:56 2005
@@ -94,12 +94,12 @@
 
 
 
-The Kickstart FAQ
+The Kickstart FAQ
 answers the most common non-technical questions
 people first ask about Struts Core.
 
 
-The Struts Core Newbie FAQ
+The Struts Core Newbie FAQ
 answers the most common technical questions asked by first-timer
 Struts Core developers.
 

Modified: struts/core/trunk/xdocs/milestones.xml
URL: 
http://svn.apache.org/viewcvs/struts/core/trunk/xdocs/milestones.xml?rev=291918&r1=291917&r2=291918&view=diff
==
--- struts/core/trunk/xdocs/milestones.xml (original)
+++ struts/core/trunk/xdocs/milestones.xml Tue Sep 27 05:01:56 2005
@@ -96,39 +96,39 @@
 
 Move to Commons Resources (if available)
 
-   
+
 (TODO) Add a Ant-style properties file to make
 variable substitutions within the XML elements,
 as found in iBATIS and Spring.
 
-   
+
 (Pending) Bundle subproject GA releases into
 Linux-style  distributions
 (Struts Classic 1.3.0 = (Core 1.3.x + Taglibs 1.3.x +
 Extras 1.3.x))
 
 
-   
-   Experimental members (TODO)
-   
-   
-   
+
+Experimental

Re: [1/5] Minor fixes for Struts Core documentation

2005-09-27 Thread Ted Husted 
These were helpful, but it's better to attach patches to Bugzilla
tickets, since patches rarely survive passing through mail clients any
more.

I did make the changes indicated, with the exception of some of the
indentation changes. Since the changes are peer reviewed, potentially
by hundreds of people, we try to minimize unecessary change. I do
agree we need to fix such things, but we should try to do that either
while we are fixing something else that would affect that line, or in
a separate commit that does nothing but make formatting changes,
without changing any of the content whatsoever.

Thanks, again, Christian.

-Ted.

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

Re: [EMAIL PROTECTED]: Project struts-tiles (in module struts) failed

2005-09-27 Thread James Mitchell 
Not sure why Gump runs in offline mode.  The missing dependency is on  
ibiblio and the build works fine for me otherwise.


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
Yahoo: jmitchtx
MSN:   [EMAIL PROTECTED]
Skype: callto://jmitchtx





On Sep 27, 2005, at 7:38 AM, Stefan Bodewig wrote:


To whom it may engage...

This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]

Project struts-tiles has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build  
Failed'.

For reference only, the following projects are affected by this:
- struts-tiles :  Model 2 Model-View-Controller framework for  
Servlets and JSP



Full details are available at:
http://vmgump.apache.org/gump/public/struts/struts-tiles/ 
index.html


That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error  
messages) were provided:
 -DEBUG- Sole output [struts-tiles-27092005.jar] identifier set to  
project name
 -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/ 
public/workspace/struts/tiles/build.properties

 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /usr/local/gump/public/workspace/struts/ 
tiles/project.xml

 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/struts/struts-tiles/gump_work/ 
build_struts_struts-tiles.html

Work Name: build_struts_struts-tiles (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: maven --offline jar
[Working Directory: /usr/local/gump/public/workspace/struts/tiles]
CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/ 
workspace/struts/tiles/target/classes:/usr/local/gump/public/ 
workspace/jakarta-commons/beanutils/dist/commons-beanutils- 
core.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/ 
target/commons-chain-27092005.jar:/usr/local/gump/public/workspace/ 
jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/ 
public/workspace/jakarta-commons/fileupload/target/commons- 
fileupload-27092005.jar:/usr/local/gump/public/workspace/jakarta- 
commons/logging/dist/commons-logging-27092005.jar:/usr/local/gump/ 
public/workspace/jakarta-commons/logging/dist/commons-logging- 
api-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/ 
validator/dist/commons-validator.jar:/usr/local/gump/public/ 
workspace/jakarta-oro/jakarta-oro-27092005.jar:/usr/local/gump/ 
public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/ 
gump/public/workspace/struts/core/dist/struts-core-27092005.jar

-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

You are working offline so the build will continue, but commons- 
validator-SNAPSHOT.jar may be out of date!
The build cannot continue because of the following unsatisfied  
dependency:


maven-taglib-plugin-1.4.jar (try downloading from http://maven- 
taglib.sourceforge.net)


Total time: 2 seconds
Finished at: Tue Sep 27 04:38:36 PDT 2005

-

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/struts/struts-tiles/ 
rss.xml
- Atom: http://vmgump.apache.org/gump/public/struts/struts-tiles/ 
atom.xml


== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2127092005, vmgump.apache.org:vmgump-public: 
2127092005

Gump E-mail Identifier (unique within run) #32.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

DO NOT REPLY [Bug 35066] - [shale] Serious issue with dialog state

2005-09-27 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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





--- Additional Comments From [EMAIL PROTECTED]  2005-09-27 15:39 ---
A few more thoughts on my proposed solution.  Rather than using the dialog name,
I am thinking the dialogs and their transitions should be identifiable according
to "context" (or perhaps scope, thread, track or some other word that describes
the concept.)  So basically if you want to have two or more dialogs running at
the same time, you just initiate one with dialog:FooStep and the other with
dialog2:BarStep.  

DialogNavigationHandler will assume anything before the ":" refers to a
particular dialog scope (I know scope isn't the right word exactly but its the
best I can do for now.)  This doesn't rule out using regular faces navigation
rules with a ":" in them, if there is no such dialog then navigation will be
delegated.  This way dialog positions can be stored in a map with this scope
name as the key.  You can also clear the status/position information
automatically when launching a dialog (in case the dialog was a popup and the
dialog was terminated by closing the window.)

BTW, there is yet another use case the fails with this bug.  In the current code
its impossible to have a sortable table in your dialog b/c all navigation is
assumed to be related to dialog transitions.

-- 
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: [EMAIL PROTECTED]: Project struts-tiles (in module struts) failed

2005-09-27 Thread Niall Pemberton 
Gump doesn't download dependencies:

http://gump.apache.org/metadata/builder.html#maven

The taglib plugin needs adding to gump repository - I've added the metadata
bit and pinged the gump list asking for someone with the appropriate
permissions to add the jar

Niall

- Original Message - 
From: "James Mitchell" <[EMAIL PROTECTED]>
Sent: Tuesday, September 27, 2005 1:46 PM


> Not sure why Gump runs in offline mode.  The missing dependency is on
> ibiblio and the build works fine for me otherwise.
>
>
> On Sep 27, 2005, at 7:38 AM, Stefan Bodewig wrote:
>
> > To whom it may engage...
> >
> > This is an automated request, but not an unsolicited one. For
> > more information please visit http://gump.apache.org/nagged.html,
> > and/or contact the folk at [EMAIL PROTECTED]
> >
> > Project struts-tiles has an issue affecting its community integration.
> > This issue affects 1 projects,
> >  and has been outstanding for 4 runs.
> > The current state of this project is 'Failed', with reason 'Build
> > Failed'.
> > For reference only, the following projects are affected by this:
> > - struts-tiles :  Model 2 Model-View-Controller framework for
> > Servlets and JSP
> >
> >
> > Full details are available at:
> > http://vmgump.apache.org/gump/public/struts/struts-tiles/
> > index.html
> >
> > That said, some information snippets are provided here.
> >
> > The following annotations (debug/informational/warning/error
> > messages) were provided:
> >  -DEBUG- Sole output [struts-tiles-27092005.jar] identifier set to
> > project name
> >  -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/
> > public/workspace/struts/tiles/build.properties
> >  -INFO- Failed with reason build failed
> >  -DEBUG- Maven POM in: /usr/local/gump/public/workspace/struts/
> > tiles/project.xml
> >  -INFO- Failed to extract fallback artifacts from Gump Repository
> >
> >
> >
> > The following work was performed:
> > http://vmgump.apache.org/gump/public/struts/struts-tiles/gump_work/
> > build_struts_struts-tiles.html
> > Work Name: build_struts_struts-tiles (Type: Build)
> > Work ended in a state of : Failed
> > Elapsed: 3 secs
> > Command Line: maven --offline jar
> > [Working Directory: /usr/local/gump/public/workspace/struts/tiles]
> > CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/
> > workspace/struts/tiles/target/classes:/usr/local/gump/public/
> > workspace/jakarta-commons/beanutils/dist/commons-beanutils-
> > core.jar:/usr/local/gump/public/workspace/jakarta-commons/chain/
> > target/commons-chain-27092005.jar:/usr/local/gump/public/workspace/
> > jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/
> > public/workspace/jakarta-commons/fileupload/target/commons-
> > fileupload-27092005.jar:/usr/local/gump/public/workspace/jakarta-
> > commons/logging/dist/commons-logging-27092005.jar:/usr/local/gump/
> > public/workspace/jakarta-commons/logging/dist/commons-logging-
> > api-27092005.jar:/usr/local/gump/public/workspace/jakarta-commons/
> > validator/dist/commons-validator.jar:/usr/local/gump/public/
> > workspace/jakarta-oro/jakarta-oro-27092005.jar:/usr/local/gump/
> > public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/
> > gump/public/workspace/struts/core/dist/struts-core-27092005.jar
> > -
> >  __  __
> > |  \/  |__ _Apache__ ___
> > | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
> > |_|  |_\__,_|\_/\___|_||_|  v. 1.0.2
> >
> > You are working offline so the build will continue, but commons-
> > validator-SNAPSHOT.jar may be out of date!
> > The build cannot continue because of the following unsatisfied
> > dependency:
> >
> > maven-taglib-plugin-1.4.jar (try downloading from http://maven-
> > taglib.sourceforge.net)
> >
> > Total time: 2 seconds
> > Finished at: Tue Sep 27 04:38:36 PDT 2005
> >
> > -
> >
> > To subscribe to this information via syndicated feeds:
> > - RSS: http://vmgump.apache.org/gump/public/struts/struts-tiles/
> > rss.xml
> > - Atom: http://vmgump.apache.org/gump/public/struts/struts-tiles/
> > atom.xml



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

Re: [shale] class type of #{dialog.data} contents

2005-09-27 Thread Sean Schofield 
Just a quick update:  The RI works perfectly with my code so I think I
have interpreted the spec correctly.  I working on a fix in MyFaces
but its slow going due to my unfamiliarity with the EL implementation.

sean

On 9/26/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
>
> On 9/26/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > Craig,
> >
> > I am using a explicity defined converter and everything is converting
> > fine through the Process Validations phase.  Its during Update Model
> > phase that things go funky.  Converters don't matter at this point do
> > they?
>
>  No ... by that time, the converted value will have been stored with
> setLocalValue(), which  should be of the appropriate data type to be stored
> during Update Model Values.
>
> > I think there might be a bug in MyFaces
> > ( http://issues.apache.org/jira/browse/MYFACES-623).
> When I examined
> > the ValueBindingImpl using my debugger it showed that it was
> > specifically trying to coerce the value to class associated with
> > java.lang.String .
>
>  Hmm ... what does the RI do?
>
> > It looks like PropertyResolverImpl in MyFaces is checking if
> > StatusImpl is an instanceof Map when it should be checking the result
> > of StatusImpl.getData().  If it were checking the right object then
> > we'd be ok (because the class that it tries to coerce to is the
> > object's class.)
>
>  Yah, the base object should be of type StatusImpl for the *first* property
> resolution (dialog.data) but not for the second (data['foo']).
>
> > sean
>
>  Craig
>
>

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

Re: Nightly builds - Status

2005-09-27 Thread James Mitchell 
Ok, I've been monitoring the nightlies for a few days now and it  
looks to be completely hands off and it all happens on Apache  
hardware.  I also made sure that all configuration for doing the  
nightlies are included either as files (nightly.sh) or as  
configuration (cron job config), so in a worse case scenario, we can  
be back up at a moments notice.


Next, I want to bring in the site generation for both 1.2.x and head.

I am planning to deploy the generated site over cvs.apache.org:/www/ 
struts.apache.org/  which means our existing web site will never be  
more than 24 hours old.


If we don't want to do that, I could put together something like a  
web console hosted on struts.zones.apache.org that we can use to kick  
off an update.or some kind of hook so that when a commit is made  
to the documentation, a process is queued to regenerate and deploy a  
new site after 4 hours.


I would also like to build in email notification if the nightly and/ 
or site generation fails like Gump gives us.  The only issue with  
relying on Gump is that Gump does not build all of what the nightlies  
build, especially documentation.


Your thoughts?


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
Yahoo: jmitchtx
MSN:   [EMAIL PROTECTED]
Skype: callto://jmitchtx





On Sep 24, 2005, at 1:29 AM, James Mitchell wrote:

Ok, that's what I needed.  I'll see if I can pull it all together.   
Thanks


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
Yahoo: jmitchtx
MSN:   [EMAIL PROTECTED]
Skype: callto://jmitchtx





On Sep 24, 2005, at 12:09 AM, Wendy Smoak wrote:



From: "James Mitchell" <[EMAIL PROTECTED]>



BTW -- Can you tell me (wiki, mail-archive, etc) where to get  
the  latest instructions to build the web site and documentation  
and how  we want it laid out?  I'm getting ready to add that task  
to the  nightly build and I don't want to do it wrong.





I haven't been able to get Maven to build a recursive multiproject  
site.  It either loops, or refuses to descend.  Here's what I have:


echo "-- build multiproject site (head) --"
cd /cygdrive/e/svn/struts/current/site/
maven multiproject:site > /path/to/build.log

echo "-- build multiproject site (head - Shale) --"
cd /cygdrive/e/svn/struts/current/shale/build
maven multiproject:site >> /path/to/build.log
cp -r target/docs/* ../../site/target/docs/shale

echo "-- build multiproject site (head - Sandbox) --"
cd /cygdrive/e/svn/struts/current/sandbox/
maven multiproject:site >> /path/to/build.log
cp -r target/docs/* ../site/target/docs/struts-sandbox

If you have a multiproject site for Ti, then you'd do the same  
thing, and copy it up to sandbox/target/docs/struts-ti before you  
copy the whole of sandbox/target/docs over to 'site'.  Or maybe  
you can get Maven to cooperate. :)


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

[test] do not answer

2005-09-27 Thread Matthias Wessendorf 
Just a ping...

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

Re: Nightly builds - Status

2005-09-27 Thread Wendy Smoak 

From: "James Mitchell" <[EMAIL PROTECTED]>

I am planning to deploy the generated site over cvs.apache.org:/www/ 
struts.apache.org/  which means our existing web site will never be  more 
than 24 hours old.


I don't see a link to the 1.2.7 docs in site/xdocs/navigation.xml.  I 
remember some discussion of what URL to use for the docs for prior versions, 
and Ted had a suggestion which sounded fine at the time, but I can't find 
the message in the archives.


--
Wendy 



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

svn commit: r292079 - /struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties

2005-09-27 Thread gvanmatre 
Author: gvanmatre
Date: Tue Sep 27 18:06:21 2005
New Revision: 292079

URL: http://svn.apache.org/viewcvs?rev=292079&view=rev
Log:
Fixed Typo.

Modified:

struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties

Modified: 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties?rev=292079&r1=292078&r2=292079&view=diff
==
--- 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties 
(original)
+++ 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties 
Tue Sep 27 18:06:21 2005
@@ -132,5 +132,5 @@
 
 #org.apache.shale.clay.utils.ClayAmalgam
 missing.attribute=The "{0}" attribute is required when using the 
ClayAmalgam.{1}() validator method binding event.
-invalid.binding=Invalid use of the Amalgam.{0}() validator method binding 
event.  This method assume the use of the Clay component's "shapeValidator" 
property binding.
+invalid.binding=Invalid use of the ClayAmalgam.{0}() validator method binding 
event.  This method assume the use of the Clay component's "shapeValidator" 
property binding.
 invalid.attribute=The "{0}" attribute is required when using the 
ClayAmalgam.{1}() validator method binding event.



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

DO NOT REPLY [Bug 33064] - [taglib] Struts tags must check attribute values using isEmpty(), not against nulls

2005-09-27 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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





--- Additional Comments From [EMAIL PROTECTED]  2005-09-28 04:39 ---
Created an attachment (id=16541)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16541&action=view)
First-pass at one approach to addressing this issue

This is a patch which updates all tag attribute setters to 'normalize' empty
values to null, as one approach to resolving this issue.

NOTE: this is *not* intended to be a final, ready-to-apply patch but rather as
a vehicle for further discussion. It includes some annotations (comments marked
'[lh]') pointing out some issues to be resolved.

The alternative approach, preserving attribute values as set and changing
checks for null to checks for null-or-empty will follow as a second, alternate
patch for comparison.

-- 
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: Wrapping Struts tags in tag files

2005-09-27 Thread Laurie Harper 

Firstly, sorry for taking so long with this...

I just uploaded installment 1, showing the 'normalize attribute values 
when set' approach [1]. The patch doesn't address configuring the 
behaviour, but it does demonstrate what I was talking about. I forgot to 
mention in the attachment comments on the ticket, but the patch is also 
only for the HTML taglib. I'll widen the scope to include the other 
taglibs once we agree which approach to use.


Putting the patch together, I tried to consider on a case-by-case 
(attribute-by-attribute) basis whether trim()'ing whitespace was 
appropriate (i.e. whether to treat whitespace-only and empty values 
equivalently). Although Nial mentioned having had reports of problems 
due to whitespace trimming, I only found a few cases where it seemed 
like it would matter.


Specifically, alt, title and longdesc (where some browsers or other user 
agents will behave differently if the attribute appears with an empty 
value vs. if it is missing) and  value (where the user may very well 
want to distinguish emtpy-string and whitespace-only values) were the 
only attributes I ended up *not* trim()'ing.


These attributes do present a problem for this patch: since 
empty/whitespace values need to be preserved, the normalize-on-set 
approach falls down. Specifically, cases like altKey=${y} ...> will still fail even if 'y' is non-empty even if 'x' 
*is* emtpy. That may be an argument for the alternate approach discussed.


I'll put together a patch showing the other approach next, but comments 
on this one are welcome. In particular, I left some annotations (marked 
'[lh]' in the patch) that may be worth additional review.


L.

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=33064

Laurie Harper wrote:

Ted Husted wrote:


Basically, I'm suggesting making more changes now (though still very
minor ones, just pervasively) to (a) ensure the code adheres to the DRY
principle, (b) reduce the chance of the changes being incomplete
(through missing checks that would need to be updated with approach 1)
and (c) reduces the chance of future mistakes creeping in.



I don't understand how the second approach furthers (a) and (c).
(a) It sounds like we would be repeating the same checks in every
accessor rather "saying it once" in a shared method in a base class.

(c) With the second approach, a very common mistake might be to
neglect applying the conversion or to apply conversions
inconsistently.

As to (b), I'd think that the first approach does imply the same level
of code review you'd make with the second approach, even if we would
be changing fewer lines of code.

IMHO, the preferred approach would be the one that combined ease of
maintenance for the development team and ease of modifcation for
individual users. That sounds like the first approach to me, since it
would seem that we would centralize our expectations for the
attribute's characteristics: null or empty, trimmed or verbatim. We
would have one point of access to maintain, and individual users would
have one point of access to modify.



Yep, that's what I was going for, I perhaps didn't explain my thinking 
clearly though. What I was thinking was to make each setter read 
something like this:


  public void setFoo(String value) {
this.value = TagUtils.getInstance().normalize(value);
  }

where normalize() would be something like

  public static String normalize(String value) {
if (value == null || "".equals(value)) {
  return null;
}
return value;
  }

In cases where an attribute shouldn't be 'normalized' the setter can 
include a clear comment to that effect and not call the utility routine. 
Existing checks for whether attributes have a null value would remain 
unchanged.


The alternative I listed as approach 1 would be to leave the attribute 
setters alone and make the call to normalize() or equivalent everywhere 
each attribute value is checked, which is the bit I see as error-prone.


The assertion that this approach would lead to less code review was 
based on the fact that any existing checks for 'null' would remain 
unchanged and it therefore wouldn't be necessary to review the entire 
taglib codebase looking for checks that should have been updated in a 
patch but weren't.


Of course we still have to ensure that normalization makes sense on an 
attribute-by-attribute basis, so maybe it's a moot point. Also, calling 
normalize() from the setters may not work well if the switch to control 
this behaviour was specified as a tag attribute; I hadn't thought of 
that before...



Whether to return empty or null strings *is* an important issue. To
streamline our business logic, my own team has to convert the empty
strings to null sometimes. Though, in other cases, we do want an empty
string to pass through, since the property might correspond to a field
on the database that doesn't accept nulls, but does accept empty
strings. We could adjust our interface between the presentation and
applicatio

Re: Wrapping Struts tags in tag files

2005-09-27 Thread Laurie Harper 
Oops, also forgot to mention: this patch causes 4 cactus tests to fail, 
all due to the  tag rendering an empty 'name' attribute in 
the existing source (i.e. without the patch applied). I believe that 
ought to be considered an existing bug, since no other tags do that.


Otherwise, all tests pass as before. It's also on my to-do list to put 
together new tests asserting the desired behavious, which should be the 
same however it's achieved.


L.

Laurie Harper wrote:

Firstly, sorry for taking so long with this...

I just uploaded installment 1, showing the 'normalize attribute values 
when set' approach [1]. The patch doesn't address configuring the 
behaviour, but it does demonstrate what I was talking about. I forgot to 
mention in the attachment comments on the ticket, but the patch is also 
only for the HTML taglib. I'll widen the scope to include the other 
taglibs once we agree which approach to use.


Putting the patch together, I tried to consider on a case-by-case 
(attribute-by-attribute) basis whether trim()'ing whitespace was 
appropriate (i.e. whether to treat whitespace-only and empty values 
equivalently). Although Nial mentioned having had reports of problems 
due to whitespace trimming, I only found a few cases where it seemed 
like it would matter.


Specifically, alt, title and longdesc (where some browsers or other user 
agents will behave differently if the attribute appears with an empty 
value vs. if it is missing) and  value (where the user may very well 
want to distinguish emtpy-string and whitespace-only values) were the 
only attributes I ended up *not* trim()'ing.


These attributes do present a problem for this patch: since 
empty/whitespace values need to be preserved, the normalize-on-set 
approach falls down. Specifically, cases like altKey=${y} ...> will still fail even if 'y' is non-empty even if 'x' 
*is* emtpy. That may be an argument for the alternate approach discussed.


I'll put together a patch showing the other approach next, but comments 
on this one are welcome. In particular, I left some annotations (marked 
'[lh]' in the patch) that may be worth additional review.


L.

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=33064

Laurie Harper wrote:


Ted Husted wrote:


Basically, I'm suggesting making more changes now (though still very
minor ones, just pervasively) to (a) ensure the code adheres to the DRY
principle, (b) reduce the chance of the changes being incomplete
(through missing checks that would need to be updated with approach 1)
and (c) reduces the chance of future mistakes creeping in.




I don't understand how the second approach furthers (a) and (c).
(a) It sounds like we would be repeating the same checks in every
accessor rather "saying it once" in a shared method in a base class.

(c) With the second approach, a very common mistake might be to
neglect applying the conversion or to apply conversions
inconsistently.

As to (b), I'd think that the first approach does imply the same level
of code review you'd make with the second approach, even if we would
be changing fewer lines of code.

IMHO, the preferred approach would be the one that combined ease of
maintenance for the development team and ease of modifcation for
individual users. That sounds like the first approach to me, since it
would seem that we would centralize our expectations for the
attribute's characteristics: null or empty, trimmed or verbatim. We
would have one point of access to maintain, and individual users would
have one point of access to modify.




Yep, that's what I was going for, I perhaps didn't explain my thinking 
clearly though. What I was thinking was to make each setter read 
something like this:


  public void setFoo(String value) {
this.value = TagUtils.getInstance().normalize(value);
  }

where normalize() would be something like

  public static String normalize(String value) {
if (value == null || "".equals(value)) {
  return null;
}
return value;
  }

In cases where an attribute shouldn't be 'normalized' the setter can 
include a clear comment to that effect and not call the utility 
routine. Existing checks for whether attributes have a null value 
would remain unchanged.


The alternative I listed as approach 1 would be to leave the attribute 
setters alone and make the call to normalize() or equivalent 
everywhere each attribute value is checked, which is the bit I see as 
error-prone.


The assertion that this approach would lead to less code review was 
based on the fact that any existing checks for 'null' would remain 
unchanged and it therefore wouldn't be necessary to review the entire 
taglib codebase looking for checks that should have been updated in a 
patch but weren't.


Of course we still have to ensure that normalization makes sense on an 
attribute-by-attribute basis, so maybe it's a moot point. Also, 
calling normalize() from the setters may not work well if the switch 
to control this behaviour was specified as