osdir.com
mailing list archive

Subject: Re: XStream subclass - msg#00015

List: java.xstream.devel

Date: Prev Next Index Thread: Prev Next Index
Thanx Joe,
your solution perfectly works for root object,
but the same problem is located in nested classes:

<org.jubu.cfg.TestBeanL3> ->>> here is everything ok
<beanL2 class="org.jubu.cfg.TestBeanL2_MBean_1"> ->>> there I need intervention
.....
</beanL2>
</org.jubu.cfg.TestBeanL3>

exists there any effective solution ?
Please give me hint.

Thank you.
J.B.
p.s. my solution is based on "replacement" of ReflectionConverter ... and I thing that it is not right way ...


Joe Walnes wrote:

Hi Juraj

For this kind of thing, I suggest creating your own
Marshaller/Unmarshaller classes - these are called in between each
object when (de)serializing the graph and can be used to do weird
custom stuff that falls outside the scope of Converters. You can plug
your custom classes in using XStream.setMarshallingStrategy().

-Joe

On 8/8/05, Juraj Burian <jubu-VIXq6x/3rUk@xxxxxxxxxxxxxxxx> wrote:

Hi Joe
My problem is quite complex :-).
I am generating class via ASM (so class file never exists) let say
before its serialization.
During deserialization I need check some attribute (for example
managed) in XML file and if is managed= "true" I need generate new
class via ASM and instantiate it, instead the original class.

Example:
<org.jubu.TestBean managed="true"> ->>>>> TestBean (class) is going to
be wrapped with generated class.
...
</org.jubu.TestBean>

Of course I want to serialize/deserialize not managed objects by
ordinary way

Thank you.
J.B.

Joe Walnes wrote:


Hi Juraj

I chose not to use protected fields as it makes it hard for me to
change the internals of XStream (necessary to add features) without
breaking backwards compatability with people like yourself.

What I prefer to do is understand how you need to customize XStream so
I can guide you and, if necessary, add the necessary hooks.

Thanks
-Joe

On 8/8/05, Juraj Burian <jubu-VIXq6x/3rUk@xxxxxxxxxxxxxxxx> wrote:



Hi.
After few hours of work with XStream I realized that it is necessary to
give into the developer hands a possibility to create a subclass of
XStream object. The problem is that few properties are declared as
private and getters are missing, but I thing that a better way to
achieve this, is to declare all properties protected for simplicity.

Let me know your opinion.

Thank you.
J.Burian














Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: Constructor Initialization

Thanks Joe. I'll give that a try. ~Lokesh

Next Message by Date: click to view message preview

the toXML call and special characters like &

I looked into the frequently asked questions but did not find anything about special characters such as &. Is the call to toXML supposed to return an XML string with all special characters such as & escaped? Right now this call “String xml = _xstream.toXML(Object someObject);” does not do it for me. Is there a work around? Thanks   ________________________________________________ Yazid Benkhellat C-COR Incorporated (CCBL) 1825 NW 167th Place Beaverton OR 97006 503-629-6155 www.c-cor.com ________________________________________________    

Previous Message by Thread: click to view message preview

Re: XStream subclass

Hi Juraj For this kind of thing, I suggest creating your own Marshaller/Unmarshaller classes - these are called in between each object when (de)serializing the graph and can be used to do weird custom stuff that falls outside the scope of Converters. You can plug your custom classes in using XStream.setMarshallingStrategy(). -Joe On 8/8/05, Juraj Burian <jubu-VIXq6x/3rUk@xxxxxxxxxxxxxxxx> wrote: > Hi Joe > My problem is quite complex :-). > I am generating class via ASM (so class file never exists) let say > before its serialization. > During deserialization I need check some attribute (for example > managed) in XML file and if is managed= "true" I need generate new > class via ASM and instantiate it, instead the original class. > > Example: > <org.jubu.TestBean managed="true"> ->>>>> TestBean (class) is going to > be wrapped with generated class. > ... > </org.jubu.TestBean> > > Of course I want to serialize/deserialize not managed objects by > ordinary way > > Thank you. > J.B. > > Joe Walnes wrote: > > >Hi Juraj > > > >I chose not to use protected fields as it makes it hard for me to > >change the internals of XStream (necessary to add features) without > >breaking backwards compatability with people like yourself. > > > >What I prefer to do is understand how you need to customize XStream so > >I can guide you and, if necessary, add the necessary hooks. > > > >Thanks > >-Joe > > > >On 8/8/05, Juraj Burian <jubu-VIXq6x/3rUk@xxxxxxxxxxxxxxxx> wrote: > > > > > >>Hi. > >>After few hours of work with XStream I realized that it is necessary to > >>give into the developer hands a possibility to create a subclass of > >>XStream object. The problem is that few properties are declared as > >>private and getters are missing, but I thing that a better way to > >>achieve this, is to declare all properties protected for simplicity. > >> > >>Let me know your opinion. > >> > >>Thank you. > >>J.Burian > >> > >> > >> > > > > > > > > >

Next Message by Thread: click to view message preview

Re: XStream subclass

I'm not 100% sure of what you're doing, but the Marshaller/Unmarshaller classes are called for every object in the graph - i.e. everytime a converter calls convertAnother(). On 8/8/05, Juraj Burian <jubu-VIXq6x/3rUk@xxxxxxxxxxxxxxxx> wrote: > Thanx Joe, > your solution perfectly works for root object, > but the same problem is located in nested classes: > > <org.jubu.cfg.TestBeanL3> ->>> here is everything ok > <beanL2 class="org.jubu.cfg.TestBeanL2_MBean_1"> ->>> there I need > intervention > ..... > </beanL2> > </org.jubu.cfg.TestBeanL3> > > exists there any effective solution ? > Please give me hint. > > Thank you. > J.B. > p.s. my solution is based on "replacement" of ReflectionConverter ... > and I thing that it is not right way ... > > > Joe Walnes wrote: > > >Hi Juraj > > > >For this kind of thing, I suggest creating your own > >Marshaller/Unmarshaller classes - these are called in between each > >object when (de)serializing the graph and can be used to do weird > >custom stuff that falls outside the scope of Converters. You can plug > >your custom classes in using XStream.setMarshallingStrategy(). > > > >-Joe > > > >On 8/8/05, Juraj Burian <jubu-VIXq6x/3rUk@xxxxxxxxxxxxxxxx> wrote: > > > > > >>Hi Joe > >>My problem is quite complex :-). > >>I am generating class via ASM (so class file never exists) let say > >>before its serialization. > >>During deserialization I need check some attribute (for example > >>managed) in XML file and if is managed= "true" I need generate new > >>class via ASM and instantiate it, instead the original class. > >> > >>Example: > >><org.jubu.TestBean managed="true"> ->>>>> TestBean (class) is going to > >>be wrapped with generated class. > >>... > >></org.jubu.TestBean> > >> > >>Of course I want to serialize/deserialize not managed objects by > >>ordinary way > >> > >>Thank you. > >>J.B. > >> > >>Joe Walnes wrote: > >> > >> > >> > >>>Hi Juraj > >>> > >>>I chose not to use protected fields as it makes it hard for me to > >>>change the internals of XStream (necessary to add features) without > >>>breaking backwards compatability with people like yourself. > >>> > >>>What I prefer to do is understand how you need to customize XStream so > >>>I can guide you and, if necessary, add the necessary hooks. > >>> > >>>Thanks > >>>-Joe > >>> > >>>On 8/8/05, Juraj Burian <jubu-VIXq6x/3rUk@xxxxxxxxxxxxxxxx> wrote: > >>> > >>> > >>> > >>> > >>>>Hi. > >>>>After few hours of work with XStream I realized that it is necessary to > >>>>give into the developer hands a possibility to create a subclass of > >>>>XStream object. The problem is that few properties are declared as > >>>>private and getters are missing, but I thing that a better way to > >>>>achieve this, is to declare all properties protected for simplicity. > >>>> > >>>>Let me know your opinion. > >>>> > >>>>Thank you. > >>>>J.Burian > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > > > > > > > > > >
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by