DO NOT REPLY [Bug 15657] New: - NotSerializableException while trying to write byte data in ServletOutputStream from Action Class

[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=15657

NotSerializableException while trying to write byte data in ServletOutputStream from 
Action Class

   Summary: NotSerializableException while trying to write byte data
in ServletOutputStream from Action Class
   Product: Struts
   Version: 1.1 Beta 1
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Utilities
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am getting "java.io.NotSerializableException: 
org.apache.struts.action.RequestProcessor" while trying to write byte data in 
ServletOutputStream from Action Class. In the stacktrace, i can see the 
exception occuring at line 1165 of RequestUtils.java.

In my application i need to write the binary data(i.e.,Image) in to the 
ServletOutputStream object of my Action Class. So, following are the steps i 
did to achieve it..

1. In execute() method of my Action class, i got the ServletOutputStream 
object from your HttpServletResponse object(which is passed as a parameter).

ServletOutputStream output = p_response.getOutputStream();
p_response.setContentType("image/png");
output.write(chart.getImageBytes());

2. In my mapping.findForward() i will pass null instead of a valid forward 
string..In that case, i will get whatever the content i have set in the 
outputstream..

3. The above works mostly (80%) of times when i invoke the action..I am able 
to see the image in Browse (which i have written in to the ServletOutputStream 
of my Action class). But rarely, i am getting the below said exception. Could 
you please let me know the fix??

NOTE:

The above said scenario works fine if i do the same in .jsp with scriplets
(bypassing struts framework) instead of doing it in Action class. I don't want 
to do this as my client requirement is to adhere to Struts Framework..


Detailed Exception log
--
Mode:byFamily
Mode:byRow
Mode:byVariant
Mode:viewreport
   <[WebAppServletContext
(2736248,gbomapp,/gbomapp)] Could not deserialize context a
ttribute
java.io.NotSerializableException: org.apache.struts.action.RequestProcessor
at java.io.ObjectOutputStream.outputObject
(ObjectOutputStream.java:1148)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at java.io.ObjectOutputStream.outputClassFields
(ObjectOutputStream.java:1827)
at java.io.ObjectOutputStream.defaultWriteObject
(ObjectOutputStream.java:480)
at java.io.ObjectOutputStream.outputObject
(ObjectOutputStream.java:1214)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366)
at weblogic.servlet.internal.AttributeWrapper.getObject
(AttributeWrapper.java:92)
at weblogic.servlet.internal.AttributeWrapper.getObject
(AttributeWrapper.java:64)
at weblogic.servlet.internal.WebAppServletContext.getAttribute
(WebAppServletContext.java:306)
at org.apache.struts.util.RequestUtils.selectApplication
(RequestUtils.java:1165)
at org.apache.struts.action.ActionServlet.process
(ActionServlet.java:1061)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:439)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet
(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet
(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet
(WebAppServletContext.java:2495)
at weblogic.servlet.internal.ServletRequestImpl.execute
(ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
>
   <[WebAppServletContext
(2736248,gbomapp,/gbomapp)] Servlet failed with Exception
java.lang.ClassCastException: org.apache.struts.util.PropertyMessageResources
at org.apache.struts.util.RequestUtils.selectApplication
(RequestUtils.java:1169)
at org.apache.struts.action.ActionServlet.process
(ActionServlet.java:1061)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:439)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet
(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet

cvs commit: jakarta-struts/doc/resources powered.xml

[jmitchell]

jmitchell2002/12/24 22:25:04

  Modified:doc/resources powered.xml
  Log:
  Removing Povoglie, cannot find reference anywhere to Struts, or even Apache.
  
  If I'm wrong, please resubmit with correct link.
  
  Revision  ChangesPath
  1.10  +0 -1  jakarta-struts/doc/resources/powered.xml
  
  Index: powered.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/resources/powered.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- powered.xml   24 Dec 2002 01:19:47 -  1.9
  +++ powered.xml   25 Dec 2002 06:25:04 -  1.10
  @@ -35,7 +35,6 @@
   http://www.webappcabaret.com/normad";>Normad - Web Timesheet 
Management System.
   https://www.organox.com.br/";>Organonx
   http://www.pizzahut.com.au/";>Pizza 
Hut Online / Sydney Metro - For pickup or delivery in the Sydney Metro 
area.
  -http://www.readymindsjobs.com/";>ReadyMinds Jobs - Online job posting 
and placement system using Struts and Tiles on JBoss and Tomcat.
   http://www.reviewalert.com/";>Review 
Alert - Free service that allows you to be notified when new reviews are 
posted on Amazon.com for dvds, music cds, books on any topic.
  
  
  

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

Re: LookupDispatchAction with ImageButtonBean

[Erik Hatcher]

I think Ted's FindForwardAction (this is in the Scaffold codebase, I 
assume, and also in his book) is the right answer for dealing with 
image buttons *and* text buttons together.  In fact, this is really the 
solution that I think beats LookupDispatchAction - although it makes 
extra mappings and potentially more Action subclasses, it seems pretty 
slick and clean to me.

	Erik


On Tuesday, December 24, 2002, at 10:14  PM, Brian Moseley wrote:

is there any possible way for LookupDispatchAction and ImageButtonBean
to work together?

since  elements don't send a proper value, but simply
coordinates, LDA's standard mechanism for choosing an action method
based on a single parameter doesn't work. furthermore, if you're using
multiple ImageButtonBeans, they all probably have different names 
anyway.

doesn't look very challenging to make LDA examine multiple (probably
ordered) parameters and simply dispatch based on the first existing
parameter. i guess it wouldn't even have to know anything about
ImageButtonBean, at that.

anybody have a better idea? has this been discussed before?



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





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

Re: modifying the mapping input path during validation

[Brian Moseley]

Ted Husted wrote:
> My first suggestion would be try not to think in terms of request
> parameters and try to think in terms of ActionForm properties.
> Generally, all the request parameters should be represented as
> ActionForm properties. Struts will then take care of automatically
> populating the properties.
>
> My second suggestion would be to try and put gory details like id=
> 104 behind ActionForward. Instead creating an ActionForward by
> appending the parameter, you can call the forward by name. I don't
> know what 104 does, but you could have the equivalent of
>
> 
>
> Where home104 is a descriptive name rather than an arbitrary
> identifier.
>
> My third suggestion would be to use an ActionMapping for the input
> property rather than a presentation page. Ideally, all pages
> should be behind ActionMapping handlers. If you need to apply some
> post-validation logic or seed any properties (!parameters) on the
> ActionForm, you can do that here.

several fine suggestions; thanks very much for the feedback. my struts
work is much more sophisticated now that i've started asking questions
of the experts :)



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

