I think it is better to throw "IllegalStateException" if collection is in illegal state than to return wrong result.

We're trying to stop exceptions from being thrown. They stop the de/serialization process of our object responses in our second tier dead in it's tracks, and communication stops.

I'm trying to establish UNinitialized as a legal state for a collection, such that it can pass safely in/out of other third party software tiers.

This thread is unbelievable.

This is *clearly* a problem of the XML serialization framework not having sufficient extension points.

It is absolutely not our fault.


Please people - get off the crackpipe!

" I can see it as very interesting to have an object property even visible on the client that the Set is in this state."

Hibernate.isInitialized(object or set);

There is your property!

Changing the public api of java collection to mean something else is *wrong*, e.g. unitializedSet.hasNext() should not return false because that is *inconsistent* since you then cannot distinguish between "empty set" and "not fetched yet".

Gavin,

There is no need for the crackpipe comments. Please allow this to proceed as a professional discussion about technical issues being faced in the field using Hibernate technology.

You're correct on both counts. It's not being correct that matters here - but that the job gets done. At the end of a day, if the customer does not have a solution, nothing else matters.

1. If there were an extension point in the Adobe (Macromedia) Flash Remoting gateway server we would be all over it. There aren't at the moment. The product is not open source. It's a huge company to try and lobby for enhancements. We're still waiting for reported bugs to be fixed, let alone enhancements. Isnt' open source designed to change this?

2. It's not a hibernate "fault". It's an absence of developer control over a feature which is causing a perfectly good method in a third party framework to crash. This feature, 99% of the time, is helpful and necessary. However, what we've run into is something the current design has not allowed for - introspection of an object outside the session through reflection causing lazy initialization (exception).

We saw a solution to this easily within our reach with this project. We pursued it, and were mistaken.

I will conclude by being respectful, saying thank you for what your product does, it is a nice piece of software. It has missing features, as all software does, and we may add them. It would be more work for us to maintain our features through the releases, but we will manage, or find another solution, or maybe eventually Adobe will enhance Flash Remoting so it plays better with ORM frameworks. Maybe they will read this thread?

Max, the reply never reaches my client because Hiberante has already crashed the response in my serialization tier during introspection. Unless I can fix this nothing will ever reach the client.

If the uninitialized collection appeared null we would not have a problem, but Java does not contain the ability to override operators. The proxy object exists in the property, and can not intercept Java code testing the existance of data in the collection (to make appear it null).

(1) I had assumed that the word "crackpipe" would be taken in the humorous vein it was intended.

(2) You need to realize that if we put dangerous and/or half-thought features into our product then we will regret it 1000 times over. Getting something like Hibernate right is certainly as much about what you leave out.

I fully appreciate the thought that goes into desgin.

But if I can't even send a few objects back to my client, how's that for design? In this case the LazyInitializationException is over-designed protection from my own code. Not in all cases, please, but in this case.

Here's an article on the O'Reilly network which discusses the "pitfalls" as they call it in using Hibernate with Flash Remoting.

See the headline Integrating Flex with the Persistence Layer

http://www.onjava.com/pub/a/onjava/2004/12/01/flexjava.html?page=2

They suggest using AOP to intercept and set your proxies to null... Do you agree?[/b]

Also see the JBOSS website for a PDF slideshow which describes integrating Flex with Hibernate. Slide #27 shows the same strategy as recommended by the O'Reilly article - an AOP Interceptor to remove the dynamic proxies.

[link]http://www.jboss.com/pdf/jbworld/ria_matrix_resources.pdf[/link]

I believe I will investigate this option, unless you have further suggestions.

Hibernate lazy loading is customizeable and you can hack it to implement this workaround, see "Custom Persister".

As said a couple of times now :)

It will not get into the core for good reasons

You have all the hooks you want in Hibernate to change this behavior
(interceptor, custom entity and collection persister, proxy class, event system) and it is opensource meaning you can patch it to be as inconsistent as you want ;)

The AOP trick sounds like and ok workaround the fact that the *serialization* framework you use does not have methods for customization of detecting the non-fetched boundaries of your
object graph.

We opted to go with our own hook to workaround this issue. Overtime, the Hibernate team may eventually realize that many people are writing their own hooks that do essentially the same thing. They will find commonality and create something we need then.

Today, they do not see a need. I would encourage anyone who reads this and is looking for a similar solution to just post at the end of this thread. If there are only a few posts, I'm fine with that.

why is it that you don't contribute the workaround/feature you have created to the hibernate wiki so everyone can see an example of how to make it work in your Flex scenario ?