From graffito-dev-return-1233-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Sun Sep 03 22:11:26 2006 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 50764 invoked from network); 3 Sep 2006 22:11:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Sep 2006 22:11:22 -0000 Received: (qmail 33645 invoked by uid 500); 3 Sep 2006 22:11:22 -0000 Mailing-List: contact graffito-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: graffito-dev@incubator.apache.org Delivered-To: mailing list graffito-dev@incubator.apache.org Received: (qmail 33634 invoked by uid 99); 3 Sep 2006 22:11:22 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Sep 2006 15:11:22 -0700 X-ASF-Spam-Status: No, hits=1.9 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of dsconnelly@adelphia.net designates 68.168.78.199 as permitted sender) Received: from [68.168.78.199] (HELO mta9.adelphia.net) (68.168.78.199) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Sep 2006 15:11:21 -0700 Received: from [192.168.0.8] (really [69.162.180.18]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060903221101.UOPH2942.mta9.adelphia.net@[192.168.0.8]> for ; Sun, 3 Sep 2006 18:11:01 -0400 Message-ID: <44FB5310.1090405@adelphia.net> Date: Sun, 03 Sep 2006 18:11:28 -0400 From: Dan Connelly User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: graffito-dev@incubator.apache.org Subject: Re: ManageableCollectionUtil should not throw "unsupported" JcrMapping exception. References: <44F953EE.1030205@adelphia.net> In-Reply-To: <44F953EE.1030205@adelphia.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N What I ended up doing for this problem, to avoid the exception, was to make a local modification in ManageableCollectionUtil. It still throws the exception (if needed) but my specialized list collection class is now easily coerced to a ManageableCollection with my replacement code. This is a hack, but a much smaller hack than trying to specialize either the objectConverter or the collectionConverter to do the wrapping. I would like to see the CollectionConverter interface extended with a method: private ManageableCollectionFactory getManageableCollectionFactory() such that the ManageableCollectionFactory class would be used in much the same way that ManageableCollectionUtil is ued. The ManageableCollectionFactory would continue to throw the "unsupported" JcrMapping exception (if needed), but presumably would wrap all of the application's collection classes correctly. Dan Connelly wrote: > I want to use a custom collectionConverter, MyCollectionConverterImpl. > > That collectionConverter can decide what to do with "unsupported" > collections from my *given* object model. (Object model cannot be > changed.) In particular, MyCollectionConverterImpl will wrap an > unsupported collection as a ManageableCollection and delegate its work > to a standard collection converter. > The collection type is discovered by reflection in the > objectConverter, so it cannot be coerced in the ocm mapping. > > Unfortunately, the default objectConverter invokes its own wrapping > tool, ManageableCollectionUtil, just before the call to > insertCollection in the custom collectionConverter. > ManageableCollectionUtil will throw an exception before the custom > collectionConverter gets its chance to wrap the unsupported collection > type. The call to insertCollection in the custom > collectionConverter is never invoked. > > A workaround would be to over-ride method insertCollectionFields using > a custom objectConverter. However, this method is private in the > standard objectConverter. Thus the method work cannot be delegated. > Code would need to be copied into the custom objectConverter. Not > good. But even if this method was public and code copying was not > needed, the object converter is not the right place for collection > conversions. > > Why not make the collectionConverters responsible for throwing an > exception on (truly) unsupported collection types? > Don't throw this exception from ManageableCollectionUtil. Just leave > an "unsupported" collection type alone there and let the > collectionConverter deal with any unsupported collection type that may > be given to it. > > -- Dan > > >