I created a new page on Confluence with the comments from this thread on
mailling list. Could anybody please share his thoughts to:
http://docs.codehaus.org/pages/viewpage.action?pageId=44418
Regards
Ralf
Werner Guttmann schrieb:
Hi,
how come we always end up talking about issues like these in regular intervals ... ;-). Anyhow, let's take all arguments in (incl. for example that the EJB 3.0 spec is changing in this regard, which I didn't know myself), and let's try to come to a well-defined decision. Does somebody feel like opening a page on Confluence so that everbody can share his/hr thoughts ?
Werner
-----Original Message-----
From: Ralf Joachim [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 25. Jänner 2006 23:12
To: [email protected]
Subject: Re: [castor-user] Using castor with setters
In addition to Jay's arguments EJB 3.0 does not define
restrictions for access to properties but access to
getters/setters is restricted to public or protected methods.
I'd view marshalling/unmarshalling or persistence as an
internal function of the class even if its implemented
externaly by castor.
Therefore I would allow castor to access non public
properties, maybe also getters/setters, to enable users to
specify design contracts for their classes as requested by
Jay. By restricting access of castor to public
properties/methods we prevent or users to implement such
design contracts.
Ralf
Jay Goldman schrieb:
Werner - to try to make you more excited about the idea...
I would say that a purpose of castor is to provide a mechanism for
instantiating Java objects from non-Java stuff (xml, jdo). In this
regard castor can be viewed as a replacement for java serialization.
IMHO this gives castor license to cross the public/private 'barrier'
when the user of castor has asked for this behavior (i.e., via
direct="true") just as java serialization allows for the setting of
private data. I would even extend it to private setters as I prefer
having all access to an object go thru a setter. If the writer of the
mapping has said use method SetXxx then use it. If there is
no mapping
file then only public methods should be used.
Moreover, it would in fact allow the user of castor to create objects
with the proper public/private contracts which is currently
impossible
to do since to use castor you have to make all your setters (and/or
members) public which defeats the whole notion of public/private.
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 25, 2006 2:23 PM
To: [email protected]
Subject: Re: [castor-user] Using castor with setters
Ralf,
there's actually a Jira issue, but I am not sure whether I am excited
about adding this feature. The folks who designed Java must have
distinguished between public and private access by thought,
and I am not
sure whether enabling access to something that has been designed by
contract is the right way to go. I know that that feature
has been added
to Java, but I'd still want to respect the design of a
public interface
(read contract) when somebody apparently put some thoughts into this.
Just my 0.02 cents
Werner
Ralf Joachim wrote:
You are quite right. I should have thought a bit more on my
suggestion
:-(
I think we should allow to access private properties when
direct="true"
is set. The access to setters/getters should be still restricted to
public in my opinon. Can you please search jira if there is such a
issue or create a new one if not.
Ralf
Jay Goldman schrieb:
Doesn't the use of direct="true" require the property to be public,
not any better than requiring that there be a public setter.
If castor would access a private property (when
direct="true") or even
a private setter (set-method="private_setter") then the goal of
restricting updates to just castor unmarshalling could be achieved;
otherwise, I haven't figured out how to get there.
I'm still using 0.9.3 - have things changed in this area?
-----Original Message-----
From: Ralf Joachim [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 25, 2006 11:38 AM
To: [email protected]
Subject: Re: [castor-user] Using castor with setters
Hi Mike,
you can tell castor to directly access the property by setting
direct="true" on the field in your mapping.
You may also want to have a look at:
http://castor.codehaus.org/xml-mapping.html#3.4-The-%3Cfiel
d%3E-elemen
t
Ralf
Mike Wannamaker schrieb:
If I want to use Castor to write out objects to XML and I have
getters for all attributes but I don't have setters how can I get
this to work for reading it back in?
IE: The API exposes getters like String getName();
however I don't
want to expose a setName(String sName); method otherwise
people using
the api would be able to call setName(). Is there a way
to do this
in Castor?
--ekiM
Aoccdrnig to rscheearch at an Elingsh uinervtisy, it
deosn't mttaer
in waht oredr the ltteers in a wrod are, the olny
iprmoatnt tihng is
taht the frist and lsat ltteer is at the rghit pclae. The
rset can be
a toatl mses and you can sitll raed it wouthit porbelm. Tihs is
bcuseae we do not raed ervey lteter by it slef but the wrod as a
wlohe.
-------------------------------------------------
If you wish to unsubscribe from this list, please send an empty
message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please send an
empty message
to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
