From gunnar at hibernate.org Mon Dec 4 10:48:05 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 4 Dec 2017 16:48:05 +0100 Subject: [hibernate-dev] List of changes in JPA 2.2 Message-ID: Hi, Related to the discussion this afternoon, this is the list of API changes in JPA 2.2: * all repeatable annotations marked with @Repeatable * new annotations javax.persistence.SequenceGenerators and TableGenerators (containing annotation types for repeatable annotations SequenceGenerator and TableGenerator) * new methods javax.persistence.Query#getResultStream() and TypedQuery#getResultStream() You can find the full diff below. Cheers, --Gunnar ===== Comparing source compatibility of javax.persistence-2.2.0.jar against javax.persistence-2.1.1.jar WARNING: You are using the option '--ignore-missing-classes', i.e. superclasses and interfaces that could not be found on the classpath are ignored. Hence changes caused by these superclasses and interfaces are not reflected in the output. === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.AssociationOverride (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.AssociationOverrides (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.AttributeOverride (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.AttributeOverrides (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.Convert (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.Converts (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.JoinColumn (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.JoinColumns (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.MapKeyJoinColumn (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.MapKeyJoinColumns (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.NamedEntityGraph (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.NamedEntityGraphs (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.NamedNativeQuery (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.NamedNativeQueries (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.NamedQuery (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.NamedQueries (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.NamedStoredProcedureQuery (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.NamedStoredProcedureQueries (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.PersistenceContext (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.PersistenceContexts (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.PersistenceUnit (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.PersistenceUnits (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.PrimaryKeyJoinColumn (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.PrimaryKeyJoinColumns (+) **** MODIFIED INTERFACE: PUBLIC ABSTRACT javax.persistence.Query (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++* NEW METHOD: PUBLIC(+) java.util.stream.Stream getResultStream() === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.SecondaryTable (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.SecondaryTables (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.SequenceGenerator (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.SequenceGenerators (+) +++ NEW ANNOTATION: PUBLIC(+) ABSTRACT(+) javax.persistence.SequenceGenerators (not serializable) +++ CLASS FILE FORMAT VERSION: 52.0 <- -1.-1 +++ NEW INTERFACE: java.lang.annotation.Annotation +++ NEW SUPERCLASS: java.lang.Object +++ NEW METHOD: PUBLIC(+) ABSTRACT(+) javax.persistence.SequenceGenerator[] value() +++ NEW ANNOTATION: java.lang.annotation.Target +++ NEW ELEMENT: value=java.lang.annotation.ElementType.TYPE,java.lang.annotation.ElementType.METHOD,java.lang.annotation.ElementType.FIELD (+) +++ NEW ANNOTATION: java.lang.annotation.Retention +++ NEW ELEMENT: value=java.lang.annotation.RetentionPolicy.RUNTIME (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.SqlResultSetMapping (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.SqlResultSetMappings (+) === UNCHANGED ANNOTATION: PUBLIC ABSTRACT javax.persistence.TableGenerator (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 +++ NEW ANNOTATION: java.lang.annotation.Repeatable +++ NEW ELEMENT: value=javax.persistence.TableGenerators (+) +++ NEW ANNOTATION: PUBLIC(+) ABSTRACT(+) javax.persistence.TableGenerators (not serializable) +++ CLASS FILE FORMAT VERSION: 52.0 <- -1.-1 +++ NEW INTERFACE: java.lang.annotation.Annotation +++ NEW SUPERCLASS: java.lang.Object +++ NEW METHOD: PUBLIC(+) ABSTRACT(+) javax.persistence.TableGenerator[] value() +++ NEW ANNOTATION: java.lang.annotation.Target +++ NEW ELEMENT: value=java.lang.annotation.ElementType.TYPE,java.lang.annotation.ElementType.METHOD,java.lang.annotation.ElementType.FIELD (+) +++ NEW ANNOTATION: java.lang.annotation.Retention +++ NEW ELEMENT: value=java.lang.annotation.RetentionPolicy.RUNTIME (+) **** MODIFIED INTERFACE: PUBLIC ABSTRACT javax.persistence.TypedQuery (not serializable) ***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0 ===* UNCHANGED INTERFACE: javax.persistence.Query +++* NEW METHOD: PUBLIC(+) java.util.stream.Stream getResultStream() From gbadner at redhat.com Tue Dec 5 10:04:18 2017 From: gbadner at redhat.com (Gail Badner) Date: Tue, 5 Dec 2017 16:04:18 +0100 Subject: [hibernate-dev] HHH-10162 Inheritance and L2 cache In-Reply-To: References: <24e7eec4-1d2d-47f5-f21d-fda0f28e24a6@gmail.com> <162f5f1f-3b21-9201-2572-86c79ec3d875@gmail.com> <5b57ca1b-6231-2ed9-75e5-4814f9ed9941@gmail.com> Message-ID: Adding Steve... On Thu, Mar 16, 2017 at 1:44 PM, Christian Beikov < christian.beikov at gmail.com> wrote: > Hey Gail, > > comments inline.. > > Am 15.03.2017 um 23:21 schrieb Gail Badner: > > Hi Christian, > > More comments below... > > On Fri, Mar 3, 2017 at 4:38 PM, Christian Beikov < > christian.beikov at gmail.com> wrote: > >> Thanks for the comments, I have updated the PR. >> >> I think that it is important to have a complete fix and I am already >> working on that, but this issue was specifically about the L2 cache, so I >> wanted to keep that stuff separate. >> >> Here are some other polymorphism related issues: >> >> - https://hibernate.atlassian.net/browse/HHH-9845 >> - https://hibernate.atlassian.net/browse/HHH-11280 >> - https://hibernate.atlassian.net/browse/HHH-4742 >> - https://hibernate.atlassian.net/browse/HHH-2927 >> >> Thanks for looking into this. It is definitely and area that can/should > be improved. > > >> The fix provided by Josh Landin for HHH-11280 would break reference >> equality and I think that is something we all want to keep. Which brings us >> to the actual problems. >> > > I agree. We definitely do not want to break reference equality. > > >> >> 1. Whenever we encounter an association that is of a polymorphic entity >> type, we should actually internally, regardless of what the user >> configures, always fetch that association with subtypes. Otherwise we could >> run into that same problem again, that we "pollute" the L1 cache with a >> proxy of the wrong type. Since we want to keep reference equality, we can't >> replace that instance. >> > > IIUC, this is only a problem if the association is with a polymorphic > entity Class that has a subclass. Since a fix would probably affect > performance, I think it would be best to only deal with this particular > case. Maybe you are saying the same thing; I just wanted to clarify. > > Yep saying the same thing. > > > What you are suggesting is to eagerly fetch the association. IIUC, a > workaround is to map such associations as eager. That way a proxy would not > be created, avoiding the problem altogether. > > Correct. > > > IMO, if the entity is mapped as lazy, it really should be lazily-loaded. > That said, I think that it would be worthwhile for Hibernate to determine > the concrete subclass for the associated entity and create the appropriate > proxy. I can think of some alternatives, but I think they would all affect > performance. Maybe there should be a property for indicating the strategy > to use. Some strategies that come to mind are: > > 1) by default, create an uninitialized proxy using the type indicated in > the mapping (as is done currently); > 2) try loading from second-level cache (as done in your fix for > HHH-10162); if the entity is not found in the cache, then execute a query > to determine the associated entity's concrete subclass; > 3) add a join to the original query to determine the associated entity's > concrete subclass, and create the appropriate uninitialized proxy. > > I roughly thought of the same strategies, but I'd like to propose a 1b) > strategy that would also check the L2 cache in case of a polymorphic > association. So maybe the config for whether a L2 lookup should be done > should be a "separate" and independent config. > > > You mentioned that you are working on something. Is tihs along the lines > of what you are thinking? Did you have other ideas? > > Just what I wrote up so far. > > > 2. When using bytecode enhancement, the loading of *ToOne instances could >> be deferred to the first access. >> > > Yes, this is another workaround. > > I wouldn't say workaround but performance improvement :) > > > >> >> 3. Actually it would also be possible if property access is used without >> bytecode enhancement, but that would require to use a special proxy for >> every object that might contain a non-initialized polymorphic association. >> The speciality about it is that it loads the association on first access. >> >> > I'm not sure I'm following this. > > When querying for an entity A like "FROM A", currently we always return A > instances although we could return special proxy A instances. The special > thing about the proxy is, that it has all state initialized except for > polymorphic associations. These associations are only loaded from the DB > when accessing them through their respective property accessors. Note that > this proxy is also something that we can use for optional "toParent" > one-to-one associations. > > The only proxies that we have right now are for uninitialized associations > which trigger loading the full entity on non-id property access. Either we > extend the existing proxy implementation by the explained functionality, or > we create a separate proxy type. > > > >> 4. Another thing that we should consider is "merging" of fetched state >> into existing instances of the L1 cache. Imagine a user loads an entity X >> and some of it's associations are lazy loaded. Then the user sets of a >> query that would fetch that association. Currently the associations will be >> left untouched because we skip any further processing as soon as we >> encounter the instance for X in the L1 cache. What we should actually do >> is, merge any fetched state into the instance if possible. >> > > +1; I think this is a good improvement. > > Note that this improvement kind of requires that there are no wrongly > typed proxy instance in the L1 cache. We could actually also "just" merge > the state that we can i.e. ignoring subtype state. > > >> Since 1. will probably affect performance, it might only make sense to do >> it along with 2. or 3. >> >> Regardless of these improvements, I think we should apply the L2 cache >> fix and handle the rest later. >> >> What do you say? >> > > I think it would be better to come up with a hibernate property and > strategies, and allow an application to opt into a strategy, rather than > making a change that can affect performance by default. > > I agree that users should have the possibility to configure this. The > question is, should this be a global config or per-entity or maybe even > per-association? When all the performance optimizations are implemented I > see no reason for adding a per-entity or per-association config, a global > default should be enough. After all, the additional query for loading the > subtype will only happen when a user tries to get his hands on the instance. > > What do you say, how should we proceed? I'd start by creating/collecting > JIRAs for the issues and posting them here so you can track them. > Next I'd like to improve the proxy implementation as described in 3) as > that would improve performance in other scenarios too. > > Thought? Feedback? > From guillaume.smet at gmail.com Wed Dec 6 02:59:48 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 6 Dec 2017 08:59:48 +0100 Subject: [hibernate-dev] Geospatial types/queries and OGM Message-ID: Hi, So here is how the MongoDB geospatial support looks like currently: https://github.com/hibernate/hibernate-ogm/tree/master/mongodb/src/main/java/org/hibernate/ogm/datastore/mongodb/type So basically, moving to JTS would have the following benefits and drawbacks: + we can remove these types from OGM + we are consistent with the current spatial support of ORM (note that there is also work on spatial4j which is different from JTS and apparently they are talking about a JTS 2 API that would be different from the current API) + you have the whole JTS API at hand - the JTS API for creating shapes is not very user friendly: you have to define a precision model and a SRID - which are of no use for MongoDB, you have to pass an array of points to create a polygon and things like that - it sure works but it's not very user friendly and looks like a 1990s API - we end up adding a 800 kB jar for something really simple: I don't really think people will use the JTS advanced features in conjunction with MongoDB - we will have to add a helper API for allowing the users to convert easily a shape to a BSON document (currently, it's included in the Geo* classes) - we won't be able to support GeometryCollection as the only thing available in the JTS API is the list of coordinates of the shapes, you can't access the types of the shapes (which are needed for the GeoJSON version of GeometryCollection) - full disclosure: I haven't added GeometryCollection support yet in what I did (I created an issue suitable for new contributors to have an easy task suitable for a potential contributor) So all in all, I'm not convinced it's such a good move. -- Guillaume From sanne at hibernate.org Sun Dec 10 14:06:04 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Sun, 10 Dec 2017 19:06:04 +0000 Subject: [hibernate-dev] Geospatial types/queries and OGM In-Reply-To: References: Message-ID: On 6 December 2017 at 07:59, Guillaume Smet wrote: > Hi, > > So here is how the MongoDB geospatial support looks like currently: > https://github.com/hibernate/hibernate-ogm/tree/master/mongodb/src/main/java/org/hibernate/ogm/datastore/mongodb/type > > So basically, moving to JTS would have the following benefits and drawbacks: > > + we can remove these types from OGM > + we are consistent with the current spatial support of ORM (note that > there is also work on spatial4j which is different from JTS and apparently > they are talking about a JTS 2 API that would be different from the current > API) > + you have the whole JTS API at hand > > - the JTS API for creating shapes is not very user friendly: you have to > define a precision model and a SRID - which are of no use for MongoDB, you > have to pass an array of points to create a polygon and things like that - > it sure works but it's not very user friendly and looks like a 1990s API > - we end up adding a 800 kB jar for something really simple: I don't really > think people will use the JTS advanced features in conjunction with MongoDB > - we will have to add a helper API for allowing the users to convert easily > a shape to a BSON document (currently, it's included in the Geo* classes) > - we won't be able to support GeometryCollection as the only thing > available in the JTS API is the list of coordinates of the shapes, you > can't access the types of the shapes (which are needed for the GeoJSON > version of GeometryCollection) - full disclosure: I haven't added > GeometryCollection support yet in what I did (I created an issue suitable > for new contributors to have an easy task suitable for a potential > contributor) > > So all in all, I'm not convinced it's such a good move. Fair enough; let's not do it then for now - if users want to use something else they might tell us. Sanne From mihalcea.vlad at gmail.com Mon Dec 11 10:24:17 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 11 Dec 2017 17:24:17 +0200 Subject: [hibernate-dev] Realising the JavaDoc jars as well Message-ID: Hi, I've noticed this Pull Request which is valid and worth integrating: https://github.com/hibernate/hibernate-orm/pull/2078 Before I merge it, I wanted to make sure whether this change was accidental or intentional. Was there any reason not to ship the JavaDoc jars along with the release artifacts and the sources jars as well? Thanks, Vlad From sanne at hibernate.org Mon Dec 11 14:32:20 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 11 Dec 2017 19:32:20 +0000 Subject: [hibernate-dev] Realising the JavaDoc jars as well In-Reply-To: References: Message-ID: +1 to merge it (if it works - which I didn't check) Some history can easily be found: - http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html Thanks, Sanne On 11 December 2017 at 15:24, Vlad Mihalcea wrote: > Hi, > > I've noticed this Pull Request which is valid and worth integrating: > > https://github.com/hibernate/hibernate-orm/pull/2078 > > Before I merge it, I wanted to make sure whether this change was accidental > or intentional. > > Was there any reason not to ship the JavaDoc jars along with the release > artifacts and the sources jars as well? > > Thanks, > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Dec 11 14:46:12 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 11 Dec 2017 19:46:12 +0000 Subject: [hibernate-dev] Realising the JavaDoc jars as well In-Reply-To: References: Message-ID: Because we decided it is generally not useful to release jars of javadocs that do not inter-link, which is why we spent so much effort producing the aggregated javadocs. On Mon, Dec 11, 2017 at 1:12 PM Vlad Mihalcea wrote: > Hi, > > I've noticed this Pull Request which is valid and worth integrating: > > https://github.com/hibernate/hibernate-orm/pull/2078 > > Before I merge it, I wanted to make sure whether this change was accidental > or intentional. > > Was there any reason not to ship the JavaDoc jars along with the release > artifacts and the sources jars as well? > > Thanks, > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Tue Dec 12 06:58:30 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 12 Dec 2017 11:58:30 +0000 Subject: [hibernate-dev] Keeping CI from being confusing. Message-ID: I see many jobs are still explicitly configured to request a build on slaves tagged as "OS1". Please get rid of that: we have no longer any slave running on OS1, some of the new slaves use the "OS1" label to allow a smooth migration - but it's a lie and it's been a long time since we removed OS1. I will need to eventually cleanup such things, as it's getting messy and confusing. Labels are expected to be used to tag specific slaves to have specific capabilities, so that some jobs can flag they require such capabilities. Typically the only label you need is "Slave" as we don't want most jobs to run on the master node. An example of a valid label is "HANA" for the job running integration tests on the HANA database; for obvious reasons this job needs to be run on the only slave actually having HANA running. While at it, if you installed any Jenkins plugin which you no longer need please remove it. General reminder: there's no dedicated team to keep CI or infrastructure running efficiently, we're all responsible so try to dedicate it some 20 minutes every month making sure your jobs are still necessary and configurations are up to date. For more extensive operations ask Davide or myself and we'll see to help. Thanks, Sanne From steve at hibernate.org Tue Dec 12 09:49:21 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 12 Dec 2017 14:49:21 +0000 Subject: [hibernate-dev] HHH-12146 - subclass-specific caching Message-ID: HHH-12146 is about being able to enable/disable caching at various levels in an entity hierarchy. E.g., given a hierarchy such as `Person` and `Company` both extending `LegalEntity`, this would allow users to say that only `Company` should be cached but not `Person` nor any other `LegalEntity` subclass. The underlying approach here is to still define region and access-strategy information per-hierarchy - users will simply be able to opt out of (or into) caching particular subclasses. In my initial attempt I simply allowed both `@Cache` and `@Cacheable` to appear anywhere in the hierarchy. However, allowing `@Cache` (as currently defined) implies that users should be able to define different regions and/or access strategies for various subclasses within the hierarchy. Stepping back, I thought a better solution would be to continue to support `@Cache` only at the root level and define this new feature in terms of `@Cacheable` at the various levels. This has a few implications that I wanted to discuss. The main thing is that this means that applications using just `@Cache` to define caching would still only be able to declare caching for the entire hierarchy. But I think that is ok because that was the legacy behavior, and so nothing is really changing there. If we find `@Cache` on the root we'd assume an implicit `@Cacheable(true)`. I think some examples will help explain... Current behavior @Inheritance(...) @Cache(...) abstract class LegalEntity { ... } class Person extends LegalEntity { ... } class Company extends LegalEntity { ... } In the current behavior both `@Cache` and `@Cacheable` are only valid on the root as seen above. Placing them on any subclass results in an error. Note too that we could have used `@Cacheable` here instead of `@Cache` in which case the default `@Cache` values would be applied. It was also legal to use both together. In fact, a portable application would use `@Cacheable` with or without `@Cache`. Proposed behavior @Inheritance(...) @Cache(...) @Cacheable(false) abstract class LegalEntity { ... } class Person extends LegalEntity { ... } @Cacheable(true) class Company extends LegalEntity { ... } Here we have the root disabling caching (assuming `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that setting. `Company` however overrides that to enable caching. We still have `@Cache` attached to the root to define the specifics of caching (region, access strategy). But as noted earlier, we could have left off `@Cache` and accepted the defaults. I also propose that we continue to accept `@Cache` (without explicit `@Cacheable`) as implying `@Cacheable(true)` although `SharedCacheMode` plays a part in that too. Anyway, I wanted to make sure everyone agrees with this. From mihalcea.vlad at gmail.com Tue Dec 12 09:54:38 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 12 Dec 2017 16:54:38 +0200 Subject: [hibernate-dev] Realising the JavaDoc jars as well In-Reply-To: References: Message-ID: I tested it locally, and when publishing the jars to Maven local, the JavaDoc is now included. Don't know if there's anything to be done about it. Vlad On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero wrote: > +1 to merge it (if it works - which I didn't check) > > Some history can easily be found: > - http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html > > Thanks, > Sanne > > > On 11 December 2017 at 15:24, Vlad Mihalcea > wrote: > > Hi, > > > > I've noticed this Pull Request which is valid and worth integrating: > > > > https://github.com/hibernate/hibernate-orm/pull/2078 > > > > Before I merge it, I wanted to make sure whether this change was > accidental > > or intentional. > > > > Was there any reason not to ship the JavaDoc jars along with the release > > artifacts and the sources jars as well? > > > > Thanks, > > Vlad > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Tue Dec 12 13:32:40 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 12 Dec 2017 18:32:40 +0000 Subject: [hibernate-dev] HHH-12146 - subclass-specific caching In-Reply-To: References: Message-ID: Conceptually it sounds useful but I'm wondering about this being safe to do in various more tricky mapping scenarios. For example consider this case: @Inheritance(...) @Cache(...) @Cacheable(true) class LegalEntity { ... } @Cacheable(false) class Person extends LegalEntity { ... } @Cacheable(true) class Company extends LegalEntity { ... } [N.B. the parent class is no longer abstract] Now imagine we have to implement a polymorphic load: `load(key, LegalEntity.class)` Would you be able to use the 2LC safely in all possible inheritance mappings? I'm particularly curious about the possibility of a Person being stored, but since we won't have data about the Person in the cache we'd materialize the load as a LegalEntity. Incidentally while writing this example I realize that such a mapping could trigger issues even with existing caching options. Thanks, Sanne On 12 December 2017 at 14:49, Steve Ebersole wrote: > HHH-12146 is about being able to enable/disable caching at various levels > in an entity hierarchy. E.g., given a hierarchy such as `Person` and > `Company` both extending `LegalEntity`, this would allow users to say that > only `Company` should be cached but not `Person` nor any other > `LegalEntity` subclass. > > The underlying approach here is to still define region and access-strategy > information per-hierarchy - users will simply be able to opt out of (or > into) caching particular subclasses. In my initial attempt I simply > allowed both `@Cache` and `@Cacheable` to appear anywhere in the > hierarchy. However, allowing `@Cache` (as currently defined) implies that > users should be able to define different regions and/or access strategies > for various subclasses within the hierarchy. Stepping back, I thought a > better solution would be to continue to support `@Cache` only at the root > level and define this new feature in terms of `@Cacheable` at the various > levels. This has a few implications that I wanted to discuss. > > The main thing is that this means that applications using just `@Cache` to > define caching would still only be able to declare caching for the entire > hierarchy. But I think that is ok because that was the legacy behavior, > and so nothing is really changing there. If we find `@Cache` on the root > we'd assume an implicit `@Cacheable(true)`. I think some examples will > help explain... > > > Current behavior > > @Inheritance(...) > @Cache(...) > abstract class LegalEntity { > ... > } > > class Person extends LegalEntity { > ... > } > > class Company extends LegalEntity { > ... > } > > In the current behavior both `@Cache` and `@Cacheable` are only valid on > the root as seen above. Placing them on any subclass results in an error. > Note too that we could have used `@Cacheable` here instead of `@Cache` in > which case the default `@Cache` values would be applied. It was also legal > to use both together. In fact, a portable application would use > `@Cacheable` with or without `@Cache`. > > > Proposed behavior > > @Inheritance(...) > @Cache(...) > @Cacheable(false) > abstract class LegalEntity { > ... > } > > class Person extends LegalEntity { > ... > } > > @Cacheable(true) > class Company extends LegalEntity { > ... > } > > Here we have the root disabling caching (assuming > `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that setting. > `Company` however overrides that to enable caching. We still have > `@Cache` attached to the root to define the specifics of caching (region, > access strategy). But as noted earlier, we could have left off `@Cache` > and accepted the defaults. > > I also propose that we continue to accept `@Cache` (without explicit > `@Cacheable`) as implying `@Cacheable(true)` although `SharedCacheMode` > plays a part in that too. > > Anyway, I wanted to make sure everyone agrees with this. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Dec 12 13:44:44 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 12 Dec 2017 18:44:44 +0000 Subject: [hibernate-dev] HHH-12146 - subclass-specific caching In-Reply-To: References: Message-ID: Its not any different than `#get( LegalEntity.class, key )` in the old config when key refers to a Person and Person is *not* in the cache simply because it has not been loaded/saved via this SF. On Tue, Dec 12, 2017 at 12:33 PM Sanne Grinovero wrote: > Conceptually it sounds useful but I'm wondering about this being safe > to do in various more tricky mapping scenarios. > > For example consider this case: > > @Inheritance(...) > @Cache(...) > @Cacheable(true) > class LegalEntity { > ... > } > > @Cacheable(false) > class Person extends LegalEntity { > ... > } > > @Cacheable(true) > class Company extends LegalEntity { > ... > } > > [N.B. the parent class is no longer abstract] > > Now imagine we have to implement a polymorphic load: `load(key, > LegalEntity.class)` > > Would you be able to use the 2LC safely in all possible inheritance > mappings? > > I'm particularly curious about the possibility of a Person being > stored, but since we won't have data about the Person in the cache > we'd materialize the load as a LegalEntity. > > Incidentally while writing this example I realize that such a mapping > could trigger issues even with existing caching options. > > Thanks, > Sanne > > > > On 12 December 2017 at 14:49, Steve Ebersole wrote: > > HHH-12146 is about being able to enable/disable caching at various levels > > in an entity hierarchy. E.g., given a hierarchy such as `Person` and > > `Company` both extending `LegalEntity`, this would allow users to say > that > > only `Company` should be cached but not `Person` nor any other > > `LegalEntity` subclass. > > > > The underlying approach here is to still define region and > access-strategy > > information per-hierarchy - users will simply be able to opt out of (or > > into) caching particular subclasses. In my initial attempt I simply > > allowed both `@Cache` and `@Cacheable` to appear anywhere in the > > hierarchy. However, allowing `@Cache` (as currently defined) implies > that > > users should be able to define different regions and/or access strategies > > for various subclasses within the hierarchy. Stepping back, I thought a > > better solution would be to continue to support `@Cache` only at the root > > level and define this new feature in terms of `@Cacheable` at the various > > levels. This has a few implications that I wanted to discuss. > > > > The main thing is that this means that applications using just `@Cache` > to > > define caching would still only be able to declare caching for the entire > > hierarchy. But I think that is ok because that was the legacy behavior, > > and so nothing is really changing there. If we find `@Cache` on the root > > we'd assume an implicit `@Cacheable(true)`. I think some examples will > > help explain... > > > > > > Current behavior > > > > @Inheritance(...) > > @Cache(...) > > abstract class LegalEntity { > > ... > > } > > > > class Person extends LegalEntity { > > ... > > } > > > > class Company extends LegalEntity { > > ... > > } > > > > In the current behavior both `@Cache` and `@Cacheable` are only valid on > > the root as seen above. Placing them on any subclass results in an > error. > > Note too that we could have used `@Cacheable` here instead of `@Cache` in > > which case the default `@Cache` values would be applied. It was also > legal > > to use both together. In fact, a portable application would use > > `@Cacheable` with or without `@Cache`. > > > > > > Proposed behavior > > > > @Inheritance(...) > > @Cache(...) > > @Cacheable(false) > > abstract class LegalEntity { > > ... > > } > > > > class Person extends LegalEntity { > > ... > > } > > > > @Cacheable(true) > > class Company extends LegalEntity { > > ... > > } > > > > Here we have the root disabling caching (assuming > > `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that setting. > > `Company` however overrides that to enable caching. We still have > > `@Cache` attached to the root to define the specifics of caching (region, > > access strategy). But as noted earlier, we could have left off `@Cache` > > and accepted the defaults. > > > > I also propose that we continue to accept `@Cache` (without explicit > > `@Cacheable`) as implying `@Cacheable(true)` although `SharedCacheMode` > > plays a part in that too. > > > > Anyway, I wanted to make sure everyone agrees with this. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Dec 12 13:45:50 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 12 Dec 2017 18:45:50 +0000 Subject: [hibernate-dev] HHH-12146 - subclass-specific caching In-Reply-To: References: Message-ID: And btw, this *has* to happen. JPA requires it and the 2.2 TCK tests for it. So there is no "keep allowing caching at the root-level" option here On Tue, Dec 12, 2017 at 12:44 PM Steve Ebersole wrote: > Its not any different than `#get( LegalEntity.class, key )` in the old > config when key refers to a Person and Person is *not* in the cache simply > because it has not been loaded/saved via this SF. > > On Tue, Dec 12, 2017 at 12:33 PM Sanne Grinovero > wrote: > >> Conceptually it sounds useful but I'm wondering about this being safe >> to do in various more tricky mapping scenarios. >> >> For example consider this case: >> >> @Inheritance(...) >> @Cache(...) >> @Cacheable(true) >> class LegalEntity { >> ... >> } >> >> @Cacheable(false) >> class Person extends LegalEntity { >> ... >> } >> >> @Cacheable(true) >> class Company extends LegalEntity { >> ... >> } >> >> [N.B. the parent class is no longer abstract] >> >> Now imagine we have to implement a polymorphic load: `load(key, >> LegalEntity.class)` >> >> Would you be able to use the 2LC safely in all possible inheritance >> mappings? >> >> I'm particularly curious about the possibility of a Person being >> stored, but since we won't have data about the Person in the cache >> we'd materialize the load as a LegalEntity. >> >> Incidentally while writing this example I realize that such a mapping >> could trigger issues even with existing caching options. >> >> Thanks, >> Sanne >> >> >> >> On 12 December 2017 at 14:49, Steve Ebersole wrote: >> > HHH-12146 is about being able to enable/disable caching at various >> levels >> > in an entity hierarchy. E.g., given a hierarchy such as `Person` and >> > `Company` both extending `LegalEntity`, this would allow users to say >> that >> > only `Company` should be cached but not `Person` nor any other >> > `LegalEntity` subclass. >> > >> > The underlying approach here is to still define region and >> access-strategy >> > information per-hierarchy - users will simply be able to opt out of (or >> > into) caching particular subclasses. In my initial attempt I simply >> > allowed both `@Cache` and `@Cacheable` to appear anywhere in the >> > hierarchy. However, allowing `@Cache` (as currently defined) implies >> that >> > users should be able to define different regions and/or access >> strategies >> > for various subclasses within the hierarchy. Stepping back, I thought a >> > better solution would be to continue to support `@Cache` only at the >> root >> > level and define this new feature in terms of `@Cacheable` at the >> various >> > levels. This has a few implications that I wanted to discuss. >> > >> > The main thing is that this means that applications using just `@Cache` >> to >> > define caching would still only be able to declare caching for the >> entire >> > hierarchy. But I think that is ok because that was the legacy behavior, >> > and so nothing is really changing there. If we find `@Cache` on the >> root >> > we'd assume an implicit `@Cacheable(true)`. I think some examples will >> > help explain... >> > >> > >> > Current behavior >> > >> > @Inheritance(...) >> > @Cache(...) >> > abstract class LegalEntity { >> > ... >> > } >> > >> > class Person extends LegalEntity { >> > ... >> > } >> > >> > class Company extends LegalEntity { >> > ... >> > } >> > >> > In the current behavior both `@Cache` and `@Cacheable` are only valid >> on >> > the root as seen above. Placing them on any subclass results in an >> error. >> > Note too that we could have used `@Cacheable` here instead of `@Cache` >> in >> > which case the default `@Cache` values would be applied. It was also >> legal >> > to use both together. In fact, a portable application would use >> > `@Cacheable` with or without `@Cache`. >> > >> > >> > Proposed behavior >> > >> > @Inheritance(...) >> > @Cache(...) >> > @Cacheable(false) >> > abstract class LegalEntity { >> > ... >> > } >> > >> > class Person extends LegalEntity { >> > ... >> > } >> > >> > @Cacheable(true) >> > class Company extends LegalEntity { >> > ... >> > } >> > >> > Here we have the root disabling caching (assuming >> > `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that setting. >> > `Company` however overrides that to enable caching. We still have >> > `@Cache` attached to the root to define the specifics of caching >> (region, >> > access strategy). But as noted earlier, we could have left off `@Cache` >> > and accepted the defaults. >> > >> > I also propose that we continue to accept `@Cache` (without explicit >> > `@Cacheable`) as implying `@Cacheable(true)` although `SharedCacheMode` >> > plays a part in that too. >> > >> > Anyway, I wanted to make sure everyone agrees with this. >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From sanne at hibernate.org Tue Dec 12 18:32:09 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 12 Dec 2017 23:32:09 +0000 Subject: [hibernate-dev] HHH-12146 - subclass-specific caching In-Reply-To: References: Message-ID: We discussed this further in chat. For the sake of others reading, the summary: I got confused about the risks of having multiple cache regions for a single hierarchy; the proposal is *not* to have multiple regions yet be able to exclude specific types from the (shared) region of a type hierarchy. Sounds great. On 12 December 2017 at 18:45, Steve Ebersole wrote: > And btw, this *has* to happen. JPA requires it and the 2.2 TCK tests for > it. So there is no "keep allowing caching at the root-level" option here > > > On Tue, Dec 12, 2017 at 12:44 PM Steve Ebersole wrote: >> >> Its not any different than `#get( LegalEntity.class, key )` in the old >> config when key refers to a Person and Person is *not* in the cache simply >> because it has not been loaded/saved via this SF. >> >> On Tue, Dec 12, 2017 at 12:33 PM Sanne Grinovero >> wrote: >>> >>> Conceptually it sounds useful but I'm wondering about this being safe >>> to do in various more tricky mapping scenarios. >>> >>> For example consider this case: >>> >>> @Inheritance(...) >>> @Cache(...) >>> @Cacheable(true) >>> class LegalEntity { >>> ... >>> } >>> >>> @Cacheable(false) >>> class Person extends LegalEntity { >>> ... >>> } >>> >>> @Cacheable(true) >>> class Company extends LegalEntity { >>> ... >>> } >>> >>> [N.B. the parent class is no longer abstract] >>> >>> Now imagine we have to implement a polymorphic load: `load(key, >>> LegalEntity.class)` >>> >>> Would you be able to use the 2LC safely in all possible inheritance >>> mappings? >>> >>> I'm particularly curious about the possibility of a Person being >>> stored, but since we won't have data about the Person in the cache >>> we'd materialize the load as a LegalEntity. >>> >>> Incidentally while writing this example I realize that such a mapping >>> could trigger issues even with existing caching options. >>> >>> Thanks, >>> Sanne >>> >>> >>> >>> On 12 December 2017 at 14:49, Steve Ebersole wrote: >>> > HHH-12146 is about being able to enable/disable caching at various >>> > levels >>> > in an entity hierarchy. E.g., given a hierarchy such as `Person` and >>> > `Company` both extending `LegalEntity`, this would allow users to say >>> > that >>> > only `Company` should be cached but not `Person` nor any other >>> > `LegalEntity` subclass. >>> > >>> > The underlying approach here is to still define region and >>> > access-strategy >>> > information per-hierarchy - users will simply be able to opt out of (or >>> > into) caching particular subclasses. In my initial attempt I simply >>> > allowed both `@Cache` and `@Cacheable` to appear anywhere in the >>> > hierarchy. However, allowing `@Cache` (as currently defined) implies >>> > that >>> > users should be able to define different regions and/or access >>> > strategies >>> > for various subclasses within the hierarchy. Stepping back, I thought >>> > a >>> > better solution would be to continue to support `@Cache` only at the >>> > root >>> > level and define this new feature in terms of `@Cacheable` at the >>> > various >>> > levels. This has a few implications that I wanted to discuss. >>> > >>> > The main thing is that this means that applications using just `@Cache` >>> > to >>> > define caching would still only be able to declare caching for the >>> > entire >>> > hierarchy. But I think that is ok because that was the legacy >>> > behavior, >>> > and so nothing is really changing there. If we find `@Cache` on the >>> > root >>> > we'd assume an implicit `@Cacheable(true)`. I think some examples will >>> > help explain... >>> > >>> > >>> > Current behavior >>> > >>> > @Inheritance(...) >>> > @Cache(...) >>> > abstract class LegalEntity { >>> > ... >>> > } >>> > >>> > class Person extends LegalEntity { >>> > ... >>> > } >>> > >>> > class Company extends LegalEntity { >>> > ... >>> > } >>> > >>> > In the current behavior both `@Cache` and `@Cacheable` are only valid >>> > on >>> > the root as seen above. Placing them on any subclass results in an >>> > error. >>> > Note too that we could have used `@Cacheable` here instead of `@Cache` >>> > in >>> > which case the default `@Cache` values would be applied. It was also >>> > legal >>> > to use both together. In fact, a portable application would use >>> > `@Cacheable` with or without `@Cache`. >>> > >>> > >>> > Proposed behavior >>> > >>> > @Inheritance(...) >>> > @Cache(...) >>> > @Cacheable(false) >>> > abstract class LegalEntity { >>> > ... >>> > } >>> > >>> > class Person extends LegalEntity { >>> > ... >>> > } >>> > >>> > @Cacheable(true) >>> > class Company extends LegalEntity { >>> > ... >>> > } >>> > >>> > Here we have the root disabling caching (assuming >>> > `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that setting. >>> > `Company` however overrides that to enable caching. We still have >>> > `@Cache` attached to the root to define the specifics of caching >>> > (region, >>> > access strategy). But as noted earlier, we could have left off >>> > `@Cache` >>> > and accepted the defaults. >>> > >>> > I also propose that we continue to accept `@Cache` (without explicit >>> > `@Cacheable`) as implying `@Cacheable(true)` although `SharedCacheMode` >>> > plays a part in that too. >>> > >>> > Anyway, I wanted to make sure everyone agrees with this. >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Tue Dec 12 18:41:47 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 12 Dec 2017 23:41:47 +0000 Subject: [hibernate-dev] Including Hibernate Spatial & dependencies in the WildFly modules Message-ID: Hi all, there's a feature request about including the (currently missing) bits to be able to use the Spatial queries in WildFly: - https://issues.jboss.org/browse/WFLY-7524?focusedCommentId=13504172 I propose we start by including these in the modules we produce as part of the Hibernate ORM release? That way the WildFly team can later decide if they want to emulate the structure we'll produce. Thanks, Sanne From steve at hibernate.org Tue Dec 12 21:38:17 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 13 Dec 2017 02:38:17 +0000 Subject: [hibernate-dev] Including Hibernate Spatial & dependencies in the WildFly modules In-Reply-To: References: Message-ID: I think that's a great idea. Was just an oversight on my part. On Tue, Dec 12, 2017 at 7:19 PM Sanne Grinovero wrote: > Hi all, > > there's a feature request about including the (currently missing) bits > to be able to use the Spatial queries in WildFly: > - https://issues.jboss.org/browse/WFLY-7524?focusedCommentId=13504172 > > I propose we start by including these in the modules we produce as > part of the Hibernate ORM release? > > That way the WildFly team can later decide if they want to emulate the > structure we'll produce. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Dec 12 22:27:18 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 13 Dec 2017 03:27:18 +0000 Subject: [hibernate-dev] HHH-12146 - subclass-specific caching In-Reply-To: References: Message-ID: I have just pushed this work to the 5.3 branch. Tomorrow I will start working on getting this all integrated with master (and branching 5.2 off). At that point we are pretty much ready for that first Beta, so let me know if anyone notices anything awry - this is a pretty big change. On Tue, Dec 12, 2017 at 7:18 PM Sanne Grinovero wrote: > We discussed this further in chat. For the sake of others reading, the > summary: I got confused about the risks of having multiple cache > regions for a single hierarchy; the proposal is *not* to have multiple > regions yet be able to exclude specific types from the (shared) region > of a type hierarchy. > > Sounds great. > > On 12 December 2017 at 18:45, Steve Ebersole wrote: > > And btw, this *has* to happen. JPA requires it and the 2.2 TCK tests for > > it. So there is no "keep allowing caching at the root-level" option here > > > > > > On Tue, Dec 12, 2017 at 12:44 PM Steve Ebersole > wrote: > >> > >> Its not any different than `#get( LegalEntity.class, key )` in the old > >> config when key refers to a Person and Person is *not* in the cache > simply > >> because it has not been loaded/saved via this SF. > >> > >> On Tue, Dec 12, 2017 at 12:33 PM Sanne Grinovero > >> wrote: > >>> > >>> Conceptually it sounds useful but I'm wondering about this being safe > >>> to do in various more tricky mapping scenarios. > >>> > >>> For example consider this case: > >>> > >>> @Inheritance(...) > >>> @Cache(...) > >>> @Cacheable(true) > >>> class LegalEntity { > >>> ... > >>> } > >>> > >>> @Cacheable(false) > >>> class Person extends LegalEntity { > >>> ... > >>> } > >>> > >>> @Cacheable(true) > >>> class Company extends LegalEntity { > >>> ... > >>> } > >>> > >>> [N.B. the parent class is no longer abstract] > >>> > >>> Now imagine we have to implement a polymorphic load: `load(key, > >>> LegalEntity.class)` > >>> > >>> Would you be able to use the 2LC safely in all possible inheritance > >>> mappings? > >>> > >>> I'm particularly curious about the possibility of a Person being > >>> stored, but since we won't have data about the Person in the cache > >>> we'd materialize the load as a LegalEntity. > >>> > >>> Incidentally while writing this example I realize that such a mapping > >>> could trigger issues even with existing caching options. > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>> > >>> On 12 December 2017 at 14:49, Steve Ebersole > wrote: > >>> > HHH-12146 is about being able to enable/disable caching at various > >>> > levels > >>> > in an entity hierarchy. E.g., given a hierarchy such as `Person` and > >>> > `Company` both extending `LegalEntity`, this would allow users to say > >>> > that > >>> > only `Company` should be cached but not `Person` nor any other > >>> > `LegalEntity` subclass. > >>> > > >>> > The underlying approach here is to still define region and > >>> > access-strategy > >>> > information per-hierarchy - users will simply be able to opt out of > (or > >>> > into) caching particular subclasses. In my initial attempt I simply > >>> > allowed both `@Cache` and `@Cacheable` to appear anywhere in the > >>> > hierarchy. However, allowing `@Cache` (as currently defined) implies > >>> > that > >>> > users should be able to define different regions and/or access > >>> > strategies > >>> > for various subclasses within the hierarchy. Stepping back, I > thought > >>> > a > >>> > better solution would be to continue to support `@Cache` only at the > >>> > root > >>> > level and define this new feature in terms of `@Cacheable` at the > >>> > various > >>> > levels. This has a few implications that I wanted to discuss. > >>> > > >>> > The main thing is that this means that applications using just > `@Cache` > >>> > to > >>> > define caching would still only be able to declare caching for the > >>> > entire > >>> > hierarchy. But I think that is ok because that was the legacy > >>> > behavior, > >>> > and so nothing is really changing there. If we find `@Cache` on the > >>> > root > >>> > we'd assume an implicit `@Cacheable(true)`. I think some examples > will > >>> > help explain... > >>> > > >>> > > >>> > Current behavior > >>> > > >>> > @Inheritance(...) > >>> > @Cache(...) > >>> > abstract class LegalEntity { > >>> > ... > >>> > } > >>> > > >>> > class Person extends LegalEntity { > >>> > ... > >>> > } > >>> > > >>> > class Company extends LegalEntity { > >>> > ... > >>> > } > >>> > > >>> > In the current behavior both `@Cache` and `@Cacheable` are only > valid > >>> > on > >>> > the root as seen above. Placing them on any subclass results in an > >>> > error. > >>> > Note too that we could have used `@Cacheable` here instead of > `@Cache` > >>> > in > >>> > which case the default `@Cache` values would be applied. It was also > >>> > legal > >>> > to use both together. In fact, a portable application would use > >>> > `@Cacheable` with or without `@Cache`. > >>> > > >>> > > >>> > Proposed behavior > >>> > > >>> > @Inheritance(...) > >>> > @Cache(...) > >>> > @Cacheable(false) > >>> > abstract class LegalEntity { > >>> > ... > >>> > } > >>> > > >>> > class Person extends LegalEntity { > >>> > ... > >>> > } > >>> > > >>> > @Cacheable(true) > >>> > class Company extends LegalEntity { > >>> > ... > >>> > } > >>> > > >>> > Here we have the root disabling caching (assuming > >>> > `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that setting. > >>> > `Company` however overrides that to enable caching. We still have > >>> > `@Cache` attached to the root to define the specifics of caching > >>> > (region, > >>> > access strategy). But as noted earlier, we could have left off > >>> > `@Cache` > >>> > and accepted the defaults. > >>> > > >>> > I also propose that we continue to accept `@Cache` (without explicit > >>> > `@Cacheable`) as implying `@Cacheable(true)` although > `SharedCacheMode` > >>> > plays a part in that too. > >>> > > >>> > Anyway, I wanted to make sure everyone agrees with this. > >>> > _______________________________________________ > >>> > 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 > From steve at hibernate.org Tue Dec 12 22:47:15 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 13 Dec 2017 03:47:15 +0000 Subject: [hibernate-dev] HHH-12146 - subclass-specific caching In-Reply-To: References: Message-ID: Vlad, these changes cause some failures in the userguide tests[1]. This is not completely unexpected since they seem to do caching-specific assertions. However, for the life of me I cannot figure out how to run these locally. The problem is the annotation processor for generating the "JPA static metamodel" classes. They either do not get generated, or at the very least the build is not adding them to the project in a way that IntelliJ import picks them up. [1] http://ci.hibernate.org/job/hibernate-orm-5.3-steve/28/testReport/ On Tue, Dec 12, 2017 at 9:27 PM Steve Ebersole wrote: > I have just pushed this work to the 5.3 branch. Tomorrow I will start > working on getting this all integrated with master (and branching 5.2 > off). At that point we are pretty much ready for that first Beta, so let > me know if anyone notices anything awry - this is a pretty big change. > > On Tue, Dec 12, 2017 at 7:18 PM Sanne Grinovero > wrote: > >> We discussed this further in chat. For the sake of others reading, the >> summary: I got confused about the risks of having multiple cache >> regions for a single hierarchy; the proposal is *not* to have multiple >> regions yet be able to exclude specific types from the (shared) region >> of a type hierarchy. >> >> Sounds great. >> >> On 12 December 2017 at 18:45, Steve Ebersole wrote: >> > And btw, this *has* to happen. JPA requires it and the 2.2 TCK tests >> for >> > it. So there is no "keep allowing caching at the root-level" option >> here >> > >> > >> > On Tue, Dec 12, 2017 at 12:44 PM Steve Ebersole >> wrote: >> >> >> >> Its not any different than `#get( LegalEntity.class, key )` in the old >> >> config when key refers to a Person and Person is *not* in the cache >> simply >> >> because it has not been loaded/saved via this SF. >> >> >> >> On Tue, Dec 12, 2017 at 12:33 PM Sanne Grinovero >> >> wrote: >> >>> >> >>> Conceptually it sounds useful but I'm wondering about this being safe >> >>> to do in various more tricky mapping scenarios. >> >>> >> >>> For example consider this case: >> >>> >> >>> @Inheritance(...) >> >>> @Cache(...) >> >>> @Cacheable(true) >> >>> class LegalEntity { >> >>> ... >> >>> } >> >>> >> >>> @Cacheable(false) >> >>> class Person extends LegalEntity { >> >>> ... >> >>> } >> >>> >> >>> @Cacheable(true) >> >>> class Company extends LegalEntity { >> >>> ... >> >>> } >> >>> >> >>> [N.B. the parent class is no longer abstract] >> >>> >> >>> Now imagine we have to implement a polymorphic load: `load(key, >> >>> LegalEntity.class)` >> >>> >> >>> Would you be able to use the 2LC safely in all possible inheritance >> >>> mappings? >> >>> >> >>> I'm particularly curious about the possibility of a Person being >> >>> stored, but since we won't have data about the Person in the cache >> >>> we'd materialize the load as a LegalEntity. >> >>> >> >>> Incidentally while writing this example I realize that such a mapping >> >>> could trigger issues even with existing caching options. >> >>> >> >>> Thanks, >> >>> Sanne >> >>> >> >>> >> >>> >> >>> On 12 December 2017 at 14:49, Steve Ebersole >> wrote: >> >>> > HHH-12146 is about being able to enable/disable caching at various >> >>> > levels >> >>> > in an entity hierarchy. E.g., given a hierarchy such as `Person` >> and >> >>> > `Company` both extending `LegalEntity`, this would allow users to >> say >> >>> > that >> >>> > only `Company` should be cached but not `Person` nor any other >> >>> > `LegalEntity` subclass. >> >>> > >> >>> > The underlying approach here is to still define region and >> >>> > access-strategy >> >>> > information per-hierarchy - users will simply be able to opt out of >> (or >> >>> > into) caching particular subclasses. In my initial attempt I simply >> >>> > allowed both `@Cache` and `@Cacheable` to appear anywhere in the >> >>> > hierarchy. However, allowing `@Cache` (as currently defined) >> implies >> >>> > that >> >>> > users should be able to define different regions and/or access >> >>> > strategies >> >>> > for various subclasses within the hierarchy. Stepping back, I >> thought >> >>> > a >> >>> > better solution would be to continue to support `@Cache` only at the >> >>> > root >> >>> > level and define this new feature in terms of `@Cacheable` at the >> >>> > various >> >>> > levels. This has a few implications that I wanted to discuss. >> >>> > >> >>> > The main thing is that this means that applications using just >> `@Cache` >> >>> > to >> >>> > define caching would still only be able to declare caching for the >> >>> > entire >> >>> > hierarchy. But I think that is ok because that was the legacy >> >>> > behavior, >> >>> > and so nothing is really changing there. If we find `@Cache` on the >> >>> > root >> >>> > we'd assume an implicit `@Cacheable(true)`. I think some examples >> will >> >>> > help explain... >> >>> > >> >>> > >> >>> > Current behavior >> >>> > >> >>> > @Inheritance(...) >> >>> > @Cache(...) >> >>> > abstract class LegalEntity { >> >>> > ... >> >>> > } >> >>> > >> >>> > class Person extends LegalEntity { >> >>> > ... >> >>> > } >> >>> > >> >>> > class Company extends LegalEntity { >> >>> > ... >> >>> > } >> >>> > >> >>> > In the current behavior both `@Cache` and `@Cacheable` are only >> valid >> >>> > on >> >>> > the root as seen above. Placing them on any subclass results in an >> >>> > error. >> >>> > Note too that we could have used `@Cacheable` here instead of >> `@Cache` >> >>> > in >> >>> > which case the default `@Cache` values would be applied. It was >> also >> >>> > legal >> >>> > to use both together. In fact, a portable application would use >> >>> > `@Cacheable` with or without `@Cache`. >> >>> > >> >>> > >> >>> > Proposed behavior >> >>> > >> >>> > @Inheritance(...) >> >>> > @Cache(...) >> >>> > @Cacheable(false) >> >>> > abstract class LegalEntity { >> >>> > ... >> >>> > } >> >>> > >> >>> > class Person extends LegalEntity { >> >>> > ... >> >>> > } >> >>> > >> >>> > @Cacheable(true) >> >>> > class Company extends LegalEntity { >> >>> > ... >> >>> > } >> >>> > >> >>> > Here we have the root disabling caching (assuming >> >>> > `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that >> setting. >> >>> > `Company` however overrides that to enable caching. We still have >> >>> > `@Cache` attached to the root to define the specifics of caching >> >>> > (region, >> >>> > access strategy). But as noted earlier, we could have left off >> >>> > `@Cache` >> >>> > and accepted the defaults. >> >>> > >> >>> > I also propose that we continue to accept `@Cache` (without explicit >> >>> > `@Cacheable`) as implying `@Cacheable(true)` although >> `SharedCacheMode` >> >>> > plays a part in that too. >> >>> > >> >>> > Anyway, I wanted to make sure everyone agrees with this. >> >>> > _______________________________________________ >> >>> > 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 >> > From steve at hibernate.org Tue Dec 12 23:02:56 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 13 Dec 2017 04:02:56 +0000 Subject: [hibernate-dev] HHH-12146 - subclass-specific caching In-Reply-To: References: Message-ID: I just went ahead and did the same we do for the other modules. On Tue, Dec 12, 2017 at 9:47 PM Steve Ebersole wrote: > Vlad, these changes cause some failures in the userguide tests[1]. This > is not completely unexpected since they seem to do caching-specific > assertions. However, for the life of me I cannot figure out how to run > these locally. The problem is the annotation processor for generating the > "JPA static metamodel" classes. They either do not get generated, or at > the very least the build is not adding them to the project in a way that > IntelliJ import picks them up. > > [1] http://ci.hibernate.org/job/hibernate-orm-5.3-steve/28/testReport/ > > On Tue, Dec 12, 2017 at 9:27 PM Steve Ebersole > wrote: > >> I have just pushed this work to the 5.3 branch. Tomorrow I will start >> working on getting this all integrated with master (and branching 5.2 >> off). At that point we are pretty much ready for that first Beta, so let >> me know if anyone notices anything awry - this is a pretty big change. >> >> On Tue, Dec 12, 2017 at 7:18 PM Sanne Grinovero >> wrote: >> >>> We discussed this further in chat. For the sake of others reading, the >>> summary: I got confused about the risks of having multiple cache >>> regions for a single hierarchy; the proposal is *not* to have multiple >>> regions yet be able to exclude specific types from the (shared) region >>> of a type hierarchy. >>> >>> Sounds great. >>> >>> On 12 December 2017 at 18:45, Steve Ebersole >>> wrote: >>> > And btw, this *has* to happen. JPA requires it and the 2.2 TCK tests >>> for >>> > it. So there is no "keep allowing caching at the root-level" option >>> here >>> > >>> > >>> > On Tue, Dec 12, 2017 at 12:44 PM Steve Ebersole >>> wrote: >>> >> >>> >> Its not any different than `#get( LegalEntity.class, key )` in the old >>> >> config when key refers to a Person and Person is *not* in the cache >>> simply >>> >> because it has not been loaded/saved via this SF. >>> >> >>> >> On Tue, Dec 12, 2017 at 12:33 PM Sanne Grinovero >> > >>> >> wrote: >>> >>> >>> >>> Conceptually it sounds useful but I'm wondering about this being safe >>> >>> to do in various more tricky mapping scenarios. >>> >>> >>> >>> For example consider this case: >>> >>> >>> >>> @Inheritance(...) >>> >>> @Cache(...) >>> >>> @Cacheable(true) >>> >>> class LegalEntity { >>> >>> ... >>> >>> } >>> >>> >>> >>> @Cacheable(false) >>> >>> class Person extends LegalEntity { >>> >>> ... >>> >>> } >>> >>> >>> >>> @Cacheable(true) >>> >>> class Company extends LegalEntity { >>> >>> ... >>> >>> } >>> >>> >>> >>> [N.B. the parent class is no longer abstract] >>> >>> >>> >>> Now imagine we have to implement a polymorphic load: `load(key, >>> >>> LegalEntity.class)` >>> >>> >>> >>> Would you be able to use the 2LC safely in all possible inheritance >>> >>> mappings? >>> >>> >>> >>> I'm particularly curious about the possibility of a Person being >>> >>> stored, but since we won't have data about the Person in the cache >>> >>> we'd materialize the load as a LegalEntity. >>> >>> >>> >>> Incidentally while writing this example I realize that such a mapping >>> >>> could trigger issues even with existing caching options. >>> >>> >>> >>> Thanks, >>> >>> Sanne >>> >>> >>> >>> >>> >>> >>> >>> On 12 December 2017 at 14:49, Steve Ebersole >>> wrote: >>> >>> > HHH-12146 is about being able to enable/disable caching at various >>> >>> > levels >>> >>> > in an entity hierarchy. E.g., given a hierarchy such as `Person` >>> and >>> >>> > `Company` both extending `LegalEntity`, this would allow users to >>> say >>> >>> > that >>> >>> > only `Company` should be cached but not `Person` nor any other >>> >>> > `LegalEntity` subclass. >>> >>> > >>> >>> > The underlying approach here is to still define region and >>> >>> > access-strategy >>> >>> > information per-hierarchy - users will simply be able to opt out >>> of (or >>> >>> > into) caching particular subclasses. In my initial attempt I >>> simply >>> >>> > allowed both `@Cache` and `@Cacheable` to appear anywhere in the >>> >>> > hierarchy. However, allowing `@Cache` (as currently defined) >>> implies >>> >>> > that >>> >>> > users should be able to define different regions and/or access >>> >>> > strategies >>> >>> > for various subclasses within the hierarchy. Stepping back, I >>> thought >>> >>> > a >>> >>> > better solution would be to continue to support `@Cache` only at >>> the >>> >>> > root >>> >>> > level and define this new feature in terms of `@Cacheable` at the >>> >>> > various >>> >>> > levels. This has a few implications that I wanted to discuss. >>> >>> > >>> >>> > The main thing is that this means that applications using just >>> `@Cache` >>> >>> > to >>> >>> > define caching would still only be able to declare caching for the >>> >>> > entire >>> >>> > hierarchy. But I think that is ok because that was the legacy >>> >>> > behavior, >>> >>> > and so nothing is really changing there. If we find `@Cache` on >>> the >>> >>> > root >>> >>> > we'd assume an implicit `@Cacheable(true)`. I think some examples >>> will >>> >>> > help explain... >>> >>> > >>> >>> > >>> >>> > Current behavior >>> >>> > >>> >>> > @Inheritance(...) >>> >>> > @Cache(...) >>> >>> > abstract class LegalEntity { >>> >>> > ... >>> >>> > } >>> >>> > >>> >>> > class Person extends LegalEntity { >>> >>> > ... >>> >>> > } >>> >>> > >>> >>> > class Company extends LegalEntity { >>> >>> > ... >>> >>> > } >>> >>> > >>> >>> > In the current behavior both `@Cache` and `@Cacheable` are only >>> valid >>> >>> > on >>> >>> > the root as seen above. Placing them on any subclass results in an >>> >>> > error. >>> >>> > Note too that we could have used `@Cacheable` here instead of >>> `@Cache` >>> >>> > in >>> >>> > which case the default `@Cache` values would be applied. It was >>> also >>> >>> > legal >>> >>> > to use both together. In fact, a portable application would use >>> >>> > `@Cacheable` with or without `@Cache`. >>> >>> > >>> >>> > >>> >>> > Proposed behavior >>> >>> > >>> >>> > @Inheritance(...) >>> >>> > @Cache(...) >>> >>> > @Cacheable(false) >>> >>> > abstract class LegalEntity { >>> >>> > ... >>> >>> > } >>> >>> > >>> >>> > class Person extends LegalEntity { >>> >>> > ... >>> >>> > } >>> >>> > >>> >>> > @Cacheable(true) >>> >>> > class Company extends LegalEntity { >>> >>> > ... >>> >>> > } >>> >>> > >>> >>> > Here we have the root disabling caching (assuming >>> >>> > `SharedCacheMode.ENABLE_SELECTIVE`). `Person` inherits that >>> setting. >>> >>> > `Company` however overrides that to enable caching. We still have >>> >>> > `@Cache` attached to the root to define the specifics of caching >>> >>> > (region, >>> >>> > access strategy). But as noted earlier, we could have left off >>> >>> > `@Cache` >>> >>> > and accepted the defaults. >>> >>> > >>> >>> > I also propose that we continue to accept `@Cache` (without >>> explicit >>> >>> > `@Cacheable`) as implying `@Cacheable(true)` although >>> `SharedCacheMode` >>> >>> > plays a part in that too. >>> >>> > >>> >>> > Anyway, I wanted to make sure everyone agrees with this. >>> >>> > _______________________________________________ >>> >>> > 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 >>> >> From sanne at hibernate.org Wed Dec 13 07:10:59 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 13 Dec 2017 13:10:59 +0100 Subject: [hibernate-dev] Killing hibernate-jpa-api ? Message-ID: Looks like the general agreement is that we will no longer need - https://github.com/hibernate/hibernate-jpa-api As we're switching to the standard API distribution, finally available: javax.persistence:javax.persistence-api:2.2 Still I expect there's going to be some confusion about this, e.g. Scott was asking today in chat where to find our custom API at versions 2.2. I'd like to deploy a relocation artifact so that people merely upgrading the version to 2.2 of their dependency to org.hibernate.javax.persistence will get an automated warning and be nicely redirected to the new artifact. Any objections? The one problem I can see is that in case we need to patch it we'd need to restore the org.hibernate.javax.persistence and it might get messy, but I think we can agree the chance for this need to arise being extremely small. Thanks, Sanne From yoann at hibernate.org Wed Dec 13 07:39:38 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 13 Dec 2017 13:39:38 +0100 Subject: [hibernate-dev] Killing hibernate-jpa-api ? In-Reply-To: References: Message-ID: Seems like the right thing to do. I'm just concerned about the license. Is it identical? Some people might be upset to get a new dependency pulled "automatically" if it has a stricter license... Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 13 December 2017 at 13:10, Sanne Grinovero wrote: > Looks like the general agreement is that we will no longer need > - https://github.com/hibernate/hibernate-jpa-api > > As we're switching to the standard API distribution, finally available: > javax.persistence:javax.persistence-api:2.2 > > Still I expect there's going to be some confusion about this, e.g. > Scott was asking today in chat where to find our custom API at > versions 2.2. > > I'd like to deploy a relocation artifact so that people merely > upgrading the version to 2.2 of their dependency to > org.hibernate.javax.persistence will get an automated warning and be > nicely redirected to the new artifact. > > Any objections? > > The one problem I can see is that in case we need to patch it we'd > need to restore the org.hibernate.javax.persistence and it might get > messy, but I think we can agree the chance for this need to arise > being extremely small. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Dec 13 07:54:27 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 13 Dec 2017 12:54:27 +0000 Subject: [hibernate-dev] Killing hibernate-jpa-api ? In-Reply-To: References: Message-ID: Considering the spec contracts are defined by the EG under the JCP, I'm not sure where we ever stood legally with publishing this under any other license. Either way, I am not concerned about the license aspect - I think it is a reasonable expectation that if I am using a jar produced by a spec that use of that jar is covered by the JCP under which it was produced. Sanne, my concern about publishing the relocation artifact is that the expectation is that we keep publishing them ever time there is a new spec version. Right? On Wed, Dec 13, 2017 at 6:47 AM Yoann Rodiere wrote: > Seems like the right thing to do. I'm just concerned about the license. Is > it identical? > Some people might be upset to get a new dependency pulled "automatically" > if it has a stricter license... > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 13 December 2017 at 13:10, Sanne Grinovero wrote: > > > Looks like the general agreement is that we will no longer need > > - https://github.com/hibernate/hibernate-jpa-api > > > > As we're switching to the standard API distribution, finally available: > > javax.persistence:javax.persistence-api:2.2 > > > > Still I expect there's going to be some confusion about this, e.g. > > Scott was asking today in chat where to find our custom API at > > versions 2.2. > > > > I'd like to deploy a relocation artifact so that people merely > > upgrading the version to 2.2 of their dependency to > > org.hibernate.javax.persistence will get an automated warning and be > > nicely redirected to the new artifact. > > > > Any objections? > > > > The one problem I can see is that in case we need to patch it we'd > > need to restore the org.hibernate.javax.persistence and it might get > > messy, but I think we can agree the chance for this need to arise > > being extremely small. > > > > Thanks, > > Sanne > > _______________________________________________ > > 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 From sanne at hibernate.org Wed Dec 13 08:04:49 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 13 Dec 2017 14:04:49 +0100 Subject: [hibernate-dev] Killing hibernate-jpa-api ? In-Reply-To: References: Message-ID: On 13 December 2017 at 13:54, Steve Ebersole wrote: > Considering the spec contracts are defined by the EG under the JCP, I'm not > sure where we ever stood legally with publishing this under any other > license. Either way, I am not concerned about the license aspect - I think > it is a reasonable expectation that if I am using a jar produced by a spec > that use of that jar is covered by the JCP under which it was produced. +1 Also, we'll be switching to use the official ones anyway. That's an orthogonal concern, my goal with this thread is to sunset our custom fork with least possible friction, but it's not going to live much longer for sure. > Sanne, my concern about publishing the relocation artifact is that the > expectation is that we keep publishing them ever time there is a new spec > version. Right? Not really. Think of it as Deprecation: it will trigger some warnings for end users, especially those who didn't get the "news" of moving to the new API, and keep things working for a little longer for those people not willing (able?) to react right away to resolve the warnings. We can keep a deprecated method (jar) around for a couple more releases, or drop it as soon as it gets too inconvenient to maintain. It's definitley not a promise of long term. > > On Wed, Dec 13, 2017 at 6:47 AM Yoann Rodiere wrote: >> >> Seems like the right thing to do. I'm just concerned about the license. Is >> it identical? >> Some people might be upset to get a new dependency pulled "automatically" >> if it has a stricter license... >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 13 December 2017 at 13:10, Sanne Grinovero wrote: >> >> > Looks like the general agreement is that we will no longer need >> > - https://github.com/hibernate/hibernate-jpa-api >> > >> > As we're switching to the standard API distribution, finally available: >> > javax.persistence:javax.persistence-api:2.2 >> > >> > Still I expect there's going to be some confusion about this, e.g. >> > Scott was asking today in chat where to find our custom API at >> > versions 2.2. >> > >> > I'd like to deploy a relocation artifact so that people merely >> > upgrading the version to 2.2 of their dependency to >> > org.hibernate.javax.persistence will get an automated warning and be >> > nicely redirected to the new artifact. >> > >> > Any objections? >> > >> > The one problem I can see is that in case we need to patch it we'd >> > need to restore the org.hibernate.javax.persistence and it might get >> > messy, but I think we can agree the chance for this need to arise >> > being extremely small. >> > >> > Thanks, >> > Sanne >> > _______________________________________________ >> > 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 From sanne at hibernate.org Wed Dec 13 08:20:36 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 13 Dec 2017 14:20:36 +0100 Subject: [hibernate-dev] Including Hibernate Spatial & dependencies in the WildFly modules In-Reply-To: References: Message-ID: On 13 December 2017 at 03:38, Steve Ebersole wrote: > I think that's a great idea. Was just an oversight on my part. Cool, that's HHH-12163 then. > > On Tue, Dec 12, 2017 at 7:19 PM Sanne Grinovero wrote: >> >> Hi all, >> >> there's a feature request about including the (currently missing) bits >> to be able to use the Spatial queries in WildFly: >> - https://issues.jboss.org/browse/WFLY-7524?focusedCommentId=13504172 >> >> I propose we start by including these in the modules we produce as >> part of the Hibernate ORM release? >> >> That way the WildFly team can later decide if they want to emulate the >> structure we'll produce. >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Wed Dec 13 08:23:56 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 13 Dec 2017 14:23:56 +0100 Subject: [hibernate-dev] Killing hibernate-jpa-api ? In-Reply-To: References: Message-ID: Just to be sure, including an EPL-licensed item is fine as far as WildFly is concerned? Other than that, +1 for that change. 2017-12-13 14:04 GMT+01:00 Sanne Grinovero : > On 13 December 2017 at 13:54, Steve Ebersole wrote: > > Considering the spec contracts are defined by the EG under the JCP, I'm > not > > sure where we ever stood legally with publishing this under any other > > license. Either way, I am not concerned about the license aspect - I > think > > it is a reasonable expectation that if I am using a jar produced by a > spec > > that use of that jar is covered by the JCP under which it was produced. > > +1 > Also, we'll be switching to use the official ones anyway. That's an > orthogonal concern, my goal with this thread is to sunset our custom > fork with least possible friction, but it's not going to live much > longer for sure. > > > Sanne, my concern about publishing the relocation artifact is that the > > expectation is that we keep publishing them ever time there is a new spec > > version. Right? > > Not really. Think of it as Deprecation: it will trigger some warnings > for end users, especially those who didn't get the "news" of moving to > the new API, and keep things working for a little longer for those > people not willing (able?) to react right away to resolve the > warnings. > > We can keep a deprecated method (jar) around for a couple more > releases, or drop it as soon as it gets too inconvenient to maintain. > It's definitley not a promise of long term. > > > > > On Wed, Dec 13, 2017 at 6:47 AM Yoann Rodiere > wrote: > >> > >> Seems like the right thing to do. I'm just concerned about the license. > Is > >> it identical? > >> Some people might be upset to get a new dependency pulled > "automatically" > >> if it has a stricter license... > >> > >> Yoann Rodi?re > >> Hibernate NoORM Team > >> yoann at hibernate.org > >> > >> On 13 December 2017 at 13:10, Sanne Grinovero > wrote: > >> > >> > Looks like the general agreement is that we will no longer need > >> > - https://github.com/hibernate/hibernate-jpa-api > >> > > >> > As we're switching to the standard API distribution, finally > available: > >> > javax.persistence:javax.persistence-api:2.2 > >> > > >> > Still I expect there's going to be some confusion about this, e.g. > >> > Scott was asking today in chat where to find our custom API at > >> > versions 2.2. > >> > > >> > I'd like to deploy a relocation artifact so that people merely > >> > upgrading the version to 2.2 of their dependency to > >> > org.hibernate.javax.persistence will get an automated warning and be > >> > nicely redirected to the new artifact. > >> > > >> > Any objections? > >> > > >> > The one problem I can see is that in case we need to patch it we'd > >> > need to restore the org.hibernate.javax.persistence and it might get > >> > messy, but I think we can agree the chance for this need to arise > >> > being extremely small. > >> > > >> > Thanks, > >> > Sanne > >> > _______________________________________________ > >> > 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 > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Dec 13 08:34:25 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 13 Dec 2017 13:34:25 +0000 Subject: [hibernate-dev] Killing hibernate-jpa-api ? In-Reply-To: References: Message-ID: On Wed, Dec 13, 2017 at 7:05 AM Sanne Grinovero wrote: > Not really. Think of it as Deprecation: it will trigger some warnings > for end users, especially those who didn't get the "news" of moving to > the new API, and keep things working for a little longer for those > people not willing (able?) to react right away to resolve the > warnings. > > We can keep a deprecated method (jar) around for a couple more > releases, or drop it as soon as it gets too inconvenient to maintain. > It's definitley not a promise of long term. > Couple more releases of what? Hibernate ORM, as opposed to JPA? I assume that's what you meant, just making sure. Honestly I would never publish a new relocation - that means we are incrementing the version of the JPA API jar, which should not happen. From steve at hibernate.org Wed Dec 13 15:04:09 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 13 Dec 2017 20:04:09 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support Message-ID: https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly about back porting the work I did on 6.0 for the ManagedBeanRegistry abstraction over dependency injection containers. We will ship support for CDI as well as non-managed beans (things we directly instantiate). Of course we'd ideally make it easy to plug in other DI containers such as Spring. So I wanted to discuss the configuration of this support. The first thing to consider is whether we want to support using multiple DI containers simultaneously. E.g. is it conceivable that an application might want to use both CDI and Spring simultaneously? I started building in support for that via a CompositeManagedBeanRegistry implementation, but stepping back I want to gauge whether that is "reasonable" before continuing down that path Assuming that we do want to support such "compositions" the next question is how we see this being configured. Clearly any time a CDI BeanManager is present during bootstrap we want to enable CDI ManagedBeanRegistry support. How would users indicate additional ManagedBeanRegistry impls be added to the CompositeManagedBeanRegistry? I have opinions about this, but I'd like to hear other's thoughts... Note that ManagedBeanRegistry is a service and is initiated via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it would be possible to completely redefine ManagedBeanRegistry support simply by replacing that initiator. A minor point... notice that the package name here is `org.hibernate.resource.cdi`, even though one of the goals here is to support non-CDI ManagedBeanRegistry impls. Do we want to use a different package name? Maybe `org.hibernate.resource.beans`? ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` - imo "cdi" conveys the proper intent. But if others feel strongly it should be something else, I am open to hearing what and why. From christian.beikov at gmail.com Thu Dec 14 02:01:01 2017 From: christian.beikov at gmail.com (Christian Beikov) Date: Thu, 14 Dec 2017 08:01:01 +0100 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: I don't think someone is actually going to use more than a single DI framework and even if they do, they will probably bridge one way or another between the DI frameworks to be able to access beans from one in the other. So I don't think we should do "compositions" since it's not a big deal to integrate different DIs and is also IMO an edge case. I'd prefer the package name `org.hibernate.resource.di` since CDI seems to be just one of the possible "integrations". Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 13.12.2017 um 21:04 schrieb Steve Ebersole: > https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly > about back porting the work I did on 6.0 for the ManagedBeanRegistry > abstraction over dependency injection containers. We will ship support for > CDI as well as non-managed beans (things we directly instantiate). Of > course we'd ideally make it easy to plug in other DI containers such as > Spring. So I wanted to discuss the configuration of this support. > > The first thing to consider is whether we want to support using multiple DI > containers simultaneously. E.g. is it conceivable that an application > might want to use both CDI and Spring simultaneously? I started building > in support for that via a CompositeManagedBeanRegistry implementation, but > stepping back I want to gauge whether that is "reasonable" before > continuing down that path > > Assuming that we do want to support such "compositions" the next question > is how we see this being configured. Clearly any time a CDI BeanManager is > present during bootstrap we want to enable CDI ManagedBeanRegistry > support. How would users indicate additional ManagedBeanRegistry impls be > added to the CompositeManagedBeanRegistry? I have opinions about this, but > I'd like to hear other's thoughts... > > Note that ManagedBeanRegistry is a service and is initiated > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it > would be possible to completely redefine ManagedBeanRegistry support simply > by replacing that initiator. > > A minor point... notice that the package name here is > `org.hibernate.resource.cdi`, even though one of the goals here is to > support non-CDI ManagedBeanRegistry impls. Do we want to use a different > package name? Maybe `org.hibernate.resource.beans`? > ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? > Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` - imo > "cdi" conveys the proper intent. But if others feel strongly it should be > something else, I am open to hearing what and why. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Thu Dec 14 03:43:02 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 14 Dec 2017 09:43:02 +0100 Subject: [hibernate-dev] Interceptors and dependency injection Message-ID: Hi all (and Steve especially as it seems you are working on the subject right now), You talking about CDI made me think of something we did at $previousJob a long time ago. I didn't quite follow what you did in 6 about CDI/Spring injection but basically the requirement was to be able to create Spring managed interceptors and to inject them in the PersistenceProvider. At the time, we ended up with the following: https://github.com/openwide-java/owsi-core-parent/blob/master/owsi-core/owsi-core-components/owsi-core-component-jpa/src/main/java/fr/openwide/core/jpa/hibernate/ejb/InterceptorAwareHibernatePersistenceProvider.java But I think it would probably be nice if we could inject them directly. Another thing we did which is not really related is creating a ChainedInterceptor to be able to define several interceptors (the idea was that we did want the ability to enable some interceptors at will depending on what a given application required). Just injecting the interceptors in a random order would probably not do it as I think you will probably want to define them in an ordered way. Not sure it's useful but I thought I might as well talk about it now that you are working on this feature. Have a nice day. -- Guillaume From yoann at hibernate.org Thu Dec 14 03:53:48 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 14 Dec 2017 09:53:48 +0100 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Same here, compositions don't seem to be a reasonable use case. And even if users provide a custom bean registry, they could just implement their specific behavior for a few specific case, then retrieve another implementations on their own and delegate to it however they want. Overriding the service initiator looks like a very reasonable way to do that. Regarding the package, "org.hibernate.resource.beans" seems more appropriate to me, since CDI is not the only implementation we will get and we know it. Also, if I wanted to nitpick, injection is not really something the bean registry must provide. We could imagine a bean registry without any support for injection, after all, just providing "monolithic beans". It would still make sense with respect to your ManagedBeanRegistry API. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 14 December 2017 at 08:01, Christian Beikov wrote: > I don't think someone is actually going to use more than a single DI > framework and even if they do, they will probably bridge one way or > another between the DI frameworks to be able to access beans from one in > the other. > > So I don't think we should do "compositions" since it's not a big deal > to integrate different DIs and is also IMO an edge case. I'd prefer the > package name `org.hibernate.resource.di` since CDI seems to be just one > of the possible "integrations". > > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly > > about back porting the work I did on 6.0 for the ManagedBeanRegistry > > abstraction over dependency injection containers. We will ship support > for > > CDI as well as non-managed beans (things we directly instantiate). Of > > course we'd ideally make it easy to plug in other DI containers such as > > Spring. So I wanted to discuss the configuration of this support. > > > > The first thing to consider is whether we want to support using multiple > DI > > containers simultaneously. E.g. is it conceivable that an application > > might want to use both CDI and Spring simultaneously? I started building > > in support for that via a CompositeManagedBeanRegistry implementation, > but > > stepping back I want to gauge whether that is "reasonable" before > > continuing down that path > > > > Assuming that we do want to support such "compositions" the next question > > is how we see this being configured. Clearly any time a CDI BeanManager > is > > present during bootstrap we want to enable CDI ManagedBeanRegistry > > support. How would users indicate additional ManagedBeanRegistry impls > be > > added to the CompositeManagedBeanRegistry? I have opinions about this, > but > > I'd like to hear other's thoughts... > > > > Note that ManagedBeanRegistry is a service and is initiated > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it > > would be possible to completely redefine ManagedBeanRegistry support > simply > > by replacing that initiator. > > > > A minor point... notice that the package name here is > > `org.hibernate.resource.cdi`, even though one of the goals here is to > > support non-CDI ManagedBeanRegistry impls. Do we want to use a different > > package name? Maybe `org.hibernate.resource.beans`? > > ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? > > Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` - > imo > > "cdi" conveys the proper intent. But if others feel strongly it should > be > > something else, I am open to hearing what and why. > > _______________________________________________ > > 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 > From sanne at hibernate.org Thu Dec 14 05:17:26 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 14 Dec 2017 10:17:26 +0000 Subject: [hibernate-dev] Killing hibernate-jpa-api ? In-Reply-To: References: Message-ID: On 13 December 2017 at 13:23, Gunnar Morling wrote: > Just to be sure, including an EPL-licensed item is fine as far as WildFly is > concerned? Other than that, +1 for that change. To clarify on this, and better answer Yoann's concern which I didn't address properly before: org.hibernate.javax.persistence also is EPL. So we're not switching license without the user's consent, and there's precedent in WildFly. Also several other libraries included in WildFly use EPL; you can find full documentation on the subject included with the WildFly distribution under docs/licenses/ Thanks, Sanne > > 2017-12-13 14:04 GMT+01:00 Sanne Grinovero : >> >> On 13 December 2017 at 13:54, Steve Ebersole wrote: >> > Considering the spec contracts are defined by the EG under the JCP, I'm >> > not >> > sure where we ever stood legally with publishing this under any other >> > license. Either way, I am not concerned about the license aspect - I >> > think >> > it is a reasonable expectation that if I am using a jar produced by a >> > spec >> > that use of that jar is covered by the JCP under which it was produced. >> >> +1 >> Also, we'll be switching to use the official ones anyway. That's an >> orthogonal concern, my goal with this thread is to sunset our custom >> fork with least possible friction, but it's not going to live much >> longer for sure. >> >> > Sanne, my concern about publishing the relocation artifact is that the >> > expectation is that we keep publishing them ever time there is a new >> > spec >> > version. Right? >> >> Not really. Think of it as Deprecation: it will trigger some warnings >> for end users, especially those who didn't get the "news" of moving to >> the new API, and keep things working for a little longer for those >> people not willing (able?) to react right away to resolve the >> warnings. >> >> We can keep a deprecated method (jar) around for a couple more >> releases, or drop it as soon as it gets too inconvenient to maintain. >> It's definitley not a promise of long term. >> >> > >> > On Wed, Dec 13, 2017 at 6:47 AM Yoann Rodiere >> > wrote: >> >> >> >> Seems like the right thing to do. I'm just concerned about the license. >> >> Is >> >> it identical? >> >> Some people might be upset to get a new dependency pulled >> >> "automatically" >> >> if it has a stricter license... >> >> >> >> Yoann Rodi?re >> >> Hibernate NoORM Team >> >> yoann at hibernate.org >> >> >> >> On 13 December 2017 at 13:10, Sanne Grinovero >> >> wrote: >> >> >> >> > Looks like the general agreement is that we will no longer need >> >> > - https://github.com/hibernate/hibernate-jpa-api >> >> > >> >> > As we're switching to the standard API distribution, finally >> >> > available: >> >> > javax.persistence:javax.persistence-api:2.2 >> >> > >> >> > Still I expect there's going to be some confusion about this, e.g. >> >> > Scott was asking today in chat where to find our custom API at >> >> > versions 2.2. >> >> > >> >> > I'd like to deploy a relocation artifact so that people merely >> >> > upgrading the version to 2.2 of their dependency to >> >> > org.hibernate.javax.persistence will get an automated warning and be >> >> > nicely redirected to the new artifact. >> >> > >> >> > Any objections? >> >> > >> >> > The one problem I can see is that in case we need to patch it we'd >> >> > need to restore the org.hibernate.javax.persistence and it might get >> >> > messy, but I think we can agree the chance for this need to arise >> >> > being extremely small. >> >> > >> >> > Thanks, >> >> > Sanne >> >> > _______________________________________________ >> >> > 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 >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From sanne at hibernate.org Thu Dec 14 05:25:09 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 14 Dec 2017 10:25:09 +0000 Subject: [hibernate-dev] Killing hibernate-jpa-api ? In-Reply-To: References: Message-ID: On 13 December 2017 at 13:34, Steve Ebersole wrote: > > > On Wed, Dec 13, 2017 at 7:05 AM Sanne Grinovero wrote: >> >> Not really. Think of it as Deprecation: it will trigger some warnings >> for end users, especially those who didn't get the "news" of moving to >> the new API, and keep things working for a little longer for those >> people not willing (able?) to react right away to resolve the >> warnings. >> >> We can keep a deprecated method (jar) around for a couple more >> releases, or drop it as soon as it gets too inconvenient to maintain. >> It's definitley not a promise of long term. > > > Couple more releases of what? Hibernate ORM, as opposed to JPA? I assume > that's what you meant, just making sure. Honestly I would never publish a > new relocation - that means we are incrementing the version of the JPA API > jar, which should not happen. I was thinking JPA API releases: we'd release an updated one using our own groupdId and artifactID but at version 2.2, which when used will trigger a deprecation warning and redirect tools to use the official spec instead. But really I just meant "couple" as intentionally vague: no promises to the community as people should really start using the "new" official GAV. Since it's a deprecation we can do this once just to do people a favour by nudging them in the right direction; we *may* want to do it again in the future, probably not if the next one is a major.. we'll have download stats and then we can see and decide later. I also see no reason to set a "cleanup reminder": this is in a separate repository, if we just forget about it that means nobody will need it. Thanks, Sanne From steve at hibernate.org Thu Dec 14 06:54:04 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 11:54:04 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Thanks for the replies. So unless we hear otherwise from anyone else, I will plan on supporting just one DI container. On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere wrote: > Same here, compositions don't seem to be a reasonable use case. And even if > users provide a custom bean registry, they could just implement their > specific behavior for a few specific case, then retrieve another > implementations on their own and delegate to it however they want. > Overriding the service initiator looks like a very reasonable way to do > that. > > Regarding the package, "org.hibernate.resource.beans" seems more > appropriate to me, since CDI is not the only implementation we will get and > we know it. Also, if I wanted to nitpick, injection is not really something > the bean registry must provide. We could imagine a bean registry without > any support for injection, after all, just providing "monolithic beans". It > would still make sense with respect to your ManagedBeanRegistry API. > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 14 December 2017 at 08:01, Christian Beikov > > wrote: > > > I don't think someone is actually going to use more than a single DI > > framework and even if they do, they will probably bridge one way or > > another between the DI frameworks to be able to access beans from one in > > the other. > > > > So I don't think we should do "compositions" since it's not a big deal > > to integrate different DIs and is also IMO an edge case. I'd prefer the > > package name `org.hibernate.resource.di` since CDI seems to be just one > > of the possible "integrations". > > > > > > Mit freundlichen Gr??en, > > ------------------------------------------------------------------------ > > *Christian Beikov* > > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: > > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are > mainly > > > about back porting the work I did on 6.0 for the ManagedBeanRegistry > > > abstraction over dependency injection containers. We will ship support > > for > > > CDI as well as non-managed beans (things we directly instantiate). Of > > > course we'd ideally make it easy to plug in other DI containers such as > > > Spring. So I wanted to discuss the configuration of this support. > > > > > > The first thing to consider is whether we want to support using > multiple > > DI > > > containers simultaneously. E.g. is it conceivable that an application > > > might want to use both CDI and Spring simultaneously? I started > building > > > in support for that via a CompositeManagedBeanRegistry implementation, > > but > > > stepping back I want to gauge whether that is "reasonable" before > > > continuing down that path > > > > > > Assuming that we do want to support such "compositions" the next > question > > > is how we see this being configured. Clearly any time a CDI > BeanManager > > is > > > present during bootstrap we want to enable CDI ManagedBeanRegistry > > > support. How would users indicate additional ManagedBeanRegistry impls > > be > > > added to the CompositeManagedBeanRegistry? I have opinions about this, > > but > > > I'd like to hear other's thoughts... > > > > > > Note that ManagedBeanRegistry is a service and is initiated > > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it > > > would be possible to completely redefine ManagedBeanRegistry support > > simply > > > by replacing that initiator. > > > > > > A minor point... notice that the package name here is > > > `org.hibernate.resource.cdi`, even though one of the goals here is to > > > support non-CDI ManagedBeanRegistry impls. Do we want to use a > different > > > package name? Maybe `org.hibernate.resource.beans`? > > > ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? > > > Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` - > > imo > > > "cdi" conveys the proper intent. But if others feel strongly it should > > be > > > something else, I am open to hearing what and why. > > > _______________________________________________ > > > 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 > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Dec 14 07:25:47 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 12:25:47 +0000 Subject: [hibernate-dev] Interceptors and dependency injection In-Reply-To: References: Message-ID: https://hibernate.atlassian.net/browse/HHH-11259 lists some other possibilities for things we might consider for accessing through ManagedBeanRegistry. We discussed Interceptor in Paris - I can definitely see that with some caveats/restrictions. Add it to that list or create a new sub-task. As for chaining Interceptors, I guess it depends how that is exposed. E.g. a comma-separated list in settings would inherently imply ordering. That works for SessionFactory-scoped Interceptors. I'm not sure we need a composite though wrapping the individual Interceptors, a List would suffice and save some memory (granted a tiny amount). For Session-scoped Interceptors we would need to account for a few things, but its certainly possible. Supposing there are also SessionFactory-scoped Interceptors: 1. How would a user indicate that the Session-scoped Interceptors should replace the SessionFactory-scoped ones versus adding to them. What's the ordering there - SessionFactory-scoped Interceptors first? Or SessionScoped ones> 2. How would a user indicate that a Session should have no Interceptors? That is a common requirement. 3. Probably some others I am not thinking of. On Thu, Dec 14, 2017 at 2:44 AM Guillaume Smet wrote: > Hi all (and Steve especially as it seems you are working on the > subject right now), > > You talking about CDI made me think of something we did at > $previousJob a long time ago. > > I didn't quite follow what you did in 6 about CDI/Spring injection but > basically the requirement was to be able to create Spring managed > interceptors and to inject them in the PersistenceProvider. > > At the time, we ended up with the following: > > https://github.com/openwide-java/owsi-core-parent/blob/master/owsi-core/owsi-core-components/owsi-core-component-jpa/src/main/java/fr/openwide/core/jpa/hibernate/ejb/InterceptorAwareHibernatePersistenceProvider.java > > But I think it would probably be nice if we could inject them directly. > > Another thing we did which is not really related is creating a > ChainedInterceptor to be able to define several interceptors (the idea > was that we did want the ability to enable some interceptors at will > depending on what a given application required). > > Just injecting the interceptors in a random order would probably not > do it as I think you will probably want to define them in an ordered > way. > > Not sure it's useful but I thought I might as well talk about it now > that you are working on this feature. > > Have a nice day. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Dec 14 07:39:22 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 12:39:22 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Anyone know what happened to the 2.0 CDI artifact on Maven Central? It was there last week, but is no longer there... On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole wrote: > Thanks for the replies. So unless we hear otherwise from anyone else, I > will plan on supporting just one DI container. > > > > On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere wrote: > >> Same here, compositions don't seem to be a reasonable use case. And even >> if >> users provide a custom bean registry, they could just implement their >> specific behavior for a few specific case, then retrieve another >> implementations on their own and delegate to it however they want. >> Overriding the service initiator looks like a very reasonable way to do >> that. >> >> Regarding the package, "org.hibernate.resource.beans" seems more >> appropriate to me, since CDI is not the only implementation we will get >> and >> we know it. Also, if I wanted to nitpick, injection is not really >> something >> the bean registry must provide. We could imagine a bean registry without >> any support for injection, after all, just providing "monolithic beans". >> It >> would still make sense with respect to your ManagedBeanRegistry API. >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 14 December 2017 at 08:01, Christian Beikov < >> christian.beikov at gmail.com> >> wrote: >> >> > I don't think someone is actually going to use more than a single DI >> > framework and even if they do, they will probably bridge one way or >> > another between the DI frameworks to be able to access beans from one in >> > the other. >> > >> > So I don't think we should do "compositions" since it's not a big deal >> > to integrate different DIs and is also IMO an edge case. I'd prefer the >> > package name `org.hibernate.resource.di` since CDI seems to be just one >> > of the possible "integrations". >> > >> > >> > Mit freundlichen Gr??en, >> > ------------------------------------------------------------------------ >> > *Christian Beikov* >> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >> mainly >> > > about back porting the work I did on 6.0 for the ManagedBeanRegistry >> > > abstraction over dependency injection containers. We will ship >> support >> > for >> > > CDI as well as non-managed beans (things we directly instantiate). Of >> > > course we'd ideally make it easy to plug in other DI containers such >> as >> > > Spring. So I wanted to discuss the configuration of this support. >> > > >> > > The first thing to consider is whether we want to support using >> multiple >> > DI >> > > containers simultaneously. E.g. is it conceivable that an application >> > > might want to use both CDI and Spring simultaneously? I started >> building >> > > in support for that via a CompositeManagedBeanRegistry implementation, >> > but >> > > stepping back I want to gauge whether that is "reasonable" before >> > > continuing down that path >> > > >> > > Assuming that we do want to support such "compositions" the next >> question >> > > is how we see this being configured. Clearly any time a CDI >> BeanManager >> > is >> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >> > > support. How would users indicate additional ManagedBeanRegistry >> impls >> > be >> > > added to the CompositeManagedBeanRegistry? I have opinions about >> this, >> > but >> > > I'd like to hear other's thoughts... >> > > >> > > Note that ManagedBeanRegistry is a service and is initiated >> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So >> it >> > > would be possible to completely redefine ManagedBeanRegistry support >> > simply >> > > by replacing that initiator. >> > > >> > > A minor point... notice that the package name here is >> > > `org.hibernate.resource.cdi`, even though one of the goals here is to >> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >> different >> > > package name? Maybe `org.hibernate.resource.beans`? >> > > ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? >> > > Other suggestions? I'm actually ok with `org.hibernate.resource.cdi` >> - >> > imo >> > > "cdi" conveys the proper intent. But if others feel strongly it >> should >> > be >> > > something else, I am open to hearing what and why. >> > > _______________________________________________ >> > > 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 >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From steve at hibernate.org Thu Dec 14 07:40:21 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 12:40:21 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Ah, nm. They change the artifact name. Boo! On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole wrote: > Anyone know what happened to the 2.0 CDI artifact on Maven Central? It > was there last week, but is no longer there... > > On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole > wrote: > >> Thanks for the replies. So unless we hear otherwise from anyone else, I >> will plan on supporting just one DI container. >> >> >> >> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >> wrote: >> >>> Same here, compositions don't seem to be a reasonable use case. And even >>> if >>> users provide a custom bean registry, they could just implement their >>> specific behavior for a few specific case, then retrieve another >>> implementations on their own and delegate to it however they want. >>> Overriding the service initiator looks like a very reasonable way to do >>> that. >>> >>> Regarding the package, "org.hibernate.resource.beans" seems more >>> appropriate to me, since CDI is not the only implementation we will get >>> and >>> we know it. Also, if I wanted to nitpick, injection is not really >>> something >>> the bean registry must provide. We could imagine a bean registry without >>> any support for injection, after all, just providing "monolithic beans". >>> It >>> would still make sense with respect to your ManagedBeanRegistry API. >>> >>> >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> >>> On 14 December 2017 at 08:01, Christian Beikov < >>> christian.beikov at gmail.com> >>> wrote: >>> >>> > I don't think someone is actually going to use more than a single DI >>> > framework and even if they do, they will probably bridge one way or >>> > another between the DI frameworks to be able to access beans from one >>> in >>> > the other. >>> > >>> > So I don't think we should do "compositions" since it's not a big deal >>> > to integrate different DIs and is also IMO an edge case. I'd prefer the >>> > package name `org.hibernate.resource.di` since CDI seems to be just one >>> > of the possible "integrations". >>> > >>> > >>> > Mit freundlichen Gr??en, >>> > >>> ------------------------------------------------------------------------ >>> > *Christian Beikov* >>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>> mainly >>> > > about back porting the work I did on 6.0 for the ManagedBeanRegistry >>> > > abstraction over dependency injection containers. We will ship >>> support >>> > for >>> > > CDI as well as non-managed beans (things we directly instantiate). >>> Of >>> > > course we'd ideally make it easy to plug in other DI containers such >>> as >>> > > Spring. So I wanted to discuss the configuration of this support. >>> > > >>> > > The first thing to consider is whether we want to support using >>> multiple >>> > DI >>> > > containers simultaneously. E.g. is it conceivable that an >>> application >>> > > might want to use both CDI and Spring simultaneously? I started >>> building >>> > > in support for that via a CompositeManagedBeanRegistry >>> implementation, >>> > but >>> > > stepping back I want to gauge whether that is "reasonable" before >>> > > continuing down that path >>> > > >>> > > Assuming that we do want to support such "compositions" the next >>> question >>> > > is how we see this being configured. Clearly any time a CDI >>> BeanManager >>> > is >>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>> > > support. How would users indicate additional ManagedBeanRegistry >>> impls >>> > be >>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>> this, >>> > but >>> > > I'd like to hear other's thoughts... >>> > > >>> > > Note that ManagedBeanRegistry is a service and is initiated >>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So >>> it >>> > > would be possible to completely redefine ManagedBeanRegistry support >>> > simply >>> > > by replacing that initiator. >>> > > >>> > > A minor point... notice that the package name here is >>> > > `org.hibernate.resource.cdi`, even though one of the goals here is to >>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>> different >>> > > package name? Maybe `org.hibernate.resource.beans`? >>> > > ``org.hibernate.resource.di`? ``org.hibernate.resource.injection`? >>> > > Other suggestions? I'm actually ok with >>> `org.hibernate.resource.cdi` - >>> > imo >>> > > "cdi" conveys the proper intent. But if others feel strongly it >>> should >>> > be >>> > > something else, I am open to hearing what and why. >>> > > _______________________________________________ >>> > > 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 >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> From steve at hibernate.org Thu Dec 14 07:47:10 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 12:47:10 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Actually my fault. Apparently renaming the package was way too aggressive and renamed the artifact On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole wrote: > Ah, nm. They change the artifact name. Boo! > > On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole > wrote: > >> Anyone know what happened to the 2.0 CDI artifact on Maven Central? It >> was there last week, but is no longer there... >> >> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >> wrote: >> >>> Thanks for the replies. So unless we hear otherwise from anyone else, I >>> will plan on supporting just one DI container. >>> >>> >>> >>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>> wrote: >>> >>>> Same here, compositions don't seem to be a reasonable use case. And >>>> even if >>>> users provide a custom bean registry, they could just implement their >>>> specific behavior for a few specific case, then retrieve another >>>> implementations on their own and delegate to it however they want. >>>> Overriding the service initiator looks like a very reasonable way to do >>>> that. >>>> >>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>> appropriate to me, since CDI is not the only implementation we will get >>>> and >>>> we know it. Also, if I wanted to nitpick, injection is not really >>>> something >>>> the bean registry must provide. We could imagine a bean registry without >>>> any support for injection, after all, just providing "monolithic >>>> beans". It >>>> would still make sense with respect to your ManagedBeanRegistry API. >>>> >>>> >>>> Yoann Rodi?re >>>> Hibernate NoORM Team >>>> yoann at hibernate.org >>>> >>>> On 14 December 2017 at 08:01, Christian Beikov < >>>> christian.beikov at gmail.com> >>>> wrote: >>>> >>>> > I don't think someone is actually going to use more than a single DI >>>> > framework and even if they do, they will probably bridge one way or >>>> > another between the DI frameworks to be able to access beans from one >>>> in >>>> > the other. >>>> > >>>> > So I don't think we should do "compositions" since it's not a big deal >>>> > to integrate different DIs and is also IMO an edge case. I'd prefer >>>> the >>>> > package name `org.hibernate.resource.di` since CDI seems to be just >>>> one >>>> > of the possible "integrations". >>>> > >>>> > >>>> > Mit freundlichen Gr??en, >>>> > >>>> ------------------------------------------------------------------------ >>>> > *Christian Beikov* >>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>>> mainly >>>> > > about back porting the work I did on 6.0 for the ManagedBeanRegistry >>>> > > abstraction over dependency injection containers. We will ship >>>> support >>>> > for >>>> > > CDI as well as non-managed beans (things we directly instantiate). >>>> Of >>>> > > course we'd ideally make it easy to plug in other DI containers >>>> such as >>>> > > Spring. So I wanted to discuss the configuration of this support. >>>> > > >>>> > > The first thing to consider is whether we want to support using >>>> multiple >>>> > DI >>>> > > containers simultaneously. E.g. is it conceivable that an >>>> application >>>> > > might want to use both CDI and Spring simultaneously? I started >>>> building >>>> > > in support for that via a CompositeManagedBeanRegistry >>>> implementation, >>>> > but >>>> > > stepping back I want to gauge whether that is "reasonable" before >>>> > > continuing down that path >>>> > > >>>> > > Assuming that we do want to support such "compositions" the next >>>> question >>>> > > is how we see this being configured. Clearly any time a CDI >>>> BeanManager >>>> > is >>>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>>> > > support. How would users indicate additional ManagedBeanRegistry >>>> impls >>>> > be >>>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>>> this, >>>> > but >>>> > > I'd like to hear other's thoughts... >>>> > > >>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>> So it >>>> > > would be possible to completely redefine ManagedBeanRegistry support >>>> > simply >>>> > > by replacing that initiator. >>>> > > >>>> > > A minor point... notice that the package name here is >>>> > > `org.hibernate.resource.cdi`, even though one of the goals here is >>>> to >>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>> different >>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>> > > ``org.hibernate.resource.di`? >>>> ``org.hibernate.resource.injection`? >>>> > > Other suggestions? I'm actually ok with >>>> `org.hibernate.resource.cdi` - >>>> > imo >>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>> should >>>> > be >>>> > > something else, I am open to hearing what and why. >>>> > > _______________________________________________ >>>> > > 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 >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> From steve at hibernate.org Thu Dec 14 07:52:55 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 12:52:55 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: There are a lot of changes to digest here, but if anyone wanted to take a look at this so far... https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole wrote: > Actually my fault. Apparently renaming the package was way too aggressive > and renamed the artifact > > On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole > wrote: > >> Ah, nm. They change the artifact name. Boo! >> >> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >> wrote: >> >>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? It >>> was there last week, but is no longer there... >>> >>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >>> wrote: >>> >>>> Thanks for the replies. So unless we hear otherwise from anyone else, >>>> I will plan on supporting just one DI container. >>>> >>>> >>>> >>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>>> wrote: >>>> >>>>> Same here, compositions don't seem to be a reasonable use case. And >>>>> even if >>>>> users provide a custom bean registry, they could just implement their >>>>> specific behavior for a few specific case, then retrieve another >>>>> implementations on their own and delegate to it however they want. >>>>> Overriding the service initiator looks like a very reasonable way to do >>>>> that. >>>>> >>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>> appropriate to me, since CDI is not the only implementation we will >>>>> get and >>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>> something >>>>> the bean registry must provide. We could imagine a bean registry >>>>> without >>>>> any support for injection, after all, just providing "monolithic >>>>> beans". It >>>>> would still make sense with respect to your ManagedBeanRegistry API. >>>>> >>>>> >>>>> Yoann Rodi?re >>>>> Hibernate NoORM Team >>>>> yoann at hibernate.org >>>>> >>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>> christian.beikov at gmail.com> >>>>> wrote: >>>>> >>>>> > I don't think someone is actually going to use more than a single DI >>>>> > framework and even if they do, they will probably bridge one way or >>>>> > another between the DI frameworks to be able to access beans from >>>>> one in >>>>> > the other. >>>>> > >>>>> > So I don't think we should do "compositions" since it's not a big >>>>> deal >>>>> > to integrate different DIs and is also IMO an edge case. I'd prefer >>>>> the >>>>> > package name `org.hibernate.resource.di` since CDI seems to be just >>>>> one >>>>> > of the possible "integrations". >>>>> > >>>>> > >>>>> > Mit freundlichen Gr??en, >>>>> > >>>>> ------------------------------------------------------------------------ >>>>> > *Christian Beikov* >>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>>>> mainly >>>>> > > about back porting the work I did on 6.0 for the >>>>> ManagedBeanRegistry >>>>> > > abstraction over dependency injection containers. We will ship >>>>> support >>>>> > for >>>>> > > CDI as well as non-managed beans (things we directly >>>>> instantiate). Of >>>>> > > course we'd ideally make it easy to plug in other DI containers >>>>> such as >>>>> > > Spring. So I wanted to discuss the configuration of this support. >>>>> > > >>>>> > > The first thing to consider is whether we want to support using >>>>> multiple >>>>> > DI >>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>> application >>>>> > > might want to use both CDI and Spring simultaneously? I started >>>>> building >>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>> implementation, >>>>> > but >>>>> > > stepping back I want to gauge whether that is "reasonable" before >>>>> > > continuing down that path >>>>> > > >>>>> > > Assuming that we do want to support such "compositions" the next >>>>> question >>>>> > > is how we see this being configured. Clearly any time a CDI >>>>> BeanManager >>>>> > is >>>>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>>>> > > support. How would users indicate additional ManagedBeanRegistry >>>>> impls >>>>> > be >>>>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>>>> this, >>>>> > but >>>>> > > I'd like to hear other's thoughts... >>>>> > > >>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>> So it >>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>> support >>>>> > simply >>>>> > > by replacing that initiator. >>>>> > > >>>>> > > A minor point... notice that the package name here is >>>>> > > `org.hibernate.resource.cdi`, even though one of the goals here is >>>>> to >>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>>> different >>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>> > > ``org.hibernate.resource.di`? >>>>> ``org.hibernate.resource.injection`? >>>>> > > Other suggestions? I'm actually ok with >>>>> `org.hibernate.resource.cdi` - >>>>> > imo >>>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>>> should >>>>> > be >>>>> > > something else, I am open to hearing what and why. >>>>> > > _______________________________________________ >>>>> > > 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 >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> From yoann at hibernate.org Thu Dec 14 08:24:06 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 14 Dec 2017 14:24:06 +0100 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Thanks. As mentioned on the commit, I'm wondering if it's such a good idea to cache the beans... Like you seem to do here: https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b#diff-8daedd2dae71b88377be643ed78b5c5dR33 CDI already has features to make sure that a given bean is a singleton, and sometimes (in Search in particular) we absolutely do not want the beans to be singletons, but rather want to instantiate them multiple times. So... is it really necessary? Also the current implementation doesn't seem to support actual named beans, which would be fetched by calling "beanManager.getBeans(clazz, new NamedQualifier(name))" where NamedQualifier would be defined as below (not a joke, it looks like it's actually what we should do). private static class NamedQualifier extends javax.enterprise.util.AnnotationLiteral implements javax.inject.Named { private final String name; public NamedQualifier(String name) { this.name = name; } @Override public String value() { return name; } } Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 14 December 2017 at 13:52, Steve Ebersole wrote: > There are a lot of changes to digest here, but if anyone wanted to take a > look at this so far... > > https://github.com/hibernate/hibernate-orm/commit/ > 564ec55ca10c0d5d2afd73243dc0aa31759e8f5b > > > On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole > wrote: > >> Actually my fault. Apparently renaming the package was way too >> aggressive and renamed the artifact >> >> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole >> wrote: >> >>> Ah, nm. They change the artifact name. Boo! >>> >>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >>> wrote: >>> >>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? It >>>> was there last week, but is no longer there... >>>> >>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >>>> wrote: >>>> >>>>> Thanks for the replies. So unless we hear otherwise from anyone else, >>>>> I will plan on supporting just one DI container. >>>>> >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>>>> wrote: >>>>> >>>>>> Same here, compositions don't seem to be a reasonable use case. And >>>>>> even if >>>>>> users provide a custom bean registry, they could just implement their >>>>>> specific behavior for a few specific case, then retrieve another >>>>>> implementations on their own and delegate to it however they want. >>>>>> Overriding the service initiator looks like a very reasonable way to >>>>>> do >>>>>> that. >>>>>> >>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>> appropriate to me, since CDI is not the only implementation we will >>>>>> get and >>>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>>> something >>>>>> the bean registry must provide. We could imagine a bean registry >>>>>> without >>>>>> any support for injection, after all, just providing "monolithic >>>>>> beans". It >>>>>> would still make sense with respect to your ManagedBeanRegistry API. >>>>>> >>>>>> >>>>>> Yoann Rodi?re >>>>>> Hibernate NoORM Team >>>>>> yoann at hibernate.org >>>>>> >>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>> christian.beikov at gmail.com> >>>>>> wrote: >>>>>> >>>>>> > I don't think someone is actually going to use more than a single DI >>>>>> > framework and even if they do, they will probably bridge one way or >>>>>> > another between the DI frameworks to be able to access beans from >>>>>> one in >>>>>> > the other. >>>>>> > >>>>>> > So I don't think we should do "compositions" since it's not a big >>>>>> deal >>>>>> > to integrate different DIs and is also IMO an edge case. I'd prefer >>>>>> the >>>>>> > package name `org.hibernate.resource.di` since CDI seems to be just >>>>>> one >>>>>> > of the possible "integrations". >>>>>> > >>>>>> > >>>>>> > Mit freundlichen Gr??en, >>>>>> > ------------------------------------------------------------ >>>>>> ------------ >>>>>> > *Christian Beikov* >>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>>>>> mainly >>>>>> > > about back porting the work I did on 6.0 for the >>>>>> ManagedBeanRegistry >>>>>> > > abstraction over dependency injection containers. We will ship >>>>>> support >>>>>> > for >>>>>> > > CDI as well as non-managed beans (things we directly >>>>>> instantiate). Of >>>>>> > > course we'd ideally make it easy to plug in other DI containers >>>>>> such as >>>>>> > > Spring. So I wanted to discuss the configuration of this support. >>>>>> > > >>>>>> > > The first thing to consider is whether we want to support using >>>>>> multiple >>>>>> > DI >>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>> application >>>>>> > > might want to use both CDI and Spring simultaneously? I started >>>>>> building >>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>> implementation, >>>>>> > but >>>>>> > > stepping back I want to gauge whether that is "reasonable" before >>>>>> > > continuing down that path >>>>>> > > >>>>>> > > Assuming that we do want to support such "compositions" the next >>>>>> question >>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>> BeanManager >>>>>> > is >>>>>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>>>>> > > support. How would users indicate additional ManagedBeanRegistry >>>>>> impls >>>>>> > be >>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>>>>> this, >>>>>> > but >>>>>> > > I'd like to hear other's thoughts... >>>>>> > > >>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>>> So it >>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>> support >>>>>> > simply >>>>>> > > by replacing that initiator. >>>>>> > > >>>>>> > > A minor point... notice that the package name here is >>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals here >>>>>> is to >>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>>>> different >>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>> > > ``org.hibernate.resource.di`? ``org.hibernate.resource. >>>>>> injection`? >>>>>> > > Other suggestions? I'm actually ok with >>>>>> `org.hibernate.resource.cdi` - >>>>>> > imo >>>>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>>>> should >>>>>> > be >>>>>> > > something else, I am open to hearing what and why. >>>>>> > > _______________________________________________ >>>>>> > > 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 >>>>>> > >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>>> From steve at hibernate.org Thu Dec 14 08:36:56 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 13:36:56 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Its easier to cleanup On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole wrote: > There are a lot of changes to digest here, but if anyone wanted to take a > look at this so far... > > > https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b > > > On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole > wrote: > >> Actually my fault. Apparently renaming the package was way too >> aggressive and renamed the artifact >> >> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole >> wrote: >> >>> Ah, nm. They change the artifact name. Boo! >>> >>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >>> wrote: >>> >>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? It >>>> was there last week, but is no longer there... >>>> >>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >>>> wrote: >>>> >>>>> Thanks for the replies. So unless we hear otherwise from anyone else, >>>>> I will plan on supporting just one DI container. >>>>> >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>>>> wrote: >>>>> >>>>>> Same here, compositions don't seem to be a reasonable use case. And >>>>>> even if >>>>>> users provide a custom bean registry, they could just implement their >>>>>> specific behavior for a few specific case, then retrieve another >>>>>> implementations on their own and delegate to it however they want. >>>>>> Overriding the service initiator looks like a very reasonable way to >>>>>> do >>>>>> that. >>>>>> >>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>> appropriate to me, since CDI is not the only implementation we will >>>>>> get and >>>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>>> something >>>>>> the bean registry must provide. We could imagine a bean registry >>>>>> without >>>>>> any support for injection, after all, just providing "monolithic >>>>>> beans". It >>>>>> would still make sense with respect to your ManagedBeanRegistry API. >>>>>> >>>>>> >>>>>> Yoann Rodi?re >>>>>> Hibernate NoORM Team >>>>>> yoann at hibernate.org >>>>>> >>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>> christian.beikov at gmail.com> >>>>>> wrote: >>>>>> >>>>>> > I don't think someone is actually going to use more than a single DI >>>>>> > framework and even if they do, they will probably bridge one way or >>>>>> > another between the DI frameworks to be able to access beans from >>>>>> one in >>>>>> > the other. >>>>>> > >>>>>> > So I don't think we should do "compositions" since it's not a big >>>>>> deal >>>>>> > to integrate different DIs and is also IMO an edge case. I'd prefer >>>>>> the >>>>>> > package name `org.hibernate.resource.di` since CDI seems to be just >>>>>> one >>>>>> > of the possible "integrations". >>>>>> > >>>>>> > >>>>>> > Mit freundlichen Gr??en, >>>>>> > >>>>>> ------------------------------------------------------------------------ >>>>>> > *Christian Beikov* >>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>>>>> mainly >>>>>> > > about back porting the work I did on 6.0 for the >>>>>> ManagedBeanRegistry >>>>>> > > abstraction over dependency injection containers. We will ship >>>>>> support >>>>>> > for >>>>>> > > CDI as well as non-managed beans (things we directly >>>>>> instantiate). Of >>>>>> > > course we'd ideally make it easy to plug in other DI containers >>>>>> such as >>>>>> > > Spring. So I wanted to discuss the configuration of this support. >>>>>> > > >>>>>> > > The first thing to consider is whether we want to support using >>>>>> multiple >>>>>> > DI >>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>> application >>>>>> > > might want to use both CDI and Spring simultaneously? I started >>>>>> building >>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>> implementation, >>>>>> > but >>>>>> > > stepping back I want to gauge whether that is "reasonable" before >>>>>> > > continuing down that path >>>>>> > > >>>>>> > > Assuming that we do want to support such "compositions" the next >>>>>> question >>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>> BeanManager >>>>>> > is >>>>>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>>>>> > > support. How would users indicate additional ManagedBeanRegistry >>>>>> impls >>>>>> > be >>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>>>>> this, >>>>>> > but >>>>>> > > I'd like to hear other's thoughts... >>>>>> > > >>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>>> So it >>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>> support >>>>>> > simply >>>>>> > > by replacing that initiator. >>>>>> > > >>>>>> > > A minor point... notice that the package name here is >>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals here >>>>>> is to >>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>>>> different >>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>> > > ``org.hibernate.resource.di`? >>>>>> ``org.hibernate.resource.injection`? >>>>>> > > Other suggestions? I'm actually ok with >>>>>> `org.hibernate.resource.cdi` - >>>>>> > imo >>>>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>>>> should >>>>>> > be >>>>>> > > something else, I am open to hearing what and why. >>>>>> > > _______________________________________________ >>>>>> > > 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 >>>>>> > >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>>> From steve at hibernate.org Thu Dec 14 08:38:43 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 13:38:43 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: WRT to named beans, I asked Guillaume on HipChat what that is supposed to look like. IIRC he mentioned producers in Paris, but I found no straight-forward way to get from name+class to a bean. He may have answered, I just have not been on HipChat yet today... On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole wrote: > Its easier to cleanup > > On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole > wrote: > >> There are a lot of changes to digest here, but if anyone wanted to take a >> look at this so far... >> >> >> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >> >> >> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole >> wrote: >> >>> Actually my fault. Apparently renaming the package was way too >>> aggressive and renamed the artifact >>> >>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole >>> wrote: >>> >>>> Ah, nm. They change the artifact name. Boo! >>>> >>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >>>> wrote: >>>> >>>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? >>>>> It was there last week, but is no longer there... >>>>> >>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >>>>> wrote: >>>>> >>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>> else, I will plan on supporting just one DI container. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>>>>> wrote: >>>>>> >>>>>>> Same here, compositions don't seem to be a reasonable use case. And >>>>>>> even if >>>>>>> users provide a custom bean registry, they could just implement their >>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>> implementations on their own and delegate to it however they want. >>>>>>> Overriding the service initiator looks like a very reasonable way to >>>>>>> do >>>>>>> that. >>>>>>> >>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>> appropriate to me, since CDI is not the only implementation we will >>>>>>> get and >>>>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>>>> something >>>>>>> the bean registry must provide. We could imagine a bean registry >>>>>>> without >>>>>>> any support for injection, after all, just providing "monolithic >>>>>>> beans". It >>>>>>> would still make sense with respect to your ManagedBeanRegistry API. >>>>>>> >>>>>>> >>>>>>> Yoann Rodi?re >>>>>>> Hibernate NoORM Team >>>>>>> yoann at hibernate.org >>>>>>> >>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>> christian.beikov at gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> > I don't think someone is actually going to use more than a single >>>>>>> DI >>>>>>> > framework and even if they do, they will probably bridge one way or >>>>>>> > another between the DI frameworks to be able to access beans from >>>>>>> one in >>>>>>> > the other. >>>>>>> > >>>>>>> > So I don't think we should do "compositions" since it's not a big >>>>>>> deal >>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>> prefer the >>>>>>> > package name `org.hibernate.resource.di` since CDI seems to be >>>>>>> just one >>>>>>> > of the possible "integrations". >>>>>>> > >>>>>>> > >>>>>>> > Mit freundlichen Gr??en, >>>>>>> > >>>>>>> ------------------------------------------------------------------------ >>>>>>> > *Christian Beikov* >>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends >>>>>>> are mainly >>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>> ManagedBeanRegistry >>>>>>> > > abstraction over dependency injection containers. We will ship >>>>>>> support >>>>>>> > for >>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>> instantiate). Of >>>>>>> > > course we'd ideally make it easy to plug in other DI containers >>>>>>> such as >>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>> support. >>>>>>> > > >>>>>>> > > The first thing to consider is whether we want to support using >>>>>>> multiple >>>>>>> > DI >>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>> application >>>>>>> > > might want to use both CDI and Spring simultaneously? I started >>>>>>> building >>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>> implementation, >>>>>>> > but >>>>>>> > > stepping back I want to gauge whether that is "reasonable" before >>>>>>> > > continuing down that path >>>>>>> > > >>>>>>> > > Assuming that we do want to support such "compositions" the next >>>>>>> question >>>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>>> BeanManager >>>>>>> > is >>>>>>> > > present during bootstrap we want to enable CDI >>>>>>> ManagedBeanRegistry >>>>>>> > > support. How would users indicate additional >>>>>>> ManagedBeanRegistry impls >>>>>>> > be >>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>> about this, >>>>>>> > but >>>>>>> > > I'd like to hear other's thoughts... >>>>>>> > > >>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>> > > via >>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>>> support >>>>>>> > simply >>>>>>> > > by replacing that initiator. >>>>>>> > > >>>>>>> > > A minor point... notice that the package name here is >>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals here >>>>>>> is to >>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>>>>> different >>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>> > > ``org.hibernate.resource.di`? >>>>>>> ``org.hibernate.resource.injection`? >>>>>>> > > Other suggestions? I'm actually ok with >>>>>>> `org.hibernate.resource.cdi` - >>>>>>> > imo >>>>>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>>>>> should >>>>>>> > be >>>>>>> > > something else, I am open to hearing what and why. >>>>>>> > > _______________________________________________ >>>>>>> > > 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 >>>>>>> > >>>>>>> _______________________________________________ >>>>>>> hibernate-dev mailing list >>>>>>> hibernate-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>> From yoann at hibernate.org Thu Dec 14 08:40:54 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 14 Dec 2017 14:40:54 +0100 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Yeah, it was 4AM in France when you asked :) I answered later on HipChat, the answer is basically the one I gave in my email. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 14 December 2017 at 14:38, Steve Ebersole wrote: > WRT to named beans, I asked Guillaume on HipChat what that is supposed to > look like. IIRC he mentioned producers in Paris, but I found no > straight-forward way to get from name+class to a bean. > > He may have answered, I just have not been on HipChat yet today... > > On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole > wrote: > >> Its easier to cleanup >> >> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole >> wrote: >> >>> There are a lot of changes to digest here, but if anyone wanted to take >>> a look at this so far... >>> >>> https://github.com/hibernate/hibernate-orm/commit/ >>> 564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>> >>> >>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole >>> wrote: >>> >>>> Actually my fault. Apparently renaming the package was way too >>>> aggressive and renamed the artifact >>>> >>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole >>>> wrote: >>>> >>>>> Ah, nm. They change the artifact name. Boo! >>>>> >>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >>>>> wrote: >>>>> >>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? >>>>>> It was there last week, but is no longer there... >>>>>> >>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>>> else, I will plan on supporting just one DI container. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>>>>>> wrote: >>>>>>> >>>>>>>> Same here, compositions don't seem to be a reasonable use case. And >>>>>>>> even if >>>>>>>> users provide a custom bean registry, they could just implement >>>>>>>> their >>>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>>> implementations on their own and delegate to it however they want. >>>>>>>> Overriding the service initiator looks like a very reasonable way >>>>>>>> to do >>>>>>>> that. >>>>>>>> >>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>>> appropriate to me, since CDI is not the only implementation we will >>>>>>>> get and >>>>>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>>>>> something >>>>>>>> the bean registry must provide. We could imagine a bean registry >>>>>>>> without >>>>>>>> any support for injection, after all, just providing "monolithic >>>>>>>> beans". It >>>>>>>> would still make sense with respect to your ManagedBeanRegistry API. >>>>>>>> >>>>>>>> >>>>>>>> Yoann Rodi?re >>>>>>>> Hibernate NoORM Team >>>>>>>> yoann at hibernate.org >>>>>>>> >>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>> christian.beikov at gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> > I don't think someone is actually going to use more than a single >>>>>>>> DI >>>>>>>> > framework and even if they do, they will probably bridge one way >>>>>>>> or >>>>>>>> > another between the DI frameworks to be able to access beans from >>>>>>>> one in >>>>>>>> > the other. >>>>>>>> > >>>>>>>> > So I don't think we should do "compositions" since it's not a big >>>>>>>> deal >>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>> prefer the >>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to be >>>>>>>> just one >>>>>>>> > of the possible "integrations". >>>>>>>> > >>>>>>>> > >>>>>>>> > Mit freundlichen Gr??en, >>>>>>>> > ------------------------------------------------------------ >>>>>>>> ------------ >>>>>>>> > *Christian Beikov* >>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends >>>>>>>> are mainly >>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>> ManagedBeanRegistry >>>>>>>> > > abstraction over dependency injection containers. We will ship >>>>>>>> support >>>>>>>> > for >>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>> instantiate). Of >>>>>>>> > > course we'd ideally make it easy to plug in other DI containers >>>>>>>> such as >>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>> support. >>>>>>>> > > >>>>>>>> > > The first thing to consider is whether we want to support using >>>>>>>> multiple >>>>>>>> > DI >>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>> application >>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>> started building >>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>> implementation, >>>>>>>> > but >>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>> before >>>>>>>> > > continuing down that path >>>>>>>> > > >>>>>>>> > > Assuming that we do want to support such "compositions" the >>>>>>>> next question >>>>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>>>> BeanManager >>>>>>>> > is >>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>> ManagedBeanRegistry >>>>>>>> > > support. How would users indicate additional >>>>>>>> ManagedBeanRegistry impls >>>>>>>> > be >>>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>>> about this, >>>>>>>> > but >>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>> > > >>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>>>>> So it >>>>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>>>> support >>>>>>>> > simply >>>>>>>> > > by replacing that initiator. >>>>>>>> > > >>>>>>>> > > A minor point... notice that the package name here is >>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals here >>>>>>>> is to >>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>>>>>> different >>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>> > > ``org.hibernate.resource.di`? ``org.hibernate.resource. >>>>>>>> injection`? >>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>> > imo >>>>>>>> > > "cdi" conveys the proper intent. But if others feel strongly >>>>>>>> it should >>>>>>>> > be >>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>> > > _______________________________________________ >>>>>>>> > > 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 >>>>>>>> > >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> >>>>>>> From steve at hibernate.org Thu Dec 14 08:44:52 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 13:44:52 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: But your answer above does not answer my question ;) I still have no idea how to go from name+Class -> bean. On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere wrote: > Yeah, it was 4AM in France when you asked :) I answered later on HipChat, > the answer is basically the one I gave in my email. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 14 December 2017 at 14:38, Steve Ebersole wrote: > >> WRT to named beans, I asked Guillaume on HipChat what that is supposed to >> look like. IIRC he mentioned producers in Paris, but I found no >> straight-forward way to get from name+class to a bean. >> >> He may have answered, I just have not been on HipChat yet today... >> >> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole >> wrote: >> >>> Its easier to cleanup >>> >>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole >>> wrote: >>> >>>> There are a lot of changes to digest here, but if anyone wanted to take >>>> a look at this so far... >>>> >>>> >>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>>> >>>> >>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole >>>> wrote: >>>> >>>>> Actually my fault. Apparently renaming the package was way too >>>>> aggressive and renamed the artifact >>>>> >>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole >>>>> wrote: >>>>> >>>>>> Ah, nm. They change the artifact name. Boo! >>>>>> >>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? >>>>>>> It was there last week, but is no longer there... >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>>>> else, I will plan on supporting just one DI container. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Same here, compositions don't seem to be a reasonable use case. >>>>>>>>> And even if >>>>>>>>> users provide a custom bean registry, they could just implement >>>>>>>>> their >>>>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>>>> implementations on their own and delegate to it however they want. >>>>>>>>> Overriding the service initiator looks like a very reasonable way >>>>>>>>> to do >>>>>>>>> that. >>>>>>>>> >>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>>>> appropriate to me, since CDI is not the only implementation we >>>>>>>>> will get and >>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>>>>>> something >>>>>>>>> the bean registry must provide. We could imagine a bean registry >>>>>>>>> without >>>>>>>>> any support for injection, after all, just providing "monolithic >>>>>>>>> beans". It >>>>>>>>> would still make sense with respect to your ManagedBeanRegistry >>>>>>>>> API. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yoann Rodi?re >>>>>>>>> Hibernate NoORM Team >>>>>>>>> yoann at hibernate.org >>>>>>>>> >>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>> christian.beikov at gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>> single DI >>>>>>>>> > framework and even if they do, they will probably bridge one way >>>>>>>>> or >>>>>>>>> > another between the DI frameworks to be able to access beans >>>>>>>>> from one in >>>>>>>>> > the other. >>>>>>>>> > >>>>>>>>> > So I don't think we should do "compositions" since it's not a >>>>>>>>> big deal >>>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>>> prefer the >>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to be >>>>>>>>> just one >>>>>>>>> > of the possible "integrations". >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>> > >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> > *Christian Beikov* >>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends >>>>>>>>> are mainly >>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>> ManagedBeanRegistry >>>>>>>>> > > abstraction over dependency injection containers. We will >>>>>>>>> ship support >>>>>>>>> > for >>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>> instantiate). Of >>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>> containers such as >>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>> support. >>>>>>>>> > > >>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>> using multiple >>>>>>>>> > DI >>>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>>> application >>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>> started building >>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>> implementation, >>>>>>>>> > but >>>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>>> before >>>>>>>>> > > continuing down that path >>>>>>>>> > > >>>>>>>>> > > Assuming that we do want to support such "compositions" the >>>>>>>>> next question >>>>>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>>>>> BeanManager >>>>>>>>> > is >>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>> ManagedBeanRegistry >>>>>>>>> > > support. How would users indicate additional >>>>>>>>> ManagedBeanRegistry impls >>>>>>>>> > be >>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>>>> about this, >>>>>>>>> > but >>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>> > > >>>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>>> > > via >>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>>>>> support >>>>>>>>> > simply >>>>>>>>> > > by replacing that initiator. >>>>>>>>> > > >>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals >>>>>>>>> here is to >>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use >>>>>>>>> a different >>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>> > imo >>>>>>>>> > > "cdi" conveys the proper intent. But if others feel strongly >>>>>>>>> it should >>>>>>>>> > be >>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>> > > _______________________________________________ >>>>>>>>> > > 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 >>>>>>>>> > >>>>>>>>> _______________________________________________ >>>>>>>>> hibernate-dev mailing list >>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>>> > From steve at hibernate.org Thu Dec 14 08:46:27 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 13:46:27 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: I'll be on HipChat later after I get back from taking my son and daughter to school. Maybe it is easier to discuss there. On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole wrote: > But your answer above does not answer my question ;) > > I still have no idea how to go from name+Class -> bean. > > > On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere wrote: > >> Yeah, it was 4AM in France when you asked :) I answered later on HipChat, >> the answer is basically the one I gave in my email. >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 14 December 2017 at 14:38, Steve Ebersole wrote: >> >>> WRT to named beans, I asked Guillaume on HipChat what that is supposed >>> to look like. IIRC he mentioned producers in Paris, but I found no >>> straight-forward way to get from name+class to a bean. >>> >>> He may have answered, I just have not been on HipChat yet today... >>> >>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole >>> wrote: >>> >>>> Its easier to cleanup >>>> >>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole >>>> wrote: >>>> >>>>> There are a lot of changes to digest here, but if anyone wanted to >>>>> take a look at this so far... >>>>> >>>>> >>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole >>>>> wrote: >>>>> >>>>>> Actually my fault. Apparently renaming the package was way too >>>>>> aggressive and renamed the artifact >>>>>> >>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >>>>>>> wrote: >>>>>>> >>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>>>>> else, I will plan on supporting just one DI container. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Same here, compositions don't seem to be a reasonable use case. >>>>>>>>>> And even if >>>>>>>>>> users provide a custom bean registry, they could just implement >>>>>>>>>> their >>>>>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>>>>> implementations on their own and delegate to it however they want. >>>>>>>>>> Overriding the service initiator looks like a very reasonable way >>>>>>>>>> to do >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>>>>> appropriate to me, since CDI is not the only implementation we >>>>>>>>>> will get and >>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>>>>>>> something >>>>>>>>>> the bean registry must provide. We could imagine a bean registry >>>>>>>>>> without >>>>>>>>>> any support for injection, after all, just providing "monolithic >>>>>>>>>> beans". It >>>>>>>>>> would still make sense with respect to your ManagedBeanRegistry >>>>>>>>>> API. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yoann Rodi?re >>>>>>>>>> Hibernate NoORM Team >>>>>>>>>> yoann at hibernate.org >>>>>>>>>> >>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>> christian.beikov at gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>> single DI >>>>>>>>>> > framework and even if they do, they will probably bridge one >>>>>>>>>> way or >>>>>>>>>> > another between the DI frameworks to be able to access beans >>>>>>>>>> from one in >>>>>>>>>> > the other. >>>>>>>>>> > >>>>>>>>>> > So I don't think we should do "compositions" since it's not a >>>>>>>>>> big deal >>>>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>>>> prefer the >>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to be >>>>>>>>>> just one >>>>>>>>>> > of the possible "integrations". >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>>> > >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> > *Christian Beikov* >>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends >>>>>>>>>> are mainly >>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>> ManagedBeanRegistry >>>>>>>>>> > > abstraction over dependency injection containers. We will >>>>>>>>>> ship support >>>>>>>>>> > for >>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>> instantiate). Of >>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>> containers such as >>>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>>> support. >>>>>>>>>> > > >>>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>>> using multiple >>>>>>>>>> > DI >>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>>>> application >>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>> started building >>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>> implementation, >>>>>>>>>> > but >>>>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>>>> before >>>>>>>>>> > > continuing down that path >>>>>>>>>> > > >>>>>>>>>> > > Assuming that we do want to support such "compositions" the >>>>>>>>>> next question >>>>>>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>>>>>> BeanManager >>>>>>>>>> > is >>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>> ManagedBeanRegistry >>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>> > be >>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>>>>> about this, >>>>>>>>>> > but >>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>> > > >>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>>>> > > via >>>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>>>>>> support >>>>>>>>>> > simply >>>>>>>>>> > > by replacing that initiator. >>>>>>>>>> > > >>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals >>>>>>>>>> here is to >>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use >>>>>>>>>> a different >>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>> > imo >>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel strongly >>>>>>>>>> it should >>>>>>>>>> > be >>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>> > > _______________________________________________ >>>>>>>>>> > > 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 >>>>>>>>>> > >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>> >>>>>>>>> >> From guillaume.smet at gmail.com Thu Dec 14 08:55:40 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 14 Dec 2017 14:55:40 +0100 Subject: [hibernate-dev] Interceptors and dependency injection In-Reply-To: References: Message-ID: On Thu, Dec 14, 2017 at 1:25 PM, Steve Ebersole wrote: > https://hibernate.atlassian.net/browse/HHH-11259 lists some other > possibilities for things we might consider for accessing through > ManagedBeanRegistry. We discussed Interceptor in Paris - I can definitely > see that with some caveats/restrictions. Add it to that list or create a > new sub-task. Done. > As for chaining Interceptors, I guess it depends how that is exposed. E.g. > a comma-separated list in settings would inherently imply ordering. That > works for SessionFactory-scoped Interceptors. I'm not sure we need a > composite though wrapping the individual Interceptors, a List > would suffice and save some memory (granted a tiny amount). For > Session-scoped Interceptors we would need to account for a few things, but > its certainly possible. Supposing there are also SessionFactory-scoped > Interceptors: > > How would a user indicate that the Session-scoped Interceptors should > replace the SessionFactory-scoped ones versus adding to them. What's the > ordering there - SessionFactory-scoped Interceptors first? Or SessionScoped > ones> > How would a user indicate that a Session should have no Interceptors? That > is a common requirement. > Probably some others I am not thinking of. Possibly the easiest solution would be to replace them all and only apply the Session-scoped ones if defined. But I'm not sure I understand all the ramifications. -- Guillaume From sanne at hibernate.org Thu Dec 14 08:56:07 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 14 Dec 2017 14:56:07 +0100 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: On 14 December 2017 at 13:47, Steve Ebersole wrote: > Actually my fault. Apparently renaming the package was way too aggressive > and renamed the artifact A relocation would have been helpful.. /me ducks and runs > > On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole wrote: > >> Ah, nm. They change the artifact name. Boo! >> >> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >> wrote: >> >>> Anyone know what happened to the 2.0 CDI artifact on Maven Central? It >>> was there last week, but is no longer there... >>> >>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole >>> wrote: >>> >>>> Thanks for the replies. So unless we hear otherwise from anyone else, I >>>> will plan on supporting just one DI container. >>>> >>>> >>>> >>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere >>>> wrote: >>>> >>>>> Same here, compositions don't seem to be a reasonable use case. And >>>>> even if >>>>> users provide a custom bean registry, they could just implement their >>>>> specific behavior for a few specific case, then retrieve another >>>>> implementations on their own and delegate to it however they want. >>>>> Overriding the service initiator looks like a very reasonable way to do >>>>> that. >>>>> >>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>> appropriate to me, since CDI is not the only implementation we will get >>>>> and >>>>> we know it. Also, if I wanted to nitpick, injection is not really >>>>> something >>>>> the bean registry must provide. We could imagine a bean registry without >>>>> any support for injection, after all, just providing "monolithic >>>>> beans". It >>>>> would still make sense with respect to your ManagedBeanRegistry API. >>>>> >>>>> >>>>> Yoann Rodi?re >>>>> Hibernate NoORM Team >>>>> yoann at hibernate.org >>>>> >>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>> christian.beikov at gmail.com> >>>>> wrote: >>>>> >>>>> > I don't think someone is actually going to use more than a single DI >>>>> > framework and even if they do, they will probably bridge one way or >>>>> > another between the DI frameworks to be able to access beans from one >>>>> in >>>>> > the other. >>>>> > >>>>> > So I don't think we should do "compositions" since it's not a big deal >>>>> > to integrate different DIs and is also IMO an edge case. I'd prefer >>>>> the >>>>> > package name `org.hibernate.resource.di` since CDI seems to be just >>>>> one >>>>> > of the possible "integrations". >>>>> > >>>>> > >>>>> > Mit freundlichen Gr??en, >>>>> > >>>>> ------------------------------------------------------------------------ >>>>> > *Christian Beikov* >>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and friends are >>>>> mainly >>>>> > > about back porting the work I did on 6.0 for the ManagedBeanRegistry >>>>> > > abstraction over dependency injection containers. We will ship >>>>> support >>>>> > for >>>>> > > CDI as well as non-managed beans (things we directly instantiate). >>>>> Of >>>>> > > course we'd ideally make it easy to plug in other DI containers >>>>> such as >>>>> > > Spring. So I wanted to discuss the configuration of this support. >>>>> > > >>>>> > > The first thing to consider is whether we want to support using >>>>> multiple >>>>> > DI >>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>> application >>>>> > > might want to use both CDI and Spring simultaneously? I started >>>>> building >>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>> implementation, >>>>> > but >>>>> > > stepping back I want to gauge whether that is "reasonable" before >>>>> > > continuing down that path >>>>> > > >>>>> > > Assuming that we do want to support such "compositions" the next >>>>> question >>>>> > > is how we see this being configured. Clearly any time a CDI >>>>> BeanManager >>>>> > is >>>>> > > present during bootstrap we want to enable CDI ManagedBeanRegistry >>>>> > > support. How would users indicate additional ManagedBeanRegistry >>>>> impls >>>>> > be >>>>> > > added to the CompositeManagedBeanRegistry? I have opinions about >>>>> this, >>>>> > but >>>>> > > I'd like to hear other's thoughts... >>>>> > > >>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>> So it >>>>> > > would be possible to completely redefine ManagedBeanRegistry support >>>>> > simply >>>>> > > by replacing that initiator. >>>>> > > >>>>> > > A minor point... notice that the package name here is >>>>> > > `org.hibernate.resource.cdi`, even though one of the goals here is >>>>> to >>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to use a >>>>> different >>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>> > > ``org.hibernate.resource.di`? >>>>> ``org.hibernate.resource.injection`? >>>>> > > Other suggestions? I'm actually ok with >>>>> `org.hibernate.resource.cdi` - >>>>> > imo >>>>> > > "cdi" conveys the proper intent. But if others feel strongly it >>>>> should >>>>> > be >>>>> > > something else, I am open to hearing what and why. >>>>> > > _______________________________________________ >>>>> > > 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 >>>>> > >>>>> _______________________________________________ >>>>> 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 From yoann at hibernate.org Thu Dec 14 09:00:52 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 14 Dec 2017 15:00:52 +0100 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Here is how it should work from what I understand (adapted from an implementation in Search, which has slightly different requirements): static T getBeanInstance(BeanManager beanManager, String beanName, Class contract) { Set> beans = beanManager.getBeans(contract, new NamedQualifier( beanName)); if ( beans.isEmpty() || beans.size() > 1 ) { // TODO proper error messages throw new IllegalArgumentException( "No matching beans or multiple matching beans" ); } Bean bean = beans.iterator().next(); CreationalContext creationalContext = beanManager.createCreationalContext( bean ); return contract.cast( beanManager.getReference( bean, contract, creationalContext ) ); } With NamedQualifier being the implementation I gave before. Sure, let's talk about it later on HipChat. Especially the caching thing, it's really a blocker for Search. I'll be online to travel in about 3 hours, though. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 14 December 2017 at 14:46, Steve Ebersole wrote: > I'll be on HipChat later after I get back from taking my son and daughter > to school. Maybe it is easier to discuss there. > > On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole > wrote: > >> But your answer above does not answer my question ;) >> >> I still have no idea how to go from name+Class -> bean. >> >> >> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere >> wrote: >> >>> Yeah, it was 4AM in France when you asked :) I answered later on >>> HipChat, the answer is basically the one I gave in my email. >>> >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> >>> On 14 December 2017 at 14:38, Steve Ebersole >>> wrote: >>> >>>> WRT to named beans, I asked Guillaume on HipChat what that is supposed >>>> to look like. IIRC he mentioned producers in Paris, but I found no >>>> straight-forward way to get from name+class to a bean. >>>> >>>> He may have answered, I just have not been on HipChat yet today... >>>> >>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole >>>> wrote: >>>> >>>>> Its easier to cleanup >>>>> >>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole >>>>> wrote: >>>>> >>>>>> There are a lot of changes to digest here, but if anyone wanted to >>>>>> take a look at this so far... >>>>>> >>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca1 >>>>>> 0c0d5d2afd73243dc0aa31759e8f5b >>>>>> >>>>>> >>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> Actually my fault. Apparently renaming the package was way too >>>>>>> aggressive and renamed the artifact >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole >>>>>>> wrote: >>>>>>> >>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>> >>>>>>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>>>>>> else, I will plan on supporting just one DI container. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>> yoann at hibernate.org> wrote: >>>>>>>>>> >>>>>>>>>>> Same here, compositions don't seem to be a reasonable use case. >>>>>>>>>>> And even if >>>>>>>>>>> users provide a custom bean registry, they could just implement >>>>>>>>>>> their >>>>>>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>>>>>> implementations on their own and delegate to it however they >>>>>>>>>>> want. >>>>>>>>>>> Overriding the service initiator looks like a very reasonable >>>>>>>>>>> way to do >>>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>>>>>> appropriate to me, since CDI is not the only implementation we >>>>>>>>>>> will get and >>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>> really something >>>>>>>>>>> the bean registry must provide. We could imagine a bean registry >>>>>>>>>>> without >>>>>>>>>>> any support for injection, after all, just providing "monolithic >>>>>>>>>>> beans". It >>>>>>>>>>> would still make sense with respect to your ManagedBeanRegistry >>>>>>>>>>> API. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yoann Rodi?re >>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>> yoann at hibernate.org >>>>>>>>>>> >>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>> christian.beikov at gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>>> single DI >>>>>>>>>>> > framework and even if they do, they will probably bridge one >>>>>>>>>>> way or >>>>>>>>>>> > another between the DI frameworks to be able to access beans >>>>>>>>>>> from one in >>>>>>>>>>> > the other. >>>>>>>>>>> > >>>>>>>>>>> > So I don't think we should do "compositions" since it's not a >>>>>>>>>>> big deal >>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>>>>> prefer the >>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to be >>>>>>>>>>> just one >>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>>>> > ------------------------------------------------------------ >>>>>>>>>>> ------------ >>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>> friends are mainly >>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>> > > abstraction over dependency injection containers. We will >>>>>>>>>>> ship support >>>>>>>>>>> > for >>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>> instantiate). Of >>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>> containers such as >>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>>>> support. >>>>>>>>>>> > > >>>>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>>>> using multiple >>>>>>>>>>> > DI >>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>>>>> application >>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>>> started building >>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>> implementation, >>>>>>>>>>> > but >>>>>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>>>>> before >>>>>>>>>>> > > continuing down that path >>>>>>>>>>> > > >>>>>>>>>>> > > Assuming that we do want to support such "compositions" the >>>>>>>>>>> next question >>>>>>>>>>> > > is how we see this being configured. Clearly any time a CDI >>>>>>>>>>> BeanManager >>>>>>>>>>> > is >>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>> > be >>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>>>>>> about this, >>>>>>>>>>> > but >>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>> > > >>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>>>>> > > via org.hibernate.resource.cdi.spi >>>>>>>>>>> .ManagedBeanRegistryInitiator. So it >>>>>>>>>>> > > would be possible to completely redefine ManagedBeanRegistry >>>>>>>>>>> support >>>>>>>>>>> > simply >>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>> > > >>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals >>>>>>>>>>> here is to >>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to >>>>>>>>>>> use a different >>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>> > imo >>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>> strongly it should >>>>>>>>>>> > be >>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>> > > 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 >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>>> >>> From steve at hibernate.org Thu Dec 14 11:57:13 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 16:57:13 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Yoann, does this approach still need to do the injections (javax.enterprise.inject.spi.InjectionTarget)? On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere wrote: > Here is how it should work from what I understand (adapted from an > implementation in Search, which has slightly different requirements): > > static T getBeanInstance(BeanManager beanManager, String beanName, > Class contract) { > Set> beans = beanManager.getBeans(contract, new NamedQualifier( > beanName)); > if ( beans.isEmpty() || beans.size() > 1 ) { > // TODO proper error messages > throw new IllegalArgumentException( "No matching beans or multiple > matching beans" ); > } > Bean bean = beans.iterator().next(); > CreationalContext creationalContext = > beanManager.createCreationalContext( bean ); > return contract.cast( beanManager.getReference( bean, contract, > creationalContext ) ); > } > > With NamedQualifier being the implementation I gave before. > > Sure, let's talk about it later on HipChat. Especially the caching thing, > it's really a blocker for Search. > > I'll be online to travel in about 3 hours, though. > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 14 December 2017 at 14:46, Steve Ebersole wrote: > >> I'll be on HipChat later after I get back from taking my son and daughter >> to school. Maybe it is easier to discuss there. >> >> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole >> wrote: >> >>> But your answer above does not answer my question ;) >>> >>> I still have no idea how to go from name+Class -> bean. >>> >>> >>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere >>> wrote: >>> >>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>> HipChat, the answer is basically the one I gave in my email. >>>> >>>> Yoann Rodi?re >>>> Hibernate NoORM Team >>>> yoann at hibernate.org >>>> >>>> On 14 December 2017 at 14:38, Steve Ebersole >>>> wrote: >>>> >>>>> WRT to named beans, I asked Guillaume on HipChat what that is supposed >>>>> to look like. IIRC he mentioned producers in Paris, but I found no >>>>> straight-forward way to get from name+class to a bean. >>>>> >>>>> He may have answered, I just have not been on HipChat yet today... >>>>> >>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole >>>>> wrote: >>>>> >>>>>> Its easier to cleanup >>>>>> >>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> There are a lot of changes to digest here, but if anyone wanted to >>>>>>> take a look at this so far... >>>>>>> >>>>>>> >>>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole >>>>>>> wrote: >>>>>>> >>>>>>>> Actually my fault. Apparently renaming the package was way too >>>>>>>> aggressive and renamed the artifact >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>> >>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from anyone >>>>>>>>>>> else, I will plan on supporting just one DI container. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>> yoann at hibernate.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use case. >>>>>>>>>>>> And even if >>>>>>>>>>>> users provide a custom bean registry, they could just implement >>>>>>>>>>>> their >>>>>>>>>>>> specific behavior for a few specific case, then retrieve another >>>>>>>>>>>> implementations on their own and delegate to it however they >>>>>>>>>>>> want. >>>>>>>>>>>> Overriding the service initiator looks like a very reasonable >>>>>>>>>>>> way to do >>>>>>>>>>>> that. >>>>>>>>>>>> >>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more >>>>>>>>>>>> appropriate to me, since CDI is not the only implementation we >>>>>>>>>>>> will get and >>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>> really something >>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>> registry without >>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>> would still make sense with respect to your ManagedBeanRegistry >>>>>>>>>>>> API. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yoann Rodi?re >>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>> yoann at hibernate.org >>>>>>>>>>>> >>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>> christian.beikov at gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>>>> single DI >>>>>>>>>>>> > framework and even if they do, they will probably bridge one >>>>>>>>>>>> way or >>>>>>>>>>>> > another between the DI frameworks to be able to access beans >>>>>>>>>>>> from one in >>>>>>>>>>>> > the other. >>>>>>>>>>>> > >>>>>>>>>>>> > So I don't think we should do "compositions" since it's not a >>>>>>>>>>>> big deal >>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>>>>>> prefer the >>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to >>>>>>>>>>>> be just one >>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>>>>> > >>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>> friends are mainly >>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>> > > abstraction over dependency injection containers. We will >>>>>>>>>>>> ship support >>>>>>>>>>>> > for >>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>> instantiate). Of >>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>> containers such as >>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>>>>> support. >>>>>>>>>>>> > > >>>>>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>>>>> using multiple >>>>>>>>>>>> > DI >>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>>>>>> application >>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>>>> started building >>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>> implementation, >>>>>>>>>>>> > but >>>>>>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>>>>>> before >>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>> > > >>>>>>>>>>>> > > Assuming that we do want to support such "compositions" the >>>>>>>>>>>> next question >>>>>>>>>>>> > > is how we see this being configured. Clearly any time a >>>>>>>>>>>> CDI BeanManager >>>>>>>>>>>> > is >>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>> > be >>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have opinions >>>>>>>>>>>> about this, >>>>>>>>>>>> > but >>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>> > > >>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>>>>>> > > via >>>>>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>> > simply >>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>> > > >>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals >>>>>>>>>>>> here is to >>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to >>>>>>>>>>>> use a different >>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>> > imo >>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>> strongly it should >>>>>>>>>>>> > be >>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>> > > 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 >>>>>>>>>>>> > >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>> >>>>>>>>>>> >>>> > From steve at hibernate.org Thu Dec 14 12:42:11 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 14 Dec 2017 17:42:11 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Here is the commit with initial support for named CDI beans and support for bypassing registry caching of ManagedBeans : https://github.com/hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8c00495d39bca7fb60 There is still a question of whether named beans support needs to do the javax.enterprise.inject.spi.InjectionTarget stuff Christian, I ended up going to "beans" as the package name because this supports non-CDI environments (direct instantiation) too. Not overly a fan of "beans" (overloaded term) but it was a lesser of evils. On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole wrote: > Yoann, does this approach still need to do the injections > (javax.enterprise.inject.spi.InjectionTarget)? > > > On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere wrote: > >> Here is how it should work from what I understand (adapted from an >> implementation in Search, which has slightly different requirements): >> >> static T getBeanInstance(BeanManager beanManager, String beanName, >> Class contract) { >> Set> beans = beanManager.getBeans(contract, new NamedQualifier( >> beanName)); >> if ( beans.isEmpty() || beans.size() > 1 ) { >> // TODO proper error messages >> throw new IllegalArgumentException( "No matching beans or multiple >> matching beans" ); >> } >> Bean bean = beans.iterator().next(); >> CreationalContext creationalContext = >> beanManager.createCreationalContext( bean ); >> return contract.cast( beanManager.getReference( bean, contract, >> creationalContext ) ); >> } >> >> With NamedQualifier being the implementation I gave before. >> >> Sure, let's talk about it later on HipChat. Especially the caching thing, >> it's really a blocker for Search. >> >> I'll be online to travel in about 3 hours, though. >> >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 14 December 2017 at 14:46, Steve Ebersole wrote: >> >>> I'll be on HipChat later after I get back from taking my son and >>> daughter to school. Maybe it is easier to discuss there. >>> >>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole >>> wrote: >>> >>>> But your answer above does not answer my question ;) >>>> >>>> I still have no idea how to go from name+Class -> bean. >>>> >>>> >>>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere >>>> wrote: >>>> >>>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>>> HipChat, the answer is basically the one I gave in my email. >>>>> >>>>> Yoann Rodi?re >>>>> Hibernate NoORM Team >>>>> yoann at hibernate.org >>>>> >>>>> On 14 December 2017 at 14:38, Steve Ebersole >>>>> wrote: >>>>> >>>>>> WRT to named beans, I asked Guillaume on HipChat what that is >>>>>> supposed to look like. IIRC he mentioned producers in Paris, but I found >>>>>> no straight-forward way to get from name+class to a bean. >>>>>> >>>>>> He may have answered, I just have not been on HipChat yet today... >>>>>> >>>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> Its easier to cleanup >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole >>>>>>> wrote: >>>>>>> >>>>>>>> There are a lot of changes to digest here, but if anyone wanted to >>>>>>>> take a look at this so far... >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Actually my fault. Apparently renaming the package was way too >>>>>>>>> aggressive and renamed the artifact >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole < >>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>> >>>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>> >>>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from >>>>>>>>>>>> anyone else, I will plan on supporting just one DI container. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>>> yoann at hibernate.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use >>>>>>>>>>>>> case. And even if >>>>>>>>>>>>> users provide a custom bean registry, they could just >>>>>>>>>>>>> implement their >>>>>>>>>>>>> specific behavior for a few specific case, then retrieve >>>>>>>>>>>>> another >>>>>>>>>>>>> implementations on their own and delegate to it however they >>>>>>>>>>>>> want. >>>>>>>>>>>>> Overriding the service initiator looks like a very reasonable >>>>>>>>>>>>> way to do >>>>>>>>>>>>> that. >>>>>>>>>>>>> >>>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems >>>>>>>>>>>>> more >>>>>>>>>>>>> appropriate to me, since CDI is not the only implementation we >>>>>>>>>>>>> will get and >>>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>>> really something >>>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>>> registry without >>>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>>> would still make sense with respect to your >>>>>>>>>>>>> ManagedBeanRegistry API. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yoann Rodi?re >>>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>>> yoann at hibernate.org >>>>>>>>>>>>> >>>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>>> christian.beikov at gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>>>>> single DI >>>>>>>>>>>>> > framework and even if they do, they will probably bridge one >>>>>>>>>>>>> way or >>>>>>>>>>>>> > another between the DI frameworks to be able to access beans >>>>>>>>>>>>> from one in >>>>>>>>>>>>> > the other. >>>>>>>>>>>>> > >>>>>>>>>>>>> > So I don't think we should do "compositions" since it's not >>>>>>>>>>>>> a big deal >>>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. I'd >>>>>>>>>>>>> prefer the >>>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to >>>>>>>>>>>>> be just one >>>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>>>>>> > >>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>>> friends are mainly >>>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>> > > abstraction over dependency injection containers. We will >>>>>>>>>>>>> ship support >>>>>>>>>>>>> > for >>>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>>> instantiate). Of >>>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>>> containers such as >>>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>>>>>> support. >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>>>>>> using multiple >>>>>>>>>>>>> > DI >>>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that an >>>>>>>>>>>>> application >>>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>>>>> started building >>>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>>> implementation, >>>>>>>>>>>>> > but >>>>>>>>>>>>> > > stepping back I want to gauge whether that is "reasonable" >>>>>>>>>>>>> before >>>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Assuming that we do want to support such "compositions" >>>>>>>>>>>>> the next question >>>>>>>>>>>>> > > is how we see this being configured. Clearly any time a >>>>>>>>>>>>> CDI BeanManager >>>>>>>>>>>>> > is >>>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>>> > be >>>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have >>>>>>>>>>>>> opinions about this, >>>>>>>>>>>>> > but >>>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is initiated >>>>>>>>>>>>> > > via >>>>>>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>>> > simply >>>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the goals >>>>>>>>>>>>> here is to >>>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to >>>>>>>>>>>>> use a different >>>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>>> > imo >>>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>>> strongly it should >>>>>>>>>>>>> > be >>>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>>> > > 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 >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>> >> From steve at hibernate.org Sat Dec 16 11:44:19 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 16 Dec 2017 16:44:19 +0000 Subject: [hibernate-dev] Keeping CI from being confusing. In-Reply-To: References: Message-ID: For the main ORM job I see someone changed the label to "AWS&&Slave", which is obviously different from the "Slave" label you recommended. Basically at this point I am completely lost as to what to use for these labels. Since I did not add this "AWS&&Slave" I am going to leave it alone. For the other ORM jobs, I do see many have the "OS1" label. I can fix those to "Slave". But I have to ask... if "Slave" is the more appropriate value for the vast majority of builds, can't that just be the default? What if we leave off the label? As you say, labels are supposed to indicate that the job "requires such capabilities" as in the capabilities implied by that label. But if a job has no such requirement, why is it a requirement to add any label? On Tue, Dec 12, 2017 at 6:31 AM Sanne Grinovero wrote: > I see many jobs are still explicitly configured to request a build on > slaves tagged as "OS1". > > Please get rid of that: we have no longer any slave running on OS1, > some of the new slaves use the "OS1" label to allow a smooth migration > - but it's a lie and it's been a long time since we removed OS1. > > I will need to eventually cleanup such things, as it's getting messy > and confusing. > > Labels are expected to be used to tag specific slaves to have specific > capabilities, so that some jobs can flag they require such > capabilities. > > Typically the only label you need is "Slave" as we don't want most > jobs to run on the master node. > > An example of a valid label is "HANA" for the job running integration > tests on the HANA database; for obvious reasons this job needs to be > run on the only slave actually having HANA running. > > While at it, if you installed any Jenkins plugin which you no longer > need please remove it. > > General reminder: there's no dedicated team to keep CI or > infrastructure running efficiently, we're all responsible so try to > dedicate it some 20 minutes every month making sure your jobs are > still necessary and configurations are up to date. > For more extensive operations ask Davide or myself and we'll see to help. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Sat Dec 16 13:53:32 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 16 Dec 2017 18:53:32 +0000 Subject: [hibernate-dev] Keeping CI from being confusing. In-Reply-To: References: Message-ID: On 16 December 2017 at 16:44, Steve Ebersole wrote: > For the main ORM job I see someone changed the label to "AWS&&Slave", which > is obviously different from the "Slave" label you recommended. Basically at > this point I am completely lost as to what to use for these labels. We used to have machines on either OS1 or AWS (two different clouds). ORM jobs used to require AWS as only the nodes on AWS have enough memory. Today using "AWS" is fine but not required as all our nodes are on AWS. > > Since I did not add this "AWS&&Slave" I am going to leave it alone. For the > other ORM jobs, I do see many have the "OS1" label. I can fix those to > "Slave". But I have to ask... if "Slave" is the more appropriate value for > the vast majority of builds, can't that just be the default? What if we > leave off the label? As you say, labels are supposed to indicate that the > job "requires such capabilities" as in the capabilities implied by that > label. But if a job has no such requirement, why is it a requirement to add > any label? The machine identified as "Master" actually runs the ci.hibernate.org main service and various other important services (e.g. in.relation.to) so we'd like to keep any non necessary load from it; also it doesn't have all the databases installed which many jobs might need. The only reason it's listed as a node capable to run a CI job at all is that it's useful to keep it available for some specific jobs, specifically we had problems with urgent changes to the website getting stuck in a long and busy build queue; the decision was to allow website publication jobs to be executed directly by the master node. Essentially, it helps with priorities. > > On Tue, Dec 12, 2017 at 6:31 AM Sanne Grinovero wrote: >> >> I see many jobs are still explicitly configured to request a build on >> slaves tagged as "OS1". >> >> Please get rid of that: we have no longer any slave running on OS1, >> some of the new slaves use the "OS1" label to allow a smooth migration >> - but it's a lie and it's been a long time since we removed OS1. >> >> I will need to eventually cleanup such things, as it's getting messy >> and confusing. >> >> Labels are expected to be used to tag specific slaves to have specific >> capabilities, so that some jobs can flag they require such >> capabilities. >> >> Typically the only label you need is "Slave" as we don't want most >> jobs to run on the master node. >> >> An example of a valid label is "HANA" for the job running integration >> tests on the HANA database; for obvious reasons this job needs to be >> run on the only slave actually having HANA running. >> >> While at it, if you installed any Jenkins plugin which you no longer >> need please remove it. >> >> General reminder: there's no dedicated team to keep CI or >> infrastructure running efficiently, we're all responsible so try to >> dedicate it some 20 minutes every month making sure your jobs are >> still necessary and configurations are up to date. >> For more extensive operations ask Davide or myself and we'll see to help. >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Sat Dec 16 14:03:36 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 16 Dec 2017 19:03:36 +0000 Subject: [hibernate-dev] Keeping CI from being confusing. In-Reply-To: References: Message-ID: Perhaps I am just dense here, but I still have no idea what you are expecting me to use as the label for my ORM jobs On Sat, Dec 16, 2017 at 12:53 PM Sanne Grinovero wrote: > On 16 December 2017 at 16:44, Steve Ebersole wrote: > > For the main ORM job I see someone changed the label to "AWS&&Slave", > which > > is obviously different from the "Slave" label you recommended. > Basically at > > this point I am completely lost as to what to use for these labels. > > We used to have machines on either OS1 or AWS (two different clouds). > ORM jobs used to require AWS as only the nodes on AWS have enough > memory. > Today using "AWS" is fine but not required as all our nodes are on AWS. > > > > > Since I did not add this "AWS&&Slave" I am going to leave it alone. For > the > > other ORM jobs, I do see many have the "OS1" label. I can fix those to > > "Slave". But I have to ask... if "Slave" is the more appropriate value > for > > the vast majority of builds, can't that just be the default? What if we > > leave off the label? As you say, labels are supposed to indicate that > the > > job "requires such capabilities" as in the capabilities implied by that > > label. But if a job has no such requirement, why is it a requirement to > add > > any label? > > The machine identified as "Master" actually runs the ci.hibernate.org > main service and various other important services (e.g. > in.relation.to) so we'd like to keep any non necessary load from it; > also it doesn't have all the databases installed which many jobs might > need. > The only reason it's listed as a node capable to run a CI job at all > is that it's useful to keep it available for some specific jobs, > specifically we had problems with urgent changes to the website > getting stuck in a long and busy build queue; the decision was to > allow website publication jobs to be executed directly by the master > node. > Essentially, it helps with priorities. > > > > > On Tue, Dec 12, 2017 at 6:31 AM Sanne Grinovero > wrote: > >> > >> I see many jobs are still explicitly configured to request a build on > >> slaves tagged as "OS1". > >> > >> Please get rid of that: we have no longer any slave running on OS1, > >> some of the new slaves use the "OS1" label to allow a smooth migration > >> - but it's a lie and it's been a long time since we removed OS1. > >> > >> I will need to eventually cleanup such things, as it's getting messy > >> and confusing. > >> > >> Labels are expected to be used to tag specific slaves to have specific > >> capabilities, so that some jobs can flag they require such > >> capabilities. > >> > >> Typically the only label you need is "Slave" as we don't want most > >> jobs to run on the master node. > >> > >> An example of a valid label is "HANA" for the job running integration > >> tests on the HANA database; for obvious reasons this job needs to be > >> run on the only slave actually having HANA running. > >> > >> While at it, if you installed any Jenkins plugin which you no longer > >> need please remove it. > >> > >> General reminder: there's no dedicated team to keep CI or > >> infrastructure running efficiently, we're all responsible so try to > >> dedicate it some 20 minutes every month making sure your jobs are > >> still necessary and configurations are up to date. > >> For more extensive operations ask Davide or myself and we'll see to > help. > >> > >> Thanks, > >> Sanne > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From daltodavide at gmail.com Sun Dec 17 09:18:19 2017 From: daltodavide at gmail.com (Davide D'Alto) Date: Sun, 17 Dec 2017 15:18:19 +0100 Subject: [hibernate-dev] Keeping CI from being confusing. In-Reply-To: References: Message-ID: I think using "Slave" alone might be goo enough. It's generic and in the future, if we have some other different clouds, jobs can use some additional labels to be more specific At the moment, I think the only labels we need are: Master, Slave and HANA On Sat, Dec 16, 2017 at 8:03 PM, Steve Ebersole wrote: > Perhaps I am just dense here, but I still have no idea what you are > expecting me to use as the label for my ORM jobs > > > On Sat, Dec 16, 2017 at 12:53 PM Sanne Grinovero > wrote: > >> On 16 December 2017 at 16:44, Steve Ebersole wrote: >> > For the main ORM job I see someone changed the label to "AWS&&Slave", >> which >> > is obviously different from the "Slave" label you recommended. >> Basically at >> > this point I am completely lost as to what to use for these labels. >> >> We used to have machines on either OS1 or AWS (two different clouds). >> ORM jobs used to require AWS as only the nodes on AWS have enough >> memory. >> Today using "AWS" is fine but not required as all our nodes are on AWS. >> >> > >> > Since I did not add this "AWS&&Slave" I am going to leave it alone. For >> the >> > other ORM jobs, I do see many have the "OS1" label. I can fix those to >> > "Slave". But I have to ask... if "Slave" is the more appropriate value >> for >> > the vast majority of builds, can't that just be the default? What if we >> > leave off the label? As you say, labels are supposed to indicate that >> the >> > job "requires such capabilities" as in the capabilities implied by that >> > label. But if a job has no such requirement, why is it a requirement to >> add >> > any label? >> >> The machine identified as "Master" actually runs the ci.hibernate.org >> main service and various other important services (e.g. >> in.relation.to) so we'd like to keep any non necessary load from it; >> also it doesn't have all the databases installed which many jobs might >> need. >> The only reason it's listed as a node capable to run a CI job at all >> is that it's useful to keep it available for some specific jobs, >> specifically we had problems with urgent changes to the website >> getting stuck in a long and busy build queue; the decision was to >> allow website publication jobs to be executed directly by the master >> node. >> Essentially, it helps with priorities. >> >> > >> > On Tue, Dec 12, 2017 at 6:31 AM Sanne Grinovero >> wrote: >> >> >> >> I see many jobs are still explicitly configured to request a build on >> >> slaves tagged as "OS1". >> >> >> >> Please get rid of that: we have no longer any slave running on OS1, >> >> some of the new slaves use the "OS1" label to allow a smooth migration >> >> - but it's a lie and it's been a long time since we removed OS1. >> >> >> >> I will need to eventually cleanup such things, as it's getting messy >> >> and confusing. >> >> >> >> Labels are expected to be used to tag specific slaves to have specific >> >> capabilities, so that some jobs can flag they require such >> >> capabilities. >> >> >> >> Typically the only label you need is "Slave" as we don't want most >> >> jobs to run on the master node. >> >> >> >> An example of a valid label is "HANA" for the job running integration >> >> tests on the HANA database; for obvious reasons this job needs to be >> >> run on the only slave actually having HANA running. >> >> >> >> While at it, if you installed any Jenkins plugin which you no longer >> >> need please remove it. >> >> >> >> General reminder: there's no dedicated team to keep CI or >> >> infrastructure running efficiently, we're all responsible so try to >> >> dedicate it some 20 minutes every month making sure your jobs are >> >> still necessary and configurations are up to date. >> >> For more extensive operations ask Davide or myself and we'll see to >> help. >> >> >> >> Thanks, >> >> Sanne >> >> _______________________________________________ >> >> 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 From sanne at hibernate.org Sun Dec 17 10:13:00 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Sun, 17 Dec 2017 15:13:00 +0000 Subject: [hibernate-dev] Keeping CI from being confusing. In-Reply-To: References: Message-ID: On 17 December 2017 at 14:18, Davide D'Alto wrote: > I think using "Slave" alone might be goo enough. +1 All jobs should use "Slave" unless there is need for an exception to this rule :) The known exceptions currently are: - the one ORM job which tests using HANA, which should use the "HANA" label - the jobs building websites, which shouldn't need any label. HTH > It's generic and in the future, if we have some other different clouds, > jobs can use some additional labels to be more specific > > At the moment, I think the only labels we need are: Master, Slave and HANA > > On Sat, Dec 16, 2017 at 8:03 PM, Steve Ebersole wrote: >> Perhaps I am just dense here, but I still have no idea what you are >> expecting me to use as the label for my ORM jobs >> >> >> On Sat, Dec 16, 2017 at 12:53 PM Sanne Grinovero >> wrote: >> >>> On 16 December 2017 at 16:44, Steve Ebersole wrote: >>> > For the main ORM job I see someone changed the label to "AWS&&Slave", >>> which >>> > is obviously different from the "Slave" label you recommended. >>> Basically at >>> > this point I am completely lost as to what to use for these labels. >>> >>> We used to have machines on either OS1 or AWS (two different clouds). >>> ORM jobs used to require AWS as only the nodes on AWS have enough >>> memory. >>> Today using "AWS" is fine but not required as all our nodes are on AWS. >>> >>> > >>> > Since I did not add this "AWS&&Slave" I am going to leave it alone. For >>> the >>> > other ORM jobs, I do see many have the "OS1" label. I can fix those to >>> > "Slave". But I have to ask... if "Slave" is the more appropriate value >>> for >>> > the vast majority of builds, can't that just be the default? What if we >>> > leave off the label? As you say, labels are supposed to indicate that >>> the >>> > job "requires such capabilities" as in the capabilities implied by that >>> > label. But if a job has no such requirement, why is it a requirement to >>> add >>> > any label? >>> >>> The machine identified as "Master" actually runs the ci.hibernate.org >>> main service and various other important services (e.g. >>> in.relation.to) so we'd like to keep any non necessary load from it; >>> also it doesn't have all the databases installed which many jobs might >>> need. >>> The only reason it's listed as a node capable to run a CI job at all >>> is that it's useful to keep it available for some specific jobs, >>> specifically we had problems with urgent changes to the website >>> getting stuck in a long and busy build queue; the decision was to >>> allow website publication jobs to be executed directly by the master >>> node. >>> Essentially, it helps with priorities. >>> >>> > >>> > On Tue, Dec 12, 2017 at 6:31 AM Sanne Grinovero >>> wrote: >>> >> >>> >> I see many jobs are still explicitly configured to request a build on >>> >> slaves tagged as "OS1". >>> >> >>> >> Please get rid of that: we have no longer any slave running on OS1, >>> >> some of the new slaves use the "OS1" label to allow a smooth migration >>> >> - but it's a lie and it's been a long time since we removed OS1. >>> >> >>> >> I will need to eventually cleanup such things, as it's getting messy >>> >> and confusing. >>> >> >>> >> Labels are expected to be used to tag specific slaves to have specific >>> >> capabilities, so that some jobs can flag they require such >>> >> capabilities. >>> >> >>> >> Typically the only label you need is "Slave" as we don't want most >>> >> jobs to run on the master node. >>> >> >>> >> An example of a valid label is "HANA" for the job running integration >>> >> tests on the HANA database; for obvious reasons this job needs to be >>> >> run on the only slave actually having HANA running. >>> >> >>> >> While at it, if you installed any Jenkins plugin which you no longer >>> >> need please remove it. >>> >> >>> >> General reminder: there's no dedicated team to keep CI or >>> >> infrastructure running efficiently, we're all responsible so try to >>> >> dedicate it some 20 minutes every month making sure your jobs are >>> >> still necessary and configurations are up to date. >>> >> For more extensive operations ask Davide or myself and we'll see to >>> help. >>> >> >>> >> Thanks, >>> >> Sanne >>> >> _______________________________________________ >>> >> 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 From rory.odonnell at oracle.com Mon Dec 18 05:22:29 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 18 Dec 2017 10:22:29 +0000 Subject: [hibernate-dev] JDK 10 entered Rampdown Phase One on 14th of December Message-ID: <73b26cd1-6aaa-02d9-f1b0-2bc0929bf763@oracle.com> Hi Sanne, *JDK 10 entered Rampdown Phase One on Thursday, 14 December [1] * * The Rampdown Phase One process will be similar to that of JDK 9 [2]. *JDK 10 Early Access? build 36 is available at : - jdk.java.net/10/* Notable changes since previous email. *JEPS included **the last 3 builds:* JDK-8192833 :This is the primary implementation subtask of JEP 322 - *Time-Based Release Versioning* JDK-8189941 : Implementation JEP 312: Thread-local handshake JDK-8186571 : Implementation: JEP 307: Parallel Full GC for G1 JDK-8190308 : Implementation: JEP 316: Heap Allocation on Alternative Memory Devices *build 36 *JDK-8148421 : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension JDK-5016517 : Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent ** *build 35 * JDK-8188870 - Bump classfile version number to 54 JDK-8185985 - HTML files in doc-files subdirectories are wrapped with standard javadoc decorations JDK-8186535 *- *Remove deprecated pre-1.2 SecurityManager methods and fields *build 34* - JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" *Bug fixes reported by Open Source Projects? :* JDK-8191078 : Wrong "Package not found" warning JDK-8191636 : [Windows] jshell tool: Wrong character in /env class-path command crashes jshell JDK-8191834 : Assigning a void expression to a "var" crashes the compiler JDK-8182638 : [macosx] Active modal dialog is hidden by another non-active one JDK-8043315 : Nimbus: Setting Nimbus.Overrides property affects custom keymap installation JDK-8172244 : AIOOBE in KeyStore.getCertificateAlias on Windows JDK-8180141 : Missing entry in LineNumberTable for break statement that jumps out of try-finall JDK 10 Schedule, Status & Features are available [3] *Feedback* - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000357.html [2] http://openjdk.java.net/projects/jdk9/rdp-1 [3] http://openjdk.java.net/projects/jdk/10/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From steve at hibernate.org Mon Dec 18 16:06:57 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 18 Dec 2017 21:06:57 +0000 Subject: [hibernate-dev] HHH-9440 - full instantiation of composites Message-ID: HHH-9440 is re From steve at hibernate.org Mon Dec 18 16:12:57 2017 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 18 Dec 2017 21:12:57 +0000 Subject: [hibernate-dev] HHH-9440 - full instantiation of composites In-Reply-To: References: Message-ID: OK then... HHH-9440 is requesting to allow full instantiation of a composite (i.e. treat its state as final). E.g.: @Embeddable class Name { private final String first; private final String last; public Name(String first, String last) { ... } } I wanted to see what everyone thought of this. Personally I am fine with this, provided: 1. We limit this to composites. The original request wanted entities as well, which I completely disagree with 2. Limit this such that none of the composite's state can be lazy if using this feature. It *can* have lazy associations because that still injects a reference for that attribute Thoughts? On Mon, Dec 18, 2017 at 3:06 PM Steve Ebersole wrote: > HHH-9440 is re > From sanne at hibernate.org Tue Dec 19 04:52:09 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 19 Dec 2017 09:52:09 +0000 Subject: [hibernate-dev] HHH-9440 - full instantiation of composites In-Reply-To: References: Message-ID: Haven't thought it through and I'm possibly not aware of all consequences but I'd be curious to hear more about why you'd be completely in disagreement with having such a feture for any model, inlcuding entities. We have since recently "refential caching" which requires entities to be fully immutable, and also a feature request to have a global option to run the whole SessionFactory in "read only mode". For both cases I'd prefer to see the entities to be mapped as really immutable rather than having to stick to trusting the users about not making changes to them. We could even consider enabling such features as referential caching automatically when we detect the entity to be (really) immutable, that would be a great usability improvement as such performance improvements could be applied without the users having to know about such aspects. Not least it would simply HHH-9440 as people wouldn't need to understand where this can be done or not: another usability win. Thanks, Sanne On 18 December 2017 at 21:12, Steve Ebersole wrote: > OK then... > > HHH-9440 is requesting to allow full instantiation of a composite (i.e. > treat its state as final). E.g.: > > @Embeddable > class Name { > private final String first; > private final String last; > > public Name(String first, String last) { > ... > } > } > > I wanted to see what everyone thought of this. Personally I am fine with > this, provided: > > 1. We limit this to composites. The original request wanted entities as > well, which I completely disagree with > 2. Limit this such that none of the composite's state can be lazy if > using this feature. It *can* have lazy associations because that still > injects a reference for that attribute > > Thoughts? > > On Mon, Dec 18, 2017 at 3:06 PM Steve Ebersole wrote: > >> HHH-9440 is re >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Dec 19 08:24:11 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 19 Dec 2017 13:24:11 +0000 Subject: [hibernate-dev] HHH-9440 - full instantiation of composites In-Reply-To: References: Message-ID: My concern with entities is not so much the full instantiation case... its where I know this goes next - namely requests to allow a mix where some attributes are ctor-injected while others are injected normally. Allowing ctor injection of any persistent state is going to open that window. Also, given the folks that want the "domain driven" approach of allowing injection of services into an entity (which I am much more inclined to consider) during instantiation, how would these 2 mesh? On Tue, Dec 19, 2017 at 3:52 AM Sanne Grinovero wrote: > Haven't thought it through and I'm possibly not aware of all > consequences but I'd be curious to hear more about why you'd be > completely in disagreement with having such a feture for any model, > inlcuding entities. > > We have since recently "refential caching" which requires entities to > be fully immutable, and also a feature request to have a global option > to run the whole SessionFactory in "read only mode". > > For both cases I'd prefer to see the entities to be mapped as really > immutable rather than having to stick to trusting the users about not > making changes to them. > We could even consider enabling such features as referential caching > automatically when we detect the entity to be (really) immutable, that > would be a great usability improvement as such performance > improvements could be applied without the users having to know about > such aspects. > > Not least it would simply HHH-9440 as people wouldn't need to > understand where this can be done or not: another usability win. > > Thanks, > Sanne > > > On 18 December 2017 at 21:12, Steve Ebersole wrote: > > OK then... > > > > HHH-9440 is requesting to allow full instantiation of a composite (i.e. > > treat its state as final). E.g.: > > > > @Embeddable > > class Name { > > private final String first; > > private final String last; > > > > public Name(String first, String last) { > > ... > > } > > } > > > > I wanted to see what everyone thought of this. Personally I am fine with > > this, provided: > > > > 1. We limit this to composites. The original request wanted entities > as > > well, which I completely disagree with > > 2. Limit this such that none of the composite's state can be lazy if > > using this feature. It *can* have lazy associations because that > still > > injects a reference for that attribute > > > > Thoughts? > > > > On Mon, Dec 18, 2017 at 3:06 PM Steve Ebersole > wrote: > > > >> HHH-9440 is re > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Dec 19 08:34:02 2017 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 19 Dec 2017 13:34:02 +0000 Subject: [hibernate-dev] HHH-12172 - Bintray v. OSSRH Message-ID: HHH-12172 is about moving away from the JBoss Nexus repo for publishing our artifacts. There is an open question about which service to use instead - Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory). Personally I think Artifactory is far superior of a UI/platform. We all know Nexus from the JBoss deployment of it, and we have all generally had nothing good to say about it. But I am wondering if anyone has practical experience with either, or knows persons/projects tyay do and could share their experiences. E.g., even though I prefer Bintray in almost every regard, I am very nervous that it seems next to impossible to get help/support with it. The same may be true with OSSRH - I don't know, hence why I am asking ;) From guillaume.smet at gmail.com Tue Dec 19 11:33:44 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 19 Dec 2017 17:33:44 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's IRC meeting: 15:34 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-12-19-14.03.html 15:34 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-12-19-14.03.txt 15:34 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-12-19-14.03.log.html Have a nice day. -- Guillaume From yoann at hibernate.org Wed Dec 20 07:50:35 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 20 Dec 2017 13:50:35 +0100 Subject: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope Message-ID: Hello all, TL;DR: Application-scoped beans cannot be used as part of the @PreDestroy method of ORM-instantiated CDI beans, and it's a bit odd because they can be used as part of the @PostConstruct method. I've been testing the CDI integration in Hibernate ORM for the past few days, trying to integrate it into Search. I think I've discovered something odd: when CDI-managed beans are destroyed, they cannot access other Application-scoped CDI beans anymore. Not sure whether this is a problem or not, so maybe we should discuss it a bit before going forward with the current behavior. Short reminder: scopes define when CDI beans are created and destroyed. @ApplicationScoped is pretty self-explanatory: created when the application starts and destroyed when it stops. Some other scopes are a bit more convoluted: @Singleton basically means created *before* the application starts and destroyed *after* the application stops (and also means "this bean shall not be proxied"), @Dependent means created when an instance is requested and destroyed when the instance is released, etc. The thing is, Hibernate ORM is typically started very early and shut down very late in the CDI lifecycle - at least within WildFly. So when Hibernate starts, CDI Application-scoped beans haven't been instantiated yet, and it turns out that when Hibernate ORM shuts down, CDI has already destroyed Application-scoped beans. Regarding startup, Steve and Scott solved the problem by delaying bean instantiation to some point in the future when the Application scope is active (and thus Application-scoped beans are available). This makes it possible to use Application-scoped beans within ORM-instantiated beans as soon as the latter are constructed (i.e. within their @PostConstruct methods). However, when Hibernate ORM shuts down, the Application scope has already been terminated. So when ORM destroys the beans it instantiated, those ORM-instantiated beans cannot call a method on referenced Application-scoped beans (CDI proxies will throw an exception). All in all, the only type of beans we can currently use in a @PreDestroy method of an ORM-instantiated bean is @Dependent beans. @Singleton beans will work, but only because they are not proxied and thus you can cheat and use them even after they have been destroyed... which I definitely wouldn't recommend. I see two ways to handle the issue: 1. We don't change anything, and simply document somewhere that beans instantiated as part of the CDI integration are instantiated within the Application scope, but are destroyed outside of it. And we suggest that any bean used in @PostDestroy method in an ORM-instantiated bean (directly or not) must have either a @Dependent scope, or a @Singleton scope and no @PostDestroy method. 2. We implement an "early shut-down" somehow, which would bring forward bean destruction to some time when the Application scope is still active. #1 may be enough for now, even though the behavior feels a bit odd, and forces users to resort to less-than-ideal practices (using a @Singleton bean after it has been destroyed). #2 would require changes in WildFly and may be a bit complex. In particular, if we aren't careful, Application-scoped beans may not be able to use Hibernate ORM from within their @PreDestroy methods... Which is probably not a good idea. So we would have to find a solution together with the WildFly team. Also to be considered: Hibernate Search would have to be shut down just before the "early shut-down" of Hibernate ORM occurs, because Hibernate Search cannot function at all without the beans it retrieves from the CDI context. Thoughts? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From guillaume.smet at hibernate.org Wed Dec 20 09:31:16 2017 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Wed, 20 Dec 2017 15:31:16 +0100 Subject: [hibernate-dev] Hibernate Validator 6.0.7.Final released Message-ID: Hi, We just released Hibernate Validator 6.0.7.Final. It adds a new @ISBN constraint and benefits from our latest performance improvements. It is based on the Bean Validation 2.0.1.Final API, which fixes a small regression (that you shouldn't encounter in a standard usage of Bean Validation). Happy holidays to everyone! -- Guillaume From sanne at hibernate.org Wed Dec 20 09:48:54 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 20 Dec 2017 14:48:54 +0000 Subject: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope In-Reply-To: References: Message-ID: Any dependency injection framework will have some capability to define the graph of dependencies across components, and such graph could be very complex, with details only known to the framework. I don't think we can solve the integration by having "before all others" / "after all others" phases as that's too coarse grained to define a full graph; we need to find a way to have the DI framework take in consideration our additional components both in terms of DI consumers and providers - then let the framework wire up things in the order it prefers. This is also to allow the DI engine to print appropriate warnings for un-resolvable situations with its native error handling, which would resolve in more familiar error messages. If that's not doable *or a priority* then all we can do is try to make it clear enough that there will be limitations and hopefully describe these clearly. Some of such limitations might be puzzling as you describe. On 20 December 2017 at 12:50, Yoann Rodiere wrote: > Hello all, > > TL;DR: Application-scoped beans cannot be used as part of the @PreDestroy > method of ORM-instantiated CDI beans, and it's a bit odd because they can > be used as part of the @PostConstruct method. > > I've been testing the CDI integration in Hibernate ORM for the past few > days, trying to integrate it into Search. I think I've discovered something > odd: when CDI-managed beans are destroyed, they cannot access other > Application-scoped CDI beans anymore. Not sure whether this is a problem or > not, so maybe we should discuss it a bit before going forward with the > current behavior. > > Short reminder: scopes define when CDI beans are created and destroyed. > @ApplicationScoped is pretty self-explanatory: created when the application > starts and destroyed when it stops. Some other scopes are a bit more > convoluted: @Singleton basically means created *before* the application > starts and destroyed *after* the application stops (and also means "this > bean shall not be proxied"), @Dependent means created when an instance is > requested and destroyed when the instance is released, etc. > > The thing is, Hibernate ORM is typically started very early and shut down > very late in the CDI lifecycle - at least within WildFly. So when Hibernate > starts, CDI Application-scoped beans haven't been instantiated yet, and it > turns out that when Hibernate ORM shuts down, CDI has already destroyed > Application-scoped beans. > > Regarding startup, Steve and Scott solved the problem by delaying bean > instantiation to some point in the future when the Application scope is > active (and thus Application-scoped beans are available). This makes it > possible to use Application-scoped beans within ORM-instantiated beans as > soon as the latter are constructed (i.e. within their @PostConstruct > methods). > However, when Hibernate ORM shuts down, the Application scope has already > been terminated. So when ORM destroys the beans it instantiated, those > ORM-instantiated beans cannot call a method on referenced > Application-scoped beans (CDI proxies will throw an exception). > > All in all, the only type of beans we can currently use in a @PreDestroy > method of an ORM-instantiated bean is @Dependent beans. @Singleton beans > will work, but only because they are not proxied and thus you can cheat and > use them even after they have been destroyed... which I definitely wouldn't > recommend. > > I see two ways to handle the issue: > > 1. We don't change anything, and simply document somewhere that beans > instantiated as part of the CDI integration are instantiated within the > Application scope, but are destroyed outside of it. And we suggest that any > bean used in @PostDestroy method in an ORM-instantiated bean (directly or > not) must have either a @Dependent scope, or a @Singleton scope and no > @PostDestroy method. > 2. We implement an "early shut-down" somehow, which would bring forward > bean destruction to some time when the Application scope is still active. > > #1 may be enough for now, even though the behavior feels a bit odd, and > forces users to resort to less-than-ideal practices (using a @Singleton > bean after it has been destroyed). > > #2 would require changes in WildFly and may be a bit complex. In > particular, if we aren't careful, Application-scoped beans may not be able > to use Hibernate ORM from within their @PreDestroy methods... Which is > probably not a good idea. So we would have to find a solution together with > the WildFly team. Also to be considered: Hibernate Search would have to be > shut down just before the "early shut-down" of Hibernate ORM occurs, > because Hibernate Search cannot function at all without the beans it > retrieves from the CDI context. > > Thoughts? > > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From yoann at hibernate.org Wed Dec 20 10:08:36 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 20 Dec 2017 16:08:36 +0100 Subject: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope In-Reply-To: References: Message-ID: > we need to find a way to have the DI framework > take in consideration our additional components both in terms of DI > consumers and providers Not sure what you mean by that. Currently the DI framework doesn't know who uses these components, and therefore it's up to us to tell the DI framework when they can be "destroyed". Do you suggest that we make the DI framework aware of the Hibernate ORM => dependency, and let it do what it can to handle that dependency? I know this would work (and probably is already doable without much change) in Spring, because in Spring DI the EntityManagerFactory is viewed as just another type of bean, and therefore its whole lifecycle is already handled by Spring DI. In WildFly though, things are a little bit different: from what I understood, WildFly starts the persistence units (Hibernate ORM) explicitly, and only then it starts the CDI context (Weld). And the opposite when shutting down. The persistence units lifecycle really isn't integrated into CDI... But maybe it should be. In particular the ability to lazily load the persistence units when they are first requested by a CDI bean, and to automatically close a persistence unit when no CDI bean depends on it anymore, would solve a lot of dependency issues. Or at least it would move the problems out of our scope. However, I'm not sure that such behavior would be compatible with all the specs WildFly must comply with. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 20 December 2017 at 15:48, Sanne Grinovero wrote: > Any dependency injection framework will have some capability to define > the graph of dependencies across components, and such graph could be > very complex, with details only known to the framework. > > I don't think we can solve the integration by having "before all > others" / "after all others" phases as that's too coarse grained to > define a full graph; we need to find a way to have the DI framework > take in consideration our additional components both in terms of DI > consumers and providers - then let the framework wire up things in the > order it prefers. This is also to allow the DI engine to print > appropriate warnings for un-resolvable situations with its native > error handling, which would resolve in more familiar error messages. > > If that's not doable *or a priority* then all we can do is try to make > it clear enough that there will be limitations and hopefully describe > these clearly. Some of such limitations might be puzzling as you > describe. > > > > On 20 December 2017 at 12:50, Yoann Rodiere wrote: > > Hello all, > > > > TL;DR: Application-scoped beans cannot be used as part of the @PreDestroy > > method of ORM-instantiated CDI beans, and it's a bit odd because they can > > be used as part of the @PostConstruct method. > > > > I've been testing the CDI integration in Hibernate ORM for the past few > > days, trying to integrate it into Search. I think I've discovered > something > > odd: when CDI-managed beans are destroyed, they cannot access other > > Application-scoped CDI beans anymore. Not sure whether this is a problem > or > > not, so maybe we should discuss it a bit before going forward with the > > current behavior. > > > > Short reminder: scopes define when CDI beans are created and destroyed. > > @ApplicationScoped is pretty self-explanatory: created when the > application > > starts and destroyed when it stops. Some other scopes are a bit more > > convoluted: @Singleton basically means created *before* the application > > starts and destroyed *after* the application stops (and also means "this > > bean shall not be proxied"), @Dependent means created when an instance is > > requested and destroyed when the instance is released, etc. > > > > The thing is, Hibernate ORM is typically started very early and shut down > > very late in the CDI lifecycle - at least within WildFly. So when > Hibernate > > starts, CDI Application-scoped beans haven't been instantiated yet, and > it > > turns out that when Hibernate ORM shuts down, CDI has already destroyed > > Application-scoped beans. > > > > Regarding startup, Steve and Scott solved the problem by delaying bean > > instantiation to some point in the future when the Application scope is > > active (and thus Application-scoped beans are available). This makes it > > possible to use Application-scoped beans within ORM-instantiated beans as > > soon as the latter are constructed (i.e. within their @PostConstruct > > methods). > > However, when Hibernate ORM shuts down, the Application scope has already > > been terminated. So when ORM destroys the beans it instantiated, those > > ORM-instantiated beans cannot call a method on referenced > > Application-scoped beans (CDI proxies will throw an exception). > > > > All in all, the only type of beans we can currently use in a @PreDestroy > > method of an ORM-instantiated bean is @Dependent beans. @Singleton beans > > will work, but only because they are not proxied and thus you can cheat > and > > use them even after they have been destroyed... which I definitely > wouldn't > > recommend. > > > > I see two ways to handle the issue: > > > > 1. We don't change anything, and simply document somewhere that beans > > instantiated as part of the CDI integration are instantiated within > the > > Application scope, but are destroyed outside of it. And we suggest > that any > > bean used in @PostDestroy method in an ORM-instantiated bean > (directly or > > not) must have either a @Dependent scope, or a @Singleton scope and no > > @PostDestroy method. > > 2. We implement an "early shut-down" somehow, which would bring > forward > > bean destruction to some time when the Application scope is still > active. > > > > #1 may be enough for now, even though the behavior feels a bit odd, and > > forces users to resort to less-than-ideal practices (using a @Singleton > > bean after it has been destroyed). > > > > #2 would require changes in WildFly and may be a bit complex. In > > particular, if we aren't careful, Application-scoped beans may not be > able > > to use Hibernate ORM from within their @PreDestroy methods... Which is > > probably not a good idea. So we would have to find a solution together > with > > the WildFly team. Also to be considered: Hibernate Search would have to > be > > shut down just before the "early shut-down" of Hibernate ORM occurs, > > because Hibernate Search cannot function at all without the beans it > > retrieves from the CDI context. > > > > Thoughts? > > > > > > Yoann Rodi?re > > Hibernate NoORM Team > > yoann at hibernate.org > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Dec 20 10:20:09 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 20 Dec 2017 15:20:09 +0000 Subject: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope In-Reply-To: References: Message-ID: On 20 December 2017 at 15:08, Yoann Rodiere wrote: >> we need to find a way to have the DI framework >> take in consideration our additional components both in terms of DI >> consumers and providers > > Not sure what you mean by that. Currently the DI framework doesn't know who > uses these components, and therefore it's up to us to tell the DI framework > when they can be "destroyed". > Do you suggest that we make the DI framework aware of the Hibernate ORM => > dependency, and let it do what it can to handle that > dependency? Right > I know this would work (and probably is already doable without much change) > in Spring, because in Spring DI the EntityManagerFactory is viewed as just > another type of bean, and therefore its whole lifecycle is already handled > by Spring DI. > In WildFly though, things are a little bit different: from what I > understood, WildFly starts the persistence units (Hibernate ORM) explicitly, > and only then it starts the CDI context (Weld). And the opposite when > shutting down. The persistence units lifecycle really isn't integrated into > CDI... But maybe it should be. In particular the ability to lazily load the > persistence units when they are first requested by a CDI bean, and to > automatically close a persistence unit when no CDI bean depends on it > anymore, would solve a lot of dependency issues. Or at least it would move > the problems out of our scope. > However, I'm not sure that such behavior would be compatible with all the > specs WildFly must comply with. If WildFly does it like that there are consequences that I don't think we should try to work around; as I said before having a "global" before/after phase is not granular enough to be able to define a full graph. If we go for the workaround - there will have to be limitations to what we can do. So either we - and our users - will have to live with such limitations or we (eventually) figure out how to do the better integration. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 20 December 2017 at 15:48, Sanne Grinovero wrote: >> >> Any dependency injection framework will have some capability to define >> the graph of dependencies across components, and such graph could be >> very complex, with details only known to the framework. >> >> I don't think we can solve the integration by having "before all >> others" / "after all others" phases as that's too coarse grained to >> define a full graph; we need to find a way to have the DI framework >> take in consideration our additional components both in terms of DI >> consumers and providers - then let the framework wire up things in the >> order it prefers. This is also to allow the DI engine to print >> appropriate warnings for un-resolvable situations with its native >> error handling, which would resolve in more familiar error messages. >> >> If that's not doable *or a priority* then all we can do is try to make >> it clear enough that there will be limitations and hopefully describe >> these clearly. Some of such limitations might be puzzling as you >> describe. >> >> >> >> On 20 December 2017 at 12:50, Yoann Rodiere wrote: >> > Hello all, >> > >> > TL;DR: Application-scoped beans cannot be used as part of the >> > @PreDestroy >> > method of ORM-instantiated CDI beans, and it's a bit odd because they >> > can >> > be used as part of the @PostConstruct method. >> > >> > I've been testing the CDI integration in Hibernate ORM for the past few >> > days, trying to integrate it into Search. I think I've discovered >> > something >> > odd: when CDI-managed beans are destroyed, they cannot access other >> > Application-scoped CDI beans anymore. Not sure whether this is a problem >> > or >> > not, so maybe we should discuss it a bit before going forward with the >> > current behavior. >> > >> > Short reminder: scopes define when CDI beans are created and destroyed. >> > @ApplicationScoped is pretty self-explanatory: created when the >> > application >> > starts and destroyed when it stops. Some other scopes are a bit more >> > convoluted: @Singleton basically means created *before* the application >> > starts and destroyed *after* the application stops (and also means "this >> > bean shall not be proxied"), @Dependent means created when an instance >> > is >> > requested and destroyed when the instance is released, etc. >> > >> > The thing is, Hibernate ORM is typically started very early and shut >> > down >> > very late in the CDI lifecycle - at least within WildFly. So when >> > Hibernate >> > starts, CDI Application-scoped beans haven't been instantiated yet, and >> > it >> > turns out that when Hibernate ORM shuts down, CDI has already destroyed >> > Application-scoped beans. >> > >> > Regarding startup, Steve and Scott solved the problem by delaying bean >> > instantiation to some point in the future when the Application scope is >> > active (and thus Application-scoped beans are available). This makes it >> > possible to use Application-scoped beans within ORM-instantiated beans >> > as >> > soon as the latter are constructed (i.e. within their @PostConstruct >> > methods). >> > However, when Hibernate ORM shuts down, the Application scope has >> > already >> > been terminated. So when ORM destroys the beans it instantiated, those >> > ORM-instantiated beans cannot call a method on referenced >> > Application-scoped beans (CDI proxies will throw an exception). >> > >> > All in all, the only type of beans we can currently use in a @PreDestroy >> > method of an ORM-instantiated bean is @Dependent beans. @Singleton beans >> > will work, but only because they are not proxied and thus you can cheat >> > and >> > use them even after they have been destroyed... which I definitely >> > wouldn't >> > recommend. >> > >> > I see two ways to handle the issue: >> > >> > 1. We don't change anything, and simply document somewhere that beans >> > instantiated as part of the CDI integration are instantiated within >> > the >> > Application scope, but are destroyed outside of it. And we suggest >> > that any >> > bean used in @PostDestroy method in an ORM-instantiated bean >> > (directly or >> > not) must have either a @Dependent scope, or a @Singleton scope and >> > no >> > @PostDestroy method. >> > 2. We implement an "early shut-down" somehow, which would bring >> > forward >> > bean destruction to some time when the Application scope is still >> > active. >> > >> > #1 may be enough for now, even though the behavior feels a bit odd, and >> > forces users to resort to less-than-ideal practices (using a @Singleton >> > bean after it has been destroyed). >> > >> > #2 would require changes in WildFly and may be a bit complex. In >> > particular, if we aren't careful, Application-scoped beans may not be >> > able >> > to use Hibernate ORM from within their @PreDestroy methods... Which is >> > probably not a good idea. So we would have to find a solution together >> > with >> > the WildFly team. Also to be considered: Hibernate Search would have to >> > be >> > shut down just before the "early shut-down" of Hibernate ORM occurs, >> > because Hibernate Search cannot function at all without the beans it >> > retrieves from the CDI context. >> > >> > Thoughts? >> > >> > >> > Yoann Rodi?re >> > Hibernate NoORM Team >> > yoann at hibernate.org >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From gunnar at hibernate.org Wed Dec 20 16:47:30 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 20 Dec 2017 22:47:30 +0100 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules Message-ID: Hi all, Following to our discussion in Paris, I've created a simple test bed for showing the usage of Hibernate ORM and its dependencies as automatic modules for the Java 9 module system: https://github.com/gunnarmorling/hibernate-orm-on-java9-modules It pretty much works as expected, I couldn't reproduce the classloader issue I was mentioning during the meeting. A few things worth noting: * 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) * 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 See https://github.com/gunnarmorling/hibernate-orm-on-java9-modules/blob/master/src/main/java/com/example/Main.java for the actual test, which is run using the module path only (i.e. no classpath). A few things caught my attention: * 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?). * 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. * 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. 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 :) Cheers, --Gunnar From mihalcea.vlad at gmail.com Thu Dec 21 02:11:27 2017 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 21 Dec 2017 09:11:27 +0200 Subject: [hibernate-dev] Locking German and French forums Message-ID: Hi, I'm going to lock the German and French forums since users posts question there from time to time, and the questions remain answered. If someone has anything against it, let me know. Otherwise, we should use the English one until we move to Discourse. Vlad From yoann at hibernate.org Thu Dec 21 03:53:07 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 21 Dec 2017 09:53:07 +0100 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Hi, Following our conversations on HipChat and the various changes you implemented (thanks!), I tested the current implementation. There were a few issues, but I managed to fix them and make all the tests in Hibernate Search pass. Here is a PR with the fixes: https://github.com/hibernate/hibernate-orm/pull/2092 Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 14 December 2017 at 18:42, Steve Ebersole wrote: > Here is the commit with initial support for named CDI beans and support > for bypassing registry caching of ManagedBeans : https://github.com/ > hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8c00495d39bca7fb60 > > There is still a question of whether named beans support needs to do > the javax.enterprise.inject.spi.InjectionTarget stuff > > Christian, I ended up going to "beans" as the package name because this > supports non-CDI environments (direct instantiation) too. Not overly a fan > of "beans" (overloaded term) but it was a lesser of evils. > > On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole > wrote: > >> Yoann, does this approach still need to do the injections >> (javax.enterprise.inject.spi.InjectionTarget)? >> >> >> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere >> wrote: >> >>> Here is how it should work from what I understand (adapted from an >>> implementation in Search, which has slightly different requirements): >>> >>> static T getBeanInstance(BeanManager beanManager, String beanName, >>> Class contract) { >>> Set> beans = beanManager.getBeans(contract, new NamedQualifier( >>> beanName)); >>> if ( beans.isEmpty() || beans.size() > 1 ) { >>> // TODO proper error messages >>> throw new IllegalArgumentException( "No matching beans or multiple >>> matching beans" ); >>> } >>> Bean bean = beans.iterator().next(); >>> CreationalContext creationalContext = beanManager.createCreationalContext( >>> bean ); >>> return contract.cast( beanManager.getReference( bean, contract, >>> creationalContext ) ); >>> } >>> >>> With NamedQualifier being the implementation I gave before. >>> >>> Sure, let's talk about it later on HipChat. Especially the caching >>> thing, it's really a blocker for Search. >>> >>> I'll be online to travel in about 3 hours, though. >>> >>> >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> >>> On 14 December 2017 at 14:46, Steve Ebersole >>> wrote: >>> >>>> I'll be on HipChat later after I get back from taking my son and >>>> daughter to school. Maybe it is easier to discuss there. >>>> >>>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole >>>> wrote: >>>> >>>>> But your answer above does not answer my question ;) >>>>> >>>>> I still have no idea how to go from name+Class -> bean. >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere >>>>> wrote: >>>>> >>>>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>>>> HipChat, the answer is basically the one I gave in my email. >>>>>> >>>>>> Yoann Rodi?re >>>>>> Hibernate NoORM Team >>>>>> yoann at hibernate.org >>>>>> >>>>>> On 14 December 2017 at 14:38, Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> WRT to named beans, I asked Guillaume on HipChat what that is >>>>>>> supposed to look like. IIRC he mentioned producers in Paris, but I found >>>>>>> no straight-forward way to get from name+class to a bean. >>>>>>> >>>>>>> He may have answered, I just have not been on HipChat yet today... >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole >>>>>>> wrote: >>>>>>> >>>>>>>> Its easier to cleanup >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole >>>>>>>> wrote: >>>>>>>> >>>>>>>>> There are a lot of changes to digest here, but if anyone wanted to >>>>>>>>> take a look at this so far... >>>>>>>>> >>>>>>>>> https://github.com/hibernate/hibernate-orm/commit/ >>>>>>>>> 564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole < >>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>> >>>>>>>>>> Actually my fault. Apparently renaming the package was way too >>>>>>>>>> aggressive and renamed the artifact >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole < >>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>> >>>>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from >>>>>>>>>>>>> anyone else, I will plan on supporting just one DI container. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>>>> yoann at hibernate.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use >>>>>>>>>>>>>> case. And even if >>>>>>>>>>>>>> users provide a custom bean registry, they could just >>>>>>>>>>>>>> implement their >>>>>>>>>>>>>> specific behavior for a few specific case, then retrieve >>>>>>>>>>>>>> another >>>>>>>>>>>>>> implementations on their own and delegate to it however they >>>>>>>>>>>>>> want. >>>>>>>>>>>>>> Overriding the service initiator looks like a very reasonable >>>>>>>>>>>>>> way to do >>>>>>>>>>>>>> that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems >>>>>>>>>>>>>> more >>>>>>>>>>>>>> appropriate to me, since CDI is not the only implementation >>>>>>>>>>>>>> we will get and >>>>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>>>> really something >>>>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>>>> registry without >>>>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>>>> would still make sense with respect to your >>>>>>>>>>>>>> ManagedBeanRegistry API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yoann Rodi?re >>>>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>>>> yoann at hibernate.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>>>> christian.beikov at gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>>>>>> single DI >>>>>>>>>>>>>> > framework and even if they do, they will probably bridge >>>>>>>>>>>>>> one way or >>>>>>>>>>>>>> > another between the DI frameworks to be able to access >>>>>>>>>>>>>> beans from one in >>>>>>>>>>>>>> > the other. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > So I don't think we should do "compositions" since it's not >>>>>>>>>>>>>> a big deal >>>>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. >>>>>>>>>>>>>> I'd prefer the >>>>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems to >>>>>>>>>>>>>> be just one >>>>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>>>>>>> > ------------------------------ >>>>>>>>>>>>>> ------------------------------------------ >>>>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>>>> friends are mainly >>>>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>> > > abstraction over dependency injection containers. We >>>>>>>>>>>>>> will ship support >>>>>>>>>>>>>> > for >>>>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>>>> instantiate). Of >>>>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>>>> containers such as >>>>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of this >>>>>>>>>>>>>> support. >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > The first thing to consider is whether we want to support >>>>>>>>>>>>>> using multiple >>>>>>>>>>>>>> > DI >>>>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that >>>>>>>>>>>>>> an application >>>>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>>>>>> started building >>>>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>>>> implementation, >>>>>>>>>>>>>> > but >>>>>>>>>>>>>> > > stepping back I want to gauge whether that is >>>>>>>>>>>>>> "reasonable" before >>>>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > Assuming that we do want to support such "compositions" >>>>>>>>>>>>>> the next question >>>>>>>>>>>>>> > > is how we see this being configured. Clearly any time a >>>>>>>>>>>>>> CDI BeanManager >>>>>>>>>>>>>> > is >>>>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>>>> > be >>>>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have >>>>>>>>>>>>>> opinions about this, >>>>>>>>>>>>>> > but >>>>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is >>>>>>>>>>>>>> initiated >>>>>>>>>>>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>>>>>>>>>>> So it >>>>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>>>> > simply >>>>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the >>>>>>>>>>>>>> goals here is to >>>>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want to >>>>>>>>>>>>>> use a different >>>>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>>>> > imo >>>>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>>>> strongly it should >>>>>>>>>>>>>> > be >>>>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>>>> > > 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 >>>>>>>>>>>>>> > >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>> From steve at hibernate.org Thu Dec 21 10:36:50 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 21 Dec 2017 15:36:50 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Awesome! Glad it worked out. However, I do think that there is still a need to expand the proposal Scott and I want to make to the CDI spec wrt something like our ExtendedBeanManager to also account for the shutdown phase. In addition to knowing when the BeanManager is ready to use, it would be nice to know when the BeanManager is ready to shutdown (a before shutdown hook). At that point we could begin cleaning up our CreationalContext, etc refs. Scott, do you already have enough insight into that in WildFly for us to go ahead and do that in our integration today? On Thu, Dec 21, 2017, 1:53 AM Yoann Rodiere wrote: > Hi, > > Following our conversations on HipChat and the various changes you > implemented (thanks!), I tested the current implementation. There were a > few issues, but I managed to fix them and make all the tests in Hibernate > Search pass. > Here is a PR with the fixes: > https://github.com/hibernate/hibernate-orm/pull/2092 > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 14 December 2017 at 18:42, Steve Ebersole wrote: > >> Here is the commit with initial support for named CDI beans and support >> for bypassing registry caching of ManagedBeans : >> https://github.com/hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8c00495d39bca7fb60 >> >> There is still a question of whether named beans support needs to do >> the javax.enterprise.inject.spi.InjectionTarget stuff >> >> Christian, I ended up going to "beans" as the package name because this >> supports non-CDI environments (direct instantiation) too. Not overly a fan >> of "beans" (overloaded term) but it was a lesser of evils. >> >> On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole >> wrote: >> >>> Yoann, does this approach still need to do the injections >>> (javax.enterprise.inject.spi.InjectionTarget)? >>> >>> >>> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere >>> wrote: >>> >>>> Here is how it should work from what I understand (adapted from an >>>> implementation in Search, which has slightly different requirements): >>>> >>>> static T getBeanInstance(BeanManager beanManager, String beanName, >>>> Class contract) { >>>> Set> beans = beanManager.getBeans(contract, new NamedQualifier( >>>> beanName)); >>>> if ( beans.isEmpty() || beans.size() > 1 ) { >>>> // TODO proper error messages >>>> throw new IllegalArgumentException( "No matching beans or multiple >>>> matching beans" ); >>>> } >>>> Bean bean = beans.iterator().next(); >>>> CreationalContext creationalContext = >>>> beanManager.createCreationalContext( bean ); >>>> return contract.cast( beanManager.getReference( bean, contract, >>>> creationalContext ) ); >>>> } >>>> >>>> With NamedQualifier being the implementation I gave before. >>>> >>>> Sure, let's talk about it later on HipChat. Especially the caching >>>> thing, it's really a blocker for Search. >>>> >>>> I'll be online to travel in about 3 hours, though. >>>> >>>> >>>> Yoann Rodi?re >>>> Hibernate NoORM Team >>>> yoann at hibernate.org >>>> >>>> On 14 December 2017 at 14:46, Steve Ebersole >>>> wrote: >>>> >>>>> I'll be on HipChat later after I get back from taking my son and >>>>> daughter to school. Maybe it is easier to discuss there. >>>>> >>>>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole >>>>> wrote: >>>>> >>>>>> But your answer above does not answer my question ;) >>>>>> >>>>>> I still have no idea how to go from name+Class -> bean. >>>>>> >>>>>> >>>>>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere >>>>>> wrote: >>>>>> >>>>>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>>>>> HipChat, the answer is basically the one I gave in my email. >>>>>>> >>>>>>> Yoann Rodi?re >>>>>>> Hibernate NoORM Team >>>>>>> yoann at hibernate.org >>>>>>> >>>>>>> On 14 December 2017 at 14:38, Steve Ebersole >>>>>>> wrote: >>>>>>> >>>>>>>> WRT to named beans, I asked Guillaume on HipChat what that is >>>>>>>> supposed to look like. IIRC he mentioned producers in Paris, but I found >>>>>>>> no straight-forward way to get from name+class to a bean. >>>>>>>> >>>>>>>> He may have answered, I just have not been on HipChat yet today... >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Its easier to cleanup >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole < >>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>> >>>>>>>>>> There are a lot of changes to digest here, but if anyone wanted >>>>>>>>>> to take a look at this so far... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole < >>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>> >>>>>>>>>>> Actually my fault. Apparently renaming the package was way too >>>>>>>>>>> aggressive and renamed the artifact >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole < >>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from >>>>>>>>>>>>>> anyone else, I will plan on supporting just one DI container. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>>>>> yoann at hibernate.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use >>>>>>>>>>>>>>> case. And even if >>>>>>>>>>>>>>> users provide a custom bean registry, they could just >>>>>>>>>>>>>>> implement their >>>>>>>>>>>>>>> specific behavior for a few specific case, then retrieve >>>>>>>>>>>>>>> another >>>>>>>>>>>>>>> implementations on their own and delegate to it however they >>>>>>>>>>>>>>> want. >>>>>>>>>>>>>>> Overriding the service initiator looks like a very >>>>>>>>>>>>>>> reasonable way to do >>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems >>>>>>>>>>>>>>> more >>>>>>>>>>>>>>> appropriate to me, since CDI is not the only implementation >>>>>>>>>>>>>>> we will get and >>>>>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>>>>> really something >>>>>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>>>>> registry without >>>>>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>>>>> would still make sense with respect to your >>>>>>>>>>>>>>> ManagedBeanRegistry API. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yoann Rodi?re >>>>>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>>>>> yoann at hibernate.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>>>>> christian.beikov at gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > I don't think someone is actually going to use more than a >>>>>>>>>>>>>>> single DI >>>>>>>>>>>>>>> > framework and even if they do, they will probably bridge >>>>>>>>>>>>>>> one way or >>>>>>>>>>>>>>> > another between the DI frameworks to be able to access >>>>>>>>>>>>>>> beans from one in >>>>>>>>>>>>>>> > the other. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > So I don't think we should do "compositions" since it's >>>>>>>>>>>>>>> not a big deal >>>>>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. >>>>>>>>>>>>>>> I'd prefer the >>>>>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems >>>>>>>>>>>>>>> to be just one >>>>>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>>>>> friends are mainly >>>>>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>>> > > abstraction over dependency injection containers. We >>>>>>>>>>>>>>> will ship support >>>>>>>>>>>>>>> > for >>>>>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>>>>> instantiate). Of >>>>>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>>>>> containers such as >>>>>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of >>>>>>>>>>>>>>> this support. >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > The first thing to consider is whether we want to >>>>>>>>>>>>>>> support using multiple >>>>>>>>>>>>>>> > DI >>>>>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that >>>>>>>>>>>>>>> an application >>>>>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? I >>>>>>>>>>>>>>> started building >>>>>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>>>>> implementation, >>>>>>>>>>>>>>> > but >>>>>>>>>>>>>>> > > stepping back I want to gauge whether that is >>>>>>>>>>>>>>> "reasonable" before >>>>>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > Assuming that we do want to support such "compositions" >>>>>>>>>>>>>>> the next question >>>>>>>>>>>>>>> > > is how we see this being configured. Clearly any time a >>>>>>>>>>>>>>> CDI BeanManager >>>>>>>>>>>>>>> > is >>>>>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have >>>>>>>>>>>>>>> opinions about this, >>>>>>>>>>>>>>> > but >>>>>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is >>>>>>>>>>>>>>> initiated >>>>>>>>>>>>>>> > > via >>>>>>>>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>>>>> > simply >>>>>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the >>>>>>>>>>>>>>> goals here is to >>>>>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want >>>>>>>>>>>>>>> to use a different >>>>>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>>>>> > imo >>>>>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>>>>> strongly it should >>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>>>>> > > 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 >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>> > From yoann at hibernate.org Thu Dec 21 10:41:39 2017 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 21 Dec 2017 16:41:39 +0100 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: > However, I do think that there is still a need to expand the proposal Scott and I want to make to the CDI spec wrt something like our ExtendedBeanManager to also account for the shutdown phase +1, I sent an email about just that on the mailing list. There are some drawbacks to this approach though, and Sanne suggested deeper integration into CDI would be a more future-proof path. The subject of this thread was "CDI integration in Hibernate ORM and the Application scope". Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On 21 December 2017 at 16:36, Steve Ebersole wrote: > Awesome! Glad it worked out. > > However, I do think that there is still a need to expand the proposal > Scott and I want to make to the CDI spec wrt something like our > ExtendedBeanManager to also account for the shutdown phase. In addition to > knowing when the BeanManager is ready to use, it would be nice to know when > the BeanManager is ready to shutdown (a before shutdown hook). At that > point we could begin cleaning up our CreationalContext, etc refs. > > Scott, do you already have enough insight into that in WildFly for us to > go ahead and do that in our integration today? > > On Thu, Dec 21, 2017, 1:53 AM Yoann Rodiere wrote: > >> Hi, >> >> Following our conversations on HipChat and the various changes you >> implemented (thanks!), I tested the current implementation. There were a >> few issues, but I managed to fix them and make all the tests in Hibernate >> Search pass. >> Here is a PR with the fixes: https://github.com/ >> hibernate/hibernate-orm/pull/2092 >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> On 14 December 2017 at 18:42, Steve Ebersole wrote: >> >>> Here is the commit with initial support for named CDI beans and support >>> for bypassing registry caching of ManagedBeans : https://github.com/ >>> hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8c00495d39bca7fb60 >>> >>> There is still a question of whether named beans support needs to do >>> the javax.enterprise.inject.spi.InjectionTarget stuff >>> >>> Christian, I ended up going to "beans" as the package name because this >>> supports non-CDI environments (direct instantiation) too. Not overly a fan >>> of "beans" (overloaded term) but it was a lesser of evils. >>> >>> On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole >>> wrote: >>> >>>> Yoann, does this approach still need to do the injections >>>> (javax.enterprise.inject.spi.InjectionTarget)? >>>> >>>> >>>> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere >>>> wrote: >>>> >>>>> Here is how it should work from what I understand (adapted from an >>>>> implementation in Search, which has slightly different requirements): >>>>> >>>>> static T getBeanInstance(BeanManager beanManager, String beanName, >>>>> Class contract) { >>>>> Set> beans = beanManager.getBeans(contract, new >>>>> NamedQualifier(beanName)); >>>>> if ( beans.isEmpty() || beans.size() > 1 ) { >>>>> // TODO proper error messages >>>>> throw new IllegalArgumentException( "No matching beans or multiple >>>>> matching beans" ); >>>>> } >>>>> Bean bean = beans.iterator().next(); >>>>> CreationalContext creationalContext = beanManager.createCreationalContext( >>>>> bean ); >>>>> return contract.cast( beanManager.getReference( bean, contract, >>>>> creationalContext ) ); >>>>> } >>>>> >>>>> With NamedQualifier being the implementation I gave before. >>>>> >>>>> Sure, let's talk about it later on HipChat. Especially the caching >>>>> thing, it's really a blocker for Search. >>>>> >>>>> I'll be online to travel in about 3 hours, though. >>>>> >>>>> >>>>> Yoann Rodi?re >>>>> Hibernate NoORM Team >>>>> yoann at hibernate.org >>>>> >>>>> On 14 December 2017 at 14:46, Steve Ebersole >>>>> wrote: >>>>> >>>>>> I'll be on HipChat later after I get back from taking my son and >>>>>> daughter to school. Maybe it is easier to discuss there. >>>>>> >>>>>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> But your answer above does not answer my question ;) >>>>>>> >>>>>>> I still have no idea how to go from name+Class -> bean. >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere >>>>>>> wrote: >>>>>>> >>>>>>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>>>>>> HipChat, the answer is basically the one I gave in my email. >>>>>>>> >>>>>>>> Yoann Rodi?re >>>>>>>> Hibernate NoORM Team >>>>>>>> yoann at hibernate.org >>>>>>>> >>>>>>>> On 14 December 2017 at 14:38, Steve Ebersole >>>>>>>> wrote: >>>>>>>> >>>>>>>>> WRT to named beans, I asked Guillaume on HipChat what that is >>>>>>>>> supposed to look like. IIRC he mentioned producers in Paris, but I found >>>>>>>>> no straight-forward way to get from name+class to a bean. >>>>>>>>> >>>>>>>>> He may have answered, I just have not been on HipChat yet today... >>>>>>>>> >>>>>>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole < >>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>> >>>>>>>>>> Its easier to cleanup >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole < >>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>> >>>>>>>>>>> There are a lot of changes to digest here, but if anyone wanted >>>>>>>>>>> to take a look at this so far... >>>>>>>>>>> >>>>>>>>>>> https://github.com/hibernate/hibernate-orm/commit/ >>>>>>>>>>> 564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole < >>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Actually my fault. Apparently renaming the package was way too >>>>>>>>>>>> aggressive and renamed the artifact >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole < >>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from >>>>>>>>>>>>>>> anyone else, I will plan on supporting just one DI container. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>>>>>> yoann at hibernate.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use >>>>>>>>>>>>>>>> case. And even if >>>>>>>>>>>>>>>> users provide a custom bean registry, they could just >>>>>>>>>>>>>>>> implement their >>>>>>>>>>>>>>>> specific behavior for a few specific case, then retrieve >>>>>>>>>>>>>>>> another >>>>>>>>>>>>>>>> implementations on their own and delegate to it however >>>>>>>>>>>>>>>> they want. >>>>>>>>>>>>>>>> Overriding the service initiator looks like a very >>>>>>>>>>>>>>>> reasonable way to do >>>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems >>>>>>>>>>>>>>>> more >>>>>>>>>>>>>>>> appropriate to me, since CDI is not the only implementation >>>>>>>>>>>>>>>> we will get and >>>>>>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>>>>>> really something >>>>>>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>>>>>> registry without >>>>>>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>>>>>> would still make sense with respect to your >>>>>>>>>>>>>>>> ManagedBeanRegistry API. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yoann Rodi?re >>>>>>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>>>>>> yoann at hibernate.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>>>>>> christian.beikov at gmail.com> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > I don't think someone is actually going to use more than >>>>>>>>>>>>>>>> a single DI >>>>>>>>>>>>>>>> > framework and even if they do, they will probably bridge >>>>>>>>>>>>>>>> one way or >>>>>>>>>>>>>>>> > another between the DI frameworks to be able to access >>>>>>>>>>>>>>>> beans from one in >>>>>>>>>>>>>>>> > the other. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > So I don't think we should do "compositions" since it's >>>>>>>>>>>>>>>> not a big deal >>>>>>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. >>>>>>>>>>>>>>>> I'd prefer the >>>>>>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems >>>>>>>>>>>>>>>> to be just one >>>>>>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>>>>>>>>> > ------------------------------ >>>>>>>>>>>>>>>> ------------------------------------------ >>>>>>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>>>>>> friends are mainly >>>>>>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>>>> > > abstraction over dependency injection containers. We >>>>>>>>>>>>>>>> will ship support >>>>>>>>>>>>>>>> > for >>>>>>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>>>>>> instantiate). Of >>>>>>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>>>>>> containers such as >>>>>>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of >>>>>>>>>>>>>>>> this support. >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > The first thing to consider is whether we want to >>>>>>>>>>>>>>>> support using multiple >>>>>>>>>>>>>>>> > DI >>>>>>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable that >>>>>>>>>>>>>>>> an application >>>>>>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? >>>>>>>>>>>>>>>> I started building >>>>>>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>>>>>> implementation, >>>>>>>>>>>>>>>> > but >>>>>>>>>>>>>>>> > > stepping back I want to gauge whether that is >>>>>>>>>>>>>>>> "reasonable" before >>>>>>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > Assuming that we do want to support such "compositions" >>>>>>>>>>>>>>>> the next question >>>>>>>>>>>>>>>> > > is how we see this being configured. Clearly any time >>>>>>>>>>>>>>>> a CDI BeanManager >>>>>>>>>>>>>>>> > is >>>>>>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have >>>>>>>>>>>>>>>> opinions about this, >>>>>>>>>>>>>>>> > but >>>>>>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is >>>>>>>>>>>>>>>> initiated >>>>>>>>>>>>>>>> > > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. >>>>>>>>>>>>>>>> So it >>>>>>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>>>>>> > simply >>>>>>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the >>>>>>>>>>>>>>>> goals here is to >>>>>>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want >>>>>>>>>>>>>>>> to use a different >>>>>>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>>>>>> > imo >>>>>>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>>>>>> strongly it should >>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>>>>>> > > 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 >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> >>>>> >> From steve at hibernate.org Thu Dec 21 11:00:21 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 21 Dec 2017 16:00:21 +0000 Subject: [hibernate-dev] ManagedBeanRegistry - dependency injection support In-Reply-To: References: Message-ID: Yep, I saw it. Just not sure I agree that this is not enough. On Thu, Dec 21, 2017 at 9:42 AM Yoann Rodiere wrote: > > However, I do think that there is still a need to expand the proposal > Scott and I want to make to the CDI spec wrt something like our > ExtendedBeanManager to also account for the shutdown phase > > +1, I sent an email about just that on the mailing list. There are some > drawbacks to this approach though, and Sanne suggested deeper integration > into CDI would be a more future-proof path. > The subject of this thread was "CDI integration in Hibernate ORM and the > Application scope". > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > On 21 December 2017 at 16:36, Steve Ebersole wrote: > >> Awesome! Glad it worked out. >> >> However, I do think that there is still a need to expand the proposal >> Scott and I want to make to the CDI spec wrt something like our >> ExtendedBeanManager to also account for the shutdown phase. In addition to >> knowing when the BeanManager is ready to use, it would be nice to know when >> the BeanManager is ready to shutdown (a before shutdown hook). At that >> point we could begin cleaning up our CreationalContext, etc refs. >> >> Scott, do you already have enough insight into that in WildFly for us to >> go ahead and do that in our integration today? >> >> On Thu, Dec 21, 2017, 1:53 AM Yoann Rodiere wrote: >> >>> Hi, >>> >>> Following our conversations on HipChat and the various changes you >>> implemented (thanks!), I tested the current implementation. There were a >>> few issues, but I managed to fix them and make all the tests in Hibernate >>> Search pass. >>> Here is a PR with the fixes: >>> https://github.com/hibernate/hibernate-orm/pull/2092 >>> >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> >>> On 14 December 2017 at 18:42, Steve Ebersole >>> wrote: >>> >>>> Here is the commit with initial support for named CDI beans and support >>>> for bypassing registry caching of ManagedBeans : >>>> https://github.com/hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8c00495d39bca7fb60 >>>> >>>> There is still a question of whether named beans support needs to do >>>> the javax.enterprise.inject.spi.InjectionTarget stuff >>>> >>>> Christian, I ended up going to "beans" as the package name because this >>>> supports non-CDI environments (direct instantiation) too. Not overly a fan >>>> of "beans" (overloaded term) but it was a lesser of evils. >>>> >>>> On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole >>>> wrote: >>>> >>>>> Yoann, does this approach still need to do the injections >>>>> (javax.enterprise.inject.spi.InjectionTarget)? >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere >>>>> wrote: >>>>> >>>>>> Here is how it should work from what I understand (adapted from an >>>>>> implementation in Search, which has slightly different requirements): >>>>>> >>>>>> static T getBeanInstance(BeanManager beanManager, String >>>>>> beanName, Class contract) { >>>>>> Set> beans = beanManager.getBeans(contract, new >>>>>> NamedQualifier(beanName)); >>>>>> if ( beans.isEmpty() || beans.size() > 1 ) { >>>>>> // TODO proper error messages >>>>>> throw new IllegalArgumentException( "No matching beans or multiple >>>>>> matching beans" ); >>>>>> } >>>>>> Bean bean = beans.iterator().next(); >>>>>> CreationalContext creationalContext = >>>>>> beanManager.createCreationalContext( bean ); >>>>>> return contract.cast( beanManager.getReference( bean, contract, >>>>>> creationalContext ) ); >>>>>> } >>>>>> >>>>>> With NamedQualifier being the implementation I gave before. >>>>>> >>>>>> Sure, let's talk about it later on HipChat. Especially the caching >>>>>> thing, it's really a blocker for Search. >>>>>> >>>>>> I'll be online to travel in about 3 hours, though. >>>>>> >>>>>> >>>>>> Yoann Rodi?re >>>>>> Hibernate NoORM Team >>>>>> yoann at hibernate.org >>>>>> >>>>>> On 14 December 2017 at 14:46, Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> I'll be on HipChat later after I get back from taking my son and >>>>>>> daughter to school. Maybe it is easier to discuss there. >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole >>>>>>> wrote: >>>>>>> >>>>>>>> But your answer above does not answer my question ;) >>>>>>>> >>>>>>>> I still have no idea how to go from name+Class -> bean. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Yeah, it was 4AM in France when you asked :) I answered later on >>>>>>>>> HipChat, the answer is basically the one I gave in my email. >>>>>>>>> >>>>>>>>> Yoann Rodi?re >>>>>>>>> Hibernate NoORM Team >>>>>>>>> yoann at hibernate.org >>>>>>>>> >>>>>>>>> On 14 December 2017 at 14:38, Steve Ebersole >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> WRT to named beans, I asked Guillaume on HipChat what that is >>>>>>>>>> supposed to look like. IIRC he mentioned producers in Paris, but I found >>>>>>>>>> no straight-forward way to get from name+class to a bean. >>>>>>>>>> >>>>>>>>>> He may have answered, I just have not been on HipChat yet today... >>>>>>>>>> >>>>>>>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole < >>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>> >>>>>>>>>>> Its easier to cleanup >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole < >>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> There are a lot of changes to digest here, but if anyone wanted >>>>>>>>>>>> to take a look at this so far... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole < >>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Actually my fault. Apparently renaming the package was way >>>>>>>>>>>>> too aggressive and renamed the artifact >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole < >>>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Ah, nm. They change the artifact name. Boo! >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole < >>>>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven >>>>>>>>>>>>>>> Central? It was there last week, but is no longer there... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole < >>>>>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for the replies. So unless we hear otherwise from >>>>>>>>>>>>>>>> anyone else, I will plan on supporting just one DI container. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere < >>>>>>>>>>>>>>>> yoann at hibernate.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use >>>>>>>>>>>>>>>>> case. And even if >>>>>>>>>>>>>>>>> users provide a custom bean registry, they could just >>>>>>>>>>>>>>>>> implement their >>>>>>>>>>>>>>>>> specific behavior for a few specific case, then retrieve >>>>>>>>>>>>>>>>> another >>>>>>>>>>>>>>>>> implementations on their own and delegate to it however >>>>>>>>>>>>>>>>> they want. >>>>>>>>>>>>>>>>> Overriding the service initiator looks like a very >>>>>>>>>>>>>>>>> reasonable way to do >>>>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regarding the package, "org.hibernate.resource.beans" >>>>>>>>>>>>>>>>> seems more >>>>>>>>>>>>>>>>> appropriate to me, since CDI is not the only >>>>>>>>>>>>>>>>> implementation we will get and >>>>>>>>>>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not >>>>>>>>>>>>>>>>> really something >>>>>>>>>>>>>>>>> the bean registry must provide. We could imagine a bean >>>>>>>>>>>>>>>>> registry without >>>>>>>>>>>>>>>>> any support for injection, after all, just providing >>>>>>>>>>>>>>>>> "monolithic beans". It >>>>>>>>>>>>>>>>> would still make sense with respect to your >>>>>>>>>>>>>>>>> ManagedBeanRegistry API. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yoann Rodi?re >>>>>>>>>>>>>>>>> Hibernate NoORM Team >>>>>>>>>>>>>>>>> yoann at hibernate.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov < >>>>>>>>>>>>>>>>> christian.beikov at gmail.com> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > I don't think someone is actually going to use more than >>>>>>>>>>>>>>>>> a single DI >>>>>>>>>>>>>>>>> > framework and even if they do, they will probably bridge >>>>>>>>>>>>>>>>> one way or >>>>>>>>>>>>>>>>> > another between the DI frameworks to be able to access >>>>>>>>>>>>>>>>> beans from one in >>>>>>>>>>>>>>>>> > the other. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > So I don't think we should do "compositions" since it's >>>>>>>>>>>>>>>>> not a big deal >>>>>>>>>>>>>>>>> > to integrate different DIs and is also IMO an edge case. >>>>>>>>>>>>>>>>> I'd prefer the >>>>>>>>>>>>>>>>> > package name `org.hibernate.resource.di` since CDI seems >>>>>>>>>>>>>>>>> to be just one >>>>>>>>>>>>>>>>> > of the possible "integrations". >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Mit freundlichen Gr??en, >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>>>>>> > *Christian Beikov* >>>>>>>>>>>>>>>>> > Am 13.12.2017 um 21:04 schrieb Steve Ebersole: >>>>>>>>>>>>>>>>> > > https://hibernate.atlassian.net/browse/HHH-11259 and >>>>>>>>>>>>>>>>> friends are mainly >>>>>>>>>>>>>>>>> > > about back porting the work I did on 6.0 for the >>>>>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>>>>> > > abstraction over dependency injection containers. We >>>>>>>>>>>>>>>>> will ship support >>>>>>>>>>>>>>>>> > for >>>>>>>>>>>>>>>>> > > CDI as well as non-managed beans (things we directly >>>>>>>>>>>>>>>>> instantiate). Of >>>>>>>>>>>>>>>>> > > course we'd ideally make it easy to plug in other DI >>>>>>>>>>>>>>>>> containers such as >>>>>>>>>>>>>>>>> > > Spring. So I wanted to discuss the configuration of >>>>>>>>>>>>>>>>> this support. >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > The first thing to consider is whether we want to >>>>>>>>>>>>>>>>> support using multiple >>>>>>>>>>>>>>>>> > DI >>>>>>>>>>>>>>>>> > > containers simultaneously. E.g. is it conceivable >>>>>>>>>>>>>>>>> that an application >>>>>>>>>>>>>>>>> > > might want to use both CDI and Spring simultaneously? >>>>>>>>>>>>>>>>> I started building >>>>>>>>>>>>>>>>> > > in support for that via a CompositeManagedBeanRegistry >>>>>>>>>>>>>>>>> implementation, >>>>>>>>>>>>>>>>> > but >>>>>>>>>>>>>>>>> > > stepping back I want to gauge whether that is >>>>>>>>>>>>>>>>> "reasonable" before >>>>>>>>>>>>>>>>> > > continuing down that path >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > Assuming that we do want to support such >>>>>>>>>>>>>>>>> "compositions" the next question >>>>>>>>>>>>>>>>> > > is how we see this being configured. Clearly any time >>>>>>>>>>>>>>>>> a CDI BeanManager >>>>>>>>>>>>>>>>> > is >>>>>>>>>>>>>>>>> > > present during bootstrap we want to enable CDI >>>>>>>>>>>>>>>>> ManagedBeanRegistry >>>>>>>>>>>>>>>>> > > support. How would users indicate additional >>>>>>>>>>>>>>>>> ManagedBeanRegistry impls >>>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>>> > > added to the CompositeManagedBeanRegistry? I have >>>>>>>>>>>>>>>>> opinions about this, >>>>>>>>>>>>>>>>> > but >>>>>>>>>>>>>>>>> > > I'd like to hear other's thoughts... >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > Note that ManagedBeanRegistry is a service and is >>>>>>>>>>>>>>>>> initiated >>>>>>>>>>>>>>>>> > > via >>>>>>>>>>>>>>>>> org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator. So it >>>>>>>>>>>>>>>>> > > would be possible to completely redefine >>>>>>>>>>>>>>>>> ManagedBeanRegistry support >>>>>>>>>>>>>>>>> > simply >>>>>>>>>>>>>>>>> > > by replacing that initiator. >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > A minor point... notice that the package name here is >>>>>>>>>>>>>>>>> > > `org.hibernate.resource.cdi`, even though one of the >>>>>>>>>>>>>>>>> goals here is to >>>>>>>>>>>>>>>>> > > support non-CDI ManagedBeanRegistry impls. Do we want >>>>>>>>>>>>>>>>> to use a different >>>>>>>>>>>>>>>>> > > package name? Maybe `org.hibernate.resource.beans`? >>>>>>>>>>>>>>>>> > > ``org.hibernate.resource.di`? >>>>>>>>>>>>>>>>> ``org.hibernate.resource.injection`? >>>>>>>>>>>>>>>>> > > Other suggestions? I'm actually ok with >>>>>>>>>>>>>>>>> `org.hibernate.resource.cdi` - >>>>>>>>>>>>>>>>> > imo >>>>>>>>>>>>>>>>> > > "cdi" conveys the proper intent. But if others feel >>>>>>>>>>>>>>>>> strongly it should >>>>>>>>>>>>>>>>> > be >>>>>>>>>>>>>>>>> > > something else, I am open to hearing what and why. >>>>>>>>>>>>>>>>> > > _______________________________________________ >>>>>>>>>>>>>>>>> > > 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 >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> >>>>>> >>> > From sanne at hibernate.org Thu Dec 21 13:40:33 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 21 Dec 2017 18:40:33 +0000 Subject: [hibernate-dev] Locking German and French forums In-Reply-To: References: Message-ID: +1 Thanks Vlad. On 21 December 2017 at 07:11, Vlad Mihalcea wrote: > Hi, > > I'm going to lock the German and French forums since users posts > question there from time to time, > and the questions remain answered. > > If someone has anything against it, let me know. Otherwise, we should use > the English one until we move to Discourse. > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Dec 22 06:33:09 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 22 Dec 2017 11:33:09 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: Thanks for investigating this Gunnar. Some thoughts inline... On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling 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.. > * 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. > * 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? * 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 * 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? > 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? 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 - ... From guillaume.smet at gmail.com Fri Dec 22 06:39:22 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 22 Dec 2017 12:39:22 +0100 Subject: [hibernate-dev] Infinispan modules contains hibernate-search-orm Message-ID: Hi, I'm trying to upgrade OGM 5.2 to WildFly 11 so that we don't release modules for an outdated version of WildFly when we'll push this release (I already did the upgrade in my ORM 5.2 support branch so it's mostly backporting and tracking issues). I have an issue with the Infinispan modules (and I don't understand why we didn't have the issue earlier but it's another subject). They contain an hibernate-search-orm module pointing to an org.hibernate:5.2 module, which means that we would need to deploy an ORM 5.2 in WildFly whereas I don't think it's necessary. Is there a use case for having hibernate-search-orm in Infinispan? It's not referenced in other modules of the Infinispan modules zip ( http://search.maven.org/#search|gav|1|g%3A"org.infinispan"%20AND%20a%3A"infinispan-wildfly-modules") and the slot is very specific so I wouldn't expect people to deploy it and use it outside of Infinispan. I would vote for not distributing this module with the Infinispan modules if it's not too much work. -- Guillaume From sanne at hibernate.org Fri Dec 22 07:40:08 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 22 Dec 2017 13:40:08 +0100 Subject: [hibernate-dev] Infinispan modules contains hibernate-search-orm In-Reply-To: References: Message-ID: On 22 December 2017 at 12:39, Guillaume Smet wrote: > Hi, > > I'm trying to upgrade OGM 5.2 to WildFly 11 so that we don't release > modules for an outdated version of WildFly when we'll push this release (I > already did the upgrade in my ORM 5.2 support branch so it's mostly > backporting and tracking issues). > > I have an issue with the Infinispan modules (and I don't understand why we > didn't have the issue earlier but it's another subject). > > They contain an hibernate-search-orm module pointing to an > org.hibernate:5.2 module, which means that we would need to deploy an ORM > 5.2 in WildFly whereas I don't think it's necessary. > > Is there a use case for having hibernate-search-orm in Infinispan? It's not > referenced in other modules of the Infinispan modules zip ( > http://search.maven.org/#search|gav|1|g%3A"org.infinispan"%20AND%20a%3A"infinispan-wildfly-modules") > and the slot is very specific so I wouldn't expect people to deploy it and > use it outside of Infinispan. You're right, there's no use case for that as it's not used for the purposes of infinispan-query - which requires hibernate-search-engine, expect that they are supposed to run integration tests with the `hibernate-search-orm` module included in WildFly. They should not distribute these other hibernate search module versions though. > I would vote for not distributing this module with the Infinispan modules > if it's not too much work. I'm pretty sure I didn't have those modules in the past. Looks like a regression in the Infinispan build. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Dec 22 12:16:56 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 22 Dec 2017 17:16:56 +0000 Subject: [hibernate-dev] Realising the JavaDoc jars as well In-Reply-To: References: Message-ID: I wanted to get everyone's opinion about the api/spi/internal package grouping we do in the aggregated Javadoc in regards to the per-module javadocs. Adding this logic adds significant overhead to the process of building the Javadoc, to the point where I am considering not performing that grouping there. Thoughts? On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea wrote: > I tested it locally, and when publishing the jars to Maven local, the > JavaDoc is now included. > > Don't know if there's anything to be done about it. > > Vlad > > On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero > wrote: > > > +1 to merge it (if it works - which I didn't check) > > > > Some history can easily be found: > > - > http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html > > > > Thanks, > > Sanne > > > > > > On 11 December 2017 at 15:24, Vlad Mihalcea > > wrote: > > > Hi, > > > > > > I've noticed this Pull Request which is valid and worth integrating: > > > > > > https://github.com/hibernate/hibernate-orm/pull/2078 > > > > > > Before I merge it, I wanted to make sure whether this change was > > accidental > > > or intentional. > > > > > > Was there any reason not to ship the JavaDoc jars along with the > release > > > artifacts and the sources jars as well? > > > > > > Thanks, > > > Vlad > > > _______________________________________________ > > > 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 > From steve at hibernate.org Fri Dec 22 17:07:42 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 22 Dec 2017 22:07:42 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 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 wrote: > Thanks for investigating this Gunnar. > > Some thoughts inline... > > On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling > 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.. > > > >> * 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. > > > >> * 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? > > > * 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 > > > * 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? > > > >> 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? > > 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 > - ... > > > > > From sanne at hibernate.org Sat Dec 23 07:52:36 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Sat, 23 Dec 2017 13:52:36 +0100 Subject: [hibernate-dev] Realising the JavaDoc jars as well In-Reply-To: References: Message-ID: On 22 December 2017 at 18:16, Steve Ebersole wrote: > I wanted to get everyone's opinion about the api/spi/internal package > grouping we do in the aggregated Javadoc in regards to the per-module > javadocs. Adding this logic adds significant overhead to the process of > building the Javadoc, to the point where I am considering not performing > that grouping there. > > Thoughts? For Hibernate Search we recently decided to not produce javadocs at all for "internal"; everything else is just documented as a single group. That cuts on the "need to know" complexity of end users. Advanced users who could have benefitted from knowing more about the internals will likely have sources. > > On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea > wrote: >> >> I tested it locally, and when publishing the jars to Maven local, the >> JavaDoc is now included. >> >> Don't know if there's anything to be done about it. >> >> Vlad >> >> On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero >> wrote: >> >> > +1 to merge it (if it works - which I didn't check) >> > >> > Some history can easily be found: >> > - >> > http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html >> > >> > Thanks, >> > Sanne >> > >> > >> > On 11 December 2017 at 15:24, Vlad Mihalcea >> > wrote: >> > > Hi, >> > > >> > > I've noticed this Pull Request which is valid and worth integrating: >> > > >> > > https://github.com/hibernate/hibernate-orm/pull/2078 >> > > >> > > Before I merge it, I wanted to make sure whether this change was >> > accidental >> > > or intentional. >> > > >> > > Was there any reason not to ship the JavaDoc jars along with the >> > > release >> > > artifacts and the sources jars as well? >> > > >> > > Thanks, >> > > Vlad >> > > _______________________________________________ >> > > 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 From gunnar at hibernate.org Sat Dec 23 09:36:45 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Sat, 23 Dec 2017 15:36:45 +0100 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 2017-12-22 23:07 GMT+01:00 Steve Ebersole : > 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 > wrote: > >> Thanks for investigating this Gunnar. >> >> Some thoughts inline... >> >> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling >> 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 >> - ... >> >> >> >> >> > From steve at hibernate.org Sat Dec 23 09:48:00 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 23 Dec 2017 14:48:00 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 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 wrote: > 2017-12-22 23:07 GMT+01:00 Steve Ebersole : > >> 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 >> wrote: >> >>> Thanks for investigating this Gunnar. >>> >>> Some thoughts inline... >>> >>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling >>> 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 >>> - ... >>> >>> >>> >>> >>> >> From steve at hibernate.org Sat Dec 23 23:38:29 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 24 Dec 2017 04:38:29 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 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 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 > wrote: > >> 2017-12-22 23:07 GMT+01:00 Steve Ebersole : >> >>> 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 >>> wrote: >>> >>>> Thanks for investigating this Gunnar. >>>> >>>> Some thoughts inline... >>>> >>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling >>>> 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 >>>> - ... >>>> >>>> >>>> >>>> >>>> >>> From steve at hibernate.org Sun Dec 24 09:23:30 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sun, 24 Dec 2017 14:23:30 +0000 Subject: [hibernate-dev] Realising the JavaDoc jars as well In-Reply-To: References: Message-ID: Sure, but the question remains :P It just adds another one: 1. Should internal packages be generated into the javadocs (individual and/or aggregated)? 2. Should the individual javadocs (only intended for publishing to Central) group the packages into api/spi(/internal) the way we do for the aggregated javadocs? Personally I think filtering out internal packages is a great idea. Regarding grouping packages, I think its not worth the effort for the individual ones - just have an overview for these that just notes this distinction. On Sat, Dec 23, 2017 at 6:53 AM Sanne Grinovero wrote: > On 22 December 2017 at 18:16, Steve Ebersole wrote: > > I wanted to get everyone's opinion about the api/spi/internal package > > grouping we do in the aggregated Javadoc in regards to the per-module > > javadocs. Adding this logic adds significant overhead to the process of > > building the Javadoc, to the point where I am considering not performing > > that grouping there. > > > > Thoughts? > > For Hibernate Search we recently decided to not produce javadocs at > all for "internal"; everything else is just documented as a single > group. > > That cuts on the "need to know" complexity of end users. Advanced > users who could have benefitted from knowing more about the internals > will likely have sources. > > > > > On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea > > wrote: > >> > >> I tested it locally, and when publishing the jars to Maven local, the > >> JavaDoc is now included. > >> > >> Don't know if there's anything to be done about it. > >> > >> Vlad > >> > >> On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero > >> wrote: > >> > >> > +1 to merge it (if it works - which I didn't check) > >> > > >> > Some history can easily be found: > >> > - > >> > > http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html > >> > > >> > Thanks, > >> > Sanne > >> > > >> > > >> > On 11 December 2017 at 15:24, Vlad Mihalcea > >> > wrote: > >> > > Hi, > >> > > > >> > > I've noticed this Pull Request which is valid and worth integrating: > >> > > > >> > > https://github.com/hibernate/hibernate-orm/pull/2078 > >> > > > >> > > Before I merge it, I wanted to make sure whether this change was > >> > accidental > >> > > or intentional. > >> > > > >> > > Was there any reason not to ship the JavaDoc jars along with the > >> > > release > >> > > artifacts and the sources jars as well? > >> > > > >> > > Thanks, > >> > > Vlad > >> > > _______________________________________________ > >> > > 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 > From brett at hibernate.org Wed Dec 27 16:36:47 2017 From: brett at hibernate.org (Brett Meyer) Date: Wed, 27 Dec 2017 16:36:47 -0500 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: +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 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 >> wrote: >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole : >>> >>>> 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 >>>> wrote: >>>> >>>>> Thanks for investigating this Gunnar. >>>>> >>>>> Some thoughts inline... >>>>> >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling >>>>> 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 From steve at hibernate.org Wed Dec 27 16:39:55 2017 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 27 Dec 2017 21:39:55 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 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 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 > 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 > >> wrote: > >> > >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole : > >>> > >>>> 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 > >>>> wrote: > >>>> > >>>>> Thanks for investigating this Gunnar. > >>>>> > >>>>> Some thoughts inline... > >>>>> > >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling > > >>>>> 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 From steve at hibernate.org Wed Dec 27 21:37:38 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Dec 2017 02:37:38 +0000 Subject: [hibernate-dev] ORM & Java 9 - strange javadoc failure Message-ID: I worked on getting Travis CI set up on ORM for reasons discussed here previously. But I am running into a really strange error when I enabled Java 9: javadoc: error - An exception occurred while building a component: ClassSerializedForm (com.sun.tools.javac.code.Symbol$CompletionFailure: class file for org.hibernate.engine.Mapping not found) Please file a bug against the javadoc tool via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database ( http://bugs.java.com) for duplicates. Include error messages and the following diagnostic in your report. Thank you. com.sun.tools.javac.code.Symbol$CompletionFailure: class file for org.hibernate.engine.Mapping not found It seems like javadoc is complaining because it sees a reference to a class (org.hibernate.engine.Mapping) that it cannot find. It is true that there is no class named org.hibernate.engine.Mapping, the real name is org.hibernate.engine.spi.Mapping - but what is strange is that I search the entire ORM project and found zero references to the String org.hibernate.engine.Mapping. I just kicked off a run of the ORM / Java 9 Jenkins job to see if it has the same failure. Anyone have any ideas? From steve at hibernate.org Thu Dec 28 10:06:57 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Dec 2017 15:06:57 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 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 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 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 >> 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 >> >> wrote: >> >> >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole : >> >>> >> >>>> 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 >> >>>> 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 > > From steve at hibernate.org Thu Dec 28 12:07:42 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Dec 2017 17:07:42 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: Gunnar, back to the original discussion... I asked you about this specifically in Paris and you responded "no" - but reading info I have found online seems to indicate that it is indeed perfectly valid to build with Java 9 and include a module-info.class into the jar and be able to load that into Java 8 (module-info is simply ignored). Are the resources I have read just wrong? On Thu, Dec 28, 2017 at 9:06 AM Steve Ebersole 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 > 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 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 >>> 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 >>> >> wrote: >>> >> >>> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole : >>> >>> >>> >>>> 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 >> > >>> >>>> 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 >> >> From steve at hibernate.org Thu Dec 28 12:56:31 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Dec 2017 17:56:31 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 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 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 > 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 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 >>> 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 >>> >> wrote: >>> >> >>> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole : >>> >>> >>> >>>> 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 >> > >>> >>>> 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 >> >> From gunnar at hibernate.org Thu Dec 28 12:58:05 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 28 Dec 2017 18:58:05 +0100 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: Automatic-Module-Name looks good. While unrelated, those look odd: * Main-Class: I don't think ORM - as a library - should declare this * Specification-Title, Specification-Version: should these rather relate to JPA title and version (as opposed to the Implementation-* ones)? 2017-12-28 16:06 GMT+01:00 Steve Ebersole : > 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 > 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 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 > >> 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 > > >> >> wrote: > >> >> > >> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole : > >> >>> > >> >>>> 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 > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Dec 28 13:10:35 2017 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Dec 2017 18:10:35 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: - Main-Class is fine afaik. It was requested previously by users and added accordingly. I'm not going to change it unless you can show me concrete reason to. - Specification-* - I had considered that. TBH its not important afaik. And Hibernate defines a specification as well (its API) that is a super set of JPA. And its not like I just added this. Those have been generated into the manifest at least as far back as the move to Gradle. I've yet to hear a compliant besides yours today On Thu, Dec 28, 2017 at 11:58 AM Gunnar Morling wrote: > Automatic-Module-Name looks good. > > While unrelated, those look odd: > > * Main-Class: I don't think ORM - as a library - should declare this > * Specification-Title, Specification-Version: should these rather relate > to JPA title and version (as opposed to the Implementation-* ones)? > > > 2017-12-28 16:06 GMT+01:00 Steve Ebersole : > >> 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 >> 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 >> 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 >> >> 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 : >> >> >>> >> >> >>>> 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 >> > >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From gunnar at hibernate.org Thu Dec 28 13:24:07 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 28 Dec 2017 19:24:07 +0100 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 2017-12-28 19:10 GMT+01:00 Steve Ebersole : > > - Main-Class is fine afaik. It was requested previously by users and > added accordingly. I'm not going to change it unless you can show me > concrete reason to. > > Seeing now that Version indeed defines a main() method, didn't expect that. No reason to change it indeed. - Specification-* - I had considered that. TBH its not important afaik. And Hibernate defines a specification as well (its API) that is a super set of JPA. And its not like I just added this. Those have been generated into the manifest at least as far back as the move to Gradle. I've yet to hear a compliant besides yours today Not important for sure, and I can get behind your reasoning about Hibernate's public API being the "specification" here. All good then, not sure who'd be consuming those headers anyways. > > On Thu, Dec 28, 2017 at 11:58 AM Gunnar Morling > wrote: > >> Automatic-Module-Name looks good. >> >> While unrelated, those look odd: >> >> * Main-Class: I don't think ORM - as a library - should declare this >> * Specification-Title, Specification-Version: should these rather relate >> to JPA title and version (as opposed to the Implementation-* ones)? >> >> >> 2017-12-28 16:06 GMT+01:00 Steve Ebersole : >> >>> 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 >>> 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 >>> 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 >> > >>> >> 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 : >>> >> >>> >>> >> >>>> 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 >>> > >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> From andrea at hibernate.org Fri Dec 29 09:14:19 2017 From: andrea at hibernate.org (andrea boriero) Date: Fri, 29 Dec 2017 14:14:19 +0000 Subject: [hibernate-dev] Realising the JavaDoc jars as well In-Reply-To: References: Message-ID: +1 for filtering out internal packages. not a strong opinion on grouping On 24 December 2017 at 14:23, Steve Ebersole wrote: > Sure, but the question remains :P It just adds another one: > > > 1. Should internal packages be generated into the javadocs (individual > and/or aggregated)? > 2. Should the individual javadocs (only intended for publishing to > Central) group the packages into api/spi(/internal) the way we do for > the > aggregated javadocs? > > Personally I think filtering out internal packages is a great idea. > > Regarding grouping packages, I think its not worth the effort for the > individual ones - just have an overview for these that just notes this > distinction. > > On Sat, Dec 23, 2017 at 6:53 AM Sanne Grinovero > wrote: > > > On 22 December 2017 at 18:16, Steve Ebersole > wrote: > > > I wanted to get everyone's opinion about the api/spi/internal package > > > grouping we do in the aggregated Javadoc in regards to the per-module > > > javadocs. Adding this logic adds significant overhead to the process > of > > > building the Javadoc, to the point where I am considering not > performing > > > that grouping there. > > > > > > Thoughts? > > > > For Hibernate Search we recently decided to not produce javadocs at > > all for "internal"; everything else is just documented as a single > > group. > > > > That cuts on the "need to know" complexity of end users. Advanced > > users who could have benefitted from knowing more about the internals > > will likely have sources. > > > > > > > > On Tue, Dec 12, 2017 at 11:37 AM Vlad Mihalcea < > mihalcea.vlad at gmail.com> > > > wrote: > > >> > > >> I tested it locally, and when publishing the jars to Maven local, the > > >> JavaDoc is now included. > > >> > > >> Don't know if there's anything to be done about it. > > >> > > >> Vlad > > >> > > >> On Mon, Dec 11, 2017 at 9:32 PM, Sanne Grinovero > > > >> wrote: > > >> > > >> > +1 to merge it (if it works - which I didn't check) > > >> > > > >> > Some history can easily be found: > > >> > - > > >> > > > http://lists.jboss.org/pipermail/hibernate-dev/2017-January/015758.html > > >> > > > >> > Thanks, > > >> > Sanne > > >> > > > >> > > > >> > On 11 December 2017 at 15:24, Vlad Mihalcea < > mihalcea.vlad at gmail.com> > > >> > wrote: > > >> > > Hi, > > >> > > > > >> > > I've noticed this Pull Request which is valid and worth > integrating: > > >> > > > > >> > > https://github.com/hibernate/hibernate-orm/pull/2078 > > >> > > > > >> > > Before I merge it, I wanted to make sure whether this change was > > >> > accidental > > >> > > or intentional. > > >> > > > > >> > > Was there any reason not to ship the JavaDoc jars along with the > > >> > > release > > >> > > artifacts and the sources jars as well? > > >> > > > > >> > > Thanks, > > >> > > Vlad > > >> > > _______________________________________________ > > >> > > 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 > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Dec 29 10:58:13 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 29 Dec 2017 15:58:13 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: 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 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 > 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 >> 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 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 >>>> 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 >>> > >>>> >> wrote: >>>> >> >>>> >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole : >>>> >>> >>>> >>>> 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 >>> >>> From brett at hibernate.org Fri Dec 29 11:35:25 2017 From: brett at hibernate.org (Brett Meyer) Date: Fri, 29 Dec 2017 11:35:25 -0500 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: <904607a5-a018-3754-1698-f280319c4e1e@hibernate.org> 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 > 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 > > 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 > > 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 > > 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 > > 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 > > > >> wrote: > >> > >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole > >: > >>> > >>>> 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 > > > >>>> wrote: > >>>> > >>>>> Thanks for investigating this Gunnar. > >>>>> > >>>>> Some thoughts inline... > >>>>> > >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling > > > >>>>> 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 > From steve at hibernate.org Fri Dec 29 11:41:39 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 29 Dec 2017 16:41:39 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: <904607a5-a018-3754-1698-f280319c4e1e@hibernate.org> References: <904607a5-a018-3754-1698-f280319c4e1e@hibernate.org> Message-ID: 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 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 > 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 >> 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 >>> 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 >>>> 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 >>>>> 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 : >>>>> >>> >>>>> >>>> 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 >>>> >>>> > From brett at hibernate.org Fri Dec 29 11:45:37 2017 From: brett at hibernate.org (Brett Meyer) Date: Fri, 29 Dec 2017 11:45:37 -0500 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: <41c4e5ce-b386-811d-1d46-c77750036b16@hibernate.org> Sorry folks, responding to this thread out of order... Steve, at first glance, this looks fine! On 12/28/17 10:06 AM, Steve Ebersole 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 > 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 > 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 > > 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 > > > >> wrote: > >> > >>> 2017-12-22 23:07 GMT+01:00 Steve Ebersole > >: > >>> > >>>> 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 > > > >>>> wrote: > >>>> > >>>>> Thanks for investigating this Gunnar. > >>>>> > >>>>> Some thoughts inline... > >>>>> > >>>>> On Wed, Dec 20, 2017 at 3:54 PM Gunnar Morling > > > >>>>> 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 > From steve at hibernate.org Fri Dec 29 15:34:47 2017 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 29 Dec 2017 20:34:47 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole wrote: > > * 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 > Actually this is different than what Sanne brought up. I actually cannot reproduce what Sanne is reporting. If I had to guess he was not specifying the bytecode provider to use "globally". This is a special kind of setting (we used to have a few) that can only be specified per-VM : either as a root `hibernate.properties` or as a System property. It has to do with how Hibernate builds its mapping model, specifically `org.hibernate.mapping.Component`. Given the redesign of the bootstrap process we may actually be able to remove that "VM wide" requirement. I'll look into that for 5.3. BTW Sanne, I created a repo[1] showing that this does indeed work when specified "properly". Gunnar, what you are seeing is very different and I'm not sure of a way to solve that yet. That is all part of auto-discovery of resources (entities, embeddables, converters, etc) during bootstrap. We need to inspect the file without loading the Class to look at its annotations. We need *something* to do that, whether that is Jandex, Javassist, etc. Byte Buddy may or may not have a similar facility. The problem here is that the Javassist dependency is needed for a very different purpose. And without a viable alternative solution, its going to have to stay that way. [1] https://github.com/sebersole/orm-bytebuddy-no-javassist From steve at hibernate.org Sat Dec 30 10:40:09 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 30 Dec 2017 15:40:09 +0000 Subject: [hibernate-dev] Using Hibernate ORM as automatic JPMS modules In-Reply-To: References: Message-ID: On Fri, Dec 29, 2017 at 2:34 PM Steve Ebersole wrote: > On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole > wrote: > >> >> * 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 >> > > Actually this is different than what Sanne brought up. I actually cannot > reproduce what Sanne is reporting. If I had to guess he was not specifying > the bytecode provider to use "globally". This is a special kind of setting > (we used to have a few) that can only be specified per-VM : either as a > root `hibernate.properties` or as a System property. It has to do with how > Hibernate builds its mapping model, specifically > `org.hibernate.mapping.Component`. Given the redesign of the bootstrap > process we may actually be able to remove that "VM wide" requirement. I'll > look into that for 5.3. BTW Sanne, I created a repo[1] showing that this > does indeed work when specified "properly". > Rafael, does Byte Buddy have such a capability? Maybe we should leverage Jandex for this particular part? From steve at hibernate.org Sat Dec 30 12:17:59 2017 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 30 Dec 2017 17:17:59 +0000 Subject: [hibernate-dev] Making BytecodeProvider no longer be ClassLoader-wide config In-Reply-To: References: Message-ID: I started playing around with possibly removing the need for BytecodeProvider to be configured per-ClassLoader[1]. In fact I got a working solution for allowing all 3 remaining ClassLoader-wide settings per-application: 1. Whether to handle binary/lob data via streams - I was able to make this one part of SessionFactoryOptions 2. Which BytecodeProvider to use. 3. Whether to use that BytecodeProvider's ReflectionOptimizer (2) and (3) currently had to be defined on MetadataBuilderOptions because of the way Metadata is built (it accesses these values way too early). Ultimately these would be moved to SessionFactoryOptions as well. However, there is a catch which I have documented[2] and would like to get everyone's feedback. Currently I lean towards simply deprecating these methods on Environment and planning on fixing these in 6.0. That's what I will plan unless there is a consensus for the other option. [1] Earlier I mistakenly said per-VM, but its simply static methods so it is really per-ClassLoader unless of course the setting is defined as a Java env var [2] https://hibernate.atlassian.net/browse/HHH-12193?focusedCommentId=100814&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-100814 On Fri, Dec 29, 2017 at 2:34 PM Steve Ebersole wrote: > On Fri, Dec 22, 2017 at 5:33 AM Steve Ebersole > wrote: > >> >> * 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 >> > > Actually this is different than what Sanne brought up. I actually cannot > reproduce what Sanne is reporting. If I had to guess he was not specifying > the bytecode provider to use "globally". This is a special kind of setting > (we used to have a few) that can only be specified per-VM : either as a > root `hibernate.properties` or as a System property. It has to do with how > Hibernate builds its mapping model, specifically > `org.hibernate.mapping.Component`. Given the redesign of the bootstrap > process we may actually be able to remove that "VM wide" requirement. I'll > look into that for 5.3. BTW Sanne, I created a repo[1] showing that this > does indeed work when specified "properly". > > [1] https://github.com/sebersole/orm-bytebuddy-no-javassist >