[hibernate-dev] Using Hibernate ORM as automatic JPMS modules

Steve Ebersole steve at hibernate.org
Fri Dec 29 11:41:39 EST 2017 

Actually I found the problem.  Its actually not related to the manifest
change.  The problem was a mismatch in the bundle group/module names for
JPA since we switched to the (now published) standard JPA API jar.  Fixing
that fixed the failures.  Sorry for the noise.


On Fri, Dec 29, 2017 at 10:35 AM Brett Meyer <brett at hibernate.org> wrote:

> Hey Steve, just to clarify, did this start failing directly after the
> manifest change?  Or are you saying it could be from other
> dependency-related updates?
>
> On 12/29/17 10:58 AM, Steve Ebersole wrote:
>
> Maybe this is similar to the problems we've had with the WildFly
> hibernate-orm-moudles stuff - versions of karaf/aries/etc not yet
> supporting EE8 techs (JPA 2.2, CDI 2.0, etc)?
>
>
> On Thu, Dec 28, 2017 at 11:56 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Brett, after making these changes the osgi tests now fail[1] with a RMI
>> connection error which I cannot decipher.  Could you see if you can
>> understand the problem?
>>
>> Thanks
>>
>> [1]
>> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/942/testReport/junit/org.hibernate.osgi.test/
>>
>>
>>
>> On Thu, Dec 28, 2017 at 9:06 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> After tweaking this, here is what I have...
>>>
>>> Manifest-Version: 1.0
>>> Created-By: 1.8.0_121 (Oracle Corporation)
>>> Main-Class: org.hibernate.Version
>>>
>>> Specification-Title: hibernate-core
>>> Specification-Version: 5.3
>>> Specification-Vendor: Hibernate.org
>>>
>>> Implementation-Title: hibernate-core
>>> Implementation-Version: 5.3.0.SNAPSHOT
>>> Implementation-Vendor-Id: org.hibernate
>>> Implementation-Vendor: Hibernate.org
>>> Implementation-Url: http://hibernate.org
>>>
>>> Automatic-Module-Name: org.hibernate.orm.core
>>>
>>> Bundle-ManifestVersion: 2
>>> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
>>> Tool: Bnd-3.4.0.201707252008
>>>
>>> Bundle-SymbolicName: org.hibernate.orm.core
>>> Bundle-Version: 5.3.0.SNAPSHOT
>>> Bundle-Name: hibernate-core
>>> Bundle-Description: A module of the Hibernate O/RM project
>>> Bundle-Vendor: Hibernate.org
>>> Bundle-DocURL: http://www.hibernate.org/orm/5.3
>>> Bnd-LastModified: 1513615321000
>>>
>>> Import-Package: ...
>>> Export-Package: ...
>>>
>>>
>>> Which looks great to me...
>>>
>>> On Wed, Dec 27, 2017 at 3:39 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> I had intended this for 5.3 which hasn't even gone Beta yet (we wont
>>>> have an Alpha).
>>>>
>>>> On Wed, Dec 27, 2017 at 3:38 PM Brett Meyer <brett at hibernate.org>
>>>> wrote:
>>>>
>>>>> +1 from me on making them consistent.  In practice, Bundle-SymbolicName
>>>>> isn't used for much, other than a guaranteed unique identifier.  One of
>>>>> the Karaf guys pointed out that Bundle-SymbolicName is used to link a
>>>>> fragment bundle to its host bundle, but we've been able to avoid
>>>>> fragments like the plague on purpose.
>>>>>
>>>>> In practice, most users should be pulling in and interacting with our
>>>>> bundles purely through Maven artifacts or our features.xml, so a change
>>>>> would largely be unnoticed.
>>>>>
>>>>> We still might consider holding off doing that until at least a minor
>>>>> version change, since there is a potential issue for any tooling that
>>>>> might be relying on that (logging/auditing, etc.)...
>>>>>
>>>>>
>>>>> On 12/23/17 11:38 PM, Steve Ebersole wrote:
>>>>> > Another thing I was noticing was an annoying minor difference
>>>>> between the
>>>>> > OSGi bundle name and the Java 9 module name:
>>>>> >
>>>>> > Automatic-Module-Name: org.hibernate.orm.core
>>>>> > Bundle-SymbolicName: org.hibernate.core
>>>>> >
>>>>> > Does it make sense to adjust the OSGi bundle name to follow the
>>>>> module
>>>>> > naming?
>>>>> >
>>>>> > On Sat, Dec 23, 2017 at 8:47 AM Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>> >
>>>>> >> I already did a PR for the `Automatic-Module-Name` yesterday and
>>>>> added you
>>>>> >> as a reviewer.  when you get a chance...
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Sat, Dec 23, 2017 at 8:36 AM Gunnar Morling <
>>>>> gunnar at hibernate.org>
>>>>> >> wrote:
>>>>> >>
>>>>> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>>>> >>>
>>>>> >>>> I created a Jira to track this:
>>>>> >>>> https://hibernate.atlassian.net/browse/HHH-12188
>>>>> >>>>
>>>>> >>>> On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole <
>>>>> steve at hibernate.org>
>>>>> >>>> wrote:
>>>>> >>>>
>>>>> >>>>> Thanks for investigating this Gunnar.
>>>>> >>>>>
>>>>> >>>>> Some thoughts inline...
>>>>> >>>>>
>>>>> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling <
>>>>> gunnar at hibernate.org>
>>>>> >>>>> wrote:
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>> * JDK 9 comes with an incomplete JTA module (java.transaction),
>>>>> so a
>>>>> >>>>>> complete one must be provided via --upgrade-module-path (I'm
>>>>> using the
>>>>> >>>>>> 2.0.0.Alpha1 version Tomaz Cerar has created for that purpose)
>>>>> >>>>>>
>>>>> >>>>> Do you know if there is a plan to fix this in Java 9?  Seems
>>>>> bizarre
>>>>> >>>>> that Java 9 expects all kinds of strict modularity from
>>>>> libraries and
>>>>> >>>>> applications when the JDK itself can't follow that..
>>>>> >>>>>
>>>>> >>> The "java.transaction" module of the JDK is marked with
>>>>> >>> @Deprecated(forRemoval=true) as of Java 9, but I don't know when
>>>>> the
>>>>> >>> removal will happen. There's JEP 320 for this (
>>>>> >>> http://openjdk.java.net/jeps/320), which also describes why the
>>>>> module
>>>>> >>> exists in its current form. It's not scheduled for Java 10
>>>>> currently, and
>>>>> >>> given the latter is in rampdown already, I wouldn't expect this
>>>>> removal to
>>>>> >>> happen before Java 11.
>>>>> >>>
>>>>> >>>
>>>>> >>>>>> * hibernate-jpa-2.1-api-1.0.0.Final.jar can't be used as an
>>>>> automatic
>>>>> >>>>>> module, as the automatic naming algorithm stumples upon the
>>>>> numbers
>>>>> >>>>>> (2.1)
>>>>> >>>>>> within the module name it derives; I'm therefore using my
>>>>> ModiTect
>>>>> >>>>>> tooling (
>>>>> >>>>>> https://github.com/moditect/moditect/) to convert the JPA API
>>>>> JAR
>>>>> >>>>>> into an
>>>>> >>>>>> explicit module on the fly
>>>>> >>>>>>
>>>>> >>>>> We actually no longer use that artifact as a dependency.  Since
>>>>> JPA
>>>>> >>>>> 2.2, the EG publishes a "blessed" API jar which is what we use
>>>>> as a
>>>>> >>>>> dependency.
>>>>> >>>>>
>>>>> >>> Ah, yes, very nice. That one already defines an explicit module
>>>>> name
>>>>> >>> ("java.persistence") via the Automatic-Module-Name manifest entry.
>>>>> >>>
>>>>> >>>>>> * When using ByteBuddy as the byte code provider, a reads
>>>>> relationship
>>>>> >>>>>> must
>>>>> >>>>>> be added from the user's module towards hibernate.core
>>>>> ("requires
>>>>> >>>>>> hibernate.core"). This is due to the usage of
>>>>> >>>>>> org.hibernate.proxy.ProxyConfiguration within the generated
>>>>> proxy
>>>>> >>>>>> classes.
>>>>> >>>>>> Ideally no dependence to the JPA provider should be needed when
>>>>> solely
>>>>> >>>>>> working with the JPA API (as this demo does), but I'm not sure
>>>>> whether
>>>>> >>>>>> this
>>>>> >>>>>> can be avoided when using proxies (or could we construct
>>>>> proxies in a
>>>>> >>>>>> way
>>>>> >>>>>> not requiring this dependence?).
>>>>> >>>>>>
>>>>> >>>>> I'm not sure what a decent solution would be here.  Ultimately
>>>>> the
>>>>> >>>>> runtime needs to be able to communicate with the generated
>>>>> proxies - how
>>>>> >>>>> else would you suggest this happen?
>>>>> >>>>>
>>>>> >>> Not sure either. Maybe we could generate a dedicated interface
>>>>> into the
>>>>> >>> user's module and then inject a generated implementation -- living
>>>>> within
>>>>> >>> the ORM module -- of that interface into the entities. Worth some
>>>>> tinkering
>>>>> >>> I reckon.
>>>>> >>>
>>>>> >>>>> * When using ByteBuddy as the byte code provider, I still needed
>>>>> to have
>>>>> >>>>>> Javassist around, as it's used in ClassFileArchiveEntryHandler.
>>>>> I
>>>>> >>>>>> understand that eventually this should be using Jandex, but I'm
>>>>> >>>>>> wondering
>>>>> >>>>>> whether we could (temporarily) change it to use ASM instead of
>>>>> >>>>>> Javassist
>>>>> >>>>>> (at least when using ByteBuddy as byte code provider, which is
>>>>> based on
>>>>> >>>>>> ASM), so people don't need to have Javassist *and* ByteBuddy
>>>>> when
>>>>> >>>>>> using the
>>>>> >>>>>> latter as byte code provider? This seems desirable esp. once we
>>>>> move to
>>>>> >>>>>> ByteBuddy by default.
>>>>> >>>>>>
>>>>> >>>>> Yes, Sanne brought this up in Paris and it is something I will
>>>>> look at
>>>>> >>>>> prior to a 5.3.0.Final
>>>>> >>>>>
>>>>> >>> Excellent.
>>>>> >>>
>>>>> >>>>> * Multiple methods in ReflectHelper call setAccessible() without
>>>>> >>>>>> checking
>>>>> >>>>>> whether the method/field/constructor already is accessible. If
>>>>> we
>>>>> >>>>>> changed
>>>>> >>>>>> that to only call setAccessible() if actually needed, people
>>>>> would
>>>>> >>>>>> have to
>>>>> >>>>>> be a little bit less permissive in their module descriptor. It'd
>>>>> >>>>>> suffice
>>>>> >>>>>> for them to declare "exports com.example.entities to
>>>>> hibernate.core"
>>>>> >>>>>> instead of "opens com.example.entities to hibernate.core",
>>>>> unless they
>>>>> >>>>>> mandate (private) field access for their entities.
>>>>> >>>>>>
>>>>> >>>>> Can you open a Jira for that?
>>>>> >>>>>
>>>>> >>> Done: https://hibernate.atlassian.net/browse/HHH-12189.
>>>>> >>>
>>>>> >>>
>>>>> >>>>>> The demo is very simple (insert and load of an entity with a
>>>>> lazy
>>>>> >>>>>> association). If there's anything else you'd like to try out
>>>>> when
>>>>> >>>>>> using ORM
>>>>> >>>>>> as JPMS modules, let me know or just fork the demo and try it
>>>>> out
>>>>> >>>>>> yourself
>>>>> >>>>>>
>>>>> >>>>> IIUC for jars targeting both Java 8 and Java 9 we cannot include
>>>>> a
>>>>> >>>>> module-info file.  But we need to set the module names - you
>>>>> mentioned
>>>>> >>>>> there was a "hinting" process.  From what I could glean from
>>>>> searching
>>>>> >>>>> (which was oddly not many hits), this is achieved by adding a
>>>>> >>>>> `Automatic-Module-Name` entry in the JAR's MANIFEST.MF.  Correct?
>>>>> >>>>>
>>>>> >>> Yes, exactly that's the mechanism. Jason Greene is working on a
>>>>> document
>>>>> >>> with recommendations around naming patterns, I hope it'll be
>>>>> published soon.
>>>>> >>>
>>>>> >>>
>>>>> >>>>> Also, IIRC we agreed with `org.hibernate.orm` as the base for
>>>>> all ORM
>>>>> >>>>> module names, so we'd have:
>>>>> >>>>>
>>>>> >>>>>     - org.hibernate.orm.c3p0
>>>>> >>>>>     - org.hibernate.orm.core
>>>>> >>>>>     - ...
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> > _______________________________________________
>>>>> > hibernate-dev mailing list
>>>>> > hibernate-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>

More information about the hibernate-dev mailing list