The discussion about this started on mailing list. Below you can see this thread as a starting point of an open discussion.
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?
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-%3Cfield%3E-element
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?
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, 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 - 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.
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.
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 ?
Are there any other opinions on allowing Castor to access private or protected properties or methods?