date:20060117

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=38298

   Summary: Enhancement to Shale Dialogs
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Shale
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]


As discussed on struts-dev list, here is an enhancement request to init dialogs
by a programmatic way.

Here is my email to struts-dev:

Is it possible to a login page (w/ j_security) and after sucessfull login do
*forward* to my "Go" dialog?

Or do I have to provide a "hello press that button" pages  (e.g.
)
*after* a user logs into that application?

-Matthias

-- 
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 38298] - Enhancement to Shale Dialogs

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=38298





--- Additional Comments From [EMAIL PROTECTED]  2006-01-17 09:20 ---
Here is the archived email thread

http://www.mail-archive.com/dev@struts.apache.org/msg16942.html



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

svn commit: r369764 - in /struts/action/trunk: ./ conf/java/ src/java/org/apache/struts/action/ src/java/org/apache/struts/config/ src/java/org/apache/struts/util/ src/test/org/apache/struts/action/ x

2006-01-17 Thread wsmoak

Author: wsmoak
Date: Tue Jan 17 04:26:20 2006
New Revision: 369764

URL: http://svn.apache.org/viewcvs?rev=369764&view=rev
Log:
Removed CGLIB enhancement.
May be re-added when Bug# 37730 ("Enhanced DynaActionForms cannot be correctly 
deserialized") is resolved.

Removed:
struts/action/trunk/src/java/org/apache/struts/util/DynaBeanInterceptor.java

struts/action/trunk/src/test/org/apache/struts/action/TestCGLibDynaActionForm.java
Modified:
struts/action/trunk/conf/java/struts-config_1_3.dtd
struts/action/trunk/pom.xml
struts/action/trunk/project.xml

struts/action/trunk/src/java/org/apache/struts/action/DynaActionFormClass.java
struts/action/trunk/src/java/org/apache/struts/config/FormBeanConfig.java

struts/action/trunk/src/test/org/apache/struts/action/TestDynaActionFormClass.java
struts/action/trunk/xdocs/userGuide/building_controller.xml
struts/action/trunk/xdocs/userGuide/release-notes.xml

Modified: struts/action/trunk/conf/java/struts-config_1_3.dtd
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/conf/java/struts-config_1_3.dtd?rev=369764&r1=369763&r2=369764&view=diff
==
--- struts/action/trunk/conf/java/struts-config_1_3.dtd (original)
+++ struts/action/trunk/conf/java/struts-config_1_3.dtd Tue Jan 17 04:26:20 2006
@@ -126,12 +126,7 @@
  typeFully qualified Java class name of the ActionForm subclass
  to use with this form bean.
  
- enhancedFlag indicating if the form bean should be dynamically
- enhanced to include getters and setters for defined
- properties. This is only valid when 'type' is a
- dynamic form bean (an instance of 
- "org.apache.struts.action.DynaActionForm" or a sub-class,
- and requires CGLIB when enabled.
+ enhancedReserved for future use.
 -->
 
 

Modified: struts/action/trunk/pom.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/pom.xml?rev=369764&r1=369763&r2=369764&view=diff
==
--- struts/action/trunk/pom.xml (original)
+++ struts/action/trunk/pom.xml Tue Jan 17 04:26:20 2006
@@ -123,12 +123,6 @@
  2.7.2
   
   
- cglib
- cglib-nodep
- 2.1_3
- true
-  
-  
  commons-beanutils
  commons-beanutils
  1.7.0

Modified: struts/action/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/project.xml?rev=369764&r1=369763&r2=369764&view=diff
==
--- struts/action/trunk/project.xml (original)
+++ struts/action/trunk/project.xml Tue Jan 17 04:26:20 2006
@@ -107,18 +107,6 @@
 
   
 
-  
-
-  cglib
-  cglib-nodep
-  2.1_3
-  http://cglib.sourceforge.net/
-  
-true
-  
-
-  
-
   
 src/java
 src/test

Modified: 
struts/action/trunk/src/java/org/apache/struts/action/DynaActionFormClass.java
URL: 
http://svn.apache.org/viewcvs/struts/action/trunk/src/java/org/apache/struts/action/DynaActionFormClass.java?rev=369764&r1=369763&r2=369764&view=diff
==
--- 
struts/action/trunk/src/java/org/apache/struts/action/DynaActionFormClass.java 
(original)
+++ 
struts/action/trunk/src/java/org/apache/struts/action/DynaActionFormClass.java 
Tue Jan 17 04:26:20 2006
@@ -23,7 +23,6 @@
 import java.io.Serializable;
 import java.util.HashMap;
 
-import net.sf.cglib.proxy.Enhancer;
 import org.apache.commons.beanutils.DynaBean;
 import org.apache.commons.beanutils.DynaClass;
 import org.apache.commons.beanutils.DynaProperty;
@@ -32,7 +31,6 @@
 import org.apache.struts.config.FormBeanConfig;
 import org.apache.struts.config.FormPropertyConfig;
 import org.apache.struts.util.RequestUtils;
-import org.apache.struts.util.DynaBeanInterceptor;
 
 
 /**
@@ -85,12 +83,6 @@
 
 
 /**
- * The CGLIB Enhancer which we will use to dynamically
- * add getters/setters if 'enhanced' is true in the form config.
- */
-protected transient Enhancer enhancer = null;
-
-/**
  * The form bean configuration information for this class.
  */
 protected FormBeanConfig config = null;
@@ -192,12 +184,7 @@
 public DynaBean newInstance()
 throws IllegalAccessException, InstantiationException {
 
-DynaActionForm dynaBean = null;
-if (config.isEnhanced()) {
-dynaBean = (DynaActionForm) getBeanEnhancer().create();
-} else {
-dynaBean = (DynaActionForm) getBeanClass().newInstance();
-}
+DynaActionForm dynaBean = (DynaActionForm) 
getBeanClass().newInstance();
 dynaBean.setDynaActionFormClass(this);
 FormPropertyConfig[] props = config.fin

DO NOT REPLY [Bug 37730] - Enhanced DynaActionForms cannot be correct deserialized

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=37730





--- Additional Comments From [EMAIL PROTECTED]  2006-01-17 13:30 ---
CGLIB enhancement has been removed from Struts Action until the problem with
serialization can be resolved.

Discussion thread:
   http://marc.theaimsgroup.com/?l=struts-dev&m=113747714213959&w=2

Revision:
   http://svn.apache.org/viewcvs?rev=369764&view=rev

-- 
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 "StrutsClassicRelease130" by WendySmoak

2006-01-17 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 WendySmoak:
http://wiki.apache.org/struts/StrutsClassicRelease130

The comment on the change is:
Removed CGLIB dependency; See Bug# 37730

--
  
  || '''Dependency''' || '''Version''' || '''Status''' ||'''Used In''' ||
  || Antlr || 2.7.2 || Released || Struts Validator ||
- || CGLib || 2.1_3 || Released || Action Framework - OPTIONAL ||
  || Commons !BeanUtils || 1.7.0 || Released || Action (!ActionServlet, 
configuration, !DynaActionForm) ||
  || Commons Chain || 1.0 || Released || core (!RequestProcessor) ||
  || Commons Digester || 1.6 || Released || Action (!ActionServlet, 
configuration) ||

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

DO NOT REPLY [Bug 37730] - Enhanced DynaActionForms cannot be correct deserialized

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=37730


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||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]

DO NOT REPLY [Bug 37301] - Allow dynamic interface implementation by ActionForms using CGLib

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=37301


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2006-01-17 13:42 ---
CGLIB enhancement has been removed from Struts Action due to Bug# 37730.  If
that issue (with serialization) is resolved, please feel free to reopen this.

-- 
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 "StrutsClassicRelease130" by WendySmoak

2006-01-17 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 WendySmoak:
http://wiki.apache.org/struts/StrutsClassicRelease130

The comment on the change is:
Updated bug status

--
  == Outstanding Bug Review ==
  
  || '''ID''' || '''Summary''' || '''Component''' || '''Status''' ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=25267 25267] || 
Mavenise Cactus tests || Taglib, EL || Problems in EL ||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=25267 25267] || 
Mavenise Cactus tests || Taglib, EL || (./) (later) ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=33132 33132] || 
[upload] org.apache.struts.upload.MultipartRequestWrapper...  || File Upload  
|| (./) FIXED ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35477 35477] || 
TagUtils.getActionMappingURL() does not consider "/*.do" ...  || Custom Tags  
|| (./) Added to FAQ ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35513 35513] || 
multiform validation  || Validator || (./) ||
@@ -88, +88 @@

  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35933 35933] || [apps] 
Source code missing from example apps  || Apps || (./) ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=35953 35953] || Remove 
deprecations prior to 1.3.0 release || All || (./) ||
  || [http://issues.apache.org/bugzilla/show_bug.cgi?id=36794 36794] || 
Document enhancement (Enhanced !DynaActionForm) || All || (./) ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=37301 37301] || 
Document enhancement (Allow dynamic interface implementation) || All || _ ||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=37301 37301] || 
Document enhancement (Allow dynamic interface implementation) || All || (./) 
(n/a) ||
- || [http://issues.apache.org/bugzilla/show_bug.cgi?id=37730 37730] || 
Enhanced !DynaActionForms cannot be correctly deserialized || All || _ ||
+ || [http://issues.apache.org/bugzilla/show_bug.cgi?id=37730 37730] || 
Enhanced !DynaActionForms cannot be correctly deserialized || All || (./) 
(removed) ||
  
  OTHER TODO
  
@@ -112, +112 @@

  
  || '''#''' || '''Description''' || '''Status''' ||
  || 1. || Announce plan to dev@ list; link from roadmap page || (./) ||
- || 2. || Review/Resolve Outstanding Bugs || _ || #37730 and #37301 TODO. 
#25267 - Problems with EL ||
+ || 2. || Review/Resolve Outstanding Bugs || (./) ||
- || 3. || Update Release Notes || _ || #37301 TODO. ||
+ || 3. || Update Release Notes || _ ||
  || 4. || Check Dependencies || (./) ||
  || 5. || Update to version 1.3.0 build.xml, project.xml, release-notes.xml, 
and the MANIFEST.MF || (./) ||
  

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

Re: 1.3.0 Release - Next Steps

2006-01-17 Thread Wendy Smoak

On 1/16/06, Ted Husted <[EMAIL PROTECTED]> wrote:

> Any new input on #37730?
>
> If we are not ready to resolve the serialization issue, then we should
> table this new feature for a subsequent release.

Done in r369764, see comments on Bug# 37730.

I resolved the CGLIB-related bugs and updated the release plan on the
Wiki.  25267 (Cactus test) is still open but will be dealt with later.

Thanks,
--
Wendy

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

Re: 1.3.0 Release - Next Steps

OK, I see by the commit and wiki logs that Wendy has done the deed,
and everything is checked that going to be checked :)

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

Since a multiproject relesae is still new ground, I'm thinking the
next step would be to assembly a prototype of what a 1.3.0 release
would look like, and post it to a home directory, for everyone to
review. Then, if appropriate, we can tag the repository, and release.

If there are no objections, tonight I can put together a prototype
release package.

-Ted.

On 1/17/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
> I hate to say it, but I'm not going to have time to work on fixing
> this in time for the 1.3 release. Wendy's suggestion (removing the
> feature for now) probably makes the most sense; I'll look at adding
> the serialization support and putting the enhanced form bean support
> into 'extras' post 1.3.0.
>
> L.

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

