Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 36614 invoked from network); 10 Aug 2006 03:13:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Aug 2006 03:13:52 -0000 Received: (qmail 23084 invoked by uid 500); 10 Aug 2006 03:13:51 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 22707 invoked by uid 500); 10 Aug 2006 03:13:49 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 22696 invoked by uid 99); 10 Aug 2006 03:13:49 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Aug 2006 20:13:49 -0700 X-ASF-Spam-Status: No, hits=0.8 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of clinton.begin@gmail.com designates 64.233.182.184 as permitted sender) Received: from [64.233.182.184] (HELO nf-out-0910.google.com) (64.233.182.184) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Aug 2006 20:13:48 -0700 Received: by nf-out-0910.google.com with SMTP id l35so375651nfa for ; Wed, 09 Aug 2006 20:13:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=FliAaxJGnv8Vip2Z3+VA4+C/IFDa68oof7P8x2w5LK8LT3iiJnGx2TQwlKAoQiA3H/tGp2trV+/VamMRSnLpVvdznM9u8zmYGq8/3DLNuZ3sKut5cWZ+Tt1FIrVmn3j0R3Whn+31fNktOzFniF3ncRqCx398Sz7NlOPmdBUMvqw= Received: by 10.78.127.6 with SMTP id z6mr994572huc; Wed, 09 Aug 2006 20:13:01 -0700 (PDT) Received: by 10.78.138.1 with HTTP; Wed, 9 Aug 2006 20:13:01 -0700 (PDT) Message-ID: <16178eb10608092013s4a1d7f8em110b0d0a35be91c6@mail.gmail.com> Date: Wed, 9 Aug 2006 21:13:01 -0600 From: "Clinton Begin" To: user-java@ibatis.apache.org Subject: Re: Support for private properties In-Reply-To: <295517f10608091920s60ea67cdnfb822abd8edf5d7e@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_59566_21169170.1155179581613" References: <295517f10608091148r38e12651r749c288204735855@mail.gmail.com> <44DA96CB.8040007@munat.com> <295517f10608091920s60ea67cdnfb822abd8edf5d7e@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_59566_21169170.1155179581613 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. Cheers, Clinton 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. > > > > b > > > > 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: > > > > > > http://issues.apache.org/jira/browse/IBATISNET-153 > > > > > > 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. > > > > ------=_Part_59566_21169170.1155179581613 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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. 

Cheers,
Clinton


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


On 8/9/06, Ben Munat < bent@munat.com > 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.

b

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:
>
> http://issues.apache.org/jira/browse/IBATISNET-153
>
> 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.


------=_Part_59566_21169170.1155179581613--