Re: modifying the mapping input path during validation

[Brian Moseley]

Erik Hatcher wrote:

> Yes, but only if you tell your action mapping the form bean associated
> with it, and from what you showed above, you don't.

yep, that was silly eh? i hadn't even considered that the form could be
shared across actions like that. i was certain that you guys would have
already solved this problem.. :) thanks again!




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

LookupDispatchAction with ImageButtonBean

[Brian Moseley]

is there any possible way for LookupDispatchAction and ImageButtonBean
to work together?

since  elements don't send a proper value, but simply
coordinates, LDA's standard mechanism for choosing an action method
based on a single parameter doesn't work. furthermore, if you're using
multiple ImageButtonBeans, they all probably have different names anyway.

doesn't look very challenging to make LDA examine multiple (probably
ordered) parameters and simply dispatch based on the first existing
parameter. i guess it wouldn't even have to know anything about
ImageButtonBean, at that.

anybody have a better idea? has this been discussed before?



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

[OT] Merry Xmas. Kwanza, Navidad, Weihnacht

[Peter A. Pilgrim]

This is Peter Pilgrim, "live en la casa en London"

Merry Christmas, Happy Kwanza, Happy Holidays, or Winter Festival,
"Schoene Weihnachten", "Buena Navidad"
and Bottom Solstice Interlude to everybody.

Keep on moving

--
Peter Pilgrim
ServerSide Java Specialist

My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''


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

Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)

[Martin Cooper]

On Tue, 24 Dec 2002, Ted Husted wrote:

> >http://jakarta.apache.org/struts/proposals/release-plan-
> 1.1b3.html
>
> I would remove
>
> 14042 - Unknown Memory leaks with JBoss 3.x +(Tomcat/Jetty)
>
> as a "must have" since I don't think we can commit to curing a
> problem with an "unknown" cause in a specific container.

The plan doesn't say we're committing to fixing the problem, it says the
problem report must be resolved before final release of Struts 1.1. I
believe we need to do that, even if we have to mark it LATER because we
haven't been able to reproduce it or track it down by the time we're
otherwise ready for a final release.

Since I'm using JBoss/Jetty in my "day job" these days, I'll be keeping an
eye out for this problem in any case.

>
> I would add
>
> 13645 - add action attribute in 

I wouldn't want to start adding enhancement requests to the list - that
would be the start of a slippery slope. However, if you want to claim that
this is a bug rather than an enhancement request, then I don't have a
strong objection to adding it (assuming someone will commit to fixing it
before 1.1 final).

>
> Otherwise, +1
>
> I am also not clear if the list needs to be resolved before b3
> ships. At this point, I believe at this point we should be
> striving for something we can just release if nothing unexpected
> turns up; so whatever *needs* to be in the release should also be
> in b3.

As stated in the second para of the Release Criteria, the items in the
list must be resolved prior to a subsequent release candidate.

One point Craig brought up before is that we agreed to switch over to use
Commons Resources prior to 1.1 final. Unless that happens before this
coming freeze date, we can't call this anything other than a Beta.

>
> Also, is the freeze date [29-JAN-2002 00:00] or [29-JAN-2002
> 24:59]?

By convention, the freeze date is neither of the above ;-) it's
29-DEC-2002 23:59 PST.

--
Martin Cooper


>
> -Ted.
>
>
>
> 12/23/2002 5:36:47 PM, Martin Cooper <[EMAIL PROTECTED]> wrote:
>
> >A number of new features have been added to Struts since the 1.1
> Beta 2
> >release, and many bugs have been fixed. Therefore, I propose that
> we
> >release the tip of the main trunk in CVS as Beta 3 for a Struts
> 1.1
> >release. I have checked in a proposed release plan, revised from
> the
> >previous version, which is available for review on the Struts web
> site:
> >
> >http://jakarta.apache.org/struts/proposals/release-plan-
> 1.1b3.html
> >
> >Release plans must pass by a majority vote of committers on the
> project,
> >but all other interested parties are welcome to cast their votes
> (and/or
> >make comments or suggestions on the plan) as well.
> >
> >
> >-
> -
> >Vote:  Struts 1.1b3 Release Plan
> >[ ] +1 I am in favor of the release, and will help support it
> >[ ] +0 I am in favor of the release, but am unable tohelp support
> it
> >[ ] -0 I am not in favor of the release
> >[ ] -1 I am against this proposal (must include a reason).
> >-
> -
> >
> >I am +1 on the Struts 1.1b3 release plan.
> >
> >--
> >Martin Cooper
> >
> >
> >--
> >To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> >For additional commands, e-mail:  [EMAIL PROTECTED]>
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: Fwd: typo on Struts page

[Martin Cooper]

On Tue, 24 Dec 2002, Ted Husted wrote:

> This is fixed in the current release notes, but I'm not sure if we
> should rewrite history and change the archival version.

The link referred to in the original message has been fixed already. Don't
know who did it or when, but it's not an issue now. ;-)

--
Martin Cooper


>
> 12/22/2002 9:01:19 PM, Pier Fumagalli <[EMAIL PROTECTED]> wrote:
>
> >FYI - Not acked.
> >
> > Pier
> >
> >Begin forwarded message:
> >
> >> From: Kris Resellmo <[EMAIL PROTECTED]>
> >> Date: Mon Dec 23, 2002  1:58:11 AM Europe/London
> >> To: [EMAIL PROTECTED]
> >> Subject: typo on Struts page
> >>
> >> http://jakarta.apache.org/struts/userGuide/release-notes-1.1-
> >> b2.html#New
> >>
> >> One line in this section reads:
> >> Nested - An very cool taglib extension
> >>
> >> It should probably be:
> >> Nested - A very cool tagbli extension
> >>
> >>
> >>
> >>
> >>
> >> Kris Resellmo
> >> Northwestern University, Evanston, IL.  USA
> >> [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >--
> >To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> >For additional commands, e-mail:  [EMAIL PROTECTED]>
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

RE: Overloaded Setters in Form

[Carl Fyffe]

I am trying to use overloaded methods because I am looping through XML
to populate forms.  I don't always know exactly which elements will be
returned, so I have a "map" of the possible elements that can be
returned which points to the proper property of the Form. I then use
PropertyUtils.setNestedProperty() to populate my Form.

I was not up to speed on the conversion utilities when I started this
project, so I created a DateForm.  This DateForm is nested into almost
all of my other Forms.  So, when I am looping through the XML and I
happen upon a date, I want to do setDateProperty(String) instead of
setDateProperty(DateForm).

I will start looking at the problem again on Thursday.  Craig, thank you
for clearing this up!

Carl


-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, December 24, 2002 1:26 PM
To: Struts Developers List
Subject: RE: Overloaded Setters in Form




On Tue, 24 Dec 2002, Carl Fyffe wrote:

> Date: Tue, 24 Dec 2002 13:12:48 -0500
> From: Carl Fyffe <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Overloaded Setters in Form
>
> Edgar does have a point, the spec doesn't say beans *bad joke* about 
> overloading.

It actually does, but by omission, not comission :-).  See below.

