These are all good suggestions, but they're all workarounds....

There's really no reason we shouldn't support private properties.  I do believe it's fairly simple, but realize that it may require that you enable certain JVM security parameters. 

I'll make the change in SVN for 2.2.0. 


On 8/9/06, Eric T. Blue < > wrote:
Thanks Ben.  I had never thought to try that.  We'll look into that solution as well. 

On 8/9/06, Ben Munat < > wrote:
Give your domain objects a method that takes a Map (or a convenience helper class that
wraps the map) and sets private variables appropriately. You can have ibatis map the
result set right into the Map and have your DAO pass it into the domain object.

I'm doing that on my current project and it's working fine. Unfortunately I've also found
that not exposing setters does not mean you won't still create brain-splitting complexity,
but that's another story.


Eric T. Blue wrote:
> Hi,
> My company is currently investigating the best strategy for not exposing
> certain getters/setters for a number of our classes in our domain
> model.  These objects end up being exposed through SOAP, and many
> getters/setters are only there to satisfy bean-compliance (public
> getters/setters).  Although we still need the properties to save/fetch
> data, they have no real meaning to the developers that are using the
> public API.  We are leaning against our business layer creating another
> set of value objects/DTOs that hide these properties.  But, we need to
> find out other alternatives.
> Is there support for mapping to private properties in new versions of
> the Java mapper?  I was browsing through the .net JIRA and came across
> this feature request:
> I suppose the other alternative is to find out if Axis can exclude
> certain properties when stubs are generated.  However, I"m not certain
> if this is possible either.  Thanks.