You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Sergey Beryozkin <se...@iona.com> on 2009/08/22 18:07:15 UTC
Re: Returning Something Less Than the Full Object Graph
Hi Dan
Can you please post a complete sample object graph, as seen on the wire,
and/or
an object graph instance to be serialized by JAXB. As well as a
corresponding sample after a (would be) max depth rule has been applied. We
can then see if we can fix it generically at the JAXB (provider) layer by
reacting to some system query like _maxdepth or say by executing an
xpath-like query.
Would you be happy with limiting the response after the db query has been
executed or would you prefer to make sure the db response already has been
filtered as needed, by creating an appropriate db query ?
If it's the former then I think we may have some space for solving this
issue at the runtime layer by installing some system query handler reacting
to queries like _maxdepth. Otherwise you'd likely need to come up with your
own query language...
cheers, Sergey
Dan Check wrote:
>
> Hi all,
>
> I have a service that returns a list of objects (~75 in total). The full
> graph of each object, as returned by hibernate, is about 100k. As a
> result,
> a listing of the full set runs about 7.5 MB. That, combined with the deep
> retrieve, makes the listing incredibly expensive & slow.
>
> Is there an easy way that I can specify a max depth for these objects when
> they're being sent over the wire? I'd like to be able to say that these
> objects should go no deeper than three levels. I'd also be willing to say
> that a certain part of the object is XMLTransient in this context, but
> only
> if I can say that it's not transient when the objects are retrieved
> individually. I don't know what the best practice is here.
>
> I'm using the JAX-RS support, and JAXB for marshalling and unmarshalling.
>
> Thanks,
> Dan
>
>
> -----
> CONFIDENTIALITY NOTICE: The information contained in this message
> may be privileged and confidential and protected from disclosure.
> If the reader of this message is not the intended recipient, or
> responsible for delivering it to the intended recipient, please
> be advised that any distribution, dissemination, copying or other
> transmission or use of the information contained in this message
> or its enclosed attachments is strictly prohibited. Please
> notify us immediately if you have received this message in error
> by replying to the sender of the message and deleting it from
> your computer. Thank you.
>
>
>
>
--
View this message in context: http://www.nabble.com/Returning-Something-Less-Than-the-Full-Object-Graph-tp25089771p25095126.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Returning Something Less Than the Full Object Graph
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Dan
No probs and thanks for this example.
Let me think a bit about it...
I have a question about Hibernate. Are objects like AuditObjects act as proxies ? That is, will the db query be executed only after JAXB will attempt to read the List<Column> ?
> Also < I finished up the List<?> converter
CXF 2.2.3 supports reading and writing explicit collections - can you try CXF 2.2.3 please ? The only exception is that JSON explicit collections can not be read at the moment
Cheers, Sergey
-----Original Message-----
From: Dan Check [mailto:check@catalist.us]
Sent: 31 August 2009 15:22
To: <us...@cxf.apache.org>
Subject: Re: Returning Something Less Than the Full Object Graph
Hi Sergey,
I wrote that email right before I went on vacation, hence the radio silence
on my end.
The better work-around on my end was to cut down the object in the service
layer prior to serialization. I bet I could also do this in an interceptor
< if the return type is a collection of a certain type, then strip off some
parts of the object prior to passing it out to JAXB.
Ideally, what I¹d love to be able to do would be to take something like the
following:
<BatchFile id=900>
<FileName>SomeFile.txt</FileName>
<AuditObject id=37>
<Column index=²1²>
... Lots of sample data elements...
</Column>
<Column index=²2²>
... Lots of sample data elements...
</Column>
... Lots more columns ...
</AuditObject>
</BatchFile>
And then say that certain elements should be reduced to just ids (or xrefs
or something), so you¹d have something like the following:
<BatchFile id=900>
<FileName>SomeFile.txt</FileName>
<AuditObject id=37 />
</BatchFile>
That way the caller would have enough to request the additional info without
starting at the batch file at the top.
For now, cutting down the object by removing the AuditObject in the service
layer makes the app performant.
Thanks, as always, for the help.
Also < I finished up the List<?> converter (by adding code on the client
side) that I wrote about previously < should I post the code to the list?
Thanks,
Dan
-----
CONFIDENTIALITY NOTICE: The information contained in this message
may be privileged and confidential and protected from disclosure.
If the reader of this message is not the intended recipient, or
responsible for delivering it to the intended recipient, please
be advised that any distribution, dissemination, copying or other
transmission or use of the information contained in this message
or its enclosed attachments is strictly prohibited. Please
notify us immediately if you have received this message in error
by replying to the sender of the message and deleting it from
your computer. Thank you.
Re: Returning Something Less Than the Full Object Graph
Posted by Dan Check <ch...@catalist.us>.
Hi Sergey,
I wrote that email right before I went on vacation, hence the radio silence
on my end.
The better work-around on my end was to cut down the object in the service
layer prior to serialization. I bet I could also do this in an interceptor
if the return type is a collection of a certain type, then strip off some
parts of the object prior to passing it out to JAXB.
Ideally, what I¹d love to be able to do would be to take something like the
following:
<BatchFile id=900>
<FileName>SomeFile.txt</FileName>
<AuditObject id=37>
<Column index=²1²>
... Lots of sample data elements...
</Column>
<Column index=²2²>
... Lots of sample data elements...
</Column>
... Lots more columns ...
</AuditObject>
</BatchFile>
And then say that certain elements should be reduced to just ids (or xrefs
or something), so you¹d have something like the following:
<BatchFile id=900>
<FileName>SomeFile.txt</FileName>
<AuditObject id=37 />
</BatchFile>
That way the caller would have enough to request the additional info without
starting at the batch file at the top.
For now, cutting down the object by removing the AuditObject in the service
layer makes the app performant.
Thanks, as always, for the help.
Also I finished up the List<?> converter (by adding code on the client
side) that I wrote about previously should I post the code to the list?
Thanks,
Dan
-----
CONFIDENTIALITY NOTICE: The information contained in this message
may be privileged and confidential and protected from disclosure.
If the reader of this message is not the intended recipient, or
responsible for delivering it to the intended recipient, please
be advised that any distribution, dissemination, copying or other
transmission or use of the information contained in this message
or its enclosed attachments is strictly prohibited. Please
notify us immediately if you have received this message in error
by replying to the sender of the message and deleting it from
your computer. Thank you.
Re: Returning Something Less Than the Full Object Graph
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi
>
> Hi Dan
>
> Can you please post a complete sample object graph, as seen on the wire,
> and/or
> an object graph instance to be serialized by JAXB.
I didn't mean a complete 100K grapgh :-), just a sample showing how a graph is structured and then also the expected grpagh after
the would be max length rule has been applied - I think we might be able to fix it generically by registering a specialized stream
writer.
cheers, Sergey
> As well as a
> corresponding sample after a (would be) max depth rule has been applied. We
> can then see if we can fix it generically at the JAXB (provider) layer by
> reacting to some system query like _maxdepth or say by executing an
> xpath-like query.
>
> Would you be happy with limiting the response after the db query has been
> executed or would you prefer to make sure the db response already has been
> filtered as needed, by creating an appropriate db query ?
>
> If it's the former then I think we may have some space for solving this
> issue at the runtime layer by installing some system query handler reacting
> to queries like _maxdepth. Otherwise you'd likely need to come up with your
> own query language...
>
> cheers, Sergey
>
>
> Dan Check wrote:
>>
>> Hi all,
>>
>> I have a service that returns a list of objects (~75 in total). The full
>> graph of each object, as returned by hibernate, is about 100k. As a
>> result,
>> a listing of the full set runs about 7.5 MB. That, combined with the deep
>> retrieve, makes the listing incredibly expensive & slow.
>>
>> Is there an easy way that I can specify a max depth for these objects when
>> they're being sent over the wire? I'd like to be able to say that these
>> objects should go no deeper than three levels. I'd also be willing to say
>> that a certain part of the object is XMLTransient in this context, but
>> only
>> if I can say that it's not transient when the objects are retrieved
>> individually. I don't know what the best practice is here.
>>
>> I'm using the JAX-RS support, and JAXB for marshalling and unmarshalling.
>>
>> Thanks,
>> Dan
>>
>>
>> -----
>> CONFIDENTIALITY NOTICE: The information contained in this message
>> may be privileged and confidential and protected from disclosure.
>> If the reader of this message is not the intended recipient, or
>> responsible for delivering it to the intended recipient, please
>> be advised that any distribution, dissemination, copying or other
>> transmission or use of the information contained in this message
>> or its enclosed attachments is strictly prohibited. Please
>> notify us immediately if you have received this message in error
>> by replying to the sender of the message and deleting it from
>> your computer. Thank you.
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Returning-Something-Less-Than-the-Full-Object-Graph-tp25089771p25095126.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>