Re: Non-discussion emails

I'm not sure if I'd call those posts "non-discussion". We often have
discussions by commenting on bug tickets. Since we are "commit then
review", a commit log or wiki post is often the genesis of a
discussion about the change.

A commit or wiki event are not historical footnotes. These posts are a
request for a peer review of the change, and an implicit vote as to
whether the change should even take place. if someone is not following
these posts, then much of the activity on the project will be missed.
If a forum is going to be a replacement for the mailing lists, then
the forum must cover all the mailing lists, else forum followers will
be given a false sense of currency.

There is a separate commits@ list, and so it would be easy to setup a
separate forum for those. (But, again, we send out the commit logs so
that they can be reviewed, so there should be a forum for those too!) 
The wiki and issue-trackers are both subscribed directly to dev@, so
getting those into separate forums would be problematic, unless Jive
does filtering on its own.

I can't over-emphasize the vital importance of mailing lists to an ASF
project. We consider the mailing list to be our communal memory. If
something doesn't happen on the list, then it didn't happen.

For today, we want everything that you can know about a project to go
over the lists, so that the PMC and others can monitor everything that
happens on a project. For tomorrow, we want everything to go over the
lists, so that our successors can search the archives and see what we
already decided and why.

Every decision we make is in exactly one place: the mailing list archives.

I'm a big fan of Jive forums, and I think having forums for the
project lists is a Good Thing. But, the forums should cover all the
traffic, because all the traffic is there for a reason.

-Ted.

On 1/16/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
> I just realzied that the non-discussion emails (bugs, wiki, and commits) are 
> going in to the forums. The account that is subscribed is [EMAIL PROTECTED] 
> Is there any way we can disable those other emails to that account?
>
> -
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=14616&messageID=28683#28683

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

Re: 1.3.0 Release - Next Steps

2006-01-17 Thread Laurie Harper

I hate to say it, but I'm not going to have time to work on fixing  
this in time for the 1.3 release. Wendy's suggestion (removing the  
feature for now) probably makes the most sense; I'll look at adding  
the serialization support and putting the enhanced form bean support  
into 'extras' post 1.3.0.


L.

On 16-Jan-06, at 7:27 PM, Ted Husted wrote:


Any new input on #37730?

If we are not ready to resolve the serialization issue, then we should
table this new feature for a subsequent release.

-Ted.

On 1/13/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
Bug# 37301 looks like an enhancement request to me... I don't  
think it

should prevent a release.  So we just need to resolve Bug #37730
(serialization) one way or the other.  Laurie, any comments on all
this?


--
Laurie Harper
Open Source advocate, Java geek: http://www.holoweb.net/laurie
Founder, Zotech Software: http://www.zotechsoftware.com/




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

Re: 1.3.0 Release - Next Steps

> 25267 (Cactus test) is still open but will be dealt with later.

Yes, I'm thinking that it's the tests that are broken, rather than the code.

Having the cactus tests would be better, but it's better to release
without than not release.

We have been testing the code through the unit tests and example
applications, as well as real-life deployments. Carpe diem!

-Ted.

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

Non-discussion emails

Ted,
I'm sure you didn't mean it this way, but you seem to imply that I don't have 
any experience with this sort of stuff. I do.

We too at OpenSymphony use mailing lists quite heavily (as does every other 
decent open source project out there). However, as technologies like RSS have 
grown more popular, we adapted. Now we get our wiki changes and CVS changes 
through RSS (Confluence and FishEye both provide RSS feeds). We also offer the 
option of email messages, but that is up to the individual.

Conversations still continue around wiki changes and commits. For those that 
subscribe to the mailing lists, they simply forward the message to the dev 
list. For those that don't, they simply post a new message asking, "John, can 
you explain why you changed Foo.java yesterday?".

Try to understand where I'm coming from: the wiki and commit changes aren't 
interesting to me (I don't have time to look through any of them). Not just for 
Struts, but for WebWork too. Instead, I do weekly reviews. With Struts, I just 
delete those messages as they come in. And when I look at the forums:

http://forums.opensymphony.com/forum.jspa?forumID=34

I see "NO NOT REPLY" and "[Struts Wiki]", making it just as difficult for me to 
keep up with the other conversations. I didn't mean to imply that those 
messages sometime don't spur a conversation, but pragmatically 99% of the 
chatter I've seen does not come from them. 

I definitely understand where you are coming from, and I hope you can see where 
I'm coming from. Often when people have different work behaviors, the best bet 
is to provide more options. This can be done by somehow allowing individuals to 
opt out of those generated emails. I hope we can do something about this.

Patrick

-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=14616&messageID=28843#28843


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

Re: 1.3.0 Release - Next Steps

2006-01-17 Thread Wendy Smoak

On 1/17/06, Ted Husted <[EMAIL PROTECTED]> wrote:

> OK, I see by the commit and wiki logs that Wendy has done the deed,
> and everything is checked that going to be checked :)

The release notes could use a final review; I didn't check it off on
the release plan.

And we also need to remove the example of the cglib enhanced form from
apps/examples.

--
Wendy

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

Re: 1.3.0 Release - Next Steps

On 1/17/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> OK, I see by the commit and wiki logs that Wendy has done the deed,
> and everything is checked that going to be checked :)
>
> * http://wiki.apache.org/struts/StrutsClassicRelease130
>
> Since a multiproject relesae is still new ground, I'm thinking the
> next step would be to assembly a prototype of what a 1.3.0 release
> would look like, and post it to a home directory, for everyone to
> review. Then, if appropriate, we can tag the repository, and release.
>
> If there are no objections, tonight I can put together a prototype
> release package.


+1, modulo Wendy's comments about release notes and cglib example. I see
light at the end of this tunnel! :-)

--
Martin Cooper


-Ted.
>
>
> On 1/17/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
> > I hate to say it, but I'm not going to have time to work on fixing
> > this in time for the 1.3 release. Wendy's suggestion (removing the
> > feature for now) probably makes the most sense; I'll look at adding
> > the serialization support and putting the enhanced form bean support
> > into 'extras' post 1.3.0.
> >
> > L.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[ANNOUNCEMENT] New Struts committers: Jason Carreira and Patrick Lightbody

Please join me in welcoming Jason Carreira and Patrick Lightbody as new Struts committers. Jason and Patrick are the 
core WebWork 2 developers and they are joining us in an important step in the merger process.  I, and many other Struts 
committers, have personally met and talked at length with both Patrick and Jason on several occasions and find them 
dedicated, skilled, and team players.  Their dedication to WebWork 2 over the years is a testament to their 
perseverance, commitment to their community, and technical skill. We look forward to their contributions as committers.


Welcome Jason and Patrick!

PMC vote: 8 +1

Don


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

Re: [ANNOUNCEMENT] New Struts committers: Jason Carreira and Patrick Lightbody

2006-01-17 Thread James Mitchell


Welcome!!!

--
James Mitchell
EdgeTech, Inc.
http://edgetechservices.net/
678.910.8017
Skype: jmitchtx



On Jan 17, 2006, at 1:54 PM, Don Brown wrote:

Please join me in welcoming Jason Carreira and Patrick Lightbody as  
new Struts committers. Jason and Patrick are the core WebWork 2  
developers and they are joining us in an important step in the  
merger process.  I, and many other Struts committers, have  
personally met and talked at length with both Patrick and Jason on  
several occasions and find them dedicated, skilled, and team  
players.  Their dedication to WebWork 2 over the years is a  
testament to their perseverance, commitment to their community, and  
technical skill. We look forward to their contributions as committers.


Welcome Jason and Patrick!

PMC vote: 8 +1

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: Non-discussion emails

2006-01-17 Thread Sean Schofield

I agree with Ted about the importance of mailing lists.  Mailing lists
are the "Apache Way."  The only time I have used off-llist
communication is during an infrastructure move where we needed to
rapidly complete several steps in a short period of time.  Even then
the basic outline of work was agreed to in advance on the mailing
list.

Mailing lists may seem outdated but they are the lifeblood of the ASF
and they continue to serve us well.  There may be more rapid ways of
communicating (phone calls and internet chat come to mind) but these
are exclusionary.  The community is world wide and people have day
jobs.  It takes a little longer to hash things out over email but
everyone gets to participate this way.

The result is a single archive that is publicly searchable and
contains all relevant decisions (no matter how trivial) in one place.

My .02

Sean

