Hi
On 20/09/12 14:46, David Mansfield wrote:
On 09/20/2012 07:11 AM, Sergey Beryozkin wrote:
Hi
On 19/09/12 23:55, David Mansfield wrote:
Hi All.
I can see this has been discussed before, but the thread ended before
any solution was proposed.
My issue is that I have an object (from hibernate) which has
"associations" (properties) which if followed probably end up
referencing my entire database.
By association, I mean an object property which holds a reference to
another object or collection of objects, except that the actual object
is probably a "lazy proxy" for the real object (or collection). If any
lazy proxies are accessed on the object, hibernate will either fetch the
object from the DB on demand or throw an exception if the session is
closed.
I need to be able, on a per service-method basis, limit the depth (or
set of properties) of the object graph traversal. For example, if I have
a collection of "Order" objects to return, I don't want the "lineItems"
property, but if I'm returning a single "Order", then I do want it.
(Like a dynamic XmlTransient).
Note: I don't want to solve the LazyInitializationException by keeping
the session open as other users may have requested, I need to limit the
graph traversal.
I see the DepthRestrictingStreamInterceptor but seems to be an "in"
interceptor to limit the exposure to denial of service from large or
maliciously formed XML object graphs. I need the reverse. Can it be used
for this purpose with or without some modification? Is there anyway to
affect the way the jaxb marhsalling happens dynamically?
Creating a custom XMLStreamWriter would be one option to do it but I'm
thinking it is probably too late to control it at the writer level,
meaning Hibernate may have already attempted to fetch a "lineItems" even
if it is a single Order. Not sure though.
You can certainly block a given XML element/attribute with a custom
writer. TransformFeature can be used for that too but it can not do a
condition-based blocking (example, block "lineItems" if a number of
Order is > 1)
Hi Serey, thanks for your pointers. Seems I need to manipulate the jaxb
process before it gets to the XMLStreamWriter. Not sure how much room
Sun/Oracle has made for customizing that process.
Am I correct that XMLStreamWriter and TransformFeature come into play
after the entire returned object from the service method has been
marshalled, or do they actually get to affect the way it gets marshalled?
They affect the serialization process but not the way JAXB sees which
properties may or may nor have to be serialzied...
Once the jaxb engine (inside writeObject) calls getLineItems(), it's too
late for me.
I wonder if you should create a custom JAXB wrapper against some of the
domain objects, and return 'null' for properties which do not have to be
on the output if a certain domain condition is true...Perhaps it can
also be optimized somehow at Hibernate or JPA level, but it's not
something I know of ...
Cheers, Sergey
Thanks,
David
--
