From graffito-dev-return-1229-apmail-incubator-graffito-dev-archive=www.apache.org@incubator.apache.org Sat Sep 02 12:48:00 2006 Return-Path: Delivered-To: apmail-incubator-graffito-dev-archive@www.apache.org Received: (qmail 18949 invoked from network); 2 Sep 2006 12:48:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Sep 2006 12:48:00 -0000 Received: (qmail 79249 invoked by uid 500); 2 Sep 2006 12:48:00 -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 79237 invoked by uid 99); 2 Sep 2006 12:48:00 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Sep 2006 05:48:00 -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; Sat, 02 Sep 2006 05:47:58 -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 <20060902124737.QUOX2942.mta9.adelphia.net@[192.168.0.8]> for ; Sat, 2 Sep 2006 08:47:37 -0400 Message-ID: <44F97D84.40306@adelphia.net> Date: Sat, 02 Sep 2006 08:48:04 -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: DON'T IGNORE ManageableCollectionUtil should not throw "unsupported" JcrMapping exception. References: <44F953EE.1030205@adelphia.net> <44F95F1A.4020309@adelphia.net> In-Reply-To: <44F95F1A.4020309@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 Hmmm. That didn't work either. There really is no good way to do this except to copy code from ObjectConverterImpl into MyObjectConverterImpl where I can hack my ManageableCollection wrapper for collection types I need to support. I also needed to make 2 methods public in ObjectConverterImpl. Ugh. Dan Connelly wrote: > Oops. This is problem is solved fairly easily by over-riding the > getCollection method. (But, it is a bit tricky there to search the > type hierarchy of the Class collectionFieldClass to determine the > wrapper to use.) > > Sorry for posting half-baked my problems and solutions. (But my > fumbling is a case-study on why the "Advanced Mapping Strategy" pages > need to be completed.) > > > 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 >> >> >> > >