>  I gave it another go after reading (AGAIN) Craig's first post on this

> topic (12/14/2002) and this time, instead of using a null getter, I 
> provided a getter for the overloaded setter.  Still does not work.  
> Introspector only returns one PropertyDescriptor for the property.  
> Edgar and Craig both lead me to believe that this is possible, but I 
> am starting to think that I am trying to put a square peg in a round 
> hole.
>

Please give up now :-).  Consider the fact that trying to create
overloaded setters will actually compile:

public void setProp(Foo foo) { ... }
public void setProp(Bar bar) { ... }

(even though Java won't recognize "prop" as a valid JavaBeans property),
but trying to create overloaded getters will give you a compile error:

public Foo getProp() { ... }
public Bar getProp() { ... }

The bottom line is that the design pattern for JavaBeans properties
talks about a getter *method* (singular) and/or a setter *method*
(singular) with no mention of *methods* (plural) in either scenario.
This is also reflected in the introspection APIs -- consider for example
the following methods on java.beans.PropertyDescriptor (which is what
beanutils is using under the covers to call the getter and setter
dynamically):

public Method getReadMethod();
public Method getWriteMethod();

Even assuming you tried to create a write-only property with just the
two set methods, there is no reaonable rule for Java to choose which one
to return via getWriteMethod().  So, the language punts and decides that
you have not defined a property at all.

> Edgar: Would you be willing to share some of your implementation 
> details?
>
> Architectural Gurus: The problem I am trying to solve is that I have a

> data source that returns Strings only (xml file), should I create 
> Beans specifically for that data source and then convert over to my 
> Form?
>

ActionForm beans should generally use String properties for anything
that is going to be updatable (by the user) via a text input field.
What kind of conversion do you need to do?  (Or, more broadly, why are
you trying to use overloaded property methods in the first place?)

> Thanks for all of your help,
>
> Carl

Craig


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

Re: Tying Up Loose Ends

[Eddie Bush]

What I've been doing is going to the query page, selecting all 
severities except enhancement - then selecting struts.  I believe this 
is the method Martin was using, though he could tell you better - as 
best I can recall, that is the method to use.

Ted Husted wrote:

Is it not the idea that the computers are suppose to do the 
counting for us? =:0) =:0)

12/24/2002 2:45:11 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> 
wrote:
 

Count the non-enhancement ones :-).



--
Eddie Bush





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

Re: [PROPOSED] html:link should have an "action=" option

[Peter A. Pilgrim]

James Turner wrote:

I find I write a lot of code that uses an intermediate action to link
between two web pages (this is good Struts policy in general)  However,
since the html:link tag has a forward= but no action=, I have to use
page= and supply a URI with the ".do" extension at the end, rather than
being about to use action= as I would with an html:form.  What do folks
think about adding action= to html:link?


I dont think this a problem. Normally you want to provide servlet request
parameters such also.

--
Peter Pilgrim
ServerSide Java Specialist

My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''


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

Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)

[Peter A. Pilgrim]

James Mitchell wrote:


Vote:  Struts 1.1b3 Release Plan
[X] +1 I am in favor of the release, and HAVE HELPED support it
[ ] +0 I am in favor of the release, but am unable tohelp support it
[ ] -0 I am not in favor of the release
[ ] -1 I am against this proposal (must include a reason).



--
Peter Pilgrim
ServerSide Java Specialist

My on-line resume and for interview videos about myself, J2EE
Open Source, Struts and Expresso.
   ||
   \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''


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

Re: Tying Up Loose Ends

[Ted Husted]

Is it not the idea that the computers are suppose to do the 
counting for us? =:0) =:0)

12/24/2002 2:45:11 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> 
wrote:
>
>Count the non-enhancement ones :-).




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

Re: Tying Up Loose Ends

[Craig R. McClanahan]

On Tue, 24 Dec 2002, Ted Husted wrote:

> Date: Tue, 24 Dec 2002 14:27:11 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tying Up Loose Ends
>
> Yes, but it doesn't return 14 tickets when I run it, it returns
> 45.

Count the non-enhancement ones :-).

>
> -T.
>

Craig

> 12/24/2002 2:07:00 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> >
> >
> >On Tue, 24 Dec 2002, Ted Husted wrote:
> >
> >> Date: Tue, 24 Dec 2002 09:17:20 -0500
> >> From: Ted Husted <[EMAIL PROTECTED]>
> >> Reply-To: Struts Developers List  [EMAIL PROTECTED]>
> >> To: Struts Developers List <[EMAIL PROTECTED]>
> >> Subject: Re: Tying Up Loose Ends
> >>
> >> 12/23/2002 5:31:07 PM, "Craig R. McClanahan"
> <[EMAIL PROTECTED]>
> >> wrote:
> >> >14, counting some that are documentation related.
> >>
> >> Craig, could you please post an active link to the Bugzilla
> query
> >> that produces this list on the Roadmap, so that we are all on
> the
> >> same page.
> >>
> >
> >There's already such a query on the roadmap page:
> >
> >  http://jakarta.apache.org/struts/status.html
> >
> >It's in the last bullet under Struts 1.1:
> >
> >  * Other routine changes per Bugzilla and Dev List
> >
> >I'm going to modify the text so that it's more obvious, though.
> >
> >> -Ted.
> >>
> >
> >Craig
> >
> >
> >--
> >To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> >For additional commands, e-mail:  [EMAIL PROTECTED]>
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

RE: Overloaded Setters in Form

[Craig R. McClanahan]

On Tue, 24 Dec 2002, Edgar P. Dollin wrote:

> Date: Tue, 24 Dec 2002 13:47:18 -0500
> From: Edgar P. Dollin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Overloaded Setters in Form
>
> I switch between booleans and strings for actions and imbed actions into
> a 'generic' class.  Struts currently, doesn't have a problem with this
> (at least in the current versions).
>
> Is there a chance this will stop working?
>

