1.) Why does the problem occur on Resin's Unix implementation, but not the
Windows -- same versions?
- This may be a container issue. If you're deploying the same .war file to
both and executing the same steps to generate the error, then the issue is
definitely with the container.
You'd need to use THE SAME WAR FILE and follow THE SAME MOUSE CLICKS/DATA
ENTRY in both the Unix and NT environments to ensure the difference really
is the container.
You may have different versions of Struts (or some other Jar file) on the
CLASSPATH - and get different behavior that way.
Regarding the setXxx(boolean xxx) -v- setXxx(String xxx) question. Is this
a property your posting from a form to a FormBean? If so, I believe that
all properties posted this way to the form bean (on a submit) are posted as
type String. If you have a setXxx(boolean xxx), then this may be a problem
- Struts receives String arguments upon posting to a FormBean. HTTP itself
can only carry String data. I'm pretty sure this is the issue
Also, I believe at release 1.1 Struts began using the Jakarta Commons /
org.apache.commons.beanutils.BeanUtils class for posting arguments to form
beans. This class more formally uses the Bean specifications to perform
introspection and find the setters/getters for the FormBean.
That is, I don't believe that it's "JSP" specifically that cares about
setters/getters, I believe it's the org.apache.commons.beanutils.BeanUtils
class used for population of form bean properties.
In short -
- The Unix/NT issue may be related to diff versions of (or different order of) jar
files on the CLASSPATH or some other configuration issue - but may
be a container bug.
- Setters are needed as part of the FormBean population of properties even if you
never call them specifically.
- It's likely easier to avoid issues like this if you just create the
beans using set/get methods for every property as a course of habit. (Note
that the JavaBean spec allows for overriding this with custom behavior if
needed).
- Since HTTP (not Struts or JSP) understands only String-type data, I
believe that Struts FormBeans need setXxx(String xxx) to work (someone pls
correct me if I'm wrong).
FWIW -
Kevin
"Michael Marrotte" <[EMAIL PROTECTED]> on 05/30/2002 09:29:25 AM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: Struts Fault?
I know beans follow a tight spec, i.e. setter signatures should match
getter
return types, etc... But, why does JSP care about this if I never use the
setter explicity? And how come JSP does not mind on Windows?
-----Original Message-----
From: Michael Marrotte [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 30, 2002 9:15 AM
To: [EMAIL PROTECTED]
Subject: Struts Fault?
I don't think so. But, you be the judge. Running Resin on SunOS I
encounter a problem -- I think a JSP translation problem -- that does not
occur running Resin on Windows. The problem is the notorious "no getter
for
property, etc...". However, the getter is defined just like all the other
properties for this bean. However, the setter which is not even used by
the
JSP -- that is, this property is only used in the context of a bean:write
--
is defined with a boolean, i.e. setXxx(boolean xxx). When I changed the
setter signature to a a String, i.e. setXxx(String xxx) the problem was
solved on Resin with SunOS.
But, I have two questions:
1.) Why does the problem occur on Resin's Unix implementation, but not the
Windows -- same versions?
2.) Why should the setter ever be considered by Struts, JSP, etc. I only
use explicitly in when processing in the Model.
Whatever the answer, there's some discrepancy between how Resin processes
Struts on SunOS and that of Windows. Or, I need a clue...
Any answers, questions, advice is greatly appreciated.
Thanks in advance,
--Michael Marrotte
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
