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 <st...@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 <st...@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 <st...@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 <br...@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 <st...@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 <gun...@hibernate.org >>>> > >>>> >> wrote: >>>> >> >>>> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole <st...@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 < >>>> st...@hibernate.org> >>>> >>>> wrote: >>>> >>>> >>>> >>>>> Thanks for investigating this Gunnar. >>>> >>>>> >>>> >>>>> Some thoughts inline... >>>> >>>>> >>>> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling < >>>> gun...@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@lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