You'll have to give us an example of your sources (apologies if you've
done this already).  If you are overloading getters and setters today, and
you're using BeanUtils and PropertyUtils mechanisms to call them (which is
what Struts does when dealing with form beans) , it should not be working
now.

If you're using introspection to directly pick a Method to call, and
bypassing the PropertyDescriptors, then you are not subject to the design
pattern restrictions on method names -- none of that is relevant since you
are not treating them as properties.  But you would also be confusing
everybody else on this mailing list who is going to assume (like I did)
that you're talking about using the standard reflection mechanisms for
JavaBeans *properties*.

> Edgar
>

Craig



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

DO NOT REPLY [Bug 15196] - Bug on the RequestUtils.computeParameters using a DynaValidatorForm as map of the parameter

[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=15196

Bug on the RequestUtils.computeParameters using a DynaValidatorForm as map of the 
parameter

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-12-24 19:38 ---
Because DynaValidatorForm implements org.apache.commons.beanutils.DynaBean, the
getMap() method is not recognized as a property getter.  It is only there to
make the properties of a DynaBean accessible when using the expression language
syntax of JSTL tags (or struts-el tags that use the same syntax).

Try using the "frame" tag from the struts-el library (included in the "contrib"
subdirectory of recent nightly builds.

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

Re: Tying Up Loose Ends

[Ted Husted]

Yes, but it doesn't return 14 tickets when I run it, it returns 
45. 

-T.

12/24/2002 2:07:00 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> 
wrote:

>
>
>On Tue, 24 Dec 2002, Ted Husted wrote:
>
>> Date: Tue, 24 Dec 2002 09:17:20 -0500
>> From: Ted Husted <[EMAIL PROTECTED]>
>> Reply-To: Struts Developers List 
>> To: Struts Developers List <[EMAIL PROTECTED]>
>> Subject: Re: Tying Up Loose Ends
>>
>> 12/23/2002 5:31:07 PM, "Craig R. McClanahan" 
<[EMAIL PROTECTED]>
>> wrote:
>> >14, counting some that are documentation related.
>>
>> Craig, could you please post an active link to the Bugzilla 
query
>> that produces this list on the Roadmap, so that we are all on 
the
>> same page.
>>
>
>There's already such a query on the roadmap page:
>
>  http://jakarta.apache.org/struts/status.html
>
>It's in the last bullet under Struts 1.1:
>
>  * Other routine changes per Bugzilla and Dev List
>
>I'm going to modify the text so that it's more obvious, though.
>
>> -Ted.
>>
>
>Craig
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




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

RE: Overloaded Setters in Form

[Edgar P. Dollin]

I switch between booleans and strings for actions and imbed actions into
a 'generic' class.  Struts currently, doesn't have a problem with this
(at least in the current versions).

Is there a chance this will stop working?

Edgar



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

cvs commit: jakarta-struts/doc status.xml

[craigmcc]

craigmcc2002/12/24 11:23:14

  Modified:doc  status.xml
  Log:
  Refine the Bugzilla queries for the current bugs (under Struts 1.1) and
  the bugs marked for later review (under Struts 1.2), and make the text
  a little more obvious.
  
  Revision  ChangesPath
  1.19  +9 -5  jakarta-struts/doc/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/status.xml,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- status.xml1 Dec 2002 16:03:21 -   1.18
  +++ status.xml24 Dec 2002 19:23:14 -  1.19
  @@ -69,13 +69,16 @@
   
   
   Other routine changes per
  -http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&version=Unknown&version=1.0.1+Final&version=1.0+Final&version=1.0+Beta+3&version=1.0+Beta+2&version=1.0+Beta+1&version=0.5+Final&version=1.0.2+Final&version=1.1+Beta+1&version=1.1+Beta+2&version=Nightly+Build&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number";>
  -Bugzilla and 
  -http://nagoya.apache.org/eyebrowse/SummarizeList?listId=41";>Dev 
list
  +http://issues.apache.org/bugzilla/";>Bugzilla and the
  +http://nagoya.apache.org/eyebrowse/SummarizeList?listId=41";>
  +Developer mailing list.
   
   
   
   
  +A live query of the current outstanding bugs can be found
  +   http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Struts&order=%27Importance%27";>here.
  +
   
   
   
  @@ -83,7 +86,8 @@
   
   Struts 1.2.x will include additional functional enhancements along the 
   same lines as Struts 1.1, such as the items marked
  -http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=LATER&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Struts&version=Unknown&version=1.0+Beta+2&version=1.0+Beta+1&version=0.5+Final&version=1.0.2+Final&version=1.0.1+Final&version=1.0+Final&version=1.0+Beta+3&version=1.1+Beta+2&version=1.1+Beta+1&version=Nightly+Build&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Bug+Number";>LATER
 in Bugzilla.
  +http://issues.apache.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=LATER&resolution=REMIND&product=Struts&order=%27Importance%27";>
  +LATER or REMIND in Bugzilla.
   The platform requirements will remain the same (Servlet 2.2 / JSP 1.1). 
   The release will focus on refactoring of existing functionality, with a 
   continued emphasis on backward compatibility.
  
  
  

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

Re: Tying Up Loose Ends

[Craig R. McClanahan]

On Tue, 24 Dec 2002, Ted Husted wrote:

> Date: Tue, 24 Dec 2002 09:17:20 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tying Up Loose Ends
>
> 12/23/2002 5:31:07 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
> >14, counting some that are documentation related.
>
> Craig, could you please post an active link to the Bugzilla query
> that produces this list on the Roadmap, so that we are all on the
> same page.
>

There's already such a query on the roadmap page:

  http://jakarta.apache.org/struts/status.html

It's in the last bullet under Struts 1.1:

  * Other routine changes per Bugzilla and Dev List

I'm going to modify the text so that it's more obvious, though.

> -Ted.
>

Craig


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

DO NOT REPLY [Bug 14800] - Fix initialization bug and add size parameter to form-property

[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=14800

Fix initialization bug and add size parameter to form-property

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-12-24 18:52 ---
The use cases you presented are compelling, and they apply to scalar properties
also.  I also added the logic to use a zero-args constructor if you didn't
specify an "initial" attribute value, and expanded the documentation on the
initial() method to precisely describe its semantics.  Unit tests too, of course :-)

Fixed in nightly build 20021225.

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

cvs commit: jakarta-struts/src/test/org/apache/struts/util TestRequestUtils.java

[craigmcc]

craigmcc2002/12/24 10:49:52

  Modified:src/share/org/apache/struts/config FormPropertyConfig.java
   src/test/org/apache/struts/action TestDynaActionForm.java
TestDynaActionFormClass.java
   src/test/org/apache/struts/mock MockPrincipal.java
TestMockBase.java
   src/test/org/apache/struts/util TestRequestUtils.java
  Log:
  The second half of the fix for 14800.  The problem with mutable property
  values is *not* limited to array elements -- it will also occur when a
  scalar property is of a mutable type.  As a solution to this, initial()
  now calculates and returns a new value every time, rather than caching
  the old one.  This is a relatively minor performance hit, but not (in
  principle at least) any worse than evaluating the initialization expression
  for an instance variable in a JavaBean every time one is created.
  
  As an added benefit, the initial() method will also attempt to create
  instances of properties (via a zero-args constructor) if you did not specify
  an "initial" value to pass in to ConvertUtils.convert().  This is true both
  for scalar properties and for elements of arrays constructed with the
  "size" attribute.  In general, DynaActionForm beans now act very much more
  like standard ActionForm beans with respect to preinitialized property
  values than they did before these changes.
  
  PR: Bugzilla #14800
  Submitted by: James Turner 
  
  Revision  ChangesPath
  1.9   +62 -49
jakarta-struts/src/share/org/apache/struts/config/FormPropertyConfig.java
  
  Index: FormPropertyConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-struts/src/share/org/apache/struts/config/FormPropertyConfig.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- FormPropertyConfig.java   23 Dec 2002 22:00:24 -  1.8
  +++ FormPropertyConfig.java   24 Dec 2002 18:49:52 -  1.9
  @@ -138,18 +138,6 @@
   protected boolean configured = false;
   
   
  -/**
  - * Have we calculated the initial value object yet?
  - */
  -protected transient boolean initialized = false;
  -
  -
  -/**
  - * The calculated initial value for this property.
  - */
  -protected transient Object initialValue = null;
  -
  -
   // - Properties
   
   
  @@ -189,7 +177,8 @@
   
   /**
* The size of the array to be created if this property is an array
  - * type and there is no specified initial value.
  + * type and there is no specified initial value.  This
  + * value must be non-negative.
*
* @since Struts 1.1-b3
*/
  @@ -203,6 +192,9 @@
   if (configured) {
   throw new IllegalStateException("Configuration is frozen");
   }
  +if (size < 0) {
  +throw new IllegalArgumentException("size < 0");
  +}
   this.size = size;
   }
   
  @@ -288,46 +280,67 @@
   
   
   /**
  - * Return an object representing the initial value of this property.
  + * Return an object representing the initial value of this property.
  + * This is calculated according to the following algorithm:
  + * 
  + * If the value you have specified for the type
  + * property represents an array (i.e. it ends with "[]"):
  + * 
  + * If you have specified a value for the initial
  + * property, ConvertUtils.convert() will be
  + * called to convert it into an instance of the specified
  + * array type.
  + * If you have not specified a value for the initial
  + * property, an array of the length specified by the
  + * size property will be created.  Each element
  + * of the array will be instantiated via the zero-args constructor
  + * on the specified class (if any).  Otherwise, null
  + * will be returned.
  + * 
  + * If the value you have specified for the type
  + * property does not represent an array:
  + * 
  + * If you have specified a value for the initial
  + * property, ConvertUtils.convert()
  + * will be called to convert it into an object instance.
  + * If you have not specified a value for the initial
  + * attribute, Struts will instantiate an instance via the
  + * zero-args constructor on the specified class (if any).
  + * Otherwise, null will be returned.
  + * 
  + * 
*/
   public Object initial() {
   
  -// Compute our initial value the first time it is requested
  -// Don't bother synchronizing, a race is basically harmless
  -if (!initialized) {
  -try {
  -Class clazz = getTyp

RE: Overloaded Setters in Form

[Craig R. McClanahan]

On Tue, 24 Dec 2002, Carl Fyffe wrote:

> Date: Tue, 24 Dec 2002 13:12:48 -0500
> From: Carl Fyffe <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: Overloaded Setters in Form
>
> Edgar does have a point, the spec doesn't say beans *bad joke* about
> overloading.

It actually does, but by omission, not comission :-).  See below.

>  I gave it another go after reading (AGAIN) Craig's first
> post on this topic (12/14/2002) and this time, instead of using a null
> getter, I provided a getter for the overloaded setter.  Still does not
> work.  Introspector only returns one PropertyDescriptor for the
> property.  Edgar and Craig both lead me to believe that this is
> possible, but I am starting to think that I am trying to put a square
> peg in a round hole.
>

Please give up now :-).  Consider the fact that trying to create
overloaded setters will actually compile:

public void setProp(Foo foo) { ... }
public void setProp(Bar bar) { ... }

(even though Java won't recognize "prop" as a valid JavaBeans property),
but trying to create overloaded getters will give you a compile error:

public Foo getProp() { ... }
public Bar getProp() { ... }

The bottom line is that the design pattern for JavaBeans properties talks
about a getter *method* (singular) and/or a setter *method* (singular)
with no mention of *methods* (plural) in either scenario.  This is also
reflected in the introspection APIs -- consider for example the following
methods on java.beans.PropertyDescriptor (which is what beanutils is using
under the covers to call the getter and setter dynamically):

public Method getReadMethod();
public Method getWriteMethod();

Even assuming you tried to create a write-only property with just the two
set methods, there is no reaonable rule for Java to choose which one to
return via getWriteMethod().  So, the language punts and decides that you
have not defined a property at all.

> Edgar: Would you be willing to share some of your implementation
> details?
>
> Architectural Gurus: The problem I am trying to solve is that I have a
> data source that returns Strings only (xml file), should I create Beans
> specifically for that data source and then convert over to my Form?
>

ActionForm beans should generally use String properties for anything that
is going to be updatable (by the user) via a text input field.  What kind
of conversion do you need to do?  (Or, more broadly, why are you trying to
use overloaded property methods in the first place?)

> Thanks for all of your help,
>
> Carl

Craig


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

RE: Overloaded Setters in Form

[Tim Moore]

I think the issue is that a particular property has to have a specific
type.  When you start overloading methods, it becomes ambiguous.  It's
not even legal Java to overload on return type alone, so I'm not sure
what Edgar meant about overloading the getter.

It's perfectly fine, though, to have "linked" properties, i.e., two sets
of getters and setters (with different names) that internally set the
same field.  I often have sets of methods like getFoo/setFoo and
getFooAsString/setFooAsString.  The latter methods just call the normal
getter/setter with some kind of conversion.

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


> -Original Message-
> From: Carl Fyffe [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, December 24, 2002 1:13 PM
> To: 'Struts Developers List'
> Subject: RE: Overloaded Setters in Form
> 
> 
> Edgar does have a point, the spec doesn't say beans *bad 
> joke* about overloading.  I gave it another go after reading 
> (AGAIN) Craig's first post on this topic (12/14/2002) and 
> this time, instead of using a null getter, I provided a 
> getter for the overloaded setter.  Still does not work.  
> Introspector only returns one PropertyDescriptor for the 
> property.  Edgar and Craig both lead me to believe that this 
> is possible, but I am starting to think that I am trying to 
> put a square peg in a round hole.
> 
> Edgar: Would you be willing to share some of your 
> implementation details?
> 
> Architectural Gurus: The problem I am trying to solve is that 
> I have a data source that returns Strings only (xml file), 
> should I create Beans specifically for that data source and 
> then convert over to my Form?
> 
> Thanks for all of your help,
> 
> Carl
> 
> 
> 
> -Original Message-
> From: Edgar P. Dollin [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, December 24, 2002 10:26 AM
> To: 'Struts Developers List'
> Subject: RE: Overloaded Setters in Form
> 
> 
> I have had success overloading properties and used the effect 
> liberally. I have found that if you are consistent in your 
> overloading, i.e. for every setter of type x supply a getter 
> of type x as well (at least in the containers I am using) 
> they seem to function.  
> 
> Based on your comments, I have a concern that something will 
> break going forward.  I looked for overloading in the spec 
> (attached) and they don't specifically speak to the issue.
> 
>   http://java.sun.com/products/javabeans/docs/beans.101.pdf
> 
> Could you point me toward some documentation which gives more details?
> 
> Thanks
> 
> Edgar
> 
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, December 24, 2002 9:12 AM
> To: Struts Developers List
> Subject: Re: Overloaded Setters in Form
> 
> 
> It's contrary to the JavaBean specification to overload the 
> property methods (getters and setters), if that's what you are 
> trying to do. So, it won't work, because it's not suppose to.
> 
> -Ted.
> 
> 
> 12/23/2002 10:31:41 PM, Carl Fyffe <[EMAIL PROTECTED]> wrote:
> >Seasons greetings friends!
> >
> >I sent an email inquiring about overloaded setters in Forms to the 
> >struts-user mailing list.  I was told that I needed a 
> BeanInfo.  I gave
> >the BeanInfo a try and it did not work.  So, I started reading
> >code and
> >decided that an overloaded example in TestBean was needed.  Of 
> course it
> >now fails just like my example.  I am stuck there.  The 
> BeanInfo's that
> 
> >I have created, with and without my overloaded methods, do 
> not  work. 
> >Does anyone have a TestBeanBeanInfo that works?  Any advice would  be
> >greatly appreciated.
> >
> >Carl
> >
> >
> >--
> >To unsubscribe, e-mail:    [EMAIL PROTECTED]>
> >For additional commands, e-mail:  [EMAIL PROTECTED]>
> >
> >
> 
> 
> 
> 
> --
> To unsubscribe, e-mail: 
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 
> --
> To unsubscribe, e-mail: 
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

RE: Overloaded Setters in Form

[Edgar P. Dollin]

I am not using Introspector.  I either use low level introspection (in
which you can specifically set your object parameter types) or I let
struts do the introspection.  Perhaps your issue is just with
Introspector?

Edgar

-Original Message-
From: Carl Fyffe [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, December 24, 2002 1:13 PM
To: 'Struts Developers List'
Subject: RE: Overloaded Setters in Form


Edgar does have a point, the spec doesn't say beans *bad joke* about
overloading.  I gave it another go after reading (AGAIN) Craig's first
post on this topic (12/14/2002) and this time, instead of using a null
getter, I provided a getter for the overloaded setter.  Still does not
work.  Introspector only returns one PropertyDescriptor for the
property.  Edgar and Craig both lead me to believe that this is
possible, but I am starting to think that I am trying to put a square
peg in a round hole.

Edgar: Would you be willing to share some of your implementation
details?

Architectural Gurus: The problem I am trying to solve is that I have a
data source that returns Strings only (xml file), should I create Beans
specifically for that data source and then convert over to my Form?

Thanks for all of your help,

Carl



-Original Message-
From: Edgar P. Dollin [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, December 24, 2002 10:26 AM
To: 'Struts Developers List'
Subject: RE: Overloaded Setters in Form


I have had success overloading properties and used the effect liberally.
I have found that if you are consistent in your overloading, i.e. for
every setter of type x supply a getter of type x as well (at least in
the containers I am using) they seem to function.  

Based on your comments, I have a concern that something will break going
forward.  I looked for overloading in the spec (attached) and they don't
specifically speak to the issue.

http://java.sun.com/products/javabeans/docs/beans.101.pdf

Could you point me toward some documentation which gives more details?

Thanks

Edgar

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, December 24, 2002 9:12 AM
To: Struts Developers List
Subject: Re: Overloaded Setters in Form


It's contrary to the JavaBean specification to overload the 
property methods (getters and setters), if that's what you are 
trying to do. So, it won't work, because it's not suppose to.

-Ted.


12/23/2002 10:31:41 PM, Carl Fyffe <[EMAIL PROTECTED]> wrote:
>Seasons greetings friends!
>
>I sent an email inquiring about overloaded setters in Forms to the 
>struts-user mailing list.  I was told that I needed a BeanInfo.  I gave
>the BeanInfo a try and it did not work.  So, I started reading
>code and
>decided that an overloaded example in TestBean was needed.  Of 
course it
>now fails just like my example.  I am stuck there.  The BeanInfo's that

>I have created, with and without my overloaded methods, do not  work. 
>Does anyone have a TestBeanBeanInfo that works?  Any advice would  be
>greatly appreciated.
>
>Carl
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

RE: Overloaded Setters in Form

[Carl Fyffe]

Edgar does have a point, the spec doesn't say beans *bad joke* about
overloading.  I gave it another go after reading (AGAIN) Craig's first
post on this topic (12/14/2002) and this time, instead of using a null
getter, I provided a getter for the overloaded setter.  Still does not
work.  Introspector only returns one PropertyDescriptor for the
property.  Edgar and Craig both lead me to believe that this is
possible, but I am starting to think that I am trying to put a square
peg in a round hole.

Edgar: Would you be willing to share some of your implementation
details?

Architectural Gurus: The problem I am trying to solve is that I have a
data source that returns Strings only (xml file), should I create Beans
specifically for that data source and then convert over to my Form?

Thanks for all of your help,

Carl



-Original Message-
From: Edgar P. Dollin [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, December 24, 2002 10:26 AM
To: 'Struts Developers List'
Subject: RE: Overloaded Setters in Form


I have had success overloading properties and used the effect liberally.
I have found that if you are consistent in your overloading, i.e. for
every setter of type x supply a getter of type x as well (at least in
the containers I am using) they seem to function.  

Based on your comments, I have a concern that something will break going
forward.  I looked for overloading in the spec (attached) and they don't
specifically speak to the issue.

http://java.sun.com/products/javabeans/docs/beans.101.pdf

Could you point me toward some documentation which gives more details?

Thanks

Edgar

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, December 24, 2002 9:12 AM
To: Struts Developers List
Subject: Re: Overloaded Setters in Form


It's contrary to the JavaBean specification to overload the 
property methods (getters and setters), if that's what you are 
trying to do. So, it won't work, because it's not suppose to.

-Ted.


12/23/2002 10:31:41 PM, Carl Fyffe <[EMAIL PROTECTED]> wrote:
>Seasons greetings friends!
>
>I sent an email inquiring about overloaded setters in Forms to the
>struts-user mailing list.  I was told that I needed a BeanInfo. 
> I gave
>the BeanInfo a try and it did not work.  So, I started reading
>code and
>decided that an overloaded example in TestBean was needed.  Of 
course it
>now fails just like my example.  I am stuck there.  The BeanInfo's that

>I have created, with and without my overloaded methods, do not  work.
>Does anyone have a TestBeanBeanInfo that works?  Any advice would
> be
>greatly appreciated.
>
>Carl
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

RE: Overloaded Setters in Form

[Edgar P. Dollin]

I have had success overloading properties and used the effect liberally.
I have found that if you are consistent in your overloading, i.e. for
every setter of type x supply a getter of type x as well (at least in
the containers I am using) they seem to function.  

Based on your comments, I have a concern that something will break going
forward.  I looked for overloading in the spec (attached) and they don't
specifically speak to the issue.

http://java.sun.com/products/javabeans/docs/beans.101.pdf

Could you point me toward some documentation which gives more details?

Thanks

Edgar

-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, December 24, 2002 9:12 AM
To: Struts Developers List
Subject: Re: Overloaded Setters in Form


It's contrary to the JavaBean specification to overload the 
property methods (getters and setters), if that's what you are 
trying to do. So, it won't work, because it's not suppose to.

-Ted.


12/23/2002 10:31:41 PM, Carl Fyffe <[EMAIL PROTECTED]> wrote:
>Seasons greetings friends!
>
>I sent an email inquiring about overloaded setters in Forms to
>the
>struts-user mailing list.  I was told that I needed a BeanInfo. 
> I gave
>the BeanInfo a try and it did not work.  So, I started reading
>code and
>decided that an overloaded example in TestBean was needed.  Of 
course it
>now fails just like my example.  I am stuck there.  The BeanInfo's that
>I have created, with and without my overloaded methods, do not
> work.
>Does anyone have a TestBeanBeanInfo that works?  Any advice would
> be
>greatly appreciated.
>
>Carl
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)

[Ted Husted]

>http://jakarta.apache.org/struts/proposals/release-plan-
1.1b3.html

I would remove 

14042 - Unknown Memory leaks with JBoss 3.x +(Tomcat/Jetty)

as a "must have" since I don't think we can commit to curing a 
problem with an "unknown" cause in a specific container. 

I would add 

13645 - add action attribute in 

Otherwise, +1

I am also not clear if the list needs to be resolved before b3 
ships. At this point, I believe at this point we should be 
striving for something we can just release if nothing unexpected 
turns up; so whatever *needs* to be in the release should also be 
in b3. 

Also, is the freeze date [29-JAN-2002 00:00] or [29-JAN-2002 
24:59]? 

-Ted.



12/23/2002 5:36:47 PM, Martin Cooper <[EMAIL PROTECTED]> wrote:

>A number of new features have been added to Struts since the 1.1 
Beta 2
>release, and many bugs have been fixed. Therefore, I propose that 
we
>release the tip of the main trunk in CVS as Beta 3 for a Struts 
1.1
>release. I have checked in a proposed release plan, revised from 
the
>previous version, which is available for review on the Struts web 
site:
>
>http://jakarta.apache.org/struts/proposals/release-plan-
1.1b3.html
>
>Release plans must pass by a majority vote of committers on the 
project,
>but all other interested parties are welcome to cast their votes 
(and/or
>make comments or suggestions on the plan) as well.
>
>
>-
-
>Vote:  Struts 1.1b3 Release Plan
>[ ] +1 I am in favor of the release, and will help support it
>[ ] +0 I am in favor of the release, but am unable tohelp support 
it
>[ ] -0 I am not in favor of the release
>[ ] -1 I am against this proposal (must include a reason).
>-
-
>
>I am +1 on the Struts 1.1b3 release plan.
>
>--
>Martin Cooper
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




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

Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)

[Cedric Dumoulin]

+1

Cedric

Martin Cooper wrote:


A number of new features have been added to Struts since the 1.1 Beta 2
release, and many bugs have been fixed. Therefore, I propose that we
release the tip of the main trunk in CVS as Beta 3 for a Struts 1.1
release. I have checked in a proposed release plan, revised from the
previous version, which is available for review on the Struts web site:

   http://jakarta.apache.org/struts/proposals/release-plan-1.1b3.html

Release plans must pass by a majority vote of committers on the project,
but all other interested parties are welcome to cast their votes (and/or
make comments or suggestions on the plan) as well.


--
Vote:  Struts 1.1b3 Release Plan
[ ] +1 I am in favor of the release, and will help support it
[ ] +0 I am in favor of the release, but am unable tohelp support it
[ ] -0 I am not in favor of the release
[ ] -1 I am against this proposal (must include a reason).
--

I am +1 on the Struts 1.1b3 release plan.

--
Martin Cooper


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


 



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

Re: Tying Up Loose Ends

[Ted Husted]

12/23/2002 5:31:07 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> 
wrote:
>14, counting some that are documentation related.

Craig, could you please post an active link to the Bugzilla query 
that produces this list on the Roadmap, so that we are all on the 
same page. 

-Ted.




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

Re: Overloaded Setters in Form

[Ted Husted]

It's contrary to the JavaBean specification to overload the 
property methods (getters and setters), if that's what you are 
trying to do. So, it won't work, because it's not suppose to.

-Ted.


12/23/2002 10:31:41 PM, Carl Fyffe <[EMAIL PROTECTED]> wrote:
>Seasons greetings friends!
>
>I sent an email inquiring about overloaded setters in Forms to 
>the
>struts-user mailing list.  I was told that I needed a BeanInfo. 
> I gave
>the BeanInfo a try and it did not work.  So, I started reading
>code and
>decided that an overloaded example in TestBean was needed.  Of 
course it
>now fails just like my example.  I am stuck there.  The
>BeanInfo's that
>I have created, with and without my overloaded methods, do not
> work.
>Does anyone have a TestBeanBeanInfo that works?  Any advice would
> be
>greatly appreciated.
>
>Carl
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




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

Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)

[Rob Leland]

On 23 Dec 2002, Martin Cooper wrote:
> Vote: Struts 1.1b3 Release Plan
> [X ] +0 I am in favor of the release, but am
> unable tohelp support it( On Vacation)

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

Re: [PROPOSED] html:link should have an "action=" option

[Ted Husted]

+1

It's already in as ticket #13645

Personally, I think we should add this to the list on the release 
plan. It should have been int he API to begin with (like using 
ActionForward for inputs). 

My latest project uses Velocity templates, and the tools support 
doing this, so I am =:). I know find that as a result of using 
Actions in links, I no longer need to use as many ActionForwards, 
and the entire architechture is much cleaner and leaner. 

What happens is that instead of seeing ActionForwards as what we 
use to encapsulate links, you can come to view ActionMappings as 
what we use to ecapsulate forms -and- links. Since we can now 
enter a forward from an ActionMapping, everything else is already 
there. (And links are just streamlined GET forms anyway.)

ActionForwards then become a workflow construct -- the outcome of 
an Action object, and nothing else. I think this was always the 
underlying intent of the architechture, but the missing html:link 
property clouded the issue.

-Ted.


12/23/2002 9:37:39 PM, James Turner <[EMAIL PROTECTED]> wrote:

>I find I write a lot of code that uses an intermediate action to 
>link between two web pages (this is good Struts policy in 
>general)  However, since the html:link tag has a forward= but no 
>action=, I have to use page= and supply a URI with the ".do" 
>extension at the end, rather than being about to use action= as I 
>would with an html:form.  What do folks think about adding 
>action= to html:link?
>
>James





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

Re: Struts Tools

[Ted Husted]

If the instructions on amending the build process were available, 
they might also be submitted to Gump, which builds a ton of JARs 
every day.

http://gump.covalent.net/jars/latest/

The driving force behind Gump is Sam Ruby, who I've copied into 
this reply. 

If for some reason the process cannot be automated at this time, 
perhaps you should setup a SourceForge project where these JARs 
can be pooled and shared. 

-Ted.


12/23/2002 2:18:52 PM, David Morris <[EMAIL PROTECTED]> 
wrote:

>I came upon this message while looking for Eclipse 
>IDE information. To make Struts easier to use in Eclipse, I 
>import the jar version followed by the java source and re-export 
>them into a bin/source jar. This corrects line feed issues and 
>makes it easy to step from my code to struts code in the 
>debugger. I do this for Struts and Tomcat as well as some of 
>the commons components. It takes about 20 minutes or so 
>for each jar file but makes it easy to find problems related 
>to things like naming errors. I end up doing this for every 
>new major release of Struts or Tomcat.
>
>It would be nice if there was a repository of pre-build jars 
>that a person could download with source included. I don't 
>know how easy it would be to build these as part of your 
>build process because of the line feed issues but I know that 
>other Windows eclipse uses who I have shared these jar files 
>seemed to appreciate the effort.
>
>David Morris




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

Re: Fwd: typo on Struts page

[Ted Husted]

This is fixed in the current release notes, but I'm not sure if we 
should rewrite history and change the archival version.

12/22/2002 9:01:19 PM, Pier Fumagalli <[EMAIL PROTECTED]> wrote:

>FYI - Not acked.
>
>   Pier
>
>Begin forwarded message:
>
>> From: Kris Resellmo <[EMAIL PROTECTED]>
>> Date: Mon Dec 23, 2002  1:58:11 AM Europe/London
>> To: [EMAIL PROTECTED]
>> Subject: typo on Struts page
>>
>> http://jakarta.apache.org/struts/userGuide/release-notes-1.1- 
>> b2.html#New
>>
>> One line in this section reads:
>> Nested - An very cool taglib extension
>>
>> It should probably be:
>> Nested - A very cool tagbli extension
>>
>>
>>
>>
>>
>> Kris Resellmo
>> Northwestern University, Evanston, IL.  USA
>> [EMAIL PROTECTED]
>>
>>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>




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

DO NOT REPLY [Bug 12871] - ExceptionHandler does not obey controller inputForward rule

[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=12871

ExceptionHandler does not obey controller inputForward rule





--- Additional Comments From [EMAIL PROTECTED]  2002-12-24 11:21 
---
No offense intended, but how are you testing that you've *fixed* this issue?  Again, 
the 
issue is _not_ about context relative paths or not, its about how the 'input' 
attribute is 
interpretted.  Look at the patch I supplied in my second post on this issue and notice 
how 
I use getInputForward, not getInput - that is the key.  I supplied the code - why are 
you 
ignoring it?

I will try Struts b3 when its released and see if it is corrected at that point.  I 
have a 
workaround by using my FixedExceptionHandler anyway.  Opening this issue was my 
contribution to the Struts community, and not critical to my project.

Also, I would suggest that try out your fix if you are going to change the code and 
claim its 
fixed.  Do you have a test scenario where you are using inputForward="true"?

Also, please consider applying my patch to the ActionError too, allowing the exception 
message to propogate and be displayable if desired (using {0}) - otherwise I'll have 
to 
continue to used my FixedExceptionHandler to propogate these messages even if you 
do fix the path handling in the builtin ExceptionHandler.  :))

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

Re: [PROPOSED] html:link should have an "action=" option

[David Graham]

Looks like Ted agrees with you:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13645

If you provide a patch, it's more likely to get done.

Dave







From: "James Turner" <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: [PROPOSED] html:link should have an "action=" option
Date: Mon, 23 Dec 2002 21:37:39 -0500

I find I write a lot of code that uses an intermediate action to link
between two web pages (this is good Struts policy in general)  However,
since the html:link tag has a forward= but no action=, I have to use
page= and supply a URI with the ".do" extension at the end, rather than
being about to use action= as I would with an html:form.  What do folks
think about adding action= to html:link?

James

_
James
ICQ#: 8239923
More ways to contact me: http://wwp.icq.com/8239923
See more about me: http://web.icq.com/whitepages/about_me?Uin=8239923
_



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



_
MSN 8: advanced junk mail protection and 3 months FREE*. 
http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= 
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_advancedjmf_3mf


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