Community
Participate
Working Groups
Build Identifier: 2.1.1 ClassDescriptor.getInheritancePolicy() lazily instantiates inheritancePolicy without checking whether such a policy should in fact be created. Ordinarily this is fine, but in extraordinary circumstances it can ruin the whole persistence context. We're using Spring-Flex to tie a Flex frontend to an EclipseLink persistance graph. If a org.eclipse.persistence.exceptions.DatabaseException is thrown and not caught, Spring-Flex will attempt to serialize it and return it to the client. As part of the AMF serialization process, all the exception's properties are introspected, including inheritancePolicy, which causes a fake InheritancePolicy to be created. Subsequent uses of the persistence graph result in a null pointer in AbstractRecord.get() because the broken InheritancePolicy has a null classIndicatorField. Reproducible: Always Steps to Reproduce: 1. Create a "Hello world" project using Spring-Flex and Eclipselink 2. Create a broken finder query, e.g. 'SELECT o FROM Foo o WHERE o.bar in ?' without setting the ? param 3. Invoke the finder... you'll get a DatabaseException 4. Try to invoke findByPrimaryKey or really any persistence operation. They'll all fail on an NPE.
Setting target and priority. See the following page for the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
Would it make sense to refactor getInheritancePolicy to acquireInheritancePolicy or similar? In general I haven't heard of problems with mis-use of calling getInheritancePolicy without first calling hasInheritancePolicy but I've seen quite a few people caught up by serialization issues. BlazeDS seems to be a major culprit, but I think the best fix here is to removed side affects from the getter? If needed I can supply a patch to rename these methods.
How do these libraries decide which properties to get (what does AMF serialization do)? Do they look for every method that starts with "get"? Does this mean to work with these frameworks, we shouldn't do lazy initialization at all. I wonder if you'll see issues with other methods as well. (e.g. getInterfacePolicy()) We will have backwards compatibility issues with simply renaming this method. We would have to look into doing something like checking to see if the descriptor is already initialized and not initializing in that case.
BlazeDS uses the standard JavaBean interface for determining properties, anything with both a getter and a setter is serialized. I'd assume this is true of a lot of serialization frameworks. I'm not sure if lazy instantiation is entirely at fault but in this case all of eclipselink breaks because the value should not be instantiated at all. A preemptive check to see if the value should be initialized at all would also solve this.
Is this bug being actively worked? Calling a simple getter method shouldn't be able to bring down a JPA container.
Please vote for this bug if you consider it important. Votes are a key determining factor when we decide which community-found bugs to work on.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
