1) Create a brand new java POJO that implements TypeCreator, has a field of type TypeCreator, and (initially) delegates all the abstract methods to the field.
2) take your method of TypeCreator that delivers the entire type for a class, and change it from pure delegation to throwing out the things you don't want. I'm not quite clear on the practicality of item #2. I will try to read some code and get back to you later. > -----Original Message----- > From: tog [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 26, 2007 9:51 AM > To: cxf-user@incubator.apache.org > Subject: Re: DefaultTypaMappingRegistry issue [was: Aegis binding and > property/fiels removal] > > Benson, Dan, > > Could you elaborate a bit on this or detail the steps because I am not > familiar with this. I will then try to test it. > Basically, I have only POGO for which I would like to remove > systematically a property. > > Thanks > Guillaume > > On 9/21/07, Benson Margulies <[EMAIL PROTECTED]> wrote: > > I have a sudden inspiration here. > > > > Make a 'filter' for the TypeCreator interface. Grab the usual type > > creator chain (from getTypeCreator()) and stick it into your filter > > object. Make your filter post-edit the Type that it creates to remove > > the things you don't love. > > > > It may be that the registry is final because the idea is that it's just > > the, well, registry. All the customization-worthy behavior really occurs > > in the creator chain. > > > > Perhaps a Dan can amplify? > > > > > > > -----Original Message----- > > > From: Benson Margulies [mailto:[EMAIL PROTECTED] > > > Sent: Friday, September 21, 2007 4:48 PM > > > To: cxf-user@incubator.apache.org > > > Subject: RE: DefaultTypaMappingRegistry issue [was: Aegis binding and > > > property/fiels removal] > > > > > > One additional note: before launching down this path, I strongly > > suggest > > > an experiment in just patching the source of CXF in that method of > > > XMLTypeCreator to prove feasibility. > > > > > > > -----Original Message----- > > > > From: Benson Margulies [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, September 21, 2007 4:43 PM > > > > To: cxf-user@incubator.apache.org > > > > Subject: RE: DefaultTypaMappingRegistry issue [was: Aegis binding > > and > > > > property/fiels removal] > > > > > > > > I don't have a clue why DefaultTypeMappingRegistry is final. It > > looks > > > > like a mistake. Why put protected methods in a final class? > > > > > > > > Here's my temporary prescription. > > > > > > > > 1) make a subclass of XMLTypeCreator. You'll probably have to > > override > > > > createClassInfo(PropertyDescriptor). If you get one of the > > properties > > > > you don't like, return null. (I could be wrong about null). In real > > > > life, the ignore property is noted way down in the BeanTypeInfo, and > > > > overriding \that/ would be a ton of work. > > > > > > > > 2) Assembly a chain of type creators like that assembled in the > > > default > > > > type mapping registry, with your subclass at the front. Pass it to > > > > setTypeCreator on the type mapping registry. > > > > > > > > Removing the wayward 'final' is an easy patch post 2.0.2, and I'd > > > > consider some feature development (in the Configuration) object to > > > allow > > > > this from Spring configuration (a pattern of unloved property > > names?). > > > > > > > > > -----Original Message----- > > > > > From: tog [mailto:[EMAIL PROTECTED] > > > > > Sent: Friday, September 21, 2007 4:22 PM > > > > > To: cxf-user@incubator.apache.org > > > > > Subject: DefaultTypaMappingRegistry issue [was: Aegis binding and > > > > > property/fiels removal] > > > > > > > > > > There seems to be an renewed interest for Aegi on the list (thanks > > > > > Benson ;-) ) > > > > > Can someone comment if what I want to achieve is do-able ? > > According > > > > > to Dan D. it is. I am clueless regarding step 4 (quoted below) > > > > > > > > > > Thanks > > > > > Guillaume > > > > > > > > > > ---------- Forwarded message ---------- > > > > > From: tog <[EMAIL PROTECTED]> > > > > > Date: Sep 11, 2007 4:20 PM > > > > > Subject: DefaultTypaMappingRegistry issue [was: Aegis binding and > > > > > property/fiels removal] > > > > > To: cxf-user@incubator.apache.org > > > > > > > > > > > > > > > > > > > > Hi Dan, > > > > > > > > > > Sorry not to follow up quickly. Actually, the > > > > > DefaultTypaMappingRegistry is final and cannot be extended as you > > > > > suggest. > > > > > > > > > > Some more insights on what I want to achieve. Today, in GroovyWS, > > > the > > > > > users have to write a .aegis.xml file for each bean they will > > write > > > > > in Groovy. This file is always the same containing the line: > > > > > > > > > > <property name="metaClass" ignore="true"/> > > > > > > > > > > I would like to modify the behavior of the BeanType inside the > > Aegis > > > > > Binding so that if such a field is present it can be ignored. > > > > > > > > > > Is there some documentation on how to modify the > > > > > DefaultTypeMappingRegisty ? > > > > > > > > > > Cheers > > > > > Guillaume > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Step 4: Write your own type registry to return your own > > > TypeCreator > > > > > > > > > > > > public class MyTypeMappingRegistry extends > > > > DefaultTypeMappingRegistry { > > > > > > > > > > > > protected AbstractTypeCreator createDefaultTypeCreator() { > > > > > > AbstractTypeCreator creator = new MyTypeCreator(); > > > > > > creator.setConfiguration(getConfiguration()); > > > > > > return creator; > > > > > > } > > > > > > } > > > > > > > > > > > > Step 5: use it: > > > > > > > > > > > > ServerFactoryBean sfb = new ServerFactoryBean(); > > > > > > > > > > > > AegisDatabinding db = new AegisDataBinding(); > > > > > > db.setTypeMappingRegistry(new MyTypeMappingRegistry()); > > > > > > sfb.setDatabinding(db); > > > > > > ... > > > > > > > > > > > > Hope that works for you! > > > > > > > > > > > > - Dan > > > > > > > > > > > > On 8/27/07, tog < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hiya > > > > > > > > > > > > > > I have some automatically generated classes that I use to > > > generate > > > > a > > > > > > > server > > > > > > > using Aegis. This is done programmaticaly. I am using an > > > > > > > AegisServiceConfiguration class to avoid publishing methods > > that > > > I > > > > > want to > > > > > > > remove. I would like similarly to remove some > > fields/properties > > > > from > > > > > the > > > > > > > serialization process. > > > > > > > How is that possible (programmaticaly) ? > > > > > > > > > > > > > > Thanks for your help. > > > > > > > > > > > > > > Guillaume > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Best Regards > > > > > Guillaume > > > > > http://cheztog.blogspot.com > > > > > > > > > > -- > > > > > > > > > > Best Regards > > > > > Guillaume > > > > > http://cheztog.blogspot.com > > > > > > > > > > -- > > > > > > > > > > Best Regards > > > > > Guillaume > > > > > http://cheztog.blogspot.com > > > > > -- > > Best Regards > Guillaume > http://cheztog.blogspot.com