On 1/17/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
> Ted,
> I'm sure you didn't mean it this way, but you seem to imply that I don't have 
> any experience with this sort of stuff. I do.
>
> We too at OpenSymphony use mailing lists quite heavily (as does every other 
> decent open source project out there). However, as technologies like RSS have 
> grown more popular, we adapted. Now we get our wiki changes and CVS changes 
> through RSS (Confluence and FishEye both provide RSS feeds). We also offer 
> the option of email messages, but that is up to the individual.
>
> Conversations still continue around wiki changes and commits. For those that 
> subscribe to the mailing lists, they simply forward the message to the dev 
> list. For those that don't, they simply post a new message asking, "John, can 
> you explain why you changed Foo.java yesterday?".
>
> Try to understand where I'm coming from: the wiki and commit changes aren't 
> interesting to me (I don't have time to look through any of them). Not just 
> for Struts, but for WebWork too. Instead, I do weekly reviews. With Struts, I 
> just delete those messages as they come in. And when I look at the forums:
>
> http://forums.opensymphony.com/forum.jspa?forumID=34
>
> I see "NO NOT REPLY" and "[Struts Wiki]", making it just as difficult for me 
> to keep up with the other conversations. I didn't mean to imply that those 
> messages sometime don't spur a conversation, but pragmatically 99% of the 
> chatter I've seen does not come from them.
>
> I definitely understand where you are coming from, and I hope you can see 
> where I'm coming from. Often when people have different work behaviors, the 
> best bet is to provide more options. This can be done by somehow allowing 
> individuals to opt out of those generated emails. I hope we can do something 
> about this.
>
> Patrick
>
> -
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=14616&messageID=28843#28843
>
>
> -
> 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: Non-discussion emails

On 1/17/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
> I definitely understand where you are coming from, and I hope you can see 
> where I'm
> coming from. Often when people have different work behaviors, the best bet is 
> to provide
> more options. This can be done by somehow allowing individuals to opt out of 
> those
> generated emails. I hope we can do something about this.

I think an important point is that these emails are being generated by
people. People are making the wiki changes, and people are creating
the issue tickets, and people are making the subversion commits. Each
and every one of those emails contains original input from a real
person that deserves the attention of the dev list.

The issue trackers posts are marked "DO NOT REPLY", because we want to
keep the discussion under the comments for each issue. So, to reply,
you follow the link to the ticket. But, by posting the status changes
to the ticket, we are all being kept abreast of what is happening on a
ticket, whether we click thru or not. We don't have to schedule time
to review the issue tracker, the issue tracker comes to us in real
time.

Case in point: Right now, Roller is being incubated, and we don't have
JIRA posting to the dev list yet. I created and posted a ticket over
the weekend. But, no one noticed until I made a second post to dev@
mentioning the ticket. Volunteers should not have to make a redundant
post to the mailing list when JIRA can do it automatically.

For a number of reasons, including legal ones, we do want all the
input and discussions, whether they take place on the wiki or the
issue tracker or anywhere else, to end up on a mailbox on an ASF
server.

Now, we could create a wiki@ mailing list and an issue@ mailing list,
to match the commit@ list, but now when people opt-in, they have to
opt into five lists instead of three. If we add a Roller blog to the
mix, then there would be six.

Right now, the ASF norm is three lists: That's what we create when
projects come through the Incubator.If we want more than that (and I'm
not sure that we do), I'd be happy to bring it up on the internal ASF
members list, to get input from other ASF communities. Perhaps someone
else here has already discussed having more lists at length, or even
tried more lists.

IMHO, it sounds like Jive is not up to the task of managing an
ASF-style dev list. Any decent mailreader can filter mails into
whatever folders we find convenient, creating the personal equivalent
of five or six separate lists, if that's what someone wants.

-Ted.

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

Re: Non-discussion emails

2006-01-17 Thread James Mitchell


My 2 cents (I know, you were dying to know how I feel ;):

I want to be a part of this (and many other) communities, and that  
means keeping up to date with the discussions that happen for a given  
project.


To that end, mailing lists work, and forums do not.  It's nice to be  
able to filter messages but that's not a deal breaker for me.  What  
is a deal breaker for me is how much time I have to spend going  
through all of the communications (discussions, commits, wiki  
updates, whatever).  Hell, if someone would email the irc transcripts  
for any project I'm a part of, I'd say "thank you, may I have another".


For me, it's about time management, with mailing lists, it's as  
simple as reading the subject and deleting the entire thread with the  
push of 1 key, or if I'm interested, I don't have to hit anything, I  
just glance down to the reading pane and read until I'm satisfied  
that either:

 a) I can help, so I hit reply
 b) I can help, but no time at the moment, delete
 c) I can't help, and I'm not interested anyway, delete
 d) I can't help, but I am interested, keep it until the thread  
completes, and if there is a solution, save it


So, I don't care about the implementation as long as it meets my  
requirements, otherwise I simply must opt out.  I hope that doesn't  
happen with my favorite community, Struts.


Thanks

--
James Mitchell
EdgeTech, Inc.
http://edgetechservices.net/
678.910.8017
Skype: jmitchtx



On Jan 17, 2006, at 2:14 PM, Sean Schofield wrote:


I agree with Ted about the importance of mailing lists.  Mailing lists
are the "Apache Way."  The only time I have used off-llist
communication is during an infrastructure move where we needed to
rapidly complete several steps in a short period of time.  Even then
the basic outline of work was agreed to in advance on the mailing
list.

Mailing lists may seem outdated but they are the lifeblood of the ASF
and they continue to serve us well.  There may be more rapid ways of
communicating (phone calls and internet chat come to mind) but these
are exclusionary.  The community is world wide and people have day
jobs.  It takes a little longer to hash things out over email but
everyone gets to participate this way.

The result is a single archive that is publicly searchable and
contains all relevant decisions (no matter how trivial) in one place.

My .02

Sean

On 1/17/06, Patrick Lightbody <[EMAIL PROTECTED]>  
wrote:

Ted,
I'm sure you didn't mean it this way, but you seem to imply that I  
don't have any experience with this sort of stuff. I do.


We too at OpenSymphony use mailing lists quite heavily (as does  
every other decent open source project out there). However, as  
technologies like RSS have grown more popular, we adapted. Now we  
get our wiki changes and CVS changes through RSS (Confluence and  
FishEye both provide RSS feeds). We also offer the option of email  
messages, but that is up to the individual.


Conversations still continue around wiki changes and commits. For  
those that subscribe to the mailing lists, they simply forward the  
message to the dev list. For those that don't, they simply post a  
new message asking, "John, can you explain why you changed  
Foo.java yesterday?".


Try to understand where I'm coming from: the wiki and commit  
changes aren't interesting to me (I don't have time to look  
through any of them). Not just for Struts, but for WebWork too.  
Instead, I do weekly reviews. With Struts, I just delete those  
messages as they come in. And when I look at the forums:


http://forums.opensymphony.com/forum.jspa?forumID=34

I see "NO NOT REPLY" and "[Struts Wiki]", making it just as  
difficult for me to keep up with the other conversations. I didn't  
mean to imply that those messages sometime don't spur a  
conversation, but pragmatically 99% of the chatter I've seen does  
not come from them.


I definitely understand where you are coming from, and I hope you  
can see where I'm coming from. Often when people have different  
work behaviors, the best bet is to provide more options. This can  
be done by somehow allowing individuals to opt out of those  
generated emails. I hope we can do something about this.


Patrick

-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa? 
threadID=14616&messageID=28843#28843



-
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: Non-discussion emails

2006-01-17 Thread Sean Schofield

> IMHO, it sounds like Jive is not up to the task of managing an
> ASF-style dev list. Any decent mailreader can filter mails into
> whatever folders we find convenient, creating the personal equivalent
> of five or six separate lists, if that's what someone wants.

GMail also has *excellent* search capabilties.  I find it to be
superior to searching the public archives so I just never delete my
mailing list emails!

BTW, there was talk of switching to JIRA a while back.  I'm still +1
for that.  Its a much nicer system and I find it less cumbersome then
bugzilla.  My point here is that its more tempting to "reply" to the
bug in the proper place.

> -Ted.

Sean

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

J'J'JIRA (was Re: Non-discussion emails)

On 1/17/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> BTW, there was talk of switching to JIRA a while back.  I'm still +1
> for that.  Its a much nicer system and I find it less cumbersome then
> bugzilla.  My point here is that its more tempting to "reply" to the
> bug in the proper place.

WebWork (and Roller) are already using JIRA. Strangely, you can import
tickets from other systems, but not from other JIRA instances (yet).
I've been talking to Jeff Turner about this, and one suggestion would
be to setup a separate JIRA instances for Struts and Roller, until
someone write the code that would let us combine them in to the JIRA
instance that the ASF already has.

Then, if we want to import the Bugzilla tickets into the new Struts
JIRA, we can, so we would have all the Struts tickets, Action 1,
Action 2, and Shale,  all in the same place. (Yeah!)

Of course, under the heading "Eating our own dogfood", I'd like to see
us using JIRA, and Confluence, and Jive, because they run on WebWork /
Action 2. Ditto for Roller, which runs on Struts Action 1.

In the interest of full disclosure, I should mention that I'm told
that JIRA still runs on WW1, while Confluence runs on WW2.

-Ted.

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

Re: Non-discussion emails

2006-01-17 Thread netsql


Of course http://struts.roomity.com is both (as is news.gmane.org)

(It's a nail, I am the hammer)

.V


To that end, mailing lists work, and forums do not. 



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

svn commit: r369939 - /struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockApplication.java

Author: craigmcc
Date: Tue Jan 17 13:54:58 2006
New Revision: 369939

URL: http://svn.apache.org/viewcvs?rev=369939&view=rev
Log:
Make the createConverter() methods return null (per spec) if no matching
registered converter can be found.

Modified:

struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockApplication.java

Modified: 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockApplication.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockApplication.java?rev=369939&r1=369938&r2=369939&view=diff
==
--- 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockApplication.java
 (original)
+++ 
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockApplication.java
 Tue Jan 17 13:54:58 2006
@@ -100,6 +100,7 @@
 addConverter(Long.TYPE,
"javax.faces.convert.LongConverter");
 addConverter(Short.class,  
"javax.faces.convert.ShortConverter");
 addConverter(Short.TYPE,   
"javax.faces.convert.ShortConverter");
+
 }
 
 
