Eclipse Community Forums: EclipseLink » ReadOnly object query causes NPE in hashCode

Help

Home

Home » Eclipse Projects » EclipseLink » ReadOnly object query causes NPE in hashCode

Show: Today's Messages :: Show Polls :: Message Navigator

ReadOnly object query causes NPE in hashCode [message #1804213]

Wed, 20 March 2019 14:38

Joel Lucuik

Messages: 2
Registered: March 2019

Junior Member

Stacktrace attached. (names modified because we can't share details)

Versions:
WebLogic Server 12.2.1.2.0
Eclipselink: 2.7.1

We're using WebLogic RMI.
We have a 1:N ClassA -> ClassA1. ClassA1 is @ReadOnly.

Not sure if the 1:N is even relevant, but good to know.

When we query for A1(s) we get a NPE in the hashCode method accessing the ID of the instance of A1.

Is there an issue with (lazy) loading ReadOnly objects if we have a custom hashCode method accessing the ID. Will the id be populated inside the hashCode?

Note when we remove the @ReadOnly there's no issue, and when we delete the hashCode and equals there's no issue.

Thanks
Joel Lucuik

Attachment: 1327_stack_trace.docx
(Size: 18.79KB, Downloaded 209 times)

Report message to a moderator

Re: ReadOnly object query causes NPE in hashCode [message #1804273 is a reply to message #1804213]

Thu, 21 March 2019 16:46

Chris Delahunt

Messages: 1389
Registered: July 2009

Senior Member

Hi Joel

Looks like the issue is with RMI serializing the collection which might not be fully fetched.
Can you show your A1 class and what exactly is getting the NPE in the hashcode method? how was the initial ClassA instance fetched from the database?
When you remove the hashcode/equality method implementations, are there any problems accessing the values in the collection on the other side?

Best Regards,
Chris

Report message to a moderator

Re: ReadOnly object query causes NPE in hashCode [message #1804345 is a reply to message #1804273]

Fri, 22 March 2019 17:49

Joel Lucuik

Messages: 2
Registered: March 2019

Junior Member

>Looks like the issue is with RMI serializing the collection which might not be fully fetched.
OK. Thanks

>Can you show your A1 class and what exactly is getting the NPE in the hashcode method?
This gets a bit confusing. Take a look below. I don't know how this could happen. Line 175 is indicated.

@Override
public int hashCode() {
int result = (int) (id ^ (id >>> 32));
result = 31 * result + (nameKey != null ? nameKey.hashCode() : 0);
result = 31 * result + (subtitleKey != null ? subtitleKey.hashCode() : 0);
// result = 31 * result + (displayed ? 1 : 0);
// result = 31 * result + (readOnly ? 1 : 0);
result = 31 * result + (fieldPartialMsgKey != null ? fieldPartialMsgKey.hashCode() : 0);
>> result = 31 * result + (fieldOrder != null ? fieldOrder.hashCode() : 0);
result = 31 * result + (allMandatory ? 1 : 0);
return result;
}

I don't think the code can get a NPE regardless. Something doesn't make sense.

result: would have hit NPE earlier
id: MAYBE, but the line number is inconsistent
fieldOrder: is already checked

I will try and reproduce this, but any thoughts on any issues in the above method please let me know.

>how was the initial ClassA instance fetched from the database?
Its a query at the beginning of the stack

public List<A1> findA1s(A a) {
String query = "select t from A1 t where t.a.aPk = :aPk";
return entityManager
.createQuery(query, A1.class)
.setParameter("aPk", a.getAPk())
.getResultList();
}

>When you remove the hashcode/equality method implementations, are there any problems accessing the values in the collection on the other side?
Not that I'm aware of. But they want both left in and need ReadOnly.

The co-worker that created this bug was just starting on the project when he raised this, so we're just looking for "things not right" with @ReadOnly.

Let me know if you see anything obvious. I will try and reproduce this anyway.

Thanks,

Joel

Report message to a moderator

Previous Topic:	Moxy Java11
Next Topic:	Eclipse Auto Save before build?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Nov 29 10:05:28 GMT 2023

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter