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: [email protected] > 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: [email protected] > > 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: [email protected] > > > 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: [email protected] > > > > > > > > > > > > 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