@@ -316,6 +317,9 @@
 public Converter createConverter(String converterId) {
 
 String converterClass = (String) converters.get(converterId);
+if (converterClass == null) {
+return null;
+}
 try {
 Class clazz = Class.forName(converterClass);
 return ((Converter) clazz.newInstance());
@@ -329,6 +333,9 @@
 public Converter createConverter(Class targetClass) {
 
 String converterClass = (String) converters1.get(targetClass);
+if (converterClass == null) {
+return null;
+}
 try {
 Class clazz = Class.forName(converterClass);
 return ((Converter) clazz.newInstance());



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

svn commit: r369940 - in /struts/shale/trunk/core-library/src/java/org/apache/shale: resources/Bundle.properties util/ConverterHelper.java

Author: craigmcc
Date: Tue Jan 17 13:55:55 2006
New Revision: 369940

URL: http://svn.apache.org/viewcvs?rev=369940&view=rev
Log:
Throw an informative ConverterException if conversion is requested for a type
that has no by-type converter registered.

Modified:

struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties

struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties?rev=369940&r1=369939&r2=369940&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
 Tue Jan 17 13:55:55 2006
@@ -60,3 +60,6 @@
 tiles.dispatchingToTile=Dispatching to tile {0}
 tiles.dispatchingToViewHandler=Dispatching {0} to the default view handler
 
+# org.apache.shale.util.ConverterHelper
+convHelper.noConverter=You have requested a conversion for type {0}, but there 
is no by-type converter registered for this type
+

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java?rev=369940&r1=369939&r2=369940&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java
 Tue Jan 17 13:55:55 2006
@@ -34,6 +34,17 @@
 public class ConverterHelper {
 
 
+//  Static 
Variables
+
+
+/**
+ * Messages for this class.
+ */
+private static Messages messages =
+new Messages("org.apache.shale.resources.Bundle",
+ ConverterHelper.class.getClassLoader());
+
+
 // -- Public 
Methods
 
 
@@ -88,11 +99,18 @@
  */
 private Converter converter(FacesContext context, Class type) {
 
+Converter converter = null;
 try {
-return context.getApplication().createConverter(type);
+converter = context.getApplication().createConverter(type);
 } catch (FacesException e) {
 throw new ConverterException(e);
 }
+if (converter == null) {
+throw new 
ConverterException(messages.getMessage("convHelper.noConverter",
+ 
context.getViewRoot().getLocale(),
+ new Object[] { 
type.getName() }));
+}
+return converter;
 
 }
 



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

Re: Non-discussion emails

On 1/17/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> > IMHO, it sounds like Jive is not up to the task of managing an
> > ASF-style dev list. Any decent mailreader can filter mails into
> > whatever folders we find convenient, creating the personal equivalent
> > of five or six separate lists, if that's what someone wants.
>
> GMail also has *excellent* search capabilties.  I find it to be
> superior to searching the public archives so I just never delete my
> mailing list emails!


+1. All my open source mail goes to GMail. I have 50+ filters set up, and as
many labels, and it's really a snap to find anything (and not lose anything
important).

--
Martin Cooper


BTW, there was talk of switching to JIRA a while back.  I'm still +1
> for that.  Its a much nicer system and I find it less cumbersome then
> bugzilla.  My point here is that its more tempting to "reply" to the
> bug in the proper place.
>
> > -Ted.
>
> Sean
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

That's great for folks that manage their information via email and email folders, but not all do. I'm finding myself
use RSS more and more to manage project, hobby, and personal information, leaving email only for correspondences that I
need to respond to.

I'd like to see a compromise where I could sign up for mailing list that only contains discussions, yet track tickets,
wiki updates, and commits via RSS. This discussion-only mailing list could be a second mailing list that just
automatically filters out undesired messages. This would leave struts-dev untouched, yet allow those that take the RSS
path to not fill up their email boxes or have to setup new filters on multiple email clients (yes, I on an average day
use 4 or 5 and it is a pain to keep them in sync).

Anyways, it is important to remember that not everyone works in the same way or
uses the same tools.

Don

Martin Cooper wrote:

On 1/17/06, Sean Schofield <[EMAIL PROTECTED]> wrote:

IMHO, it sounds like Jive is not up to the task of managing an
ASF-style dev list. Any decent mailreader can filter mails into
whatever folders we find convenient, creating the personal equivalent
of five or six separate lists, if that's what someone wants.

GMail also has *excellent* search capabilties. I find it to be
superior to searching the public archives so I just never delete my
mailing list emails!

+1. All my open source mail goes to GMail. I have 50+ filters set up, and as
many labels, and it's really a snap to find anything (and not lose anything
important).

--
Martin Cooper

BTW, there was talk of switching to JIRA a while back. I'm still +1

for that. Its a much nicer system and I find it less cumbersome then
bugzilla. My point here is that its more tempting to "reply" to the
bug in the proper place.

-Ted.

Sean

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

Re: J'J'JIRA (was Re: Non-discussion emails)

On 1/17/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> On 1/17/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> > BTW, there was talk of switching to JIRA a while back.  I'm still +1
> > for that.  Its a much nicer system and I find it less cumbersome then
> > bugzilla.  My point here is that its more tempting to "reply" to the
> > bug in the proper place.
>
> WebWork (and Roller) are already using JIRA. Strangely, you can import
> tickets from other systems, but not from other JIRA instances (yet).
> I've been talking to Jeff Turner about this, and one suggestion would
> be to setup a separate JIRA instances for Struts and Roller, until
> someone write the code that would let us combine them in to the JIRA
> instance that the ASF already has.

We can ask, but I doubt if the infra@ folks would be too thrilled about
that, for two reasons. One is that there have been quite a few issues with
keeping the one JIRA instance we have now up and running recently, mostly
because it's one of the most heavily loaded JIRA instances on the planet.
The other, which is related, is that JIRA has been a significant resource
hog, so multiple instances isn't very appealing in that respect. Jeff Turner
has been working hard to help us out, but he's only one guy, and he has a
day job too. ;-)

I'm not against moving to JIRA, but I think the above issues will need to be
addressed. Craig has also mentioned the ease of reassigning issues between
Struts and Commons, but that seems to happen a lot less these days, so I'm
less concerned about that now.

--
Martin Cooper

Then, if we want to import the Bugzilla tickets into the new Struts
> JIRA, we can, so we would have all the Struts tickets, Action 1,
> Action 2, and Shale,  all in the same place. (Yeah!)
>
> Of course, under the heading "Eating our own dogfood", I'd like to see
> us using JIRA, and Confluence, and Jive, because they run on WebWork /
> Action 2. Ditto for Roller, which runs on Struts Action 1.
>
> In the interest of full disclosure, I should mention that I'm told
> that JIRA still runs on WW1, while Confluence runs on WW2.
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Non-discussion emails

On 1/17/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> That's great for folks that manage their information via email and email
> folders, but not all do.  I'm finding myself
> use RSS more and more to manage project, hobby, and personal information,
> leaving email only for correspondences that I
> need to respond to.
>
> I'd like to see a compromise where I could sign up for mailing list that
> only contains discussions, yet track tickets,
> wiki updates, and commits via RSS.  This discussion-only mailing list
> could be a second mailing list that just
> automatically filters out undesired messages.  This would leave struts-dev
> untouched, yet allow those that take the RSS
> path to not fill up their email boxes or have to setup new filters on
> multiple email clients (yes, I on an average day
> use 4 or 5 and it is a pain to keep them in sync).
>
> Anyways, it is important to remember that not everyone works in the same
> way or uses the same tools.


Agreed. It's also important to remember that, beyond keeping all of the dev
discussions in one place, one of the main reasons ASF projects are set up
this way, with commit messages and wiki changes going to the dev list, is
for legal oversight. That doesn't necessarily preclude other options, but
whatever else we do, we need to ensure that we retain oversight.

--
Martin Cooper


Don
>
> Martin Cooper wrote:
> > On 1/17/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> >
> >>>IMHO, it sounds like Jive is not up to the task of managing an
> >>>ASF-style dev list. Any decent mailreader can filter mails into
> >>>whatever folders we find convenient, creating the personal equivalent
> >>>of five or six separate lists, if that's what someone wants.
> >>
> >>GMail also has *excellent* search capabilties.  I find it to be
> >>superior to searching the public archives so I just never delete my
> >>mailing list emails!
> >
> >
> >
> > +1. All my open source mail goes to GMail. I have 50+ filters set up,
> and as
> > many labels, and it's really a snap to find anything (and not lose
> anything
> > important).
> >
> > --
> > Martin Cooper
> >
> >
> > BTW, there was talk of switching to JIRA a while back.  I'm still +1
> >
> >>for that.  Its a much nicer system and I find it less cumbersome then
> >>bugzilla.  My point here is that its more tempting to "reply" to the
> >>bug in the proper place.
> >>
> >>
> >>>-Ted.
> >>
> >>Sean
> >>
> >>-
> >>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]
>
>

J'J'JIRA (was Non-discussion emails)

Sort of also going off tangent again, but I can't sing the praises enough about 
Contegix and their hosting service. I know there are plenty of legal concerns 
that Ted tried explaining to me that might prevent them from being used, but if 
those can be worked around or addressed in another way, I am positive the 
Struts community would benefit from Contegix hosting infrastructure.

They are _really_ good.

-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=14750&messageID=28979#28979


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

Re: Non-discussion emails

On 1/17/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I'd like to see a compromise where I could sign up for mailing list that only 
> contains
> discussions, yet track tickets,
> wiki updates, and commits via RSS.  This discussion-only mailing list could 
> be a second
> mailing list that just
> automatically filters out undesired messages.

I guess what I don't understand is why relay one via RSS and not the other.

The mailing list discussions may be free-form, but that does not make
them more or less valuable than the discussions we have through the
issue ticket, wiki, and repository logs.

Wendy updates the release plan, and through the wiki log automatically
discusses her changes with me and with the rest of us. Craig commits
and automatically discusses what he just did and what he's going to do
next. Looking over the issue tickets, every third or fourth turns into
a discussion. Sometimes the discussion is: "Got a problem or a patch",
followed by "Fixed", but that's a discussion nonetheless.

What bothers me most is the implication that just because these logs
are being forwarded from the issue tracker, or repository, or wiki,
they are somehow less valuable than a free-form message. In practice,
I'd say the opposite is more likely to be true. The *real* development
decisions are being made on the tickets and in the commits. It's only
the odds and ends that we discuss here.

-Ted.

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

Re: Non-discussion emails

I don't think anyone, and certainly not I, is arguing that wiki and ticket messages are somehow less important, only
that they are different, and perhaps viewed at different times or in different ways.

Just as those that prefer mail clients heavily use folders to sort their mail, I've found RSS readers to be a great way
to track different types of discussions or sites. I've found it productive personally to only use email for things I
need to respond to, i.e. interpersonal discussions. I keep my inbox completely empty and rarely use folders.

On the other hand, for my day job, I use the RSS feed from Trac to follow a project's "Timeline", or history of commits,
ticket updates, and wiki changes. Since 95% of the time I don't need to respond, the RSS approach works well.

My point is we need to keep an open mind, and allow people to use whatever tools or approaches they find most valuable.
This WebWork merger is bigger than a merging of code, but also one of people, development styles, project directions,
etc. We need to make an extra effort not to try force everyone to do it "our way" or reject new ideas or styles
outright. I'm not saying anyone is doing that currently, but we must be extra vigilant to protect against it.

If Struts is going to be accepting of what some would call two opposite web framework approaches, we should also be
tolerant, even encouraging, of different personal ideas, approaches, and perspectives.

;)

Don

Ted Husted wrote:

On 1/17/06, Don Brown <[EMAIL PROTECTED]> wrote:

I guess what I don't understand is why relay one via RSS and not the other.

The mailing list discussions may be free-form, but that does not make
them more or less valuable than the discussions we have through the
issue ticket, wiki, and repository logs.

Wendy updates the release plan, and through the wiki log automatically
discusses her changes with me and with the rest of us. Craig commits
and automatically discusses what he just did and what he's going to do
next. Looking over the issue tickets, every third or fourth turns into
a discussion. Sometimes the discussion is: "Got a problem or a patch",
followed by "Fixed", but that's a discussion nonetheless.

What bothers me most is the implication that just because these logs
are being forwarded from the issue tracker, or repository, or wiki,
they are somehow less valuable than a free-form message. In practice,
I'd say the opposite is more likely to be true. The *real* development
decisions are being made on the tickets and in the commits. It's only
the odds and ends that we discuss here.

-Ted.

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

svn commit: r369991 - in /struts/shale/trunk/core-library/src/java/org/apache/shale: resources/Bundle.properties util/ConverterHelper.java util/PropertyHelper.java

Author: craigmcc
Date: Tue Jan 17 16:56:48 2006
New Revision: 369991

URL: http://svn.apache.org/viewcvs?rev=369991&view=rev
Log:
Clean up some logic errors surfaced by writing some unit tests using
these two helper classes.

Modified:

struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties

struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java

struts/shale/trunk/core-library/src/java/org/apache/shale/util/PropertyHelper.java

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties?rev=369991&r1=369990&r2=369991&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/resources/Bundle.properties
 Tue Jan 17 16:56:48 2006
@@ -61,5 +61,6 @@
 tiles.dispatchingToViewHandler=Dispatching {0} to the default view handler
 
 # org.apache.shale.util.ConverterHelper
+convHelper.missing=You have requested a converter, but the type specified is 
null
 convHelper.noConverter=You have requested a conversion for type {0}, but there 
is no by-type converter registered for this type
 

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java?rev=369991&r1=369990&r2=369991&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/ConverterHelper.java
 Tue Jan 17 16:56:48 2006
@@ -61,6 +61,9 @@
  */
 public Object asObject(FacesContext context, Class type, String value) {
 
+if (String.class == type) {
+return value;
+}
 return converter(context, type).getAsObject(context, 
context.getViewRoot(), value);
 
 }
@@ -79,6 +82,11 @@
  */
 public String asString(FacesContext context, Class type, Object value) {
 
+if (value == null) {
+return null;
+} else if ((String.class == type) && (value instanceof String)) {
+return (String) value;
+}
 return converter(context, type).getAsString(context, 
context.getViewRoot(), value);
 
 }
@@ -98,6 +106,11 @@
  *  registered for the specified type
  */
 private Converter converter(FacesContext context, Class type) {
+
+if (type == null) {
+throw new 
ConverterException(messages.getMessage("convHelper.missing",
+ 
context.getViewRoot().getLocale()));
+}
 
 Converter converter = null;
 try {

Modified: 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/PropertyHelper.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/src/java/org/apache/shale/util/PropertyHelper.java?rev=369991&r1=369990&r2=369991&view=diff
==
--- 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/PropertyHelper.java
 (original)
+++ 
struts/shale/trunk/core-library/src/java/org/apache/shale/util/PropertyHelper.java
 Tue Jan 17 16:56:48 2006
@@ -165,7 +165,7 @@
 
 BeanInfo beanInfo = null;
 try {
-Introspector.getBeanInfo(bean.getClass());
+beanInfo = Introspector.getBeanInfo(bean.getClass());
 } catch (IntrospectionException e) {
 throw new EvaluationException(e);
 }
@@ -178,7 +178,6 @@
 if (name.equals(descriptors[i].getName())) {
 return descriptors[i];
 }
-return descriptors[i];
 }
 
 throw new PropertyNotFoundException(name);



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

svn commit: r369992 - in /struts/shale/trunk/tiger: nbproject/private/ src/java/org/apache/shale/tiger/faces/ src/test/org/apache/shale/tiger/config/ src/test/org/apache/shale/tiger/faces/

Author: craigmcc
Date: Tue Jan 17 16:58:12 2006
New Revision: 369992

URL: http://svn.apache.org/viewcvs?rev=369992&view=rev
Log:
In VariableResolverImpl, remove direct dependency on Commons BeanUtils by
using the new helper methods for property access and conversion.  As a side
effect of this change, also change the unit tests that specified properties
of type java.sql.Date, since JSF does not supply a standard converter for this,
while BeanUtils did.

Modified:
struts/shale/trunk/tiger/nbproject/private/private.xml

struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverImpl.java

struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/FacesConfigParserTestCase.java

struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/test-config-4.xml

struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/test-config-5.xml

struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/VariableResolverImpl4TestCase.java

struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/VariableResolverImpl5TestCase.java

Modified: struts/shale/trunk/tiger/nbproject/private/private.xml
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/tiger/nbproject/private/private.xml?rev=369992&r1=369991&r2=369992&view=diff
==
--- struts/shale/trunk/tiger/nbproject/private/private.xml (original)
+++ struts/shale/trunk/tiger/nbproject/private/private.xml Tue Jan 17 16:58:12 
2006
@@ -1,4 +1,4 @@
-
-http://www.netbeans.org/ns/project-private/1";>
-http://www.netbeans.org/ns/editor-bookmarks/1"/>
-
+
+http://www.netbeans.org/ns/project-private/1";>
+http://www.netbeans.org/ns/editor-bookmarks/1"/>
+

Modified: 
struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverImpl.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverImpl.java?rev=369992&r1=369991&r2=369992&view=diff
==
--- 
struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverImpl.java
 (original)
+++ 
struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverImpl.java
 Tue Jan 17 16:58:12 2006
@@ -23,12 +23,9 @@
 import javax.faces.context.ExternalContext;
 import javax.faces.context.FacesContext;
 import javax.faces.el.EvaluationException;
+import javax.faces.el.PropertyNotFoundException;
 import javax.faces.el.ValueBinding;
 import javax.faces.el.VariableResolver;
-import org.apache.commons.beanutils.BeanUtils;
-import org.apache.commons.beanutils.ConversionException;
-import org.apache.commons.beanutils.ConvertUtils;
-import org.apache.commons.beanutils.PropertyUtils;
 import org.apache.commons.logging.Log;
 import org.apache.commons.logging.LogFactory;
 import org.apache.shale.tiger.config.FacesConfigConfig;
@@ -40,7 +37,9 @@
 import org.apache.shale.tiger.managed.config.ManagedPropertyConfig;
 import org.apache.shale.tiger.managed.config.MapEntriesConfig;
 import org.apache.shale.tiger.managed.config.MapEntryConfig;
+import org.apache.shale.util.ConverterHelper;
 import org.apache.shale.util.Messages;
+import org.apache.shale.util.PropertyHelper;
 
 /**
  * Implementation of VariableResolver that delegates
@@ -101,6 +100,12 @@
 
 
 /**
+ * Helper bean for performing conversions.
+ */
+private ConverterHelper convHelper = new ConverterHelper();
+
+
+/**
  * Log instance for this class.
  */
 private transient Log log = null;
@@ -119,6 +124,13 @@
 private VariableResolver original = null;
 
 
+/**
+ * Helper bean for accessing properties.
+ */
+private PropertyHelper propHelper = new PropertyHelper();
+
+
+
 // --- VariableResolver Methods
 
 
@@ -193,60 +205,6 @@
 
 
 /**
- * Convert the specified value to the specified type.
- *
- * @param context FacesContext for the current request
- * @param type Type to which the value should be converted, or
- *  null to leave it as a string
- * @param value Value to be converted
- *
- * @exception EvaluationException if an evaluation error occurs
- */
-private Object convert(FacesContext context, Class type, String value) {
-
-// If the type is not specified, return the value unchanged
-if (type == null) {
-return value;
-}
-
-// Handle primitive type conversions explicitly
-try {
-if ((type == Boolean.TYPE) || (type == Boolean.class)) {
-return Boolean.valueOf(value);
-} else if ((type == Byte.TYPE) || (type == Byte.class)) {
-return Byte.valueOf(value);
-} else if ((type == Double.TYPE) || (type == Double.class)) {
-return Double.valueOf(value);
-} else if ((type == Float.T

Re: 1.3.0 Release - Next Steps

I reviewed the notes in November, and I'll go over the commit logs
since, to see if there is anything else we need to mention. But they
should already be very close.

One question would be whether we should copy the release notes page to
each of the subproject and then edit them down to contain only their
own notes.

For the 1.3.0 release at least, I would be in favor of keeping the
entire set of notes in the Action package too, as a convenience.

-Ted.

On 1/17/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> On 1/17/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> > OK, I see by the commit and wiki logs that Wendy has done the deed,
> > and everything is checked that going to be checked :)
>
> The release notes could use a final review; I didn't check it off on
> the release plan.
>
> And we also need to remove the example of the cglib enhanced form from
> apps/examples.

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

Re: Non-discussion emails

Wow, seems like there is a lot of push back on this topic. All I ask Please 
respect that Jason and I (as well as the WebWork community) come from a very 
well-established open source community and have a lot of alternative experience 
in this area. We both have different perspectives, but this merger is more than 
dumping code in the Struts codebase. It is working with the teams too.

To Ted's specific points:

 * I am very well aware the emails are a direct result of a peron's action. To 
my original point: I don't care. I personally review the wiki and bug tracker 
at a different time than when I check email.
 * Jive Forums certainly can filter the email, and I may turn that on, but then 
I've bypassed the team rather than working with them. I don't like that 
approach at all.

To Sean's points:

  * I am not proposing that we get rid of email lists. I am only suggesting 
that there be ways to opt out of certain lists/types of mail. Why is offering 
more options such a problem? I fail to see how everything being list-based 
leads to the conclusion that "The result is a single archive that is publicly 
searchable and contains all relevant decisions (no matter how trivial) in one 
place." Why can't there be multiple archives that can all be searched at once? 
We provide that with WebWork by allowing users to search the WebWork 
_category_, which includes the Dev, User, and CVS lists.

To James:

  * I fully support that you work that way and am not suggesting your workflow 
change at all. I 100% support complete email-based communication. I only ask 
that some users such as myself be able to opt out.

So, I'd like to propose something. Ted said:

> Now, we could create a wiki@ mailing list and an issue@ mailing list,
> to match the commit@ list, but now when people opt-in, they have to
> opt into five lists instead of three. If we add a Roller blog to the
>  mix, then there would be six.

I offer two suggestions, either is perfectly fine with me. Any other 
suggestions that provide more alternatives are also of course welcome:

1) Why not create a simple web-based form to manage all the lists. By default, 
all 5, 6, or 7 lists are checked when the user clicks the "subscribe" button, 
but each list can be independently subscribed and unsubscribed. You can even 
set the Reply-To header for some of the lists (bugs, wiki, etc) to point back 
to the dev@ list.

and/or

2) Using a Forums-based approach and different mailing lists for each type of 
content (wiki@, dev@, bug@, etc), create a single Struts category with several 
sub-forms that sync to the lists. Now users can search the Struts category and 
get a unified archive.

Thoughts? I understand that this does involve some work, and for those of you 
who are quite happy with how things are now, it may seem like a waste of time. 
As such, I'm more than willing to do the actual work for any proposed solution.

Patrick
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=14616&messageID=29027#29027


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

Re: Checkstyle (was svn commit: r360442 [1/3] )

Is anyone using an automatic code reformatting tool that can read a
CheckStyle configuration?

I'd like to clean up some of the stylistic errors, but I would prefer
that most of the reformatting be done by a proven tool. I have utter
confidence in IDEA, but I don't know if we can perfectly align the
settings with CheckStyle.

For more, see

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

Having CheckStyle standards is great, but I would rather have a
consistent code style that we can enforce with an automatic
reformatting tool.

-Ted.

On 12/31/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> See also
>
>
> for more on this.
>
> On 12/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: husted
> > Date: Sat Dec 31 12:10:04 2005
> > New Revision: 360442
> >
> > URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
> > Log:
> > Code reformatting only. No functional changes.
> > * Used JetBrains IDEA 5.x to conform code format per our guidelines.
>

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

Re: J'J'JIRA (was Non-discussion emails)

Unfortunately, Contegix did not respond to the Request for Proposal,
and another host has been recommended to the board. When the host
takes over, hopefully we will be able to try more things, but that's
still several months down the road. If for some reason, the new host
didn't work out, I'm sure Contegix would have another chance to submit
a proposal.

What we need to keep in mind is that it's not just about Struts, it's
about the ASF too.

-Ted.

On 1/17/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
> Sort of also going off tangent again, but I can't sing the praises enough 
> about Contegix and their hosting service. I know there are plenty of legal 
> concerns that Ted tried explaining to me that might prevent them from being 
> used, but if those can be worked around or addressed in another way, I am 
> positive the Struts community would benefit from Contegix hosting 
> infrastructure.
>
> They are _really_ good.
>
> -
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=14750&messageID=28979#28979

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

Re: svn commit: r369992 - in /struts/shale/trunk/tiger: nbproject/private/ src/java/org/apache/shale/tiger/faces/ src/test/org/apache/shale/tiger/config/ src/test/org/apache/shale/tiger/faces/

2006-01-17 Thread Gary VanMatre

This seems like a handly utility.  Clay has something similar, PropUtils, that 
uses the ConvertUtils.  I think we could refactor to use this utility.  Is 
there a specific reason that you wanted to factor out Commons BeanUtils?

Gary
-- Original message -- 
From: [EMAIL PROTECTED] 

> Author: craigmcc 
> Date: Tue Jan 17 16:58:12 2006 
> New Revision: 369992 
> 
> URL: http://svn.apache.org/viewcvs?rev=369992&view=rev 
> Log: 
> In VariableResolverImpl, remove direct dependency on Commons BeanUtils by 
> using the new helper methods for property access and conversion. As a side 
> effect of this change, also change the unit tests that specified properties 
> of type java.sql.Date, since JSF does not supply a standard converter for 
> this, 
> while BeanUtils did. 
> 
> Modified: 
> struts/shale/trunk/tiger/nbproject/private/private.xml 
> 
> struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverI
>  
> mpl.java 
> 
> struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/FacesConfigParse
>  
> rTestCase.java 
> 
> struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/test-config-4.xm
>  
> l 
> 
> struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/test-config-5.xm
>  
> l 
> 
> struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/VariableResolverI
>  
> mpl4TestCase.java 
> 
> struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/VariableResolverI
>  
> mpl5TestCase.java 
> 
> Modified: struts/shale/trunk/tiger/nbproject/private/private.xml 
> URL: 
> http://svn.apache.org/viewcvs/struts/shale/trunk/tiger/nbproject/private/private
>  
> .xml?rev=369992&r1=369991&r2=369992&view=diff 
> ==
>  
> --- struts/shale/trunk/tiger/nbproject/private/private.xml (original) 
> +++ struts/shale/trunk/tiger/nbproject/private/private.xml Tue Jan 17 
> 16:58:12 
> 2006 
> @@ -1,4 +1,4 @@ 
> - 
> - 
> - 
> - 
> + 
> + 
> + 
> + 
> 
> Modified: 
> struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverI
>  
> mpl.java 
> URL: 
> http://svn.apache.org/viewcvs/struts/shale/trunk/tiger/src/java/org/apache/shale
>  
> /tiger/faces/VariableResolverImpl.java?rev=369992&r1=369991&r2=369992&view=diff
>  
> ==
>  
> --- 
> struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverI
>  
> mpl.java (original) 
> +++ 
> struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverI
>  
> mpl.java Tue Jan 17 16:58:12 2006 
> @@ -23,12 +23,9 @@ 
> import javax.faces.context.ExternalContext; 
> import javax.faces.context.FacesContext; 
> import javax.faces.el.EvaluationException; 
> +import javax.faces.el.PropertyNotFoundException; 
> import javax.faces.el.ValueBinding; 
> import javax.faces.el.VariableResolver; 
> -import org.apache.commons.beanutils.BeanUtils; 
> -import org.apache.commons.beanutils.ConversionException; 
> -import org.apache.commons.beanutils.ConvertUtils; 
> -import org.apache.commons.beanutils.PropertyUtils; 
> import org.apache.commons.logging.Log; 
> import org.apache.commons.logging.LogFactory; 
> import org.apache.shale.tiger.config.FacesConfigConfig; 
> @@ -40,7 +37,9 @@ 
> import org.apache.shale.tiger.managed.config.ManagedPropertyConfig; 
> import org.apache.shale.tiger.managed.config.MapEntriesConfig; 
> import org.apache.shale.tiger.managed.config.MapEntryConfig; 
> +import org.apache.shale.util.ConverterHelper; 
> import org.apache.shale.util.Messages; 
> +import org.apache.shale.util.PropertyHelper; 
> 
> /** 
> * 
Implementation of VariableResolver that delegates 
> @@ -101,6 +100,12 @@ 
> 
> 
> /** 
> + * 
Helper bean for performing conversions.

> + */ 
> + private ConverterHelper convHelper = new ConverterHelper(); 
> + 
> + 
> + /** 
> * 
Log instance for this class.

> */ 
> private transient Log log = null; 
> @@ -119,6 +124,13 @@ 
> private VariableResolver original = null; 
> 
> 
> + /** 
> + * 
Helper bean for accessing properties.

> + */ 
> + private PropertyHelper propHelper = new PropertyHelper(); 
> + 
> + 
> + 
> // --- VariableResolver Methods 
> 
> 
> @@ -193,60 +205,6 @@ 
> 
> 
> /** 
> - * 
Convert the specified value to the specified type.

> - * 
> - * @param context FacesContext for the current request 
> - * @param type Type to which the value should be converted, or 
> - * null to leave it as a string 
> - * @param value Value to be converted 
> - * 
> - * @exception EvaluationException if an evaluation error occurs 
> - */ 
> - private Object convert(FacesContext context, Class type, String value) { 
> - 
> - // If the type is not specified, return the value unchanged 
> - if (type == null) { 
> - return value; 
> - } 
> - 
> - // Handle primitive type conversions explicitly 
> - try { 
> - if ((type == Boolean.TYPE) || (type =

Re: Non-discussion emails

On 1/17/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
> Thoughts? I understand that this does involve some work, and for those of you 
> who are
> quite happy with how things are now, it may seem like a waste of time. As 
> such, I'm
> more than willing to do the actual work for any proposed solution.

The ASF infrastructure is about to enter into a transitional period.
After more than a year of hemming and hawing, we finally made some
decisions as to how to proceed. Two new infrastructure teams will be
coming on board. One will handle the mail, and the other will  handle
everything else.

This is just not a good time to try and do things that deviate from
the ASF norm. My suggestion would be to table the discussion for six
months and revisit it when the new infrastructure teams are up and
running, and ready to prove themselves.

Of course, if there are things that can be done without involving the
ASF infrastructure, by all means, go ahead and do it. :)

My suggestion would be to setup Jive forums for each of the lists that
we would like to see (user, dev, commit, issues, and wiki), and use
filters to separate content as needed. Then, people will be able to
see exactly what the effect would be. After six months, we'd have
enough experience and traffic to demonstrate how well it works, and we
could pitch it to the new infrastructure team.

-Ted.

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

Re: Non-discussion emails

2006-01-17 Thread niallp

Committers obviously need to have oversight of everything - wiki, bugs, commits 
and posted messages, but thats a limited number of us and easy to ensure that 
we're fully subscribed up to everything.

For other community members Jive is excellent and I think this is a great 
addition to support community participation. People who don't want to be 
permanently subscribed and receieve all the emails can pop in and out posting 
on an adhoc basis.

> I offer two suggestions, either is perfectly fine
> with me. Any other suggestions that provide more
> alternatives are also of course welcome:
> 
> 1) Why not create a simple web-based form to manage
> all the lists. By default, all 5, 6, or 7 lists are
> checked when the user clicks the "subscribe" button,
> but each list can be independently subscribed and
> unsubscribed. You can even set the Reply-To header
> for some of the lists (bugs, wiki, etc) to point back
> to the dev@ list.
> and/or
> 
> 2) Using a Forums-based approach and different
> mailing lists for each type of content (wiki@, dev@,
> bug@, etc), create a single Struts category with
> several sub-forms that sync to the lists. Now users
> can search the Struts category and get a unified
> archive.
> 
> Thoughts? I understand that this does involve some
> work, and for those of you who are quite happy with
> how things are now, it may seem like a waste of time.
> As such, I'm more than willing to do the actual work
> for any proposed solution.

I like both these ideas +1 from me.

Niall

> Patrick
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=14616&messageID=29031#29031


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

Re: svn commit: r369992 - in /struts/shale/trunk/tiger: nbproject/private/ src/java/org/apache/shale/tiger/faces/ src/test/org/apache/shale/tiger/config/ src/test/org/apache/shale/tiger/faces/

2006-01-17 Thread Craig McClanahan

On 1/17/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> This seems like a handly utility.  Clay has something similar, PropUtils,
> that uses the ConvertUtils.  I think we could refactor to use this
> utility.  Is there a specific reason that you wanted to factor out Commons
> BeanUtils?


Yes ... it seems to be the source of some memory leaks from not always
getting cleaned up at runtime.  Plus, when I develop on Windows,
commons-beanutils.jar gets left locked a lot, meaning you have to restart
your container to be able to do a clean rebuild.

This doesn't help a lot right at the moment, because we still inherit the
dependency from Digester and the JSF implementation if its bundled.  But
it's a step down the path of simplifying the dependency hierarchy for Shale,
especially in a JavaEE 5 world where the JSF implementation will already be
provided by the container.

Gary


Craig


-- Original message --
> From: [EMAIL PROTECTED]
>
> > Author: craigmcc
> > Date: Tue Jan 17 16:58:12 2006
> > New Revision: 369992
> >
> > URL: http://svn.apache.org/viewcvs?rev=369992&view=rev
> > Log:
> > In VariableResolverImpl, remove direct dependency on Commons BeanUtils
> by
> > using the new helper methods for property access and conversion. As a
> side
> > effect of this change, also change the unit tests that specified
> properties
> > of type java.sql.Date, since JSF does not supply a standard converter
> for this,
> > while BeanUtils did.
> >
> > Modified:
> > struts/shale/trunk/tiger/nbproject/private/private.xml
> >
> >
> struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverI
> > mpl.java
> >
> >
> struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/FacesConfigParse
> > rTestCase.java
> >
> > struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/test-
> config-4.xm
> > l
> >
> > struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/config/test-
> config-5.xm
> > l
> >
> >
> struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/VariableResolverI
> > mpl4TestCase.java
> >
> >
> struts/shale/trunk/tiger/src/test/org/apache/shale/tiger/faces/VariableResolverI
> > mpl5TestCase.java
> >
> > Modified: struts/shale/trunk/tiger/nbproject/private/private.xml
> > URL:
> >
> http://svn.apache.org/viewcvs/struts/shale/trunk/tiger/nbproject/private/private
> > .xml?rev=369992&r1=369991&r2=369992&view=diff
> >
> ==
> > --- struts/shale/trunk/tiger/nbproject/private/private.xml (original)
> > +++ struts/shale/trunk/tiger/nbproject/private/private.xml Tue Jan 17
> 16:58:12
> > 2006
> > @@ -1,4 +1,4 @@
> > -
> > -
> > -
> > -
> > +
> > +
> > +
> > +
> >
> > Modified:
> >
> struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverI
> > mpl.java
> > URL:
> >
> http://svn.apache.org/viewcvs/struts/shale/trunk/tiger/src/java/org/apache/shale
> >
> /tiger/faces/VariableResolverImpl.java?rev=369992&r1=369991&r2=369992&view=diff
> >
> ==
> > ---
> >
> struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverI
> > mpl.java (original)
> > +++
> >
> struts/shale/trunk/tiger/src/java/org/apache/shale/tiger/faces/VariableResolverI
> > mpl.java Tue Jan 17 16:58:12 2006
> > @@ -23,12 +23,9 @@
> > import javax.faces.context.ExternalContext;
> > import javax.faces.context.FacesContext;
> > import javax.faces.el.EvaluationException;
> > +import javax.faces.el.PropertyNotFoundException;
> > import javax.faces.el.ValueBinding;
> > import javax.faces.el.VariableResolver;
> > -import org.apache.commons.beanutils.BeanUtils;
> > -import org.apache.commons.beanutils.ConversionException;
> > -import org.apache.commons.beanutils.ConvertUtils;
> > -import org.apache.commons.beanutils.PropertyUtils;
> > import org.apache.commons.logging.Log;
> > import org.apache.commons.logging.LogFactory;
> > import org.apache.shale.tiger.config.FacesConfigConfig;
> > @@ -40,7 +37,9 @@
> > import org.apache.shale.tiger.managed.config.ManagedPropertyConfig;
> > import org.apache.shale.tiger.managed.config.MapEntriesConfig;
> > import org.apache.shale.tiger.managed.config.MapEntryConfig;
> > +import org.apache.shale.util.ConverterHelper;
> > import org.apache.shale.util.Messages;
> > +import org.apache.shale.util.PropertyHelper;
> >
> > /**
> > *
> Implementation of VariableResolver that delegates
> > @@ -101,6 +100,12 @@
> >
> >
> > /**
> > + *
> Helper bean for performing conversions.
>
> > + */
> > + private ConverterHelper convHelper = new ConverterHelper();
> > +
> > +
> > + /**
> > *
> Log instance for this class.
>
> > */
> > private transient Log log = null;
> > @@ -119,6 +124,13 @@
> > private VariableResolver original = null;
> >
> >
> > + /**
> > + *
> Helper bean for accessing properties.
>
> > + */
> > + private PropertyHelper propHelper = new PropertyHelper();
> > +
> > +
> > +
> > // --

svn commit: r370014 - in /struts/apps/trunk/examples: project.xml src/java/org/apache/struts/webapp/exercise/EnhancedDynaFormAction.java src/webapp/WEB-INF/exercise/struts-config.xml src/webapp/exerci

2006-01-17 Thread wsmoak

Author: wsmoak
Date: Tue Jan 17 18:36:06 2006
New Revision: 370014

URL: http://svn.apache.org/viewcvs?rev=370014&view=rev
Log:
Removed the example of CGLIB enhancement.  See Bug# 37730 and r369764 in 
struts-action.

Removed:

struts/apps/trunk/examples/src/java/org/apache/struts/webapp/exercise/EnhancedDynaFormAction.java
struts/apps/trunk/examples/src/webapp/exercise/enhanced-dynabean.jsp
Modified:
struts/apps/trunk/examples/project.xml
struts/apps/trunk/examples/src/webapp/WEB-INF/exercise/struts-config.xml
struts/apps/trunk/examples/src/webapp/exercise/index.html

Modified: struts/apps/trunk/examples/project.xml
URL: 
http://svn.apache.org/viewcvs/struts/apps/trunk/examples/project.xml?rev=370014&r1=370013&r2=370014&view=diff
==
--- struts/apps/trunk/examples/project.xml (original)
+++ struts/apps/trunk/examples/project.xml Tue Jan 17 18:36:06 2006
@@ -10,17 +10,6 @@
   Struts webapp
 
   
-
-  cglib
-  cglib-nodep
-  2.1_3
-  http://cglib.sourceforge.net/
-  
-true
-true
-true
-  
-
 
 
   jstl

Modified: 
struts/apps/trunk/examples/src/webapp/WEB-INF/exercise/struts-config.xml
URL: 
http://svn.apache.org/viewcvs/struts/apps/trunk/examples/src/webapp/WEB-INF/exercise/struts-config.xml?rev=370014&r1=370013&r2=370014&view=diff
==
--- struts/apps/trunk/examples/src/webapp/WEB-INF/exercise/struts-config.xml 
(original)
+++ struts/apps/trunk/examples/src/webapp/WEB-INF/exercise/struts-config.xml 
Tue Jan 17 18:36:06 2006
@@ -11,37 +11,6 @@
   
   
 
-
-
-  
-  
-  
-  
-  
-
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-  
-
-  
-  
-  
-  
-  
-
-  
-  
-  
-  
-
   
   
 http://jakarta.apache.org/struts"; />
@@ -100,10 +69,6 @@
 
 
   
-
-
-
-  
 
   
   

Modified: struts/apps/trunk/examples/src/webapp/exercise/index.html
URL: 
http://svn.apache.org/viewcvs/struts/apps/trunk/examples/src/webapp/exercise/index.html?rev=370014&r1=370013&r2=370014&view=diff
==
--- struts/apps/trunk/examples/src/webapp/exercise/index.html (original)
+++ struts/apps/trunk/examples/src/webapp/exercise/index.html Tue Jan 17 
18:36:06 2006
@@ -88,7 +88,6 @@
 Use an ActionForward to redirect 
to the default page for the application ("/")
 Use an ActionForward to 
redirect to the default page for this module ("/$module/")
 Use an ActionForward to redirect 
another path ("/html-link.do")
-Reference properties of an enhanced 
dyna form with JSTL EL
   
 
 



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

Re: 1.3.0 Release - Next Steps

2006-01-17 Thread Wendy Smoak

On 1/17/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:

> And we also need to remove the example of the cglib enhanced form from
> apps/examples.

Done in r370014.

--
Wendy

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

Re: Checkstyle (was svn commit: r360442 [1/3] )

I've been using jEdit's checkstyle plugin.  I had to temporary modify 
the checkstyle xml to remove those dynamic properties, but otherwise, it 
worked great.


Don

Ted Husted wrote:


Is anyone using an automatic code reformatting tool that can read a
CheckStyle configuration?

I'd like to clean up some of the stylistic errors, but I would prefer
that most of the reformatting be done by a proven tool. I have utter
confidence in IDEA, but I don't know if we can perfectly align the
settings with CheckStyle.

For more, see

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

Having CheckStyle standards is great, but I would rather have a
consistent code style that we can enforce with an automatic
reformatting tool.

-Ted.

On 12/31/05, Ted Husted <[EMAIL PROTECTED]> wrote:
 


See also


for more on this.

On 12/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
   


Author: husted
Date: Sat Dec 31 12:10:04 2005
New Revision: 360442

URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
Log:
Code reformatting only. No functional changes.
* Used JetBrains IDEA 5.x to conform code format per our guidelines.
 



-
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: Checkstyle (was svn commit: r360442 [1/3] )

Does it actually reformat the code? Or just report on what should be
reformatted?

On 1/17/06, Don Brown <[EMAIL PROTECTED]> wrote:
> I've been using jEdit's checkstyle plugin.  I had to temporary modify
> the checkstyle xml to remove those dynamic properties, but otherwise, it
> worked great.
>
> Don
>
> Ted Husted wrote:
>
> >Is anyone using an automatic code reformatting tool that can read a
> >CheckStyle configuration?
> >
> >I'd like to clean up some of the stylistic errors, but I would prefer
> >that most of the reformatting be done by a proven tool. I have utter
> >confidence in IDEA, but I don't know if we can perfectly align the
> >settings with CheckStyle.
> >
> >For more, see
> >
> >* http://issues.apache.org/bugzilla/show_bug.cgi?id=36306
> >
> >Having CheckStyle standards is great, but I would rather have a
> >consistent code style that we can enforce with an automatic
> >reformatting tool.
> >
> >-Ted.
> >
> >On 12/31/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> >
> >
> >>See also
> >>
> >>
> >>for more on this.
> >>
> >>On 12/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>Author: husted
> >>>Date: Sat Dec 31 12:10:04 2005
> >>>New Revision: 360442
> >>>
> >>>URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
> >>>Log:
> >>>Code reformatting only. No functional changes.
> >>>* Used JetBrains IDEA 5.x to conform code format per our guidelines.

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

Re: Checkstyle (was svn commit: r360442 [1/3] )

It just fills the errors list with checkstyle errors, that you can then 
click on to be taken to the file and line.  It was very handy for 
cleaning up Scripting.


Don

Ted Husted wrote:


Does it actually reformat the code? Or just report on what should be
reformatted?

On 1/17/06, Don Brown <[EMAIL PROTECTED]> wrote:
 


I've been using jEdit's checkstyle plugin.  I had to temporary modify
the checkstyle xml to remove those dynamic properties, but otherwise, it
worked great.

Don

Ted Husted wrote:

   


Is anyone using an automatic code reformatting tool that can read a
CheckStyle configuration?

I'd like to clean up some of the stylistic errors, but I would prefer
that most of the reformatting be done by a proven tool. I have utter
confidence in IDEA, but I don't know if we can perfectly align the
settings with CheckStyle.

For more, see

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

Having CheckStyle standards is great, but I would rather have a
consistent code style that we can enforce with an automatic
reformatting tool.

-Ted.

On 12/31/05, Ted Husted <[EMAIL PROTECTED]> wrote:


 


See also


for more on this.

On 12/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


   


Author: husted
Date: Sat Dec 31 12:10:04 2005
New Revision: 360442

URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
Log:
Code reformatting only. No functional changes.
* Used JetBrains IDEA 5.x to conform code format per our guidelines.
 



-
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: Checkstyle (was svn commit: r360442 [1/3] )

2006-01-17 Thread Frank W. Zammetti


You may want to have a look at Jalopy:

jalopy.sf.net

There are plugins for various IDEs and editors, as well as an Ant task 
(IIRC, you can use Ant tasks from Maven?).  It won't fix everything, but 
it will help enforce many of the more common coding standards.  It 
should be possible to configure its rules to match those of CheckStyle, 
so you could then use CheckStyle to manually deal with what remains that 
Jalopy doesn't fix.


Frank

Don Brown wrote:
It just fills the errors list with checkstyle errors, that you can then 
click on to be taken to the file and line.  It was very handy for 
cleaning up Scripting.


Don

Ted Husted wrote:


Does it actually reformat the code? Or just report on what should be
reformatted?

On 1/17/06, Don Brown <[EMAIL PROTECTED]> wrote:
 


I've been using jEdit's checkstyle plugin.  I had to temporary modify
the checkstyle xml to remove those dynamic properties, but otherwise, it
worked great.

Don

Ted Husted wrote:

  

Is anyone using an automatic code reformatting tool that can read a
CheckStyle configuration?

I'd like to clean up some of the stylistic errors, but I would prefer
that most of the reformatting be done by a proven tool. I have utter
confidence in IDEA, but I don't know if we can perfectly align the
settings with CheckStyle.

For more, see

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

Having CheckStyle standards is great, but I would rather have a
consistent code style that we can enforce with an automatic
reformatting tool.

-Ted.

On 12/31/05, Ted Husted <[EMAIL PROTECTED]> wrote:




See also


for more on this.

On 12/31/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


  

Author: husted
Date: Sat Dec 31 12:10:04 2005
New Revision: 360442

URL: http://svn.apache.org/viewcvs?rev=360442&view=rev
Log:
Code reformatting only. No functional changes.
* Used JetBrains IDEA 5.x to conform code format per our guidelines.



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






--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]

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

svn commit: r370045 - in /struts/shale/trunk/clay-plugin/src: java/org/apache/shale/clay/component/chain/PropertyValueCommand.java java/org/apache/shale/clay/utils/PropUtils.java test/org/apache/shale

2006-01-17 Thread gvanmatre

Author: gvanmatre
Date: Tue Jan 17 20:35:49 2006
New Revision: 370045

URL: http://svn.apache.org/viewcvs?rev=370045&view=rev
Log:
Refactored removing a dependency with commons-beanutils by using the new 
ProperyHelper and ConverterHelper classes in the shale core library.

Removed:

struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/utils/PropUtils.java

struts/shale/trunk/clay-plugin/src/test/org/apache/shale/clay/utils/PropUtilsTestCase.java
Modified:

struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/PropertyValueCommand.java

Modified: 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/PropertyValueCommand.java
URL: 
http://svn.apache.org/viewcvs/struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/PropertyValueCommand.java?rev=370045&r1=370044&r2=370045&view=diff
==
--- 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/PropertyValueCommand.java
 (original)
+++ 
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/PropertyValueCommand.java
 Tue Jan 17 20:35:49 2006
@@ -20,6 +20,7 @@
 
 import javax.faces.component.UIComponentBase;
 import javax.faces.context.FacesContext;
+import javax.faces.el.PropertyNotFoundException;
 import javax.faces.el.ValueBinding;
 
 import org.apache.commons.chain.Command;
@@ -28,8 +29,9 @@
 import org.apache.commons.logging.LogFactory;
 import org.apache.shale.clay.config.beans.AttributeBean;
 import org.apache.shale.clay.config.beans.ComponentBean;
-import org.apache.shale.clay.utils.PropUtils;
 import org.apache.shale.faces.ShaleConstants;
+import org.apache.shale.util.ConverterHelper;
+import org.apache.shale.util.PropertyHelper;
 import org.apache.shale.util.Tags;
 
 /**
@@ -48,6 +50,54 @@
 }
 
 /**
+ * Helper class to provide access to the properties of JavaBeans.
+ */
+private PropertyHelper propertyHelper = new PropertyHelper();
+
+/**
+ * Helper class to provide access to by-type JavaServer Faces
+ * Converter capabilities.
+ */
+private ConverterHelper converterHelper = new ConverterHelper();
+
+/**
+ * Sets a property value on the target component.  If the data
+ * type of the target bean property is not a String and the property
+ * value is a String, the data type is converted to the target type
+ * using the ConverterHelper.  The value is applied to
+ * the component using PropertyHelper. 
+ */
+private void setProperty(FacesContext context, Object target, String 
propertyName, Object propertyValue) {
+Class classz = null;
+StringBuffer actualPropertyName = new StringBuffer(propertyName);
+
+try {
+classz = propertyHelper.getType(target, 
actualPropertyName.toString());
+} catch (PropertyNotFoundException e) {
+if (propertyName.length() > 3 && propertyName.startsWith("is") ) {
+   actualPropertyName.delete(0, 2);
+   actualPropertyName.setCharAt(0, 
Character.toLowerCase(actualPropertyName.charAt(0)));
+
+   classz = propertyHelper.getType(target, 
actualPropertyName.toString());
+} else {
+   throw e;
+}
+  
+}
+
+if (classz != Object.class && classz != propertyValue.getClass() 
+&& propertyValue.getClass() == String.class) {
+   
+Object targetValue = converterHelper.asObject(context, classz, 
(String) propertyValue);
+propertyHelper.setValue(target, actualPropertyName.toString(), 
targetValue);
+} else {
+propertyHelper.setValue(target, actualPropertyName.toString(), 
propertyValue);
+}
+
+}
+
+
+/**
  * 
  * Looks at the [EMAIL PROTECTED] AttributeBean} on the [EMAIL PROTECTED] 
ClayContext} to see
  * if the value is a binding EL.  If it is not it just updates the 
component
@@ -119,8 +169,8 @@
 ValueBinding vb = 
facesContext.getApplication().createValueBinding(expr);
 Object value = vb.getValue(facesContext);
 try {
-PropUtils.setProperty(child, attributeBean.getName(), value);
- } catch (Exception e) {
+setProperty(facesContext ,child, attributeBean.getName(), 
value);
+} catch (Exception e) {
  if (child instanceof UIComponentBase)
((UIComponentBase) 
child).getAttributes().put(attributeBean.getName(), expr); 
  else
@@ -128,7 +178,7 @@
  }
 } else  {
 try {
-   PropUtils.setProperty(child, attributeBean.getName(), expr);
+   setProperty(facesContext, child, attributeBean.getName(), expr);
 } catch (Exception e) {
 if (ch

Re: Non-discussion emails

Fair enough to wait a few months while infrastructure sorts things out.
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=14616&messageID=29056#29056


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

Re: svn commit: r369992 - in /struts/shale/trunk/tiger: nbproject/private/ src/java/org/apache/shale/tiger/faces/ src/test/org/apache/shale/tiger/config/ src/test/org/apache/shale/tiger/faces/

2006-01-17 Thread Gary VanMatre

>On 1/17/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>>
>> This seems like a handly utility.  Clay has something similar, PropUtils,
>> that uses the ConvertUtils.  I think we could refactor to use this
>> utility.  Is there a specific reason that you wanted to factor out Commons
>> BeanUtils?
>
>
>Yes ... it seems to be the source of some memory leaks from not always
>getting cleaned up at runtime.  Plus, when I develop on Windows,
>commons-beanutils.jar gets left locked a lot, meaning you have to restart
>your container to be able to do a clean rebuild.
>
>This doesn't help a lot right at the moment, because we still inherit the
>dependency from Digester and the JSF implementation if its bundled.  But
>it's a step down the path of simplifying the dependency hierarchy for Shale,
>especially in a JavaEE 5 world where the JSF implementation will already be
>provided by the container.

That snapped in very nicely :-)   Along the same lines, have you looked at the 
org.apache.shale.usecases.rolodex.GenericComparator?  It might be a canidate
for the core utils if we plugged in the FacesContext?

>>Gary
>Craig
Gary

Re: svn commit: r369992 - in /struts/shale/trunk/tiger: nbproject/private/ src/java/org/apache/shale/tiger/faces/ src/test/org/apache/shale/tiger/config/ src/test/org/apache/shale/tiger/faces/

2006-01-17 Thread Craig McClanahan

On 1/17/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> >On 1/17/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> >>
> >> This seems like a handly utility.  Clay has something similar,
> PropUtils,
> >> that uses the ConvertUtils.  I think we could refactor to use this
> >> utility.  Is there a specific reason that you wanted to factor out
> Commons
> >> BeanUtils?
> >
> >
> >Yes ... it seems to be the source of some memory leaks from not always
> >getting cleaned up at runtime.  Plus, when I develop on Windows,
> >commons-beanutils.jar gets left locked a lot, meaning you have to restart
> >your container to be able to do a clean rebuild.
> >
> >This doesn't help a lot right at the moment, because we still inherit the
> >dependency from Digester and the JSF implementation if its bundled.  But
> >it's a step down the path of simplifying the dependency hierarchy for
> Shale,
> >especially in a JavaEE 5 world where the JSF implementation will already
> be
> >provided by the container.
>
> That snapped in very nicely :-)

Cool.  I should, for the record, mention one other practical reason for this
change ... the new ConverterHelper uses the registered by-type converters
that the JSF application is using for everything else, rather than the set
of BeanUtils converters that are registered separately.  That would seem to
meet developer expectations better than the way it was before.

   Along the same lines, have you looked at the
> org.apache.shale.usecases.rolodex.GenericComparator?  It might be a
> canidate
> for the core utils if we plugged in the FacesContext?

I can see how you could leverage PropertyHelper here (and with that it would
make a dandy utility helper class).   But I don't think you actually need
type conversion support, right?  If so, we don't need to worry about a
FacesContext.  The PropertyHelper methods do not need one.

>>Gary
> >Craig
> Gary
>

Craig

Re: Checkstyle (was svn commit: r360442 [1/3] )