You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by tog <gu...@gmail.com> on 2007/09/11 16:20:35 UTC
DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
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 < guillaume.alleon@gmail.com> 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
RE: DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by Benson Margulies <bi...@basistech.com>.
Jacob,
I'm definitely the new guy on the volunteer block on Aegis. When Dan
isn't off at a conference, he generally jumps on Aegis issues quickly.
I'm pitching in as well, but I'm still not entirely confident about some
architectural issues. I'm sure we'll get to this stuff.
We just added a JIRA category for Aegis, please make sure that your
issues have it selected.
--benson
> -----Original Message-----
> From: Jacob Marcus [mailto:jacob.marcus@gmail.com]
> Sent: Wednesday, September 12, 2007 7:45 AM
> To: cxf-user@incubator.apache.org
> Subject: Re: DefaultTypaMappingRegistry issue [was: Aegis binding and
> property/fiels removal]
>
> Benson,
>
> I have seen a couple of issues related to Aegis binding.
>
> 1) If the simple front end POJO has java.lang.Object in it's
signature,
> binding fails if you send subclasses of Object in the soap message.
This
> is
> fairly easy to reproduce and seems to be related the name space
handling
> in
> the ObjectType class. I have solved it temporarily by extending the
> ObjectType.
>
> 2) I have logged a Jira issue. (My first issue, so please forgive me
if
> have
> not filled all the fields correctly).
> http://issues.apache.org/jira/browse/CXF-992
>
> I hope these are on some one's radar.
>
> Thanks,
> Jacob
>
>
> On 9/12/07, Benson Margulies <bi...@basistech.com> wrote:
> >
> > I have some ideas in this area, but we need to finish some of what's
> > currently outstanding. We could enhance the options class.
> >
> > > -----Original Message-----
> > > From: tog [mailto:guillaume.alleon@gmail.com]
> > > Sent: Tuesday, September 11, 2007 10:21 AM
> > > To: cxf-user@incubator.apache.org
> > > Subject: DefaultTypaMappingRegistry issue [was: Aegis binding and
> > > property/fiels removal]
> > >
> > > 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 < guillaume.alleon@gmail.com> 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
> >
Re: DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by Jacob Marcus <ja...@gmail.com>.
Benson,
I have seen a couple of issues related to Aegis binding.
1) If the simple front end POJO has java.lang.Object in it's signature,
binding fails if you send subclasses of Object in the soap message. This is
fairly easy to reproduce and seems to be related the name space handling in
the ObjectType class. I have solved it temporarily by extending the
ObjectType.
2) I have logged a Jira issue. (My first issue, so please forgive me if have
not filled all the fields correctly).
http://issues.apache.org/jira/browse/CXF-992
I hope these are on some one's radar.
Thanks,
Jacob
On 9/12/07, Benson Margulies <bi...@basistech.com> wrote:
>
> I have some ideas in this area, but we need to finish some of what's
> currently outstanding. We could enhance the options class.
>
> > -----Original Message-----
> > From: tog [mailto:guillaume.alleon@gmail.com]
> > Sent: Tuesday, September 11, 2007 10:21 AM
> > To: cxf-user@incubator.apache.org
> > Subject: DefaultTypaMappingRegistry issue [was: Aegis binding and
> > property/fiels removal]
> >
> > 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 < guillaume.alleon@gmail.com> 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
>
RE: DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by Benson Margulies <bi...@basistech.com>.
I have some ideas in this area, but we need to finish some of what's
currently outstanding. We could enhance the options class.
> -----Original Message-----
> From: tog [mailto:guillaume.alleon@gmail.com]
> Sent: Tuesday, September 11, 2007 10:21 AM
> To: cxf-user@incubator.apache.org
> Subject: DefaultTypaMappingRegistry issue [was: Aegis binding and
> property/fiels removal]
>
> 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 < guillaume.alleon@gmail.com> 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
RE: DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by Benson Margulies <bi...@basistech.com>.
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:guillaume.alleon@gmail.com]
> 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 <bi...@basistech.com> 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:bim2007@basistech.com]
> > > 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:bim2007@basistech.com]
> > > > 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:guillaume.alleon@gmail.com]
> > > > > 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 <gu...@gmail.com>
> > > > > 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 < guillaume.alleon@gmail.com> 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
Re: DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by tog <gu...@gmail.com>.
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 <bi...@basistech.com> 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:bim2007@basistech.com]
> > 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:bim2007@basistech.com]
> > > 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:guillaume.alleon@gmail.com]
> > > > 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 <gu...@gmail.com>
> > > > 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 < guillaume.alleon@gmail.com> 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
RE: DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by Benson Margulies <bi...@basistech.com>.
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:bim2007@basistech.com]
> 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:bim2007@basistech.com]
> > 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:guillaume.alleon@gmail.com]
> > > 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 <gu...@gmail.com>
> > > 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 < guillaume.alleon@gmail.com> 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
RE: DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by Benson Margulies <bi...@basistech.com>.
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:bim2007@basistech.com]
> 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:guillaume.alleon@gmail.com]
> > 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 <gu...@gmail.com>
> > 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 < guillaume.alleon@gmail.com> 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
RE: DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by Benson Margulies <bi...@basistech.com>.
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:guillaume.alleon@gmail.com]
> 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 <gu...@gmail.com>
> 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 < guillaume.alleon@gmail.com> 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
DefaultTypaMappingRegistry issue [was: Aegis binding and property/fiels removal]
Posted by tog <gu...@gmail.com>.
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 <gu...@gmail.com>
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 < guillaume.alleon@gmail.com> 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