change the "exclude-unlisted-classes" behavior in Java SE environments
Description
Attachments
- 16 Jul 2013, 01:23 AM
Activity
Brett Meyer March 7, 2014 at 10:08 PM
Bulk closing tickets resolved in released versions
Steve Ebersole September 11, 2013 at 9:06 PM
I have no idea what either of the 2 have to do with each other. But you continue to show frustration here as well.
And I love how you make up a non-sense sentence and then ask me what I meant by saying it. Lol.
Nick Williams September 11, 2013 at 8:27 PMEdited
What the heck does https://hibernate.atlassian.net/browse/HHH-8111#icft=HHH-8111 have to do with this? There's no relation between the two. My report for that bug has nothing to do with my report for this bug.
And in what world does "the spec says we don't have to support this so if we do support it but it's broken it's not actually a bug" make any sense at all?
Whatever. It's fixed. I'm done with it.
Steve Ebersole September 11, 2013 at 8:22 PM
The "bug" is about allowing to specify a value for exclude-unlisted-classes when used in SE environments. And no, I don't believe Hibernate never supported that. What it did allow/support in SE environments was to either:
1) not specify exclude-unlisted-classes and have scanning happen
2) specify exclude-unlisted-classes and have scanning not happen regardless of value
So I understand the discussion very well. You just want to argue, imo, as a continuation of your earlier frustration over HHH-8111. Really you are arguing that our ignoring the boolean value specified within exclude-unlisted-classes was a bug. I simply pointed out that that is in fact not really true, since the JPA spec specifically says exclude-unlisted-classes is not supposed to be used in SE environments. So this cannot really be a bug.
As Brett said the patch was largely accepted. Up to you if you want to continue to argue...
Nick Williams September 11, 2013 at 8:09 PMEdited
Brett, I'm relaxed. I just think Steve is understanding either A) what I'm saying or B) what this bug is about, and I want to make sure everyone is on the same page. I understand that you have merged my changes and fixed the bug, and I thank you for that. But Steve appears (and maybe I'm misunderstanding here) to be arguing for removing support for <exclude-unlisted-classes> in Java SE environments. That would un-relax me if that change were made. 🙂
Details
Details
Assignee
Reporter
Original estimate
Time tracking
Components
Fix versions
Priority
Major
In JPA 1.0's
persistence.xml,<exclude-unlisted-classes>defaulted tofalse(providers always scanned for entities). As of JPA 2.0,<exclude-unlisted-classes>was changed to default totrue. However, Hibernate EntityManager does not honor this. See lines 219-221 ofPersistenceXmlParser.java:else if ( tag.equals( "exclude-unlisted-classes" ) ) { persistenceUnit.setExcludeUnlistedClasses( true ); }This has two consequences:
If you omit
<exclude-unlisted-classes>, Hibernate will scan for entities, which is not compliant. Hibernate should default to the right value based on the JPA version.If you intentionally add
<exclude-unlisted-classes>false</exclude-unlisted-classes>topersistence.xmlto enable scanning, Hibernate will disable scanning, which is downright incorrect.This probably makes more sense:
else if ( tag.equals( "exclude-unlisted-classes" ) ) { persistenceUnit.setExcludeUnlistedClasses( extractBooleanContent(element, !isJpaGte20) ); } ... private static boolean extractBooleanContent(Element element, boolean defaultBool) { String content = extractContent( element, null ); if (content != null && content.length() > 0) { return Boolean.valueOf(content); } return defaultBool; }I don't know where the imaginary
isJpaGte20variable would come from.