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

Reply via email to