Re: [VOTE] Proposed Committer James Holmes

[dion]

+1 from a non-committer.
--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


   

Ted Husted 

cc:   

 Subject: [VOTE] Proposed Committer James 
Holmes   
06/18/02 09:33 

PM 

Please respond 

to "Struts 

Developers 

List"  

   

   





James is a longstanding member of the Struts community and has been
submitting and vetting a good number of patches for Struts 1.1 beta 1.
He's been distributing and maintaining his own Struts add-in (the
Console) for some time, and has shown he can manage a public project
from soup to nuts. I believe he would be a good addition to the team,
and I hereby propose him as a Struts Committer. He has my +1.

Votes please?

-Ted.

Note that I have no idea whether James would be interested in donating
the Console to the ASF or not, but that would be a separate issue, and
is not the subject of this vote.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9933] - add a new resource to Contributor Extensions

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9933

add a new resource to Contributor Extensions





--- Additional Comments From [EMAIL PROTECTED]  2002-06-18 19:41 ---
James Holmes told me that Ted Husted was reviewing the resource page. I'll ask 
him if he wants to add the link before to make a patch.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: thank you

[Ted Husted]

Hey, I'm just too lazy to keep applying your patches =;o)

-T.

James Holmes wrote:
> 
> I want to thank Ted for [nominating] me to become a
> committer and to thank everyone who has voted for me.
> I’m honored to have been selected.
> 
> I’m anxious to dig in and make meaningful
> contributions.
> 
> Thanks,
> 
> James Holmes
> [EMAIL PROTECTED]
> http://www.jamesholmes.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

thank you

[James Holmes]

I want to thank Ted for electing me to become a
committer and to thank everyone who has voted for me. 
I’m honored to have been selected.

I’m anxious to dig in and make meaningful
contributions.

Thanks,

James Holmes
[EMAIL PROTECTED]
http://www.jamesholmes.com/struts/


__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Display request parameter instead of bean property?

[Tomas Viberg]

Yes, I found the discussion in the users list and will now change my behaviour :-)

/ Tomas


- Original Message - 
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 18, 2002 5:53 PM
Subject: Re: Display request parameter instead of bean property?


> 
> 
> On Tue, 18 Jun 2002, Tomas Viberg wrote:
> 
> > Date: Tue, 18 Jun 2002 13:15:20 +0200
> > From: Tomas Viberg <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Display request parameter instead of bean property?
> >
> > Hello,
> >
> > I've been thinking... Wouldn't it be a good idea that some form fields
> > (text, textarea, etc.), could display the value of the request parameter
> > instead of the bean property under some circumstances. One example when
> > this would be nice is when the conversion of the input value to the
> > target type fails. For instance, if I enter '1.0' in a form field mapped
> > to a bean property of type int, the field contains '0' when it is
> > redisplayed. In this case, I think it would be better if it displayed
> > the (invalid) value entered by the user.
> >
> 
> That is why your form bean properties should generally be strings, and you
> should do the conversion to int later (creating an error message if
> conversion fails).
> 
> > Anybody agree/disagree?
> >
> > Regards,
> > Tomas Viberg <[EMAIL PROTECTED]>
> >
> 
> Craig
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed Committer James Holmes

[Craig R. McClanahan]

+1

Craig


On Tue, 18 Jun 2002, Ted Husted wrote:

> Date: Tue, 18 Jun 2002 07:33:44 -0400
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Proposed Committer James Holmes
>
> James is a longstanding member of the Struts community and has been
> submitting and vetting a good number of patches for Struts 1.1 beta 1.
> He's been distributing and maintaining his own Struts add-in (the
> Console) for some time, and has shown he can manage a public project
> from soup to nuts. I believe he would be a good addition to the team,
> and I hereby propose him as a Struts Committer. He has my +1.
>
> Votes please?
>
> -Ted.
>
> Note that I have no idea whether James would be interested in donating
> the Console to the ASF or not, but that would be a separate issue, and
> is not the subject of this vote.
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Display request parameter instead of bean property?

[Craig R. McClanahan]

On Tue, 18 Jun 2002, Tomas Viberg wrote:

