[hibernate-dev] Using Hibernate ORM as automatic JPMS modules
Brett Meyer
brett at hibernate.org
Fri Dec 29 11:35:25 EST 2017
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
> <mailto: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 <mailto: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
> <http://osgi.ee>;filter:="(&(osgi.ee
> <http://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 <mailto: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 <mailto: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 <mailto: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 <mailto:gunnar at hibernate.org>>
> >> wrote:
> >>
> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole
> <steve at hibernate.org <mailto: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 <mailto: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 <mailto: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
> <mailto:hibernate-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list