You might be able to do something like adding  "beforeMarshal" method on the 
object in question or add a Mashaller.Listener onto the Marshaller.   The 
method could try and detect what it needs to do and set a flag that would make 
the call to getLineItems() return null instead of call off to hibernate or 
something.

http://docs.oracle.com/javase/6/docs/api/javax/xml/bind/Marshaller.html#marshalEventCallback


Dan



On Sep 19, 2012, at 6:55 PM, David Mansfield <[email protected]> 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?
> 
> -- 
> Thanks,
> David Mansfield
> Cobite, INC.
> 

-- 
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply via email to