> Date: Tue, 18 Jun 2002 13:15:20 +0200
> From: Tomas Viberg <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Display request parameter instead of bean property?
>
> Hello,
>
> I've been thinking... Wouldn't it be a good idea that some form fields
> (text, textarea, etc.), could display the value of the request parameter
> instead of the bean property under some circumstances. One example when
> this would be nice is when the conversion of the input value to the
> target type fails. For instance, if I enter '1.0' in a form field mapped
> to a bean property of type int, the field contains '0' when it is
> redisplayed. In this case, I think it would be better if it displayed
> the (invalid) value entered by the user.
>

That is why your form bean properties should generally be strings, and you
should do the conversion to int later (creating an error message if
conversion fails).

> Anybody agree/disagree?
>
> Regards,
> Tomas Viberg <[EMAIL PROTECTED]>
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Authentication

[James Holmes]

Sandra--

This message should be posted to the Struts Users
mailing list: [EMAIL PROTECTED]

You should also check the mailing lists archives as
their have been numerous posts in the past about
Authentication.

http://www.mail-archive.com/struts-user%40jakarta.apache.org/

Hope that helps,

-james
[EMAIL PROTECTED]
http://www.jamesholmes.com/struts/


--- Heligon Sandra <[EMAIL PROTECTED]> wrote:
> 
>   Hi,
> 
>   I read a message on the struts-user mailing list
> which deals with
> "Authentication and
>   Authorization implementations" in struts.
>   Currently I am developing a struts application and
> I don't know what
> is the best solution
>   for managing authentication, use a subclass of
> ActionServlet or
> create a base Action with
>   the authentication code ? 
>   Has somebody a document that summarize all the
> solutions and the
> disadvantages/advantages
>   of each?
>   In this message François Rey mentioned a document
> about
> Authentication management and eShell framework how
> can   
>   I download it ?
> 
>   Thanks a lot in advance
>   Sandra
> 
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] Proposed Committer James Holmes

[Martin Cooper]

+1

--
Martin Cooper


> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 18, 2002 4:34 AM
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Proposed Committer James Holmes
> 
> 
> James is a longstanding member of the Struts community and has been
> submitting and vetting a good number of patches for Struts 1.1 beta 1.
> He's been distributing and maintaining his own Struts add-in (the
> Console) for some time, and has shown he can manage a public project
> from soup to nuts. I believe he would be a good addition to the team,
> and I hereby propose him as a Struts Committer. He has my +1.
> 
> Votes please?
> 
> -Ted.
> 
> Note that I have no idea whether James would be interested in donating
> the Console to the ASF or not, but that would be a separate issue, and
> is not the subject of this vote.
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Struts Authentication

[Heligon Sandra]

Hi,

I read a message on the struts-user mailing list which deals with
"Authentication and
Authorization implementations" in struts.
Currently I am developing a struts application and I don't know what
is the best solution
for managing authentication, use a subclass of ActionServlet or
create a base Action with
the authentication code ? 
Has somebody a document that summarize all the solutions and the
disadvantages/advantages
of each?
In this message François Rey mentioned a document about
Authentication management and eShell framework how can  
I download it ?

Thanks a lot in advance
Sandra


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9549] - "No getter method for property xxx of bean yyyy" while the bean HAS the method

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9549

"No getter method for property xxx of bean " while the bean HAS the method

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-06-18 14:53 ---
Thank you all for the comments.

We found that if an ActionForm property has a reference name with the first 
lowercase letter follwed by an uppercase letter (like in my case fEmision) the 
intropector ignores the getter for this bean. 

You can fix this changing the property name with AT LEAST TWO lower case 
characters at the beginning (we change it to fechaEmision). 

I relly don't know if this is a violation of the standards, but this naming 
style for the properties should be considered since it reduces extra typing.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed Committer James Holmes

[Arron Bates]

+1

Arron.


Ted Husted wrote:

>James is a longstanding member of the Struts community and has been
>submitting and vetting a good number of patches for Struts 1.1 beta 1.
>He's been distributing and maintaining his own Struts add-in (the
>Console) for some time, and has shown he can manage a public project
>from soup to nuts. I believe he would be a good addition to the team,
>and I hereby propose him as a Struts Committer. He has my +1.
>
>Votes please?
>
>-Ted.
>
>Note that I have no idea whether James would be interested in donating
>the Console to the ASF or not, but that would be a separate issue, and
>is not the subject of this vote.
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Proposed Committer James Holmes

[emmanuel.boudrant]

 If non committers can vote , then +1
-Emmanuel
  Ted Husted <[EMAIL PROTECTED]> a écrit : James is a longstanding member of the 
Struts community and has been
submitting and vetting a good number of patches for Struts 1.1 beta 1.
He's been distributing and maintaining his own Struts add-in (the
Console) for some time, and has shown he can manage a public project
from soup to nuts. I believe he would be a good addition to the team,
and I hereby propose him as a Struts Committer. He has my +1.

Votes please?

-Ted.

Note that I have no idea whether James would be interested in donating
the Console to the ASF or not, but that would be a separate issue, and
is not the subject of this vote.

--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



-
Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en français !

[VOTE] Proposed Committer James Holmes

[Ted Husted]

James is a longstanding member of the Struts community and has been
submitting and vetting a good number of patches for Struts 1.1 beta 1.
He's been distributing and maintaining his own Struts add-in (the
Console) for some time, and has shown he can manage a public project
from soup to nuts. I believe he would be a good addition to the team,
and I hereby propose him as a Struts Committer. He has my +1.

Votes please?

-Ted.

Note that I have no idea whether James would be interested in donating
the Console to the ASF or not, but that would be a separate issue, and
is not the subject of this vote.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Display request parameter instead of bean property?

[James Mitchell]

You should ask this on the users list.

There's already been detailed discussion on this topic there.

James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the "Open Minded Developer Network"
http://struts-atlanta.open-tools.org

> -Original Message-
> From: Tomas Viberg [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 18, 2002 7:15 AM
> To: [EMAIL PROTECTED]
> Subject: Display request parameter instead of bean property?
> 
> 
> Hello,
> 
> I've been thinking... Wouldn't it be a good idea that some form 
> fields (text, textarea, etc.), could display the value of the 
> request parameter instead of the bean property under some 
> circumstances. One example when this would be nice is when the 
> conversion of the input value to the target type fails. For 
> instance, if I enter '1.0' in a form field mapped to a bean 
> property of type int, the field contains '0' when it is 
> redisplayed. In this case, I think it would be better if it 
> displayed the (invalid) value entered by the user.
> 
> Anybody agree/disagree?
> 
> Regards,
> Tomas Viberg <[EMAIL PROTECTED]>
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Display request parameter instead of bean property?

[Tomas Viberg]

Hello,

I've been thinking... Wouldn't it be a good idea that some form fields (text, 
textarea, etc.), could display the value of the request parameter instead of the bean 
property under some circumstances. One example when this would be nice is when the 
conversion of the input value to the target type fails. For instance, if I enter '1.0' 
in a form field mapped to a bean property of type int, the field contains '0' when it 
is redisplayed. In this case, I think it would be better if it displayed the (invalid) 
value entered by the user.

Anybody agree/disagree?

Regards,
Tomas Viberg <[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9949] New: - Suggest, a 'multiple' attribute for the

[bugzilla]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9949

Suggest, a 'multiple' attribute for the  tag

I am developing a JSP which may or may not be passed request (1 or more) 
parameters. As such at the start of my JSP, I have:



If there are parameters in the request “param1” above will be set to a 
java.lang.String[]

But if there are no parameters in the request object, this raises a 
JSPException. So had to enclose this within a 
tag

But here-in I had to specify the parameter name that is expected. (the problem 
I face here is my JSP does not know before hand what parameter to expect)

So suggest an attribute like “multiple” for the 
tag

Which will return true, if they are 1 or more parameters in the request object. 
(better that checking for the existence of a particular parameter in the 
request)

This could be extended to other logic tags where-ever appropriate.

rgds g1

--
To unsubscribe, e-mail:   
For additional commands, e-mail: