From gbadner at redhat.com Sat Sep 1 03:21:49 2018 From: gbadner at redhat.com (Gail Badner) Date: Sat, 1 Sep 2018 00:21:49 -0700 Subject: [hibernate-dev] @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element In-Reply-To: References: Message-ID: FYI, I am taking PTO Tuesday, 9/4. I hope to be able to move forward on this when I return on 9/5. I see some differences. Some may be expected, but I think there are some bugs. For example, suppose we have the following entities: @Entity public class Parent { @Id private Long id; } @Entity public class ChildPKJC { @Id private Long id; @OneToOne // note that cascade-persist is not enabled @PrimaryKeyJoinColumn private Parent parent; } public class ChildMapsId { @Id private Long id; @OneToOne // note that cascade-persist is not enabled @MapsId private Parent parent; } ------------------------------------------------------------------------------------------------------------------------------------------- When persisting ChildPKJC: 1) the application must initialize ChildPKJC#id before persisting the entity [1]; otherwise, the following exception is thrown: javax.persistence.PersistenceException: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): 2) if ChildPKJC#parent is new with an assigned ID, and ChildPKJC#id is assigned parent's ID, the ChildPKJC Entity is persisted with the parent's ID, but parent is not persisted. When persisting ChildMapsId: 1) Hibernate automatically initializes ChildMapsId#id to parent.id [2] 2) if ChildMapsId#parent is new, parent is automatically cascade-persisted (even though CascadeStyle.PERSIST is not mapped), then the ChildMapsId entity is persisted. Are these expected difference? (My guess is yes) ------------------------------------------------------------------------------------------------------------------------------------------- Foreign key generation: If ChildPKJC#parent is optional there is no foreign key generated from ChildPKJC referencing Parent. [3] If ChildPKJC#parent is not optional, a foreign key is generated For ChildMapsId, a foreign key is generated from ChildPKJC referencing Parent, even if ChildMapsId#parent is optional. Is this a bug? My guess is that it is. Adding the following mapping to ChildMapsId#parent works to disable foreign key generation: @JoinColumn(foreignKey = @ForeignKey(value = ConstraintMode.NO_CONSTRAINT)) (can be used as a workaround) ------------------------------------------------------------------------------------------------------------------------------------------- Loading an existing ChildPKJC/ChildMapsId with an optional Parent association by ID, when there is no Parent entity with the same ID (IIUC, this is the only way that ChildPKJC#parent or ChildMapsId#parent can be optional [3]): For ChildPKJC, the loaded ChildPKJC entity will have a null parent. There is no need to add @NotFound(IGNORE) to ChildPKJC#parent. If ChildPKJC#parent is optional, it is always eagerly loaded. This makes sense, since we cannot create a proxy if there is the possibility of a null Parent entity. For ChildMapsId, the loaded value will be null because ObjectNotFoundException will be thrown when Hibernate tries to load the Parent entity. Adding @NotFound(IGNORE) to ChildMapsId#parent will result in ChildMapsId entity being loaded with a null parent association. Is this expected? If so, then ChildMapsId#parent cannot be optional by default (without @NotFound(IGNORE). I think it would make more sense if the ChildMapsId entity is loaded with a null parent association, consistent with what happens for ChildPKJC. If we go that route, then ChildMapsId#parent will always have to be loaded eagerly. ------------------------------------------------------------------------------------------------------------------------------------------- Please let me know your thoughts on this. [1] this requirement is documented in Example 178. Derived identifier @PrimaryKeyJoinColumn with a note that says: "Unlike @MapsId, the application developer is responsible for ensuring that the identifier and the many-to-one (or one-to-one) association are in sync as you can see in the PersonDetails#setPerson method." [2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of the spec has this footnote: [12] If the application does not set the primary key attribute corresponding to the relationship, the value of that attribute may not be available until after the entity has been flushed to the database. [3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote: [121]It is not expected that a database foreign key be defined for the OneToOne mapping, as the OneToOne relationship may be defined as ?optional=true?. On Fri, Aug 31, 2018 at 1:29 PM, Gail Badner wrote: > The fix for HHH-12436 involves correcting the foreign key direction for > "real" one-to-one associations. I've been looking into the ramifications of > this change because I'm concerned that applications can rely on the old > (incorrect) foreign key direction. > > In the process I've found that Hibernate treats: > > @OneToOne > @PrimaryKeyJoinColumn > private Employee employee; > > differently from: > > @OneToOne > @MapsId > private Employee employee; > > I believe they should be treated consistently. You can see my reasoning > below. [1] > > Before going into details about how they are treated differently, I'd like > to get confirmation, in case I am missing some subtlety. > > Could someone please confirm this? > > Regards, > Gail > > ------------------------------------------------------------ > --------------------------------- > [1] > > In 2.4.1.3 Examples of Derived Identities, Example 4(b) uses MapsId > without the value element as follows: > > @MapsId > @JoinColumn(name="FK") > @OneToOne Person patient; > > This example has the following footnote: > "[15] Note that the use of PrimaryKeyJoinColumn instead of MapsId would > result in the same mapping in this example. Use of MapsId > is preferred for the mapping of derived identities." > > The description has a footnote that says that using PrimaryKeyJoinColumn > instead of MapsId would result in the same mapping. > > In 11.1.45 PrimaryKeyJoinColumns Annotation, Example 2 uses > @PrimaryKeyJoinColumns as follows: > > @OneToOne > @PrimaryKeyJoinColumns({ > @PrimaryKeyJoinColumn(name="ID", > referencedColumnName="EMP_ID"), > @PrimaryKeyJoinColumn(name="NAME", > referencedColumnName="EMP_NAME")}) > EmployeeInfo info; > > This example has the following footnote: > "[123]Note that the derived identity mechanisms decribed in section > 2.4.1.1 is now preferred to the use of PrimaryKeyJoinColumn for > this case." > > From gbadner at redhat.com Sat Sep 1 03:33:05 2018 From: gbadner at redhat.com (Gail Badner) Date: Sat, 1 Sep 2018 00:33:05 -0700 Subject: [hibernate-dev] @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element In-Reply-To: References: Message-ID: FWIW, I've already spent a lot of time looking into the possible bugs I've described. I have a good idea about how to fix each one, so there's no need to research these. At this point, I'm just trying to get confirmation of whether they really are bugs. On Sat, Sep 1, 2018 at 12:21 AM, Gail Badner wrote: > FYI, I am taking PTO Tuesday, 9/4. I hope to be able to move forward on > this when I return on 9/5. > > I see some differences. Some may be expected, but I think there are some > bugs. > > For example, suppose we have the following entities: > > @Entity > public class Parent { > @Id > private Long id; > } > > @Entity > public class ChildPKJC { > @Id > private Long id; > > @OneToOne // note that cascade-persist is not enabled > @PrimaryKeyJoinColumn > private Parent parent; > } > > public class ChildMapsId { > @Id > private Long id; > > @OneToOne // note that cascade-persist is not enabled > @MapsId > private Parent parent; > } > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------- > > When persisting ChildPKJC: > > 1) the application must initialize ChildPKJC#id before persisting the > entity [1]; otherwise, the following exception is thrown: > javax.persistence.PersistenceException: org.hibernate.id.IdentifierGenerationException: > ids for this class must be manually assigned before calling save(): > > 2) if ChildPKJC#parent is new with an assigned ID, and ChildPKJC#id is > assigned parent's ID, the ChildPKJC Entity is persisted with the parent's > ID, but parent is not persisted. > > When persisting ChildMapsId: > > 1) Hibernate automatically initializes ChildMapsId#id to parent.id [2] > > 2) if ChildMapsId#parent is new, parent is automatically > cascade-persisted (even though CascadeStyle.PERSIST is not mapped), then > the ChildMapsId entity is persisted. > > Are these expected difference? (My guess is yes) > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------- > > Foreign key generation: > > If ChildPKJC#parent is optional there is no foreign key generated from ChildPKJC > referencing Parent. [3] If ChildPKJC#parent is not optional, a foreign > key is generated > > For ChildMapsId, a foreign key is generated from ChildPKJC referencing > Parent, even if ChildMapsId#parent is optional. > > Is this a bug? My guess is that it is. > > Adding the following mapping to ChildMapsId#parent works to disable > foreign key generation: > @JoinColumn(foreignKey = @ForeignKey(value = ConstraintMode.NO_CONSTRAINT)) > > (can be used as a workaround) > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------- > > Loading an existing ChildPKJC/ChildMapsId with an optional Parent > association by ID, when there is no Parent entity with the same ID (IIUC, > this is the only way that ChildPKJC#parent or ChildMapsId#parent can be > optional [3]): > > For ChildPKJC, the loaded ChildPKJC entity will have a null parent. There > is no need to add @NotFound(IGNORE) to ChildPKJC#parent. > > If ChildPKJC#parent is optional, it is always eagerly loaded. > > This makes sense, since we cannot create a proxy if there is the > possibility of a null Parent entity. > > For ChildMapsId, the loaded value will be null because ObjectNotFoundException > will be thrown when Hibernate tries to load the Parent entity. > Adding @NotFound(IGNORE) to ChildMapsId#parent will result in ChildMapsId > entity being loaded with a null parent association. > > Is this expected? If so, then ChildMapsId#parent cannot be optional by > default (without @NotFound(IGNORE). > > I think it would make more sense if the ChildMapsId entity is loaded with > a null parent association, consistent with what happens for ChildPKJC. If > we go that route, then ChildMapsId#parent will always have to be loaded > eagerly. > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------- > > Please let me know your thoughts on this. > > [1] this requirement is documented in Example 178. Derived identifier > @PrimaryKeyJoinColumn with a note that says: "Unlike @MapsId, the > application developer is responsible for ensuring that the identifier and > the many-to-one (or one-to-one) association are in sync as you can see in > the PersonDetails#setPerson method." > > [2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of the > spec has this footnote: > [12] If the application does not set the primary key attribute > corresponding to the relationship, the value of that attribute may not be > available until after the entity has been flushed to the database. > > [3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote: > [121]It is not expected that a database foreign key be defined for the > OneToOne mapping, as the OneToOne relationship may be defined as > ?optional=true?. > > > On Fri, Aug 31, 2018 at 1:29 PM, Gail Badner wrote: > >> The fix for HHH-12436 involves correcting the foreign key direction for >> "real" one-to-one associations. I've been looking into the ramifications of >> this change because I'm concerned that applications can rely on the old >> (incorrect) foreign key direction. >> >> In the process I've found that Hibernate treats: >> >> @OneToOne >> @PrimaryKeyJoinColumn >> private Employee employee; >> >> differently from: >> >> @OneToOne >> @MapsId >> private Employee employee; >> >> I believe they should be treated consistently. You can see my reasoning >> below. [1] >> >> Before going into details about how they are treated differently, I'd >> like to get confirmation, in case I am missing some subtlety. >> >> Could someone please confirm this? >> >> Regards, >> Gail >> >> ------------------------------------------------------------ >> --------------------------------- >> [1] >> >> In 2.4.1.3 Examples of Derived Identities, Example 4(b) uses MapsId >> without the value element as follows: >> >> @MapsId >> @JoinColumn(name="FK") >> @OneToOne Person patient; >> >> This example has the following footnote: >> "[15] Note that the use of PrimaryKeyJoinColumn instead of MapsId would >> result in the same mapping in this example. Use of MapsId >> is preferred for the mapping of derived identities." >> >> The description has a footnote that says that using PrimaryKeyJoinColumn >> instead of MapsId would result in the same mapping. >> >> In 11.1.45 PrimaryKeyJoinColumns Annotation, Example 2 uses >> @PrimaryKeyJoinColumns as follows: >> >> @OneToOne >> @PrimaryKeyJoinColumns({ >> @PrimaryKeyJoinColumn(name="ID", >> referencedColumnName="EMP_ID"), >> @PrimaryKeyJoinColumn(name="NAME", >> referencedColumnName="EMP_NAME")}) >> EmployeeInfo info; >> >> This example has the following footnote: >> "[123]Note that the derived identity mechanisms decribed in section >> 2.4.1.1 is now preferred to the use of PrimaryKeyJoinColumn for >> this case." >> >> From mihalcea.vlad at gmail.com Mon Sep 3 02:17:18 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 3 Sep 2018 09:17:18 +0300 Subject: [hibernate-dev] @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element In-Reply-To: References: Message-ID: Here are my comments: 1. I think the @MapsId behavior is the right one even if we don't enable cascading on the child-side. Although theoretically, we should not do that, in reality, if we disable this behavior, some apps will break. We could document the behavior so that, when used @MapdId or PKJC, Hibernate is allowed to cascade the parent if it's transient. 2. According to the JPA spec, the @OneToOne optional attribute is defined like this: (Optional) Whether the association is optional. > If set to false then a non-null relationship must > always exist. I don't think that `optional` should be related to the FK generation. For me, `optional` is more like adding NOT NULL to the FK column. 3. This reminds me of this Jira issue: https://hibernate.atlassian.net/browse/HHH-12770 I guess it makes sense to have what you proposed: Is this expected? If so, then ChildMapsId#parent cannot be optional by > default (without @NotFound(IGNORE). As for these questions: 1) the application must initialize ChildPKJC#id before persisting the > entity [1]; otherwise, the following exception is thrown: > javax.persistence.PersistenceException: > org.hibernate.id.IdentifierGenerationException: ids for this class must be > manually assigned before calling save(): This is a consequence of the current behavior. I've added this phrase to explain what happens. If we change the behavior, we should update the doc too. Related to: [2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of the > spec has this footnote: > [12] If the application does not set the primary key attribute > corresponding to the relationship, the value of that attribute may not be > available until after the entity has been flushed to the database. They say "may not", meaning that setting the ID prior to flushing is not going to break the spec. For sequence identifiers, we always get the ID generated prior to the flush anyway. And for: [3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote: > [121]It is not expected that a database foreign key be defined for the > OneToOne mapping, as the OneToOne relationship may be defined as > ?optional=true?. I don't think that makes any sense at all. The real one-to-one database table relationship is supposed to use a FK. Now, without MapsId or PKJC, we actually have a "one-to-many" table relationship with a UNIQUE constraint. Even so, the FK is always mandatory. I have no idea why the JPA spec says that. Vlad On Sat, Sep 1, 2018 at 10:33 AM, Gail Badner wrote: > FWIW, I've already spent a lot of time looking into the possible bugs I've > described. I have a good idea about how to fix each one, so there's no need > to research these. At this point, I'm just trying to get confirmation of > whether they really are bugs. > > On Sat, Sep 1, 2018 at 12:21 AM, Gail Badner wrote: > > > FYI, I am taking PTO Tuesday, 9/4. I hope to be able to move forward on > > this when I return on 9/5. > > > > I see some differences. Some may be expected, but I think there are some > > bugs. > > > > For example, suppose we have the following entities: > > > > @Entity > > public class Parent { > > @Id > > private Long id; > > } > > > > @Entity > > public class ChildPKJC { > > @Id > > private Long id; > > > > @OneToOne // note that cascade-persist is not enabled > > @PrimaryKeyJoinColumn > > private Parent parent; > > } > > > > public class ChildMapsId { > > @Id > > private Long id; > > > > @OneToOne // note that cascade-persist is not enabled > > @MapsId > > private Parent parent; > > } > > > > ------------------------------------------------------------ > > ------------------------------------------------------------ > > ------------------- > > > > When persisting ChildPKJC: > > > > 1) the application must initialize ChildPKJC#id before persisting the > > entity [1]; otherwise, the following exception is thrown: > > javax.persistence.PersistenceException: org.hibernate.id. > IdentifierGenerationException: > > ids for this class must be manually assigned before calling save(): > > > > 2) if ChildPKJC#parent is new with an assigned ID, and ChildPKJC#id is > > assigned parent's ID, the ChildPKJC Entity is persisted with the parent's > > ID, but parent is not persisted. > > > > When persisting ChildMapsId: > > > > 1) Hibernate automatically initializes ChildMapsId#id to parent.id [2] > > > > 2) if ChildMapsId#parent is new, parent is automatically > > cascade-persisted (even though CascadeStyle.PERSIST is not mapped), then > > the ChildMapsId entity is persisted. > > > > Are these expected difference? (My guess is yes) > > > > ------------------------------------------------------------ > > ------------------------------------------------------------ > > ------------------- > > > > Foreign key generation: > > > > If ChildPKJC#parent is optional there is no foreign key generated from > ChildPKJC > > referencing Parent. [3] If ChildPKJC#parent is not optional, a foreign > > key is generated > > > > For ChildMapsId, a foreign key is generated from ChildPKJC referencing > > Parent, even if ChildMapsId#parent is optional. > > > > Is this a bug? My guess is that it is. > > > > Adding the following mapping to ChildMapsId#parent works to disable > > foreign key generation: > > @JoinColumn(foreignKey = @ForeignKey(value = > ConstraintMode.NO_CONSTRAINT)) > > > > (can be used as a workaround) > > > > ------------------------------------------------------------ > > ------------------------------------------------------------ > > ------------------- > > > > Loading an existing ChildPKJC/ChildMapsId with an optional Parent > > association by ID, when there is no Parent entity with the same ID (IIUC, > > this is the only way that ChildPKJC#parent or ChildMapsId#parent can be > > optional [3]): > > > > For ChildPKJC, the loaded ChildPKJC entity will have a null parent. There > > is no need to add @NotFound(IGNORE) to ChildPKJC#parent. > > > > If ChildPKJC#parent is optional, it is always eagerly loaded. > > > > This makes sense, since we cannot create a proxy if there is the > > possibility of a null Parent entity. > > > > For ChildMapsId, the loaded value will be null because > ObjectNotFoundException > > will be thrown when Hibernate tries to load the Parent entity. > > Adding @NotFound(IGNORE) to ChildMapsId#parent will result in ChildMapsId > > entity being loaded with a null parent association. > > > > Is this expected? If so, then ChildMapsId#parent cannot be optional by > > default (without @NotFound(IGNORE). > > > > I think it would make more sense if the ChildMapsId entity is loaded with > > a null parent association, consistent with what happens for ChildPKJC. If > > we go that route, then ChildMapsId#parent will always have to be loaded > > eagerly. > > > > ------------------------------------------------------------ > > ------------------------------------------------------------ > > ------------------- > > > > Please let me know your thoughts on this. > > > > [1] this requirement is documented in Example 178. Derived identifier > > @PrimaryKeyJoinColumn with a note that says: "Unlike @MapsId, the > > application developer is responsible for ensuring that the identifier and > > the many-to-one (or one-to-one) association are in sync as you can see in > > the PersonDetails#setPerson method." > > > > [2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of the > > spec has this footnote: > > [12] If the application does not set the primary key attribute > > corresponding to the relationship, the value of that attribute may not be > > available until after the entity has been flushed to the database. > > > > [3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote: > > [121]It is not expected that a database foreign key be defined for the > > OneToOne mapping, as the OneToOne relationship may be defined as > > ?optional=true?. > > > > > > On Fri, Aug 31, 2018 at 1:29 PM, Gail Badner wrote: > > > >> The fix for HHH-12436 involves correcting the foreign key direction for > >> "real" one-to-one associations. I've been looking into the > ramifications of > >> this change because I'm concerned that applications can rely on the old > >> (incorrect) foreign key direction. > >> > >> In the process I've found that Hibernate treats: > >> > >> @OneToOne > >> @PrimaryKeyJoinColumn > >> private Employee employee; > >> > >> differently from: > >> > >> @OneToOne > >> @MapsId > >> private Employee employee; > >> > >> I believe they should be treated consistently. You can see my reasoning > >> below. [1] > >> > >> Before going into details about how they are treated differently, I'd > >> like to get confirmation, in case I am missing some subtlety. > >> > >> Could someone please confirm this? > >> > >> Regards, > >> Gail > >> > >> ------------------------------------------------------------ > >> --------------------------------- > >> [1] > >> > >> In 2.4.1.3 Examples of Derived Identities, Example 4(b) uses MapsId > >> without the value element as follows: > >> > >> @MapsId > >> @JoinColumn(name="FK") > >> @OneToOne Person patient; > >> > >> This example has the following footnote: > >> "[15] Note that the use of PrimaryKeyJoinColumn instead of MapsId would > >> result in the same mapping in this example. Use of MapsId > >> is preferred for the mapping of derived identities." > >> > >> The description has a footnote that says that using PrimaryKeyJoinColumn > >> instead of MapsId would result in the same mapping. > >> > >> In 11.1.45 PrimaryKeyJoinColumns Annotation, Example 2 uses > >> @PrimaryKeyJoinColumns as follows: > >> > >> @OneToOne > >> @PrimaryKeyJoinColumns({ > >> @PrimaryKeyJoinColumn(name="ID", > >> referencedColumnName="EMP_ID"), > >> @PrimaryKeyJoinColumn(name="NAME", > >> referencedColumnName="EMP_NAME")}) > >> EmployeeInfo info; > >> > >> This example has the following footnote: > >> "[123]Note that the derived identity mechanisms decribed in section > >> 2.4.1.1 is now preferred to the use of PrimaryKeyJoinColumn for > >> this case." > >> > >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Wed Sep 5 09:42:00 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 5 Sep 2018 15:42:00 +0200 Subject: [hibernate-dev] Hibernate Spatial - JTS update - compatibility issue Message-ID: Hi list, Karel, In https://hibernate.atlassian.net/browse/HHH-12144 , people are asking about a JTS upgrade and at least one person seems to be willing to contribute it. The issue is that in newer JTS versions, they have changed the package names so we would have a compatibility issue (see https://github.com/locationtech/jts/blob/master/MIGRATION.md), which, if I understand our spatial support correctly, would require hibernate-spatial users to change their own code. So the big question is: would that be acceptable to do in a potential 5.4 or should we wait for 6? I'm not exactly sure of the type of compatibility guarantees we offer for hibernate-spatial. Karel, do you have plans for it? Thanks, -- Guillaume From karel at geovise.com Wed Sep 5 11:13:28 2018 From: karel at geovise.com (Karel Maesen) Date: Wed, 5 Sep 2018 17:13:28 +0200 Subject: [hibernate-dev] Hibernate Spatial - JTS update - compatibility issue In-Reply-To: References: Message-ID: Hi Guillaume, We can do this in a 5.4. As a commenter on this issue correctly noted, geolatte-geom has already moved to 1.16.0-RC1, so the change in HS can follow quickly. We should wait for the official 1.16 release though before releasing it. I'll put the ticket into progress, and upgrade the geolatte-geom dependency so people can see the progress. Best regards, Karel On Wed, Sep 5, 2018 at 3:42 PM Guillaume Smet wrote: > Hi list, Karel, > > In https://hibernate.atlassian.net/browse/HHH-12144 , people are asking > about a JTS upgrade and at least one person seems to be willing to > contribute it. > > The issue is that in newer JTS versions, they have changed the package > names so we would have a compatibility issue (see > https://github.com/locationtech/jts/blob/master/MIGRATION.md), which, if > I understand our spatial support correctly, would require hibernate-spatial > users to change their own code. > > So the big question is: would that be acceptable to do in a potential 5.4 > or should we wait for 6? > > I'm not exactly sure of the type of compatibility guarantees we offer for > hibernate-spatial. > > Karel, do you have plans for it? > > Thanks, > > -- > Guillaume > From gbadner at redhat.com Wed Sep 5 20:05:41 2018 From: gbadner at redhat.com (Gail Badner) Date: Wed, 5 Sep 2018 17:05:41 -0700 Subject: [hibernate-dev] @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element In-Reply-To: References: Message-ID: Comments below... On Sun, Sep 2, 2018 at 11:17 PM, Vlad Mihalcea wrote: > Here are my comments: > > 1. I think the @MapsId behavior is the right one even if we don't enable > cascading on the child-side. > Although theoretically, we should not do that, in reality, if we disable > this behavior, some apps will break. > I don't know the history of why cascade-persist is forced. I see 2 jiras related to this (HHH-4858, HHH-4887). Emmanuel, can you provide some information about why this was added for @MapsId, but not @PrimaryKeyJoinColumn? I don't see anything in the spec about this. Am I missing something? I agree that removing cascade-persist from @MapsId now would cause applications to break. If this is Hibernate-specific behavior then shouldn't this functionality be enabled/disabled via a property ( e.g., hibernate.jpa.compliance.cascade_persist_id_associations) and JpaCompliance? The default would be "enabled". > > We could document the behavior so that, when used @MapdId or PKJC, > Hibernate is allowed to cascade the parent if it's transient. > > Do we really want to add this functionality with @PKJC at this point, since @MapsId is preferred, and cascade=CascadeType.PERSIST can easily be added to @OneToOne. > 2. According to the JPA spec, the @OneToOne optional attribute is defined > like this: > > (Optional) Whether the association is optional. >> If set to false then a non-null relationship must >> always exist. > > > I don't think that `optional` should be related to the FK generation. For > me, `optional` is more like adding NOT NULL to the FK column. > I think in this particular case, it is important. With the following mapping: @Entity public class ChildPKJC { @Id private Long id; @OneToOne // note that cascade-persist is not enabled @PrimaryKeyJoinColumn private Parent parent; } If ChildPKJC#parent is null, that means that ChildPKJC#id has a non-null value that does not correspond to a Parent ID. If this happens and there is a foreign key constraint, a constraint violation would occur. It seems to me that the spec supports this use case with @PKJC, and annotating with @NotFound(IGNORE) should not be necessary. Emmanuel, do you agree? Should using @MapsId instead of @PKJC work the same way? > 3. This reminds me of this Jira issue: > > https://hibernate.atlassian.net/browse/HHH-12770 > > I guess it makes sense to have what you proposed: > > Is this expected? If so, then ChildMapsId#parent cannot be optional by >> default (without @NotFound(IGNORE). > > > As for these questions: > > 1) the application must initialize ChildPKJC#id before persisting the >> entity [1]; otherwise, the following exception is thrown: >> javax.persistence.PersistenceException: >> org.hibernate.id.IdentifierGenerationException: ids for this class must >> be >> manually assigned before calling save(): > > > This is a consequence of the current behavior. I've added this phrase to > explain what happens. > If we change the behavior, we should update the doc too. > > Related to: > > [2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of the >> spec has this footnote: >> [12] If the application does not set the primary key attribute >> corresponding to the relationship, the value of that attribute may not be >> available until after the entity has been flushed to the database. > > > They say "may not", meaning that setting the ID prior to flushing is not > going to break the spec. > For @MapsId, the spec seems to say that, if the application doesn't assign the ID attributes corresponding to a relationship, the persistence provider will assign ID attributes during flush (at the latest). I find the documentation on this topic to be confusing, so maybe I'm missing something. I don't see anything in the spec that this same behavior is expected for @PKJC. Emmanuel, please confirm. > > For sequence identifiers, we always get the ID generated prior to the > flush anyway. > > And for: > > [3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote: >> [121]It is not expected that a database foreign key be defined for the >> OneToOne mapping, as the OneToOne relationship may be defined as >> ?optional=true?. > > > I don't think that makes any sense at all. The real one-to-one database > table relationship is supposed to use a FK. > Now, without MapsId or PKJC, we actually have a "one-to-many" table > relationship with a UNIQUE constraint. > Even so, the FK is always mandatory. I have no idea why the JPA spec says > that. > Please see what I wrote above about this. Thanks, Gail > > Vlad > > > On Sat, Sep 1, 2018 at 10:33 AM, Gail Badner wrote: > >> FWIW, I've already spent a lot of time looking into the possible bugs I've >> described. I have a good idea about how to fix each one, so there's no >> need >> to research these. At this point, I'm just trying to get confirmation of >> whether they really are bugs. >> >> On Sat, Sep 1, 2018 at 12:21 AM, Gail Badner wrote: >> >> > FYI, I am taking PTO Tuesday, 9/4. I hope to be able to move forward on >> > this when I return on 9/5. >> > >> > I see some differences. Some may be expected, but I think there are some >> > bugs. >> > >> > For example, suppose we have the following entities: >> > >> > @Entity >> > public class Parent { >> > @Id >> > private Long id; >> > } >> > >> > @Entity >> > public class ChildPKJC { >> > @Id >> > private Long id; >> > >> > @OneToOne // note that cascade-persist is not enabled >> > @PrimaryKeyJoinColumn >> > private Parent parent; >> > } >> > >> > public class ChildMapsId { >> > @Id >> > private Long id; >> > >> > @OneToOne // note that cascade-persist is not enabled >> > @MapsId >> > private Parent parent; >> > } >> > >> > ------------------------------------------------------------ >> > ------------------------------------------------------------ >> > ------------------- >> > >> > When persisting ChildPKJC: >> > >> > 1) the application must initialize ChildPKJC#id before persisting the >> > entity [1]; otherwise, the following exception is thrown: >> > javax.persistence.PersistenceException: org.hibernate.id.IdentifierGen >> erationException: >> > ids for this class must be manually assigned before calling save(): >> > >> > 2) if ChildPKJC#parent is new with an assigned ID, and ChildPKJC#id is >> > assigned parent's ID, the ChildPKJC Entity is persisted with the >> parent's >> > ID, but parent is not persisted. >> > >> > When persisting ChildMapsId: >> > >> > 1) Hibernate automatically initializes ChildMapsId#id to parent.id [2] >> > >> > 2) if ChildMapsId#parent is new, parent is automatically >> > cascade-persisted (even though CascadeStyle.PERSIST is not mapped), then >> > the ChildMapsId entity is persisted. >> > >> > Are these expected difference? (My guess is yes) >> > >> > ------------------------------------------------------------ >> > ------------------------------------------------------------ >> > ------------------- >> > >> > Foreign key generation: >> > >> > If ChildPKJC#parent is optional there is no foreign key generated from >> ChildPKJC >> > referencing Parent. [3] If ChildPKJC#parent is not optional, a foreign >> > key is generated >> > >> > For ChildMapsId, a foreign key is generated from ChildPKJC referencing >> > Parent, even if ChildMapsId#parent is optional. >> > >> > Is this a bug? My guess is that it is. >> > >> > Adding the following mapping to ChildMapsId#parent works to disable >> > foreign key generation: >> > @JoinColumn(foreignKey = @ForeignKey(value = >> ConstraintMode.NO_CONSTRAINT)) >> > >> > (can be used as a workaround) >> > >> > ------------------------------------------------------------ >> > ------------------------------------------------------------ >> > ------------------- >> > >> > Loading an existing ChildPKJC/ChildMapsId with an optional Parent >> > association by ID, when there is no Parent entity with the same ID >> (IIUC, >> > this is the only way that ChildPKJC#parent or ChildMapsId#parent can be >> > optional [3]): >> > >> > For ChildPKJC, the loaded ChildPKJC entity will have a null parent. >> There >> > is no need to add @NotFound(IGNORE) to ChildPKJC#parent. >> > >> > If ChildPKJC#parent is optional, it is always eagerly loaded. >> > >> > This makes sense, since we cannot create a proxy if there is the >> > possibility of a null Parent entity. >> > >> > For ChildMapsId, the loaded value will be null because >> ObjectNotFoundException >> > will be thrown when Hibernate tries to load the Parent entity. >> > Adding @NotFound(IGNORE) to ChildMapsId#parent will result in >> ChildMapsId >> > entity being loaded with a null parent association. >> > >> > Is this expected? If so, then ChildMapsId#parent cannot be optional by >> > default (without @NotFound(IGNORE). >> > >> > I think it would make more sense if the ChildMapsId entity is loaded >> with >> > a null parent association, consistent with what happens for ChildPKJC. >> If >> > we go that route, then ChildMapsId#parent will always have to be loaded >> > eagerly. >> > >> > ------------------------------------------------------------ >> > ------------------------------------------------------------ >> > ------------------- >> > >> > Please let me know your thoughts on this. >> > >> > [1] this requirement is documented in Example 178. Derived identifier >> > @PrimaryKeyJoinColumn with a note that says: "Unlike @MapsId, the >> > application developer is responsible for ensuring that the identifier >> and >> > the many-to-one (or one-to-one) association are in sync as you can see >> in >> > the PersonDetails#setPerson method." >> > >> > [2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of >> the >> > spec has this footnote: >> > [12] If the application does not set the primary key attribute >> > corresponding to the relationship, the value of that attribute may not >> be >> > available until after the entity has been flushed to the database. >> > >> > [3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote: >> > [121]It is not expected that a database foreign key be defined for the >> > OneToOne mapping, as the OneToOne relationship may be defined as >> > ?optional=true?. >> > >> > >> > On Fri, Aug 31, 2018 at 1:29 PM, Gail Badner >> wrote: >> > >> >> The fix for HHH-12436 involves correcting the foreign key direction for >> >> "real" one-to-one associations. I've been looking into the >> ramifications of >> >> this change because I'm concerned that applications can rely on the old >> >> (incorrect) foreign key direction. >> >> >> >> In the process I've found that Hibernate treats: >> >> >> >> @OneToOne >> >> @PrimaryKeyJoinColumn >> >> private Employee employee; >> >> >> >> differently from: >> >> >> >> @OneToOne >> >> @MapsId >> >> private Employee employee; >> >> >> >> I believe they should be treated consistently. You can see my reasoning >> >> below. [1] >> >> >> >> Before going into details about how they are treated differently, I'd >> >> like to get confirmation, in case I am missing some subtlety. >> >> >> >> Could someone please confirm this? >> >> >> >> Regards, >> >> Gail >> >> >> >> ------------------------------------------------------------ >> >> --------------------------------- >> >> [1] >> >> >> >> In 2.4.1.3 Examples of Derived Identities, Example 4(b) uses MapsId >> >> without the value element as follows: >> >> >> >> @MapsId >> >> @JoinColumn(name="FK") >> >> @OneToOne Person patient; >> >> >> >> This example has the following footnote: >> >> "[15] Note that the use of PrimaryKeyJoinColumn instead of MapsId would >> >> result in the same mapping in this example. Use of MapsId >> >> is preferred for the mapping of derived identities." >> >> >> >> The description has a footnote that says that using >> PrimaryKeyJoinColumn >> >> instead of MapsId would result in the same mapping. >> >> >> >> In 11.1.45 PrimaryKeyJoinColumns Annotation, Example 2 uses >> >> @PrimaryKeyJoinColumns as follows: >> >> >> >> @OneToOne >> >> @PrimaryKeyJoinColumns({ >> >> @PrimaryKeyJoinColumn(name="ID", >> >> referencedColumnName="EMP_ID"), >> >> @PrimaryKeyJoinColumn(name="NAME", >> >> referencedColumnName="EMP_NAME")}) >> >> EmployeeInfo info; >> >> >> >> This example has the following footnote: >> >> "[123]Note that the derived identity mechanisms decribed in section >> >> 2.4.1.1 is now preferred to the use of PrimaryKeyJoinColumn for >> >> this case." >> >> >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From rory.odonnell at oracle.com Fri Sep 7 05:41:06 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 7 Sep 2018 10:41:06 +0100 Subject: [hibernate-dev] JDK 12 & JMC 7.0.0 Early Access builds are available Message-ID: Hi Sanne, *JDK 11 build 28 is our first JDK 11 Release Candidate [1] * * JDK 11 build 28 is available at : - jdk.java.net/11/ *JDK 12 Early Access build 10 is available at : - jdk.java.net/12/* * Release Notes for JDK 12 [2] * *JEPs integrated to JDK 12:* o 325: Switch Expressions (Preview [3]) * *JEPs proposed to target JDK 12:* o 326: Raw String Literals (Preview [3]) *FOSS bug fixes in recent builds.* * Apache Ant - JDK-8209965(b09) *Other important fixes in JDK 12* * Disabled all DES TLS Cipher Suites (JDK-8208350 ) o DES-based TLS cipher suites are considered obsolete and should no longer be used *JMC 7.0.0 Early Access build 04 is available at :- **http://jdk.java.net/jmc/* * Overview - summary [4] * These early-access, open-source builds are provided under the Universal Permissive License, version?1.0. * Feedback via the http://bugreport.java.com/ o Be sure to include jmc application Build id from "Help" - "About JDK Mission Control". Rgds, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001844.html [2] http://jdk.java.net/12/release-notes [3] http://openjdk.java.net/jeps/12 [4] https://download.java.net/java/early_access/jmc7/core/common/docs/api/overview-summary.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From yoann at hibernate.org Mon Sep 10 05:57:30 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 10 Sep 2018 11:57:30 +0200 Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central Message-ID: Hello, Even though it was released almost two weeks ago, Hibernate ORM 5.1.16.Final does not seem to be on Central: * https://search.maven.org/search?q=g:org.hibernate%20AND%20a:hibernate-core%20AND%20v:5.1.16.Final * https://repo1.maven.org/maven2/org/hibernate/hibernate-core/5.1.16.Final/ I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should report this issue to someone? Guillaume, maybe the same people you reported your Validator issue to? Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From steve at hibernate.org Mon Sep 10 08:33:57 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 10 Sep 2018 07:33:57 -0500 Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central In-Reply-To: References: Message-ID: Often when releasing to BinTray I have to manually trigger the sync to Central. Not sure why and it's never been a big enough issue to investigate - I just know to check as part of my release process. It would ultimately be great to figure out why the auto sync does not work. On Mon, Sep 10, 2018, 4:58 AM Yoann Rodiere wrote: > Hello, > > Even though it was released almost two weeks ago, Hibernate ORM > 5.1.16.Final does not seem to be on Central: > > * > > https://search.maven.org/search?q=g:org.hibernate%20AND%20a:hibernate-core%20AND%20v:5.1.16.Final > * > https://repo1.maven.org/maven2/org/hibernate/hibernate-core/5.1.16.Final/ > > I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should > report this issue to someone? Guillaume, maybe the same people you reported > your Validator issue to? > > 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 guillaume.smet at gmail.com Mon Sep 10 08:38:50 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 10 Sep 2018 14:38:50 +0200 Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central In-Reply-To: References: Message-ID: On Mon, Sep 10, 2018 at 2:34 PM Steve Ebersole wrote: > Often when releasing to BinTray I have to manually trigger the sync to > Central. Not sure why and it's never been a big enough issue to > investigate - I just know to check as part of my release process. > I think 5.1 is still using Nexus so it's the same sync problem I have with HV. Other than that, yes, for all the 5.3 releases I did, I had to manually trigger the sync in the Bintray interface. -- Guillaume From guillaume.smet at gmail.com Mon Sep 10 08:42:32 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 10 Sep 2018 14:42:32 +0200 Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central In-Reply-To: References: Message-ID: On Mon, Sep 10, 2018 at 11:58 AM Yoann Rodiere wrote: > I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should > report this issue to someone? Guillaume, maybe the same people you reported > your Validator issue to? > I reported it in the issue I opened for HV a while ago. Don't hold your breath :). -- Guillaume From yoann at hibernate.org Mon Sep 10 09:15:03 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 10 Sep 2018 15:15:03 +0200 Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central In-Reply-To: References: Message-ID: Thanks Guillaume, at least it's on someone else's plate now :) Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Mon, 10 Sep 2018 at 14:43, Guillaume Smet wrote: > On Mon, Sep 10, 2018 at 11:58 AM Yoann Rodiere > wrote: > >> I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should >> report this issue to someone? Guillaume, maybe the same people you >> reported >> your Validator issue to? >> > > I reported it in the issue I opened for HV a while ago. > > Don't hold your breath :). > > -- > Guillaume > From gunnar at hibernate.org Tue Sep 11 05:31:21 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 11 Sep 2018 11:31:21 +0200 Subject: [hibernate-dev] [ORM] Support for upsert semantics Message-ID: Hi, A common requirement that comes up repeatedly is "upsert" operations, i.e. either insert a record or update the existing one with the same PK, if it already exists. Many (most?) RDBMS support it, either by implementing SQL 2003's MERGE keyword or via proprietary alternatives [1]. I think it'd be great if there was something like Session#upsert(), exposing these semantics at the entity level. Perhaps the idea was already brought up in the past, but I wanted to throw it out in any case. Any thoughts? Cheers, --Gunnar [1] https://vladmihalcea.com/how-do-upsert-and-merge-work-in-oracle-sql-server-postgresql-and-mysql/ From guillaume.smet at gmail.com Tue Sep 11 09:20:06 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 11 Sep 2018 15:20:06 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's meeting: 15:18 < jbott> Meeting ended Tue Sep 11 13:18:04 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:18 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-11-13.00.html 15:18 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-11-13.00.txt 15:18 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-11-13.00.log.html Cheers, -- Guillaume From steve at hibernate.org Tue Sep 11 09:38:54 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 11 Sep 2018 08:38:54 -0500 Subject: [hibernate-dev] [ORM] Support for upsert semantics In-Reply-To: References: Message-ID: It's been discussed several times in the past. We already have something very similar - `Session#saveOrUpdate`. So what exactly is the difference semantically? There really is none. There is, however, a practical difference... `Session#saveOrUpdate` handling leverages Hibernate's "unsaved value"[1] to decided between an INSERT and an UPDATE. In most cases, this is an extremely efficient decision. However, for an entity that (1) is unversioned and (2) uses assigned identifiers, Hibernate will actually perform a SELECT to make this decision. So it is conceivable to handle all `Session#saveOrUpdate` or maybe just this special case using an UPSERT. However, there are also cases where we simply cannot use UPSERT. The main one that comes to mind as particularly difficult is an entity which defines one or more properties (or sub-embedded properties) as insertable=true & updatable=false, or vice-versa. All-in-all I am just not convinced that the effort is worth it given the limited applicability. But certainly, if someone wanted to implement such a thing we should consider including it. Now, internally there is a case where we might be able to leverage UPSERTs for performance... Namely when updating an entity with optional secondary tables we will first try to update the row in the secondary table and then, if a row did not exist, insert one. We could change this to leverage UPSERT. However, we still have the same limitation with regard to insertable/updatable here as well. [1] HBM's `, don't think we have an annotation equivalent though at the moment. We have a pretty decent algorithm for "guessing" the unsaved value. On Tue, Sep 11, 2018 at 4:32 AM Gunnar Morling wrote: > Hi, > > A common requirement that comes up repeatedly is "upsert" operations, i.e. > either insert a record or update the existing one with the same PK, if it > already exists. Many (most?) RDBMS support it, either by implementing SQL > 2003's MERGE keyword or via proprietary alternatives [1]. > > I think it'd be great if there was something like Session#upsert(), > exposing these semantics at the entity level. Perhaps the idea was already > brought up in the past, but I wanted to throw it out in any case. > > Any thoughts? > > Cheers, > > --Gunnar > > [1] > > https://vladmihalcea.com/how-do-upsert-and-merge-work-in-oracle-sql-server-postgresql-and-mysql/ > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Tue Sep 11 15:59:15 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 11 Sep 2018 12:59:15 -0700 Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central In-Reply-To: References: Message-ID: Strange. Any idea if this has anything to do with the maintenance done on Nexus? On Mon, Sep 10, 2018 at 6:15 AM, Yoann Rodiere wrote: > Thanks Guillaume, at least it's on someone else's plate now :) > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Mon, 10 Sep 2018 at 14:43, Guillaume Smet > wrote: > > > On Mon, Sep 10, 2018 at 11:58 AM Yoann Rodiere > > wrote: > > > >> I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should > >> report this issue to someone? Guillaume, maybe the same people you > >> reported > >> your Validator issue to? > >> > > > > I reported it in the issue I opened for HV a while ago. > > > > Don't hold your breath :). > > > > -- > > Guillaume > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From yoann at hibernate.org Wed Sep 12 03:01:08 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Wed, 12 Sep 2018 09:01:08 +0200 Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central In-Reply-To: References: Message-ID: Same goes with the Hibernate Search artifacts I published about 36 hours ago. I updated the JBoss Nexus ticket. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Tue, 11 Sep 2018 at 21:59, Gail Badner wrote: > Strange. Any idea if this has anything to do with the maintenance done on > Nexus? > > On Mon, Sep 10, 2018 at 6:15 AM, Yoann Rodiere > wrote: > >> Thanks Guillaume, at least it's on someone else's plate now :) >> >> Yoann Rodi?re >> Hibernate NoORM Team >> yoann at hibernate.org >> >> >> On Mon, 10 Sep 2018 at 14:43, Guillaume Smet >> wrote: >> >> > On Mon, Sep 10, 2018 at 11:58 AM Yoann Rodiere >> > wrote: >> > >> >> I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should >> >> report this issue to someone? Guillaume, maybe the same people you >> >> reported >> >> your Validator issue to? >> >> >> > >> > I reported it in the issue I opened for HV a while ago. >> > >> > Don't hold your breath :). >> > >> > -- >> > Guillaume >> > >> _______________________________________________ >> 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 Sep 13 03:52:08 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 13 Sep 2018 09:52:08 +0200 Subject: [hibernate-dev] Hibernate ORM 5.1.16.Final is not on Maven Central In-Reply-To: References: Message-ID: ORM 5.1.16 is now available on Central. On Wed, Sep 12, 2018 at 9:01 AM Yoann Rodiere wrote: > Same goes with the Hibernate Search artifacts I published about 36 hours > ago. > > I updated the JBoss Nexus ticket. > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > > > On Tue, 11 Sep 2018 at 21:59, Gail Badner wrote: > >> Strange. Any idea if this has anything to do with the maintenance done on >> Nexus? >> >> On Mon, Sep 10, 2018 at 6:15 AM, Yoann Rodiere >> wrote: >> >>> Thanks Guillaume, at least it's on someone else's plate now :) >>> >>> Yoann Rodi?re >>> Hibernate NoORM Team >>> yoann at hibernate.org >>> >>> >>> On Mon, 10 Sep 2018 at 14:43, Guillaume Smet >>> wrote: >>> >>> > On Mon, Sep 10, 2018 at 11:58 AM Yoann Rodiere >>> > wrote: >>> > >>> >> I'll stick to 5.1.15 for now in Hibernate Search, but maybe we should >>> >> report this issue to someone? Guillaume, maybe the same people you >>> >> reported >>> >> your Validator issue to? >>> >> >>> > >>> > I reported it in the issue I opened for HV a while ago. >>> > >>> > Don't hold your breath :). >>> > >>> > -- >>> > Guillaume >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> From yoann at hibernate.org Thu Sep 13 04:00:51 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 13 Sep 2018 10:00:51 +0200 Subject: [hibernate-dev] Hibernate Search 5.10.4.Final, 5.9.4.Final, 5.6.6.Final released Message-ID: Hello, We just published maintenance releases for the three actively maintained branches of Hibernate Search. They upgrade Hibernate Search to the latest compatible Hibernate ORM versions and fixes an issue with spatial bridges. See our blog for more information: http://in.relation.to/2018/09/13/hibernate-search-5-10-4-Final-5-9-3-Final-5-6-6-Final/ Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From yoann at hibernate.org Thu Sep 13 04:02:16 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 13 Sep 2018 10:02:16 +0200 Subject: [hibernate-dev] Hibernate Search 5.10.4.Final, 5.9.4.Final, 5.6.6.Final released In-Reply-To: References: Message-ID: Sorry for the confusion: it is 5.9.3.Final and not 5.9.4.Final. Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org On Thu, 13 Sep 2018 at 10:00, Yoann Rodiere wrote: > Hello, > > We just published maintenance releases for the three actively maintained > branches of Hibernate Search. They upgrade Hibernate Search to the latest > compatible Hibernate ORM versions and fixes an issue with spatial bridges. > > See our blog for more information: > http://in.relation.to/2018/09/13/hibernate-search-5-10-4-Final-5-9-3-Final-5-6-6-Final/ > > Yoann Rodi?re > Hibernate NoORM Team > yoann at hibernate.org > From steve at hibernate.org Fri Sep 14 12:20:06 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 14 Sep 2018 11:20:06 -0500 Subject: [hibernate-dev] Loggers Message-ID: Yes, I know no one likes talking about logging. "Its not important", until it is ;) TLDR I am considering moving to using "module names" for logger names instead of Class names even for DEBUG/TRACE logging and see if anyone had strong arguments to not do this.. Full version--- For some time I have been moving to an approach of defining message loggers[1] using a single contract per function or "module" - e.g.: 1. the second level caching module uses the dedicated message logger `ConnectionPoolingLogger` 2. the ManagedBeanRegistry module uses the dedicated message logger `BeansMessageLogger` 3. etc Each of these define a dedicate instance instance they can use. E.g. ConnectionPoolingLogger is defined as: ```` @MessageLogger( projectCode = "HHH" ) @ValidIdRange( min = 10001001, max = 10001500 ) public interface ConnectionPoolingLogger extends BasicLogger { ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger( ConnectionPoolingLogger.class, "org.hibernate.orm.connections.pooling" ); ... } ```` I won't get into all the whys I do this unless someone cares ;) But I am contemplating doing the same for basic loggers so I wanted to ask everyone else's opinion since this means a change in how you'd have to configure logging for DEBUG/TRACE output. Usually you'd use the Class name as the logger name and use that to control logging in the back-end (log4j, etc). If I do this, you'd have to instead use the module name. There are quite a few reasons I am considering this, including all of the reasons I did it for message loggers in the first place. If I am debugging the loading of a collection or an entity, today I'd have to know all the packages involved (there is no common root name) and list them in my log4j.properties; that is because the process is ultimately handled by delegates or helpers in many different packages (`org.hibernate.loader`, `org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be nice to just be able to say `org.hibernate.loading` or `org.hibernate.loading.entity` or `org.hibernate.loading.collection` or ... for a number of reasons: 1. When we need to see logging from someone it is a lot easier to tell the module name(s) you need enabled as opposed a list of package and class names. 2. When running JPA TCK it is essentially impossible to attach debugger to step through code when debugging a failure - you have to rely on debugging through output. *Well that used to be the case, but the latest TCK broke logging to STDOUT somehow so we ended up having to try and reproduce the failure in our testsuite - so then it does not matter either way ;)* 3. Easier to document - http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Logging.html Thoughts? [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which we use for user-focused log messages. Should always be logged at >= INFO [2] [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for developer-focused log messages (for debugging). Should always be logged at DEBUG or TRACE From smarlow at redhat.com Fri Sep 14 16:14:33 2018 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 14 Sep 2018 16:14:33 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? Message-ID: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> I'm deploying an application with two persistence units however, the ServiceContributor contribute(StandardServiceRegistryBuilder) [1] is only being called once, instead of per SessionFactory/EMF (or so it seems). Is there a way to have the contribute(StandardServiceRegistryBuilder) be called per SessionFactory/EMF instead? Scott [1] https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 From steve at hibernate.org Fri Sep 14 18:14:02 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 14 Sep 2018 17:14:02 -0500 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> Message-ID: Doing so would require a programatic call while bootstrapping Hibernate. The ServiceContributors are applied during `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` processing. So we'd need a call to register a ServiceContributor with the StandardServiceRegistryBuilder. Of course that also means you'd have to have access to the StandardServiceRegistryBuilder On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow wrote: > I'm deploying an application with two persistence units however, the > ServiceContributor contribute(StandardServiceRegistryBuilder) [1] is > only being called once, instead of per SessionFactory/EMF (or so it seems). > > Is there a way to have the contribute(StandardServiceRegistryBuilder) be > called per SessionFactory/EMF instead? > > Scott > > [1] > > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Sep 14 18:15:21 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 14 Sep 2018 17:15:21 -0500 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> Message-ID: Another thought. If you are specifically talking about JPA container integration we could always accept ServiceContributor(s) via the integration values Map. On Fri, Sep 14, 2018 at 10:14 PM Steve Ebersole wrote: > Doing so would require a programatic call while bootstrapping Hibernate. > The ServiceContributors are applied during > `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > processing. So we'd need a call to register a ServiceContributor with the > StandardServiceRegistryBuilder. > > Of course that also means you'd have to have access to the > StandardServiceRegistryBuilder > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow wrote: > >> I'm deploying an application with two persistence units however, the >> ServiceContributor contribute(StandardServiceRegistryBuilder) [1] is >> only being called once, instead of per SessionFactory/EMF (or so it >> seems). >> >> Is there a way to have the contribute(StandardServiceRegistryBuilder) be >> called per SessionFactory/EMF instead? >> >> Scott >> >> [1] >> >> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From gbadner at redhat.com Mon Sep 17 14:56:16 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 17 Sep 2018 11:56:16 -0700 Subject: [hibernate-dev] Fwd: Fwd: @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element In-Reply-To: <20180912125426.GE47868@redhat.com> References: <20180912125426.GE47868@redhat.com> Message-ID: Forwarding Emmanuel's responses, which reduces the scope of what I thought was buggy behavior. There are still some weird cases though. I'll hone in on those in a separate thread. ---------- Forwarded message ---------- From: Emmanuel Bernard Date: Wed, Sep 12, 2018 at 5:54 AM Subject: Re: Fwd: @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without value element To: Gail Badner Cc: Guillaume Smet On Wed 18-09-12 0:29, Gail Badner wrote: > Hibernate treats @OneToOne @PKJC differently from @OneToOne MapsId (without > a value element). I believe some of the differences are expected, but I > suspect some of the differences are bugs. In some cases, I'm not sure which > is treated correctly. > All my comments are caveat by me not having looked at this for years. Note that these are different features. @PKJC says that we don't create a new FK column, we reuse the id one. @MapsId says, copy the value of the id from that property and pretend it's an id generator. > I've also found that the following mapping has some problems: > > @OneToOne > @MapsId > @JoinColumn(name = "FK") > private Employee employee; > > Sometimes Hibernate treats that mapping like @OneToOne @PKJC; other cases > it treats that mapping like @OneToOne @MapsId. > > I'm in the process of documenting the differences in a Google document so > it can all be sorted out. > > As a start, it would help a lot if you could address the questions in this > email. > > I've gotten very familiar with the related code, so once I have the > answers, I'll know how to fix them. > > Thanks, > Gail > > ---------- Forwarded message ---------- > From: Gail Badner > Date: Sat, Sep 1, 2018 at 12:21 AM > Subject: Re: @OneToOne with @PrimaryKeyJoinColumn(s) vs @MapsId without > value element > To: hibernate-dev > > > FYI, I am taking PTO Tuesday, 9/4. I hope to be able to move forward on > this when I return on 9/5. > > I see some differences. Some may be expected, but I think there are some > bugs. > > For example, suppose we have the following entities: > > @Entity > public class Parent { > @Id > private Long id; > } > > @Entity > public class ChildPKJC { > @Id > private Long id; > > @OneToOne // note that cascade-persist is not enabled > @PrimaryKeyJoinColumn > private Parent parent; > } > > public class ChildMapsId { > @Id > private Long id; > > @OneToOne // note that cascade-persist is not enabled > @MapsId > private Parent parent; > } > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------- > > When persisting ChildPKJC: > > 1) the application must initialize ChildPKJC#id before persisting the > entity [1]; otherwise, the following exception is thrown: > javax.persistence.PersistenceException: > org.hibernate.id.IdentifierGenerationException: > ids for this class must be manually assigned before calling save(): > Sounds fine. > 2) if ChildPKJC#parent is new with an assigned ID, and ChildPKJC#id is > assigned parent's ID, the ChildPKJC Entity is persisted with the parent's > ID, but parent is not persisted. > Sounds fine. > When persisting ChildMapsId: > > 1) Hibernate automatically initializes ChildMapsId#id to parent.id [2] > Yes that's the expected behavior. > 2) if ChildMapsId#parent is new, parent is automatically cascade-persisted > (even though CascadeStyle.PERSIST is not mapped), then the ChildMapsId > entity > is persisted. > So that is not expressed in the spec but it might be that disabling that is making things too complex for the Hibernate ORM engine. I would not sweat too much on it. > Are these expected difference? (My guess is yes) > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------- > > Foreign key generation: > > If ChildPKJC#parent is optional there is no foreign key generated from > ChildPKJC > referencing Parent. > Sounds fine. [3] If ChildPKJC#parent is not optional, a foreign key > is generated > Sounds fine. > For ChildMapsId, a foreign key is generated from ChildPKJC referencing > Parent, even if ChildMapsId#parent is optional. > ChildMapsId cannot be optional as it is the generator of the id. So we ignore that the user has marked it optional. > Is this a bug? My guess is that it is. > Not to me, see above. > Adding the following mapping to ChildMapsId#parent works to disable foreign > key generation: > @JoinColumn(foreignKey = @ForeignKey(value = ConstraintMode.NO_CONSTRAINT)) > (can be used as a workaround) > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------- > > Loading an existing ChildPKJC/ChildMapsId with an optional Parent > association by ID, when there is no Parent entity with the same ID (IIUC, > this is the only way that ChildPKJC#parent or ChildMapsId#parent can be > optional [3]): > > For ChildPKJC, the loaded ChildPKJC entity will have a null parent. There > is no need to add @NotFound(IGNORE) to ChildPKJC#parent. > That's a bit weird but if the parent is not optional, why isn't there a parent in the database with the proper id. Feels like a data incoherence problem. If people have that,t hey must make it optional. > If ChildPKJC#parent is optional, it is always eagerly loaded. > > This makes sense, since we cannot create a proxy if there is the > possibility of a null Parent entity. > > For ChildMapsId, the loaded value will be null because > ObjectNotFoundException > will be thrown when Hibernate tries to load the Parent entity. > Right, this is a data incoherence, the parent must not be null. Adding @NotFound(IGNORE) to ChildMapsId#parent will result in ChildMapsId > entity being loaded with a null parent association. > > Is this expected? If so, then ChildMapsId#parent cannot be optional by > default (without @NotFound(IGNORE). > Again I don't think parent being null is valid for @MapsId > I think it would make more sense if the ChildMapsId entity is loaded with a > null parent association, consistent with what happens for ChildPKJC. If we > go that route, then ChildMapsId#parent will always have to be loaded > eagerly. > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------- > > Please let me know your thoughts on this. > > [1] this requirement is documented in Example 178. Derived identifier > @PrimaryKeyJoinColumn with a note that says: "Unlike @MapsId, the > application developer is responsible for ensuring that the identifier and > the many-to-one (or one-to-one) association are in sync as you can see in > the PersonDetails#setPerson method." > > [2] Section 2.4.1 Primary Keys Corresponding to Derived Identities of the > spec has this footnote: > [12] If the application does not set the primary key attribute > corresponding to the relationship, the value of that attribute may not be > available until after the entity has been flushed to the database. > > [3] Section 11.1.44 PrimaryKeyJoinColumn Annotation has a footnote: > [121]It is not expected that a database foreign key be defined for the > OneToOne mapping, as the OneToOne relationship may be defined as > ?optional=true?. > > > On Fri, Aug 31, 2018 at 1:29 PM, Gail Badner wrote: > > The fix for HHH-12436 involves correcting the foreign key direction for >> "real" one-to-one associations. I've been looking into the ramifications >> of >> this change because I'm concerned that applications can rely on the old >> (incorrect) foreign key direction. >> >> In the process I've found that Hibernate treats: >> >> @OneToOne >> @PrimaryKeyJoinColumn >> private Employee employee; >> >> differently from: >> >> @OneToOne >> @MapsId >> private Employee employee; >> >> I believe they should be treated consistently. You can see my reasoning >> below. [1] >> >> Before going into details about how they are treated differently, I'd like >> to get confirmation, in case I am missing some subtlety. >> >> Could someone please confirm this? >> >> Regards, >> Gail >> >> ------------------------------------------------------------ >> --------------------------------- >> [1] >> >> In 2.4.1.3 Examples of Derived Identities, Example 4(b) uses MapsId >> without the value element as follows: >> >> @MapsId >> @JoinColumn(name="FK") >> @OneToOne Person patient; >> >> This example has the following footnote: >> "[15] Note that the use of PrimaryKeyJoinColumn instead of MapsId would >> result in the same mapping in this example. Use of MapsId >> is preferred for the mapping of derived identities." >> >> The description has a footnote that says that using PrimaryKeyJoinColumn >> instead of MapsId would result in the same mapping. >> >> In 11.1.45 PrimaryKeyJoinColumns Annotation, Example 2 uses >> @PrimaryKeyJoinColumns as follows: >> >> @OneToOne >> @PrimaryKeyJoinColumns({ >> @PrimaryKeyJoinColumn(name="ID", >> referencedColumnName="EMP_ID"), >> @PrimaryKeyJoinColumn(name="NAME", >> referencedColumnName="EMP_NAME")}) >> EmployeeInfo info; >> >> This example has the following footnote: >> "[123]Note that the derived identity mechanisms decribed in section >> 2.4.1.1 is now preferred to the use of PrimaryKeyJoinColumn for >> this case." >> >> >> From yoann at hibernate.org Tue Sep 18 11:43:04 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 18 Sep 2018 17:43:04 +0200 Subject: [hibernate-dev] Broken link JIRA tickets Message-ID: Hello, FYI, I added default content to the JIRA tickets created from the 404 error page on hibernate.org, so that at the very least we have the exact broken link, and if available, the referrer. Before that, reporters had to check a box in order to add the information, and a lot did not... To see it in action: http://hibernate.org/foobar Yoann Rodi?re Hibernate NoORM Team yoann at hibernate.org From smarlow at redhat.com Tue Sep 18 14:43:09 2018 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 18 Sep 2018 14:43:09 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> Message-ID: On 9/14/18 6:14 PM, Steve Ebersole wrote: > Doing so would require a programatic call while bootstrapping > Hibernate.? The ServiceContributors are applied during > `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > processing.? So we'd need a call to register a ServiceContributor with > the StandardServiceRegistryBuilder. > > Of course that also means you'd have to have access to the > StandardServiceRegistryBuilder I don't have a way to add a programatic call while bootstrapping "not JPA container". > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow > wrote: > > I'm deploying an application with two persistence units however, the > ServiceContributor contribute(StandardServiceRegistryBuilder) [1] is > only being called once, instead of per SessionFactory/EMF (or so it > seems). > > Is there a way to have the > contribute(StandardServiceRegistryBuilder) be > called per SessionFactory/EMF instead? > > Scott > > [1] > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Tue Sep 18 14:43:32 2018 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 18 Sep 2018 14:43:32 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> Message-ID: <98575d79-81a4-d5e3-882f-c3cd52d80db8@redhat.com> On 9/14/18 6:15 PM, Steve Ebersole wrote: > Another thought.? If you are specifically talking about JPA container > integration we could always accept ServiceContributor(s) via the > integration values Map. This is for both JPA container integration and not container integration. > > On Fri, Sep 14, 2018 at 10:14 PM Steve Ebersole > wrote: > > Doing so would require a programatic call while bootstrapping > Hibernate.? The ServiceContributors are applied during > `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > processing.? So we'd need a call to register a ServiceContributor > with the StandardServiceRegistryBuilder. > > Of course that also means you'd have to have access to the > StandardServiceRegistryBuilder > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow > wrote: > > I'm deploying an application with two persistence units however, > the > ServiceContributor contribute(StandardServiceRegistryBuilder) > [1] is > only being called once, instead of per SessionFactory/EMF (or so > it seems). > > Is there a way to have the > contribute(StandardServiceRegistryBuilder) be > called per SessionFactory/EMF instead? > > Scott > > [1] > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Wed Sep 19 01:49:53 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 19 Sep 2018 08:49:53 +0300 Subject: [hibernate-dev] Loggers In-Reply-To: References: Message-ID: I think it's a good idea. However, will this break all current applications that use the package name log appenders? Vlad On Fri, Sep 14, 2018 at 7:20 PM, Steve Ebersole wrote: > Yes, I know no one likes talking about logging. "Its not important", until > it is ;) > > TLDR I am considering moving to using "module names" for logger names > instead of Class names even for DEBUG/TRACE logging and see if anyone had > strong arguments to not do this.. > > Full version--- > > For some time I have been moving to an approach of defining message > loggers[1] using a single contract per function or "module" - e.g.: > > 1. the second level caching module uses the dedicated message logger > `ConnectionPoolingLogger` > 2. the ManagedBeanRegistry module uses the dedicated message logger > `BeansMessageLogger` > 3. etc > > Each of these define a dedicate instance instance they can use. E.g. > ConnectionPoolingLogger is defined as: > > ```` > @MessageLogger( projectCode = "HHH" ) > @ValidIdRange( min = 10001001, max = 10001500 ) > public interface ConnectionPoolingLogger extends BasicLogger { > > ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger( > ConnectionPoolingLogger.class, > "org.hibernate.orm.connections.pooling" > ); > > ... > } > ```` > > I won't get into all the whys I do this unless someone cares ;) > > But I am contemplating doing the same for basic loggers so I wanted to ask > everyone else's opinion since this means a change in how you'd have to > configure logging for DEBUG/TRACE output. Usually you'd use the Class name > as the logger name and use that to control logging in the back-end (log4j, > etc). If I do this, you'd have to instead use the module name. > > There are quite a few reasons I am considering this, including all of the > reasons I did it for message loggers in the first place. If I am > debugging the loading of a collection or an entity, today I'd have to know > all the packages involved (there is no common root name) and list them in > my log4j.properties; that is because the process is ultimately handled by > delegates or helpers in many different packages (`org.hibernate.loader`, > `org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be > nice to just be able to say `org.hibernate.loading` or > `org.hibernate.loading.entity` or `org.hibernate.loading.collection` or > ... > for a number of reasons: > > 1. When we need to see logging from someone it is a lot easier to tell > the module name(s) you need enabled as opposed a list of package and > class > names. > 2. When running JPA TCK it is essentially impossible to attach debugger > to step through code when debugging a failure - you have to rely on > debugging through output. *Well that used to be the case, but the > latest TCK broke logging to STDOUT somehow so we ended up having to try > and > reproduce the failure in our testsuite - so then it does not matter > either > way ;)* > 3. Easier to document - > http://docs.jboss.org/hibernate/orm/5.3/topical/ > html_single/logging/Logging.html > > Thoughts? > > > [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which > we use for user-focused log messages. Should always be logged at >= INFO > [2] > [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for > developer-focused log messages (for debugging). Should always be logged at > DEBUG or TRACE > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Wed Sep 19 05:41:43 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 19 Sep 2018 11:41:43 +0200 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> Message-ID: Would SessionFactoryServiceContributor [1] be of use to you? It lets you add services to the SF-scoped service registry; not sure whether that suits your requirements or no. --Gunnar [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow : > > > On 9/14/18 6:14 PM, Steve Ebersole wrote: > > Doing so would require a programatic call while bootstrapping > > Hibernate. The ServiceContributors are applied during > > `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > > processing. So we'd need a call to register a ServiceContributor with > > the StandardServiceRegistryBuilder. > > > > Of course that also means you'd have to have access to the > > StandardServiceRegistryBuilder > > I don't have a way to add a programatic call while bootstrapping "not > JPA container". > > > > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow > > wrote: > > > > I'm deploying an application with two persistence units however, the > > ServiceContributor contribute(StandardServiceRegistryBuilder) [1] is > > only being called once, instead of per SessionFactory/EMF (or so it > > seems). > > > > Is there a way to have the > > contribute(StandardServiceRegistryBuilder) be > > called per SessionFactory/EMF instead? > > > > Scott > > > > [1] > > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > > _______________________________________________ > > 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 smarlow at redhat.com Wed Sep 19 09:12:32 2018 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 19 Sep 2018 09:12:32 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> Message-ID: <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> On 9/19/18 5:41 AM, Gunnar Morling wrote: > Would SessionFactoryServiceContributor [1] be of use to you? It lets you > add services to the SF-scoped service registry; not sure whether that > suits your requirements or no. Thanks, I will give that a try. We currently use RegionFactoryInitiator and update the configuration settings passed via RegionFactoryInitiator#resolveRegionFactory(Map configurationValues, ServiceRegistryImplementor). I wonder if that is possible with SessionFactoryServiceContributor? > > --Gunnar > > [1] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java > > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow > >: > > > > > > On 9/14/18 6:14 PM, Steve Ebersole wrote: > > > Doing so would require a programatic call while bootstrapping > > > Hibernate.? The ServiceContributors are applied during > > > `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > > > processing.? So we'd need a call to register a ServiceContributor with > > > the StandardServiceRegistryBuilder. > > > > > > Of course that also means you'd have to have access to the > > > StandardServiceRegistryBuilder > > > > I don't have a way to add a programatic call while bootstrapping "not > > JPA container". > > > > > > > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow > > > >> wrote: > > > > > > ? ? I'm deploying an application with two persistence units > however, the > > > ? ? ServiceContributor contribute(StandardServiceRegistryBuilder) > [1] is > > > ? ? only being called once, instead of per SessionFactory/EMF (or so it > > > ? ? seems). > > > > > > ? ? Is there a way to have the > > > ? ? contribute(StandardServiceRegistryBuilder) be > > > ? ? called per SessionFactory/EMF instead? > > > > > > ? ? Scott > > > > > > ? ? [1] > > > > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > > > ? ? _______________________________________________ > > > ? ? 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 Sep 19 09:20:28 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 19 Sep 2018 08:20:28 -0500 Subject: [hibernate-dev] Loggers In-Reply-To: References: Message-ID: Yes. As I mentioned in my original, this would mean potential changes for people configuring logging. I've started doing this for new logging in 6 and it works great. Mainly asking opinions about changing existing logging and whether the benefits are worth the effort. And keep in mind that the many many changes in 6 already would require such logging config changes anyway for those configuring logging On Wed, Sep 19, 2018, 12:50 AM Vlad Mihalcea wrote: > I think it's a good idea. > > However, will this break all current applications that use the package > name log appenders? > > Vlad > > On Fri, Sep 14, 2018 at 7:20 PM, Steve Ebersole > wrote: > >> Yes, I know no one likes talking about logging. "Its not important", >> until >> it is ;) >> >> TLDR I am considering moving to using "module names" for logger names >> instead of Class names even for DEBUG/TRACE logging and see if anyone had >> strong arguments to not do this.. >> >> Full version--- >> >> For some time I have been moving to an approach of defining message >> loggers[1] using a single contract per function or "module" - e.g.: >> >> 1. the second level caching module uses the dedicated message logger >> `ConnectionPoolingLogger` >> 2. the ManagedBeanRegistry module uses the dedicated message logger >> `BeansMessageLogger` >> 3. etc > > >> >> Each of these define a dedicate instance instance they can use. E.g. >> ConnectionPoolingLogger is defined as: >> >> ```` >> @MessageLogger( projectCode = "HHH" ) >> @ValidIdRange( min = 10001001, max = 10001500 ) >> public interface ConnectionPoolingLogger extends BasicLogger { >> >> ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger( >> ConnectionPoolingLogger.class, >> "org.hibernate.orm.connections.pooling" >> ); >> >> ... >> } >> ```` >> >> I won't get into all the whys I do this unless someone cares ;) >> >> But I am contemplating doing the same for basic loggers so I wanted to ask >> everyone else's opinion since this means a change in how you'd have to >> configure logging for DEBUG/TRACE output. Usually you'd use the Class >> name >> as the logger name and use that to control logging in the back-end (log4j, >> etc). If I do this, you'd have to instead use the module name. >> >> There are quite a few reasons I am considering this, including all of the >> reasons I did it for message loggers in the first place. If I am >> debugging the loading of a collection or an entity, today I'd have to know >> all the packages involved (there is no common root name) and list them in >> my log4j.properties; that is because the process is ultimately handled by >> delegates or helpers in many different packages (`org.hibernate.loader`, >> `org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be >> nice to just be able to say `org.hibernate.loading` or >> `org.hibernate.loading.entity` or `org.hibernate.loading.collection` or >> ... >> for a number of reasons: >> >> 1. When we need to see logging from someone it is a lot easier to tell >> the module name(s) you need enabled as opposed a list of package and >> class >> names. >> 2. When running JPA TCK it is essentially impossible to attach debugger >> to step through code when debugging a failure - you have to rely on >> debugging through output. *Well that used to be the case, but the >> latest TCK broke logging to STDOUT somehow so we ended up having to >> try and >> reproduce the failure in our testsuite - so then it does not matter >> either >> way ;)* >> 3. Easier to document - >> >> http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Logging.html >> >> Thoughts? >> >> >> [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which >> we use for user-focused log messages. Should always be logged at >= INFO >> [2] >> [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for >> developer-focused log messages (for debugging). Should always be logged >> at >> DEBUG or TRACE >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From steve at hibernate.org Wed Sep 19 09:22:45 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 19 Sep 2018 08:22:45 -0500 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> Message-ID: Ohhh... Sorry I misunderstood. I thought you were asking about ways to have the contributor only apply to one of the PUs... I'm surprised it isn't applied to each actually. I'd consider that a bug. Can you put together a test? On Wed, Sep 19, 2018, 8:12 AM Scott Marlow wrote: > > > On 9/19/18 5:41 AM, Gunnar Morling wrote: > > Would SessionFactoryServiceContributor [1] be of use to you? It lets you > > add services to the SF-scoped service registry; not sure whether that > > suits your requirements or no. > > Thanks, I will give that a try. We currently use RegionFactoryInitiator > and update the configuration settings passed via > RegionFactoryInitiator#resolveRegionFactory(Map configurationValues, > ServiceRegistryImplementor). I wonder if that is possible with > SessionFactoryServiceContributor? > > > > > --Gunnar > > > > [1] > > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java > > > > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow > > >: > > > > > > > > > On 9/14/18 6:14 PM, Steve Ebersole wrote: > > > > Doing so would require a programatic call while bootstrapping > > > > Hibernate. The ServiceContributors are applied during > > > > `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > > > > processing. So we'd need a call to register a ServiceContributor > with > > > > the StandardServiceRegistryBuilder. > > > > > > > > Of course that also means you'd have to have access to the > > > > StandardServiceRegistryBuilder > > > > > > I don't have a way to add a programatic call while bootstrapping "not > > > JPA container". > > > > > > > > > > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow > > > > > >> wrote: > > > > > > > > I'm deploying an application with two persistence units > > however, the > > > > ServiceContributor contribute(StandardServiceRegistryBuilder) > > [1] is > > > > only being called once, instead of per SessionFactory/EMF (or > so it > > > > seems). > > > > > > > > Is there a way to have the > > > > contribute(StandardServiceRegistryBuilder) be > > > > called per SessionFactory/EMF instead? > > > > > > > > Scott > > > > > > > > [1] > > > > > > > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > > > > _______________________________________________ > > > > 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 smarlow at redhat.com Wed Sep 19 09:52:50 2018 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 19 Sep 2018 09:52:50 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> Message-ID: On 9/19/18 9:22 AM, Steve Ebersole wrote: > Ohhh... Sorry I misunderstood.? I thought you were asking about ways to > have the contributor only apply to one of the PUs... > > I'm surprised it isn't applied to each actually.? I'd consider that a > bug.? Can you put together a test? Yes, I will work on a test. > > > On Wed, Sep 19, 2018, 8:12 AM Scott Marlow > wrote: > > > > On 9/19/18 5:41 AM, Gunnar Morling wrote: > > Would SessionFactoryServiceContributor [1] be of use to you? It > lets you > > add services to the SF-scoped service registry; not sure whether > that > > suits your requirements or no. > > Thanks, I will give that a try.? We currently use > RegionFactoryInitiator > and update the configuration settings passed via > RegionFactoryInitiator#resolveRegionFactory(Map configurationValues, > ServiceRegistryImplementor).? I wonder if that is possible with > SessionFactoryServiceContributor? > > > > > --Gunnar > > > > [1] > > > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java > > > > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow > > > >>: > >? > > >? > > >? > On 9/14/18 6:14 PM, Steve Ebersole wrote: > >? > > Doing so would require a programatic call while bootstrapping > >? > > Hibernate.? The ServiceContributors are applied during > >? > > > `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > >? > > processing.? So we'd need a call to register a > ServiceContributor with > >? > > the StandardServiceRegistryBuilder. > >? > > > >? > > Of course that also means you'd have to have access to the > >? > > StandardServiceRegistryBuilder > >? > > >? > I don't have a way to add a programatic call while > bootstrapping "not > >? > JPA container". > >? > > >? > > > >? > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow > > > > > >? > > > >>> wrote: > >? > > > >? > > ? ? I'm deploying an application with two persistence units > > however, the > >? > > ? ? ServiceContributor > contribute(StandardServiceRegistryBuilder) > > [1] is > >? > > ? ? only being called once, instead of per > SessionFactory/EMF (or so it > >? > > ? ? seems). > >? > > > >? > > ? ? Is there a way to have the > >? > > ? ? contribute(StandardServiceRegistryBuilder) be > >? > > ? ? called per SessionFactory/EMF instead? > >? > > > >? > > ? ? Scott > >? > > > >? > > ? ? [1] > >? > > > > > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > >? > > ? ? _______________________________________________ > >? > > ? ? 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 smarlow at redhat.com Wed Sep 19 12:12:52 2018 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 19 Sep 2018 12:12:52 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> Message-ID: <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> Please look at https://github.com/scottmarlow/hibernate-orm/tree/ServiceContributorTest and let me know if this is a valid test. I added a test that calls registry.getService( RegionFactory.class ) twice and fails if the RegionFactoryInitiator doesn't get called twice. Is that the same as creating two separate SFs and expecting the RegionFactoryInitiator to be called twice? On 9/19/18 9:52 AM, Scott Marlow wrote: > > > On 9/19/18 9:22 AM, Steve Ebersole wrote: >> Ohhh... Sorry I misunderstood.? I thought you were asking about ways >> to have the contributor only apply to one of the PUs... >> >> I'm surprised it isn't applied to each actually.? I'd consider that a >> bug.? Can you put together a test? > > Yes, I will work on a test. > >> >> >> On Wed, Sep 19, 2018, 8:12 AM Scott Marlow > > wrote: >> >> >> >> ??? On 9/19/18 5:41 AM, Gunnar Morling wrote: >> ???? > Would SessionFactoryServiceContributor [1] be of use to you? It >> ??? lets you >> ???? > add services to the SF-scoped service registry; not sure whether >> ??? that >> ???? > suits your requirements or no. >> >> ??? Thanks, I will give that a try.? We currently use >> ??? RegionFactoryInitiator >> ??? and update the configuration settings passed via >> ??? RegionFactoryInitiator#resolveRegionFactory(Map configurationValues, >> ??? ServiceRegistryImplementor).? I wonder if that is possible with >> ??? SessionFactoryServiceContributor? >> >> ???? > >> ???? > --Gunnar >> ???? > >> ???? > [1] >> ???? > >> >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java >> >> ???? > >> ???? > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow >> ???? > >> ??? >>: >> ???? >? > >> ???? >? > >> ???? >? > On 9/14/18 6:14 PM, Steve Ebersole wrote: >> ???? >? > > Doing so would require a programatic call while bootstrapping >> ???? >? > > Hibernate.? The ServiceContributors are applied during >> ???? >? > > >> ??? `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` >> ???? >? > > processing.? So we'd need a call to register a >> ??? ServiceContributor with >> ???? >? > > the StandardServiceRegistryBuilder. >> ???? >? > > >> ???? >? > > Of course that also means you'd have to have access to the >> ???? >? > > StandardServiceRegistryBuilder >> ???? >? > >> ???? >? > I don't have a way to add a programatic call while >> ??? bootstrapping "not >> ???? >? > JPA container". >> ???? >? > >> ???? >? > > >> ???? >? > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow >> ??? >> ???? > > >> ???? >? > > >> ??? >>> wrote: >> ???? >? > > >> ???? >? > > ? ? I'm deploying an application with two persistence units >> ???? > however, the >> ???? >? > > ? ? ServiceContributor >> ??? contribute(StandardServiceRegistryBuilder) >> ???? > [1] is >> ???? >? > > ? ? only being called once, instead of per >> ??? SessionFactory/EMF (or so it >> ???? >? > > ? ? seems). >> ???? >? > > >> ???? >? > > ? ? Is there a way to have the >> ???? >? > > ? ? contribute(StandardServiceRegistryBuilder) be >> ???? >? > > ? ? called per SessionFactory/EMF instead? >> ???? >? > > >> ???? >? > > ? ? Scott >> ???? >? > > >> ???? >? > > ? ? [1] >> ???? >? > > >> ???? > >> >> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 >> >> ???? >? > > ? ? _______________________________________________ >> ???? >? > > ? ? 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 Sep 19 15:47:45 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 19 Sep 2018 14:47:45 -0500 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> Message-ID: StandardServiceRegistry`No, it's not. Each call to `registry.getService( RegionFactory.class )` in your test returns the same `RegionFactory` - by design. By default each SF bootstrap uses a unique StandardServiceRegistry which is what the ServiceContributor contributes services to. In terms of your test, it would be like creating a second `StandardServiceRegistry` and asking that for the second RegionFactory On Wed, Sep 19, 2018 at 11:12 AM Scott Marlow wrote: > Please look at > https://github.com/scottmarlow/hibernate-orm/tree/ServiceContributorTest > and let me know if this is a valid test. I added a test that calls > registry.getService( RegionFactory.class ) twice and fails if the > RegionFactoryInitiator doesn't get called twice. > > Is that the same as creating two separate SFs and expecting the > RegionFactoryInitiator to be called twice? > > > On 9/19/18 9:52 AM, Scott Marlow wrote: > > > > > > On 9/19/18 9:22 AM, Steve Ebersole wrote: > >> Ohhh... Sorry I misunderstood. I thought you were asking about ways > >> to have the contributor only apply to one of the PUs... > >> > >> I'm surprised it isn't applied to each actually. I'd consider that a > >> bug. Can you put together a test? > > > > Yes, I will work on a test. > > > >> > >> > >> On Wed, Sep 19, 2018, 8:12 AM Scott Marlow >> > wrote: > >> > >> > >> > >> On 9/19/18 5:41 AM, Gunnar Morling wrote: > >> > Would SessionFactoryServiceContributor [1] be of use to you? It > >> lets you > >> > add services to the SF-scoped service registry; not sure whether > >> that > >> > suits your requirements or no. > >> > >> Thanks, I will give that a try. We currently use > >> RegionFactoryInitiator > >> and update the configuration settings passed via > >> RegionFactoryInitiator#resolveRegionFactory(Map configurationValues, > >> ServiceRegistryImplementor). I wonder if that is possible with > >> SessionFactoryServiceContributor? > >> > >> > > >> > --Gunnar > >> > > >> > [1] > >> > > >> > >> > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java > >> > >> > > >> > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow > >> > > >> >>: > >> > > > >> > > > >> > > On 9/14/18 6:14 PM, Steve Ebersole wrote: > >> > > > Doing so would require a programatic call while > bootstrapping > >> > > > Hibernate. The ServiceContributors are applied during > >> > > > > >> `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > >> > > > processing. So we'd need a call to register a > >> ServiceContributor with > >> > > > the StandardServiceRegistryBuilder. > >> > > > > >> > > > Of course that also means you'd have to have access to the > >> > > > StandardServiceRegistryBuilder > >> > > > >> > > I don't have a way to add a programatic call while > >> bootstrapping "not > >> > > JPA container". > >> > > > >> > > > > >> > > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow > >> > >> > > > >> > > > > >> >>> wrote: > >> > > > > >> > > > I'm deploying an application with two persistence units > >> > however, the > >> > > > ServiceContributor > >> contribute(StandardServiceRegistryBuilder) > >> > [1] is > >> > > > only being called once, instead of per > >> SessionFactory/EMF (or so it > >> > > > seems). > >> > > > > >> > > > Is there a way to have the > >> > > > contribute(StandardServiceRegistryBuilder) be > >> > > > called per SessionFactory/EMF instead? > >> > > > > >> > > > Scott > >> > > > > >> > > > [1] > >> > > > > >> > > >> > >> > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > >> > >> > > > _______________________________________________ > >> > > > 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 smarlow at redhat.com Thu Sep 20 12:05:53 2018 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 20 Sep 2018 12:05:53 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> Message-ID: Is https://gist.github.com/scottmarlow/63241549820243923aab16e664c3c6c3 closer to what we need? On 9/19/18 3:47 PM, Steve Ebersole wrote: > StandardServiceRegistry`No, it's not. > > Each call to `registry.getService( RegionFactory.class )` in your test > returns the same `RegionFactory` - by design. > > By default each SF bootstrap uses a unique StandardServiceRegistry which > is what the ServiceContributor contributes services to.? In terms of > your test, it would be like creating a second `StandardServiceRegistry` > and asking that for the second RegionFactory > > > > On Wed, Sep 19, 2018 at 11:12 AM Scott Marlow > wrote: > > Please look at > https://github.com/scottmarlow/hibernate-orm/tree/ServiceContributorTest > > and let me know if this is a valid test.? I added a test that calls > registry.getService( RegionFactory.class ) twice and fails if the > RegionFactoryInitiator doesn't get called twice. > > Is that the same as creating two separate SFs and expecting the > RegionFactoryInitiator to be called twice? > > > On 9/19/18 9:52 AM, Scott Marlow wrote: > > > > > > On 9/19/18 9:22 AM, Steve Ebersole wrote: > >> Ohhh... Sorry I misunderstood.? I thought you were asking about > ways > >> to have the contributor only apply to one of the PUs... > >> > >> I'm surprised it isn't applied to each actually.? I'd consider > that a > >> bug.? Can you put together a test? > > > > Yes, I will work on a test. > > > >> > >> > >> On Wed, Sep 19, 2018, 8:12 AM Scott Marlow > >> >> wrote: > >> > >> > >> > >> ??? On 9/19/18 5:41 AM, Gunnar Morling wrote: > >> ???? > Would SessionFactoryServiceContributor [1] be of use to > you? It > >> ??? lets you > >> ???? > add services to the SF-scoped service registry; not sure > whether > >> ??? that > >> ???? > suits your requirements or no. > >> > >> ??? Thanks, I will give that a try.? We currently use > >> ??? RegionFactoryInitiator > >> ??? and update the configuration settings passed via > >> ??? RegionFactoryInitiator#resolveRegionFactory(Map > configurationValues, > >> ??? ServiceRegistryImplementor).? I wonder if that is possible with > >> ??? SessionFactoryServiceContributor? > >> > >> ???? > > >> ???? > --Gunnar > >> ???? > > >> ???? > [1] > >> ???? > > >> > >> > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java > > >> > >> ???? > > >> ???? > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow > >> ???? > > > > >> ??? > >>>: > >> ???? >? > > >> ???? >? > > >> ???? >? > On 9/14/18 6:14 PM, Steve Ebersole wrote: > >> ???? >? > > Doing so would require a programatic call while > bootstrapping > >> ???? >? > > Hibernate.? The ServiceContributors are applied during > >> ???? >? > > > >> > `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` > >> ???? >? > > processing.? So we'd need a call to register a > >> ??? ServiceContributor with > >> ???? >? > > the StandardServiceRegistryBuilder. > >> ???? >? > > > >> ???? >? > > Of course that also means you'd have to have access > to the > >> ???? >? > > StandardServiceRegistryBuilder > >> ???? >? > > >> ???? >? > I don't have a way to add a programatic call while > >> ??? bootstrapping "not > >> ???? >? > JPA container". > >> ???? >? > > >> ???? >? > > > >> ???? >? > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow > >> ??? > > > >> ???? > > >> > >> ???? >? > > > > >> ??? > >>>> wrote: > >> ???? >? > > > >> ???? >? > > ? ? I'm deploying an application with two > persistence units > >> ???? > however, the > >> ???? >? > > ? ? ServiceContributor > >> ??? contribute(StandardServiceRegistryBuilder) > >> ???? > [1] is > >> ???? >? > > ? ? only being called once, instead of per > >> ??? SessionFactory/EMF (or so it > >> ???? >? > > ? ? seems). > >> ???? >? > > > >> ???? >? > > ? ? Is there a way to have the > >> ???? >? > > ? ? contribute(StandardServiceRegistryBuilder) be > >> ???? >? > > ? ? called per SessionFactory/EMF instead? > >> ???? >? > > > >> ???? >? > > ? ? Scott > >> ???? >? > > > >> ???? >? > > ? ? [1] > >> ???? >? > > > >> ???? > > >> > >> > https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 > > >> > >> ???? >? > > ? ? _______________________________________________ > >> ???? >? > > ? ? 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 smarlow at redhat.com Thu Sep 20 15:17:01 2018 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 20 Sep 2018 15:17:01 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> Message-ID: <4f2c3e5e-5580-8649-587c-a87bb59d2606@redhat.com> I'm going to try some more changes on the WF side, to see if I can work around this problem. I'll report back on how that goes. :) On 9/20/18 12:05 PM, Scott Marlow wrote: > Is https://gist.github.com/scottmarlow/63241549820243923aab16e664c3c6c3 > closer to what we need? > > On 9/19/18 3:47 PM, Steve Ebersole wrote: >> StandardServiceRegistry`No, it's not. >> >> Each call to `registry.getService( RegionFactory.class )` in your test >> returns the same `RegionFactory` - by design. >> >> By default each SF bootstrap uses a unique StandardServiceRegistry >> which is what the ServiceContributor contributes services to.? In >> terms of your test, it would be like creating a second >> `StandardServiceRegistry` and asking that for the second RegionFactory >> >> >> >> On Wed, Sep 19, 2018 at 11:12 AM Scott Marlow > > wrote: >> >> ??? Please look at >> >> https://github.com/scottmarlow/hibernate-orm/tree/ServiceContributorTest >> >> ??? and let me know if this is a valid test.? I added a test that calls >> ??? registry.getService( RegionFactory.class ) twice and fails if the >> ??? RegionFactoryInitiator doesn't get called twice. >> >> ??? Is that the same as creating two separate SFs and expecting the >> ??? RegionFactoryInitiator to be called twice? >> >> >> ??? On 9/19/18 9:52 AM, Scott Marlow wrote: >> ???? > >> ???? > >> ???? > On 9/19/18 9:22 AM, Steve Ebersole wrote: >> ???? >> Ohhh... Sorry I misunderstood.? I thought you were asking about >> ??? ways >> ???? >> to have the contributor only apply to one of the PUs... >> ???? >> >> ???? >> I'm surprised it isn't applied to each actually.? I'd consider >> ??? that a >> ???? >> bug.? Can you put together a test? >> ???? > >> ???? > Yes, I will work on a test. >> ???? > >> ???? >> >> ???? >> >> ???? >> On Wed, Sep 19, 2018, 8:12 AM Scott Marlow > ??? >> ???? >> >> wrote: >> ???? >> >> ???? >> >> ???? >> >> ???? >> ??? On 9/19/18 5:41 AM, Gunnar Morling wrote: >> ???? >> ???? > Would SessionFactoryServiceContributor [1] be of use to >> ??? you? It >> ???? >> ??? lets you >> ???? >> ???? > add services to the SF-scoped service registry; not sure >> ??? whether >> ???? >> ??? that >> ???? >> ???? > suits your requirements or no. >> ???? >> >> ???? >> ??? Thanks, I will give that a try.? We currently use >> ???? >> ??? RegionFactoryInitiator >> ???? >> ??? and update the configuration settings passed via >> ???? >> ??? RegionFactoryInitiator#resolveRegionFactory(Map >> ??? configurationValues, >> ???? >> ??? ServiceRegistryImplementor).? I wonder if that is possible >> with >> ???? >> ??? SessionFactoryServiceContributor? >> ???? >> >> ???? >> ???? > >> ???? >> ???? > --Gunnar >> ???? >> ???? > >> ???? >> ???? > [1] >> ???? >> ???? > >> ???? >> >> ???? >> >> >> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java >> >> >> ???? >> >> ???? >> ???? > >> ???? >> ???? > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow >> ???? >> ???? > >> ??? > >> ???? >> ??? >> ??? >>>: >> ???? >> ???? >? > >> ???? >> ???? >? > >> ???? >> ???? >? > On 9/14/18 6:14 PM, Steve Ebersole wrote: >> ???? >> ???? >? > > Doing so would require a programatic call while >> ??? bootstrapping >> ???? >> ???? >? > > Hibernate.? The ServiceContributors are applied >> during >> ???? >> ???? >? > > >> ???? >> >> `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` >> ???? >> ???? >? > > processing.? So we'd need a call to register a >> ???? >> ??? ServiceContributor with >> ???? >> ???? >? > > the StandardServiceRegistryBuilder. >> ???? >> ???? >? > > >> ???? >> ???? >? > > Of course that also means you'd have to have access >> ??? to the >> ???? >> ???? >? > > StandardServiceRegistryBuilder >> ???? >> ???? >? > >> ???? >> ???? >? > I don't have a way to add a programatic call while >> ???? >> ??? bootstrapping "not >> ???? >> ???? >? > JPA container". >> ???? >> ???? >? > >> ???? >> ???? >? > > >> ???? >> ???? >? > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow >> ???? >> ??? >> ??? > >> ???? >> ???? > >> ??? >> >> ???? >> ???? >? > > > ??? > ??? > >> ???? >> ??? >> ??? >>>> wrote: >> ???? >> ???? >? > > >> ???? >> ???? >? > > ? ? I'm deploying an application with two >> ??? persistence units >> ???? >> ???? > however, the >> ???? >> ???? >? > > ? ? ServiceContributor >> ???? >> ??? contribute(StandardServiceRegistryBuilder) >> ???? >> ???? > [1] is >> ???? >> ???? >? > > ? ? only being called once, instead of per >> ???? >> ??? SessionFactory/EMF (or so it >> ???? >> ???? >? > > ? ? seems). >> ???? >> ???? >? > > >> ???? >> ???? >? > > ? ? Is there a way to have the >> ???? >> ???? >? > > ? ? contribute(StandardServiceRegistryBuilder) be >> ???? >> ???? >? > > ? ? called per SessionFactory/EMF instead? >> ???? >> ???? >? > > >> ???? >> ???? >? > > ? ? Scott >> ???? >> ???? >? > > >> ???? >> ???? >? > > ? ? [1] >> ???? >> ???? >? > > >> ???? >> ???? > >> ???? >> >> ???? >> >> >> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 >> >> >> ???? >> >> ???? >> ???? >? > > ? ? _______________________________________________ >> ???? >> ???? >? > > ? ? 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 smarlow at redhat.com Thu Sep 20 15:29:27 2018 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 20 Sep 2018 15:29:27 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: <4f2c3e5e-5580-8649-587c-a87bb59d2606@redhat.com> References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> <4f2c3e5e-5580-8649-587c-a87bb59d2606@redhat.com> Message-ID: <22eef8a7-232f-1b82-51b0-05e9cad40715@redhat.com> On 9/20/18 3:17 PM, Scott Marlow wrote: > I'm going to try some more changes on the WF side, to see if I can work > around this problem.? I'll report back on how that goes. :) I tried overriding the ServiceRegistryImplementor#initiateService(Map configurationValues, ServiceRegistryImplementor registry) + getFallback(Map configurationValues, ServiceRegistryImplementor registry) methods to check if perhaps those get called for all persistence units, but no. So, we still need to create a reproducer for Hibernate ORM. > > On 9/20/18 12:05 PM, Scott Marlow wrote: >> Is >> https://gist.github.com/scottmarlow/63241549820243923aab16e664c3c6c3 >> closer to what we need? >> >> On 9/19/18 3:47 PM, Steve Ebersole wrote: >>> StandardServiceRegistry`No, it's not. >>> >>> Each call to `registry.getService( RegionFactory.class )` in your >>> test returns the same `RegionFactory` - by design. >>> >>> By default each SF bootstrap uses a unique StandardServiceRegistry >>> which is what the ServiceContributor contributes services to.? In >>> terms of your test, it would be like creating a second >>> `StandardServiceRegistry` and asking that for the second RegionFactory >>> >>> >>> >>> On Wed, Sep 19, 2018 at 11:12 AM Scott Marlow >> > wrote: >>> >>> ??? Please look at >>> https://github.com/scottmarlow/hibernate-orm/tree/ServiceContributorTest >>> >>> ??? and let me know if this is a valid test.? I added a test that calls >>> ??? registry.getService( RegionFactory.class ) twice and fails if the >>> ??? RegionFactoryInitiator doesn't get called twice. >>> >>> ??? Is that the same as creating two separate SFs and expecting the >>> ??? RegionFactoryInitiator to be called twice? >>> >>> >>> ??? On 9/19/18 9:52 AM, Scott Marlow wrote: >>> ???? > >>> ???? > >>> ???? > On 9/19/18 9:22 AM, Steve Ebersole wrote: >>> ???? >> Ohhh... Sorry I misunderstood.? I thought you were asking about >>> ??? ways >>> ???? >> to have the contributor only apply to one of the PUs... >>> ???? >> >>> ???? >> I'm surprised it isn't applied to each actually.? I'd consider >>> ??? that a >>> ???? >> bug.? Can you put together a test? >>> ???? > >>> ???? > Yes, I will work on a test. >>> ???? > >>> ???? >> >>> ???? >> >>> ???? >> On Wed, Sep 19, 2018, 8:12 AM Scott Marlow >> ??? >>> ???? >> >> wrote: >>> ???? >> >>> ???? >> >>> ???? >> >>> ???? >> ??? On 9/19/18 5:41 AM, Gunnar Morling wrote: >>> ???? >> ???? > Would SessionFactoryServiceContributor [1] be of use to >>> ??? you? It >>> ???? >> ??? lets you >>> ???? >> ???? > add services to the SF-scoped service registry; not sure >>> ??? whether >>> ???? >> ??? that >>> ???? >> ???? > suits your requirements or no. >>> ???? >> >>> ???? >> ??? Thanks, I will give that a try.? We currently use >>> ???? >> ??? RegionFactoryInitiator >>> ???? >> ??? and update the configuration settings passed via >>> ???? >> ??? RegionFactoryInitiator#resolveRegionFactory(Map >>> ??? configurationValues, >>> ???? >> ??? ServiceRegistryImplementor).? I wonder if that is >>> possible with >>> ???? >> ??? SessionFactoryServiceContributor? >>> ???? >> >>> ???? >> ???? > >>> ???? >> ???? > --Gunnar >>> ???? >> ???? > >>> ???? >> ???? > [1] >>> ???? >> ???? > >>> ???? >> >>> ???? >> >>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java >>> >>> >>> ???? >> >>> ???? >> ???? > >>> ???? >> ???? > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow >>> ???? >> ???? > >>> ??? > >>> ???? >> ??? >>> ??? >>>: >>> ???? >> ???? >? > >>> ???? >> ???? >? > >>> ???? >> ???? >? > On 9/14/18 6:14 PM, Steve Ebersole wrote: >>> ???? >> ???? >? > > Doing so would require a programatic call while >>> ??? bootstrapping >>> ???? >> ???? >? > > Hibernate.? The ServiceContributors are applied >>> during >>> ???? >> ???? >? > > >>> ???? >> >>> `org.hibernate.boot.registry.StandardServiceRegistryBuilder#build` >>> ???? >> ???? >? > > processing.? So we'd need a call to register a >>> ???? >> ??? ServiceContributor with >>> ???? >> ???? >? > > the StandardServiceRegistryBuilder. >>> ???? >> ???? >? > > >>> ???? >> ???? >? > > Of course that also means you'd have to have access >>> ??? to the >>> ???? >> ???? >? > > StandardServiceRegistryBuilder >>> ???? >> ???? >? > >>> ???? >> ???? >? > I don't have a way to add a programatic call while >>> ???? >> ??? bootstrapping "not >>> ???? >> ???? >? > JPA container". >>> ???? >> ???? >? > >>> ???? >> ???? >? > > >>> ???? >> ???? >? > > On Fri, Sep 14, 2018 at 9:27 PM Scott Marlow >>> ???? >> ??? >>> ??? > >>> ???? >> ???? > >>> ??? >> >>> ???? >> ???? >? > > >> ??? >> ??? > >>> ???? >> ??? >>> ??? >>>> wrote: >>> ???? >> ???? >? > > >>> ???? >> ???? >? > > ? ? I'm deploying an application with two >>> ??? persistence units >>> ???? >> ???? > however, the >>> ???? >> ???? >? > > ? ? ServiceContributor >>> ???? >> ??? contribute(StandardServiceRegistryBuilder) >>> ???? >> ???? > [1] is >>> ???? >> ???? >? > > ? ? only being called once, instead of per >>> ???? >> ??? SessionFactory/EMF (or so it >>> ???? >> ???? >? > > ? ? seems). >>> ???? >> ???? >? > > >>> ???? >> ???? >? > > ? ? Is there a way to have the >>> ???? >> ???? >? > > ? ? contribute(StandardServiceRegistryBuilder) be >>> ???? >> ???? >? > > ? ? called per SessionFactory/EMF instead? >>> ???? >> ???? >? > > >>> ???? >> ???? >? > > ? ? Scott >>> ???? >> ???? >? > > >>> ???? >> ???? >? > > ? ? [1] >>> ???? >> ???? >? > > >>> ???? >> ???? > >>> ???? >> >>> ???? >> >>> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L28 >>> >>> >>> ???? >> >>> ???? >> ???? >? > > ? ? _______________________________________________ >>> ???? >> ???? >? > > ? ? 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 smarlow at redhat.com Fri Sep 21 10:04:57 2018 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 21 Sep 2018 10:04:57 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: <22eef8a7-232f-1b82-51b0-05e9cad40715@redhat.com> References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> <4f2c3e5e-5580-8649-587c-a87bb59d2606@redhat.com> <22eef8a7-232f-1b82-51b0-05e9cad40715@redhat.com> Message-ID: <1ea6d411-5315-e8dd-9188-e2cc00ca4fb3@redhat.com> I verified that SessionFactoryServiceContributor doesn't help WF either, as we see the same problem. I did hack together a unit test under ORM (using the WF integration testing) that shows that we don't see the same problem when the https://github.com/hibernate/hibernate-orm/tree/master/hibernate-jipijapa integration classes are used. It seems likely that something is wrong with the https://github.com/wildfly/wildfly/tree/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5 classes, that causes the problem that I am seeing. Scott From steve at hibernate.org Fri Sep 21 10:29:52 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 21 Sep 2018 09:29:52 -0500 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: <1ea6d411-5315-e8dd-9188-e2cc00ca4fb3@redhat.com> References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> <4f2c3e5e-5580-8649-587c-a87bb59d2606@redhat.com> <22eef8a7-232f-1b82-51b0-05e9cad40715@redhat.com> <1ea6d411-5315-e8dd-9188-e2cc00ca4fb3@redhat.com> Message-ID: Honestly Scott, I am thoroughly confused now as to what you are wanting and what you are reporting. Your last code fragment[1] is close. As I said earlier, building a SessionFactory typically involves individual service registries being used for each SF. You have to go out of your way for that to not be the case. I am pretty sure WF does not do this "going out of its way". So not sure why the test does. To me either: 1. write a unit test for StandardServiceRegistry(/Builder) 2. write a functional test for how building a SessionFactory handles StandardServiceRegistry. Instead you kind of do both and therefor do neither. I created a fork of your gist that shows a better test using (2), which I think is more what you are wondering about. It is "better" imo because I *think* it better represents what you do in WF/Jipijapa - https://gist.github.com/sebersole/d93a28b1dcf16f6f7eb823b7341a9097 [1] https://gist.github.com/scottmarlow/63241549820243923aab16e664c3c6c3 On Fri, Sep 21, 2018 at 9:05 AM Scott Marlow wrote: > I verified that SessionFactoryServiceContributor doesn't help WF either, > as we see the same problem. > > I did hack together a unit test under ORM (using the WF integration > testing) that shows that we don't see the same problem when the > https://github.com/hibernate/hibernate-orm/tree/master/hibernate-jipijapa > integration classes are used. > > It seems likely that something is wrong with the > > https://github.com/wildfly/wildfly/tree/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5 > classes, that causes the problem that I am seeing. > > Scott > From smarlow at redhat.com Fri Sep 21 13:03:09 2018 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 21 Sep 2018 13:03:09 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> <4f2c3e5e-5580-8649-587c-a87bb59d2606@redhat.com> <22eef8a7-232f-1b82-51b0-05e9cad40715@redhat.com> <1ea6d411-5315-e8dd-9188-e2cc00ca4fb3@redhat.com> Message-ID: <84c3eda0-74b1-a794-e71a-0de8326f4854@redhat.com> On 9/21/18 10:29 AM, Steve Ebersole wrote: > Honestly Scott, I am thoroughly confused now as to what you are wanting > and what you are reporting. > > Your last code fragment[1] is close.??As I said earlier, building a > SessionFactory typically involves individual service registries being > used for each SF.? You have to go out of your way for that to not be the > case.? I am pretty sure WF does not do this "going out of its way".? So > not sure why the test does.? To me either: > > 1. write a unit test for?StandardServiceRegistry(/Builder) > 2. write a functional test for how building a SessionFactory handles > StandardServiceRegistry. > > Instead you kind of do both and therefor do neither. > > I created a fork of your gist that shows a better test using (2), which > I think is more what you are wondering about.? It is "better" imo > because I *think* it better represents what you do in WF/Jipijapa - > https://gist.github.com/sebersole/d93a28b1dcf16f6f7eb823b7341a9097 Thanks, this helps! I pushed updates to https://github.com/scottmarlow/hibernate-orm/commits/ServiceContributorTest and squashed my commits. The good news is that MyRegionFactoryInitiator#resolveRegionFactory + MyRegionFactoryInitiator#contribute are being called. :) I'm not sure why MyRegionFactoryInitiator#fallback doesn't get called. I commented out the RegionFactory lookup/testing, to resolve compile errors. > > > [1] https://gist.github.com/scottmarlow/63241549820243923aab16e664c3c6c3 > From steve at hibernate.org Fri Sep 21 13:30:00 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 21 Sep 2018 12:30:00 -0500 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: <84c3eda0-74b1-a794-e71a-0de8326f4854@redhat.com> References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> <4f2c3e5e-5580-8649-587c-a87bb59d2606@redhat.com> <22eef8a7-232f-1b82-51b0-05e9cad40715@redhat.com> <1ea6d411-5315-e8dd-9188-e2cc00ca4fb3@redhat.com> <84c3eda0-74b1-a794-e71a-0de8326f4854@redhat.com> Message-ID: What's being returned instead of the fallback? Is that configured somewhere for Hibernate to use that? Like a testing hibernate.properties? On Fri, Sep 21, 2018 at 12:03 PM Scott Marlow wrote: > > > On 9/21/18 10:29 AM, Steve Ebersole wrote: > > Honestly Scott, I am thoroughly confused now as to what you are wanting > > and what you are reporting. > > > > Your last code fragment[1] is close. As I said earlier, building a > > SessionFactory typically involves individual service registries being > > used for each SF. You have to go out of your way for that to not be the > > case. I am pretty sure WF does not do this "going out of its way". So > > not sure why the test does. To me either: > > > > 1. write a unit test for StandardServiceRegistry(/Builder) > > 2. write a functional test for how building a SessionFactory handles > > StandardServiceRegistry. > > > > Instead you kind of do both and therefor do neither. > > > > I created a fork of your gist that shows a better test using (2), which > > I think is more what you are wondering about. It is "better" imo > > because I *think* it better represents what you do in WF/Jipijapa - > > https://gist.github.com/sebersole/d93a28b1dcf16f6f7eb823b7341a9097 > > Thanks, this helps! > > I pushed updates to > https://github.com/scottmarlow/hibernate-orm/commits/ServiceContributorTest > and squashed my commits. > > The good news is that MyRegionFactoryInitiator#resolveRegionFactory + > MyRegionFactoryInitiator#contribute are being called. :) > > I'm not sure why MyRegionFactoryInitiator#fallback doesn't get called. > > I commented out the RegionFactory lookup/testing, to resolve compile > errors. > > > > > > > [1] https://gist.github.com/scottmarlow/63241549820243923aab16e664c3c6c3 > > > From guillaume.smet at gmail.com Mon Sep 24 10:22:28 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 24 Sep 2018 16:22:28 +0200 Subject: [hibernate-dev] Hibernate JTS upgrade: migration notes required Message-ID: Hi Karel, Back from vacation and I just saw this commit: https://github.com/hibernate/hibernate-orm/commit/b3e56a5db71110d07a095762a788c53ef258bd01 . As it will break user code, we need a note in the migration guide about this change (migration-guide.adoc at the root of the repository). The migration guide in master ( https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc) is currently empty but you can see some examples in the 5.3 migration guide: https://github.com/hibernate/hibernate-orm/blob/5.3/migration-guide.adoc . Could you take care of it? Thanks! -- Guillaume From karel at geovise.com Mon Sep 24 10:24:32 2018 From: karel at geovise.com (Karel Maesen) Date: Mon, 24 Sep 2018 16:24:32 +0200 Subject: [hibernate-dev] Hibernate JTS upgrade: migration notes required In-Reply-To: References: Message-ID: Hi Guillaume, Thanks for pointing this out. I will take care of it. Regards, Karel On Mon, Sep 24, 2018 at 4:23 PM Guillaume Smet wrote: > Hi Karel, > > Back from vacation and I just saw this commit: > https://github.com/hibernate/hibernate-orm/commit/b3e56a5db71110d07a095762a788c53ef258bd01 > . > > As it will break user code, we need a note in the migration guide about > this change (migration-guide.adoc at the root of the repository). > > The migration guide in master ( > https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc) > is currently empty but you can see some examples in the 5.3 migration guide: > https://github.com/hibernate/hibernate-orm/blob/5.3/migration-guide.adoc . > > Could you take care of it? > > Thanks! > > -- > Guillaume > From gbadner at redhat.com Mon Sep 24 19:03:49 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 24 Sep 2018 16:03:49 -0700 Subject: [hibernate-dev] *-to-one associations and @NotFound Message-ID: As a result of fixing HHH-12436 , some eager *-to-one associations that were loaded using FetchMode.JOIN may instead be loaded using FetchMode.SELECT, and vice-versa. In some cases, @NotFound behavior is different depending on the FetchMode for the association. The reason why FetchMode may change due to HHH-12436 is that the ForeignKeyDirection of some *-to-one associations were incorrect. Correcting the ForeignKeyDirection will result in a different AssociationKey, which may ultimately affect the FetchMode Hibernate assigns to an association. My hope is to resolve the inconsistencies before fixing HHH-12436 , so it does not result in a change in application behavior. I've created a Google Doc to document the inconsistencies and to make it easier to discuss how to go about resolving them: https://docs.google.com/document/d/1o3Q6tYD5jjxC6Ok7vBYzxRGsixpG46p-5zDiDCAKLsI/ Please feel free to request access to the document if you wish to review or add comments. Regards, Gail From smarlow at redhat.com Tue Sep 25 09:41:07 2018 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 25 Sep 2018 09:41:07 -0400 Subject: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader? In-Reply-To: References: <4d56eae8-3b9a-d75a-171e-5858451866cb@redhat.com> <2ac7cef9-f4fb-b372-2b67-d4d7783d93b5@redhat.com> <4a225f5c-ef0e-85a9-eb1e-68e6845557c4@redhat.com> <4f2c3e5e-5580-8649-587c-a87bb59d2606@redhat.com> <22eef8a7-232f-1b82-51b0-05e9cad40715@redhat.com> <1ea6d411-5315-e8dd-9188-e2cc00ca4fb3@redhat.com> <84c3eda0-74b1-a794-e71a-0de8326f4854@redhat.com> Message-ID: <7aea306e-dbe0-fb01-9172-d26f47f28ffd@redhat.com> I'm not blocked on this anymore, I was caught off guard by the debugger not stopping on my breakpoint for both deployment threads. I also reread the Intellij documentation, which explained that I was suspending all threads on breakpoint, instead of just the current thread. Sorry for the intrusion. On 9/21/18 1:30 PM, Steve Ebersole wrote: > What's being returned instead of the fallback? > Is that configured > somewhere for Hibernate to use that?? Like a testing hibernate.properties? > > On Fri, Sep 21, 2018 at 12:03 PM Scott Marlow > wrote: > From guillaume.smet at gmail.com Tue Sep 25 10:23:46 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 25 Sep 2018 16:23:46 +0200 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: Hi, Here are the minutes of this week's meeting: 15:21 < jbott> Meeting ended Tue Sep 25 13:20:53 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:21 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-25-12.59.html 15:21 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-25-12.59.txt 15:21 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-09-25-12.59.log.html -- Guillaume From rory.odonnell at oracle.com Wed Sep 26 05:09:52 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 26 Sep 2018 10:09:52 +0100 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 11 Message-ID: Hi Sanne, *1) Release Announcement: General Availability of JDK 11 * * JDK 11, the reference implementation of Java 11 and the first long-term support release produced under the six-month rapid-cadence release model [1][2], is now Generally Available. * GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/11 This release includes seventeen features: * 181: Nest-Based Access Control * 309: Dynamic Class-File Constants * 315: Improve Aarch64 Intrinsics * 318: Epsilon: A No-Op Garbage Collector * 320: Remove the Java EE and CORBA Modules * 321: HTTP Client (Standard) * 323: Local-Variable Syntax for Lambda Parameters * 324: Key Agreement with Curve25519 and Curve448 * 327: Unicode 10 * 328: Flight Recorder * 329: ChaCha20 and Poly1305 Cryptographic Algorithms * 330: Launch Single-File Source-Code Programs * 331: Low-Overhead Heap Profiling * 332: Transport Layer Security (TLS) 1.3 * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) * 335: Deprecate the Nashorn JavaScript Engine * 336: Deprecate the Pack200 Tools and API 2) Quality Outreach Report for September 2018 is available* * * Quality Outreach report September 2018 *Thanks to everyone who contributed to JDK 11 by downloading and testing the early-access builds. In particular the following developers who logged **18 issues in the JDK Bug System.* * Netty * Eclipse Jetty * Apache Lucene * JUnit5 * Apache Tomcat * Apache Ant * Apache POI * AssertJ * Eclipse Collections * Byte Buddy * RxJava 3) JDK 12 EA build 12, under both the GPL and Oracle EA licenses, are now available at http://jdk.java.net/11 . * Schedule , Status & Features o http://openjdk.java.net/projects/jdk/12/ * Release Notes: o http://jdk.java.net/12/release-notes ** Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland From sanne at hibernate.org Thu Sep 27 05:40:48 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 27 Sep 2018 10:40:48 +0100 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 11 In-Reply-To: References: Message-ID: Thanks Rory! we have no specific problems to report, yet users will need to be aware of some changes but I guess that's of no surprise to you all. One is that people won't be able to blindly rely on our dependencies being defined by Maven descriptors, as the dependencies need to be different on various JVM versions, because e.g. the removal of some XML parsing modules from the JDK distributions. Also people will momentarily need to use some flags, as not all our dependencies are ready for JDK11 yet without the flags, but we expect this to change now that the release was done. I'll give it a couple of weeks for our dependencies to settle down on changes, then we'll likely spin new releases out with better instructions and a blog. -- Sanne On Wed, 26 Sep 2018 at 10:15, Rory O'Donnell wrote: > > Hi Sanne, > > *1) Release Announcement: General Availability of JDK 11 * > > * JDK 11, the reference implementation of Java 11 and the first > long-term support release produced under the six-month rapid-cadence > release model [1][2], is now Generally Available. > * GPL-licensed OpenJDK builds from Oracle are available here: > https://jdk.java.net/11 > > This release includes seventeen features: > > * 181: Nest-Based Access Control > * 309: Dynamic Class-File Constants > * 315: Improve Aarch64 Intrinsics > * 318: Epsilon: A No-Op Garbage Collector > > * 320: Remove the Java EE and CORBA Modules > > * 321: HTTP Client (Standard) > * 323: Local-Variable Syntax for Lambda Parameters > > * 324: Key Agreement with Curve25519 and Curve448 > > * 327: Unicode 10 > * 328: Flight Recorder > * 329: ChaCha20 and Poly1305 Cryptographic Algorithms > > * 330: Launch Single-File Source-Code Programs > > * 331: Low-Overhead Heap Profiling > * 332: Transport Layer Security (TLS) 1.3 > > * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) > > * 335: Deprecate the Nashorn JavaScript Engine > > * 336: Deprecate the Pack200 Tools and API > > > > 2) Quality Outreach Report for September 2018 is available* > * > > * Quality Outreach report September 2018 > > *Thanks to everyone who contributed to JDK 11 by downloading and testing > the early-access builds. > In particular the following developers who logged **18 issues in the JDK > Bug System.* > > * Netty > * Eclipse Jetty > * Apache Lucene > * JUnit5 > * Apache Tomcat > * Apache Ant > * Apache POI > * AssertJ > * Eclipse Collections > * Byte Buddy > * RxJava > > 3) JDK 12 EA build 12, under both the GPL and Oracle EA licenses, are > now available at http://jdk.java.net/11 . > > * Schedule , Status & Features > o http://openjdk.java.net/projects/jdk/12/ > * Release Notes: > o http://jdk.java.net/12/release-notes > > ** > > Rgds,Rory > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA, Dublin,Ireland > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From rory.odonnell at oracle.com Thu Sep 27 05:55:41 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 27 Sep 2018 10:55:41 +0100 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 11 In-Reply-To: References: Message-ID: <2fb3cecd-b936-a8db-761f-9c3939984f05@oracle.com> Thanks Sanne, look forward to the update in a couple of weeks! Rgds,Rory On 27/09/2018 10:40, Sanne Grinovero wrote: > Thanks Rory! > > we have no specific problems to report, yet users will need to be > aware of some changes but I guess that's of no surprise to you all. > > One is that people won't be able to blindly rely on our dependencies > being defined by Maven descriptors, as the dependencies need to be > different on various JVM versions, because e.g. the removal of some > XML parsing modules from the JDK distributions. > > Also people will momentarily need to use some flags, as not all our > dependencies are ready for JDK11 yet without the flags, but we expect > this to change now that the release was done. > > I'll give it a couple of weeks for our dependencies to settle down on > changes, then we'll likely spin new releases out with better > instructions and a blog. > > -- Sanne > > On Wed, 26 Sep 2018 at 10:15, Rory O'Donnell wrote: >> Hi Sanne, >> >> *1) Release Announcement: General Availability of JDK 11 * >> >> * JDK 11, the reference implementation of Java 11 and the first >> long-term support release produced under the six-month rapid-cadence >> release model [1][2], is now Generally Available. >> * GPL-licensed OpenJDK builds from Oracle are available here: >> https://jdk.java.net/11 >> >> This release includes seventeen features: >> >> * 181: Nest-Based Access Control >> * 309: Dynamic Class-File Constants >> * 315: Improve Aarch64 Intrinsics >> * 318: Epsilon: A No-Op Garbage Collector >> >> * 320: Remove the Java EE and CORBA Modules >> >> * 321: HTTP Client (Standard) >> * 323: Local-Variable Syntax for Lambda Parameters >> >> * 324: Key Agreement with Curve25519 and Curve448 >> >> * 327: Unicode 10 >> * 328: Flight Recorder >> * 329: ChaCha20 and Poly1305 Cryptographic Algorithms >> >> * 330: Launch Single-File Source-Code Programs >> >> * 331: Low-Overhead Heap Profiling >> * 332: Transport Layer Security (TLS) 1.3 >> >> * 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) >> >> * 335: Deprecate the Nashorn JavaScript Engine >> >> * 336: Deprecate the Pack200 Tools and API >> >> >> >> 2) Quality Outreach Report for September 2018 is available* >> * >> >> * Quality Outreach report September 2018 >> >> *Thanks to everyone who contributed to JDK 11 by downloading and testing >> the early-access builds. >> In particular the following developers who logged **18 issues in the JDK >> Bug System.* >> >> * Netty >> * Eclipse Jetty >> * Apache Lucene >> * JUnit5 >> * Apache Tomcat >> * Apache Ant >> * Apache POI >> * AssertJ >> * Eclipse Collections >> * Byte Buddy >> * RxJava >> >> 3) JDK 12 EA build 12, under both the GPL and Oracle EA licenses, are >> now available at http://jdk.java.net/11 . >> >> * Schedule , Status & Features >> o http://openjdk.java.net/projects/jdk/12/ >> * Release Notes: >> o http://jdk.java.net/12/release-notes >> >> ** >> >> Rgds,Rory >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA, Dublin,Ireland >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From guillaume.smet at gmail.com Thu Sep 27 06:12:44 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 27 Sep 2018 12:12:44 +0200 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 11 In-Reply-To: <2fb3cecd-b936-a8db-761f-9c3939984f05@oracle.com> References: <2fb3cecd-b936-a8db-761f-9c3939984f05@oracle.com> Message-ID: On Thu, Sep 27, 2018 at 11:56 AM Rory O'Donnell wrote: > On 27/09/2018 10:40, Sanne Grinovero wrote: > > I'll give it a couple of weeks for our dependencies to settle down on > > changes, then we'll likely spin new releases out with better > > instructions and a blog. > FWIW, I already posted a blog there: http://in.relation.to/2018/09/13/using-hibernate-orm-with-jdk11/ . The ByteBuddy/ASM issue should be fixed soon so we'll upgrade them for 5.4 and we won't need the magical flag anymore. We also plan to do something about the JAXB dependencies but it's a bit more complicated due to the license used for it. Hopefully, we will get all these issues sorted out soon. -- Guillaume From rory.odonnell at oracle.com Thu Sep 27 06:25:44 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 27 Sep 2018 11:25:44 +0100 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 11 In-Reply-To: References: <2fb3cecd-b936-a8db-761f-9c3939984f05@oracle.com> Message-ID: Good to know, thanks Guillaume. Rgds,Rory On 27/09/2018 11:12, Guillaume Smet wrote: > On Thu, Sep 27, 2018 at 11:56 AM Rory O'Donnell > > wrote: > > On 27/09/2018 10:40, Sanne Grinovero wrote: > > I'll give it a couple of weeks for our dependencies to settle > down on > > changes, then we'll likely spin new releases out with better > > instructions and a blog. > > > FWIW, I already posted a blog there: > http://in.relation.to/2018/09/13/using-hibernate-orm-with-jdk11/ . > > The ByteBuddy/ASM issue should be fixed soon so we'll upgrade them for > 5.4 and we won't need the magical flag anymore. > > We also plan to do something about the JAXB dependencies but it's a > bit more complicated due to the license used for it. > > Hopefully, we will get all these issues sorted out soon. > > -- > Guillaume -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From sanne at hibernate.org Fri Sep 28 11:29:08 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 28 Sep 2018 16:29:08 +0100 Subject: [hibernate-dev] Loggers In-Reply-To: References: Message-ID: Hi Steve, I love the cathegories idea; I think we discussed it before. My only concern is that it's a lot of work to implement, but if you feel it's doable that's great. In terms of "changes needed" I'm not worried either. Like you said, 6 would have had different names for most cases; at least moving forward such names would be more stable even if we decide to move some code in the future. One doubt is the granularity. I guess the risk is that maintainers will tend to reuse the same limited set of cathegories; we will need to make sure there are enough cathegories so that people can still enable the single aspect they might be interested in debugging, but maybe that's not important as people can always post-filter things when the output gets too verbose. We will need a way to coordinate on valid ranges for the various @ValidIdRange. Infinispan used a wiki for this; the upside is that it's out of the repository: a good thing to avoid reuse across repo branches - e.g. it's not ideal to have to change ids when backporting - , but downside of requiring human care. Thanks, Sanne On Wed, 19 Sep 2018 at 14:31, Steve Ebersole wrote: > > Yes. As I mentioned in my original, this would mean potential changes for > people configuring logging. I've started doing this for new logging in 6 > and it works great. > > Mainly asking opinions about changing existing logging and whether the > benefits are worth the effort. > > And keep in mind that the many many changes in 6 already would require such > logging config changes anyway for those configuring logging > > > On Wed, Sep 19, 2018, 12:50 AM Vlad Mihalcea > wrote: > > > I think it's a good idea. > > > > However, will this break all current applications that use the package > > name log appenders? > > > > Vlad > > > > On Fri, Sep 14, 2018 at 7:20 PM, Steve Ebersole > > wrote: > > > >> Yes, I know no one likes talking about logging. "Its not important", > >> until > >> it is ;) > >> > >> TLDR I am considering moving to using "module names" for logger names > >> instead of Class names even for DEBUG/TRACE logging and see if anyone had > >> strong arguments to not do this.. > >> > >> Full version--- > >> > >> For some time I have been moving to an approach of defining message > >> loggers[1] using a single contract per function or "module" - e.g.: > >> > >> 1. the second level caching module uses the dedicated message logger > >> `ConnectionPoolingLogger` > >> 2. the ManagedBeanRegistry module uses the dedicated message logger > >> `BeansMessageLogger` > >> 3. etc > > > > > >> > >> Each of these define a dedicate instance instance they can use. E.g. > >> ConnectionPoolingLogger is defined as: > >> > >> ```` > >> @MessageLogger( projectCode = "HHH" ) > >> @ValidIdRange( min = 10001001, max = 10001500 ) > >> public interface ConnectionPoolingLogger extends BasicLogger { > >> > >> ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger( > >> ConnectionPoolingLogger.class, > >> "org.hibernate.orm.connections.pooling" > >> ); > >> > >> ... > >> } > >> ```` > >> > >> I won't get into all the whys I do this unless someone cares ;) > >> > >> But I am contemplating doing the same for basic loggers so I wanted to ask > >> everyone else's opinion since this means a change in how you'd have to > >> configure logging for DEBUG/TRACE output. Usually you'd use the Class > >> name > >> as the logger name and use that to control logging in the back-end (log4j, > >> etc). If I do this, you'd have to instead use the module name. > >> > >> There are quite a few reasons I am considering this, including all of the > >> reasons I did it for message loggers in the first place. If I am > >> debugging the loading of a collection or an entity, today I'd have to know > >> all the packages involved (there is no common root name) and list them in > >> my log4j.properties; that is because the process is ultimately handled by > >> delegates or helpers in many different packages (`org.hibernate.loader`, > >> `org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be > >> nice to just be able to say `org.hibernate.loading` or > >> `org.hibernate.loading.entity` or `org.hibernate.loading.collection` or > >> ... > >> for a number of reasons: > >> > >> 1. When we need to see logging from someone it is a lot easier to tell > >> the module name(s) you need enabled as opposed a list of package and > >> class > >> names. > >> 2. When running JPA TCK it is essentially impossible to attach debugger > >> to step through code when debugging a failure - you have to rely on > >> debugging through output. *Well that used to be the case, but the > >> latest TCK broke logging to STDOUT somehow so we ended up having to > >> try and > >> reproduce the failure in our testsuite - so then it does not matter > >> either > >> way ;)* > >> 3. Easier to document - > >> > >> http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Logging.html > >> > >> Thoughts? > >> > >> > >> [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which > >> we use for user-focused log messages. Should always be logged at >= INFO > >> [2] > >> [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for > >> developer-focused log messages (for debugging). Should always be logged > >> at > >> DEBUG or TRACE > >> _______________________________________________ > >> 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 Sep 28 11:42:52 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 28 Sep 2018 10:42:52 -0500 Subject: [hibernate-dev] Loggers In-Reply-To: References: Message-ID: Thanks for the feedback! WRT effort, the plan is to make these changes as I do work in a particular area which is what I have been doing - not a "one shot, go back and change all logging". WRT granularity, sure that would be a concern. It really comes back to having a good "logical" design of the logger name hierarchy. WRT coordination, yep - https://github.com/sebersole/hibernate-core/blob/wip/6.0/logger_id_ranges.adoc On Fri, Sep 28, 2018 at 10:35 AM Sanne Grinovero wrote: > Hi Steve, > > I love the cathegories idea; I think we discussed it before. My only > concern is that it's a lot of work to implement, but if you feel it's > doable that's great. > > In terms of "changes needed" I'm not worried either. Like you said, 6 > would have had different names for most cases; at least moving forward > such names would be more stable even if we decide to move some code in > the future. > > One doubt is the granularity. I guess the risk is that maintainers > will tend to reuse the same limited set of cathegories; we will need > to make sure there are enough cathegories so that people can still > enable the single aspect they might be interested in debugging, but > maybe that's not important as people can always post-filter things > when the output gets too verbose. > > We will need a way to coordinate on valid ranges for the various > @ValidIdRange. Infinispan used a wiki for this; the upside is that > it's out of the repository: a good thing to avoid reuse across repo > branches - e.g. it's not ideal to have to change ids when backporting > - , but downside of requiring human care. > > Thanks, > Sanne > > > On Wed, 19 Sep 2018 at 14:31, Steve Ebersole wrote: > > > > Yes. As I mentioned in my original, this would mean potential changes > for > > people configuring logging. I've started doing this for new logging in 6 > > and it works great. > > > > Mainly asking opinions about changing existing logging and whether the > > benefits are worth the effort. > > > > And keep in mind that the many many changes in 6 already would require > such > > logging config changes anyway for those configuring logging > > > > > > On Wed, Sep 19, 2018, 12:50 AM Vlad Mihalcea > > wrote: > > > > > I think it's a good idea. > > > > > > However, will this break all current applications that use the package > > > name log appenders? > > > > > > Vlad > > > > > > On Fri, Sep 14, 2018 at 7:20 PM, Steve Ebersole > > > wrote: > > > > > >> Yes, I know no one likes talking about logging. "Its not important", > > >> until > > >> it is ;) > > >> > > >> TLDR I am considering moving to using "module names" for logger names > > >> instead of Class names even for DEBUG/TRACE logging and see if anyone > had > > >> strong arguments to not do this.. > > >> > > >> Full version--- > > >> > > >> For some time I have been moving to an approach of defining message > > >> loggers[1] using a single contract per function or "module" - e.g.: > > >> > > >> 1. the second level caching module uses the dedicated message > logger > > >> `ConnectionPoolingLogger` > > >> 2. the ManagedBeanRegistry module uses the dedicated message logger > > >> `BeansMessageLogger` > > >> 3. etc > > > > > > > > >> > > >> Each of these define a dedicate instance instance they can use. E.g. > > >> ConnectionPoolingLogger is defined as: > > >> > > >> ```` > > >> @MessageLogger( projectCode = "HHH" ) > > >> @ValidIdRange( min = 10001001, max = 10001500 ) > > >> public interface ConnectionPoolingLogger extends BasicLogger { > > >> > > >> ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger( > > >> ConnectionPoolingLogger.class, > > >> "org.hibernate.orm.connections.pooling" > > >> ); > > >> > > >> ... > > >> } > > >> ```` > > >> > > >> I won't get into all the whys I do this unless someone cares ;) > > >> > > >> But I am contemplating doing the same for basic loggers so I wanted > to ask > > >> everyone else's opinion since this means a change in how you'd have to > > >> configure logging for DEBUG/TRACE output. Usually you'd use the Class > > >> name > > >> as the logger name and use that to control logging in the back-end > (log4j, > > >> etc). If I do this, you'd have to instead use the module name. > > >> > > >> There are quite a few reasons I am considering this, including all > of the > > >> reasons I did it for message loggers in the first place. If I am > > >> debugging the loading of a collection or an entity, today I'd have to > know > > >> all the packages involved (there is no common root name) and list > them in > > >> my log4j.properties; that is because the process is ultimately > handled by > > >> delegates or helpers in many different packages > (`org.hibernate.loader`, > > >> `org.hibernate.persister`, `org.hibernate.type`, ...). It sure would > be > > >> nice to just be able to say `org.hibernate.loading` or > > >> `org.hibernate.loading.entity` or `org.hibernate.loading.collection` > or > > >> ... > > >> for a number of reasons: > > >> > > >> 1. When we need to see logging from someone it is a lot easier to > tell > > >> the module name(s) you need enabled as opposed a list of package > and > > >> class > > >> names. > > >> 2. When running JPA TCK it is essentially impossible to attach > debugger > > >> to step through code when debugging a failure - you have to rely on > > >> debugging through output. *Well that used to be the case, but the > > >> latest TCK broke logging to STDOUT somehow so we ended up having to > > >> try and > > >> reproduce the failure in our testsuite - so then it does not matter > > >> either > > >> way ;)* > > >> 3. Easier to document - > > >> > > >> > http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Logging.html > > >> > > >> Thoughts? > > >> > > >> > > >> [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - > which > > >> we use for user-focused log messages. Should always be logged at >= > INFO > > >> [2] > > >> [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for > > >> developer-focused log messages (for debugging). Should always be > logged > > >> at > > >> DEBUG or TRACE > > >> _______________________________________________ > > >> 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 Fri Sep 28 11:46:02 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 28 Sep 2018 16:46:02 +0100 Subject: [hibernate-dev] Loggers In-Reply-To: References: Message-ID: On Fri, 28 Sep 2018 at 16:43, Steve Ebersole wrote: > > Thanks for the feedback! I'm actually sorry for the delay :) Just back from 2 weeks off, catching up. > WRT effort, the plan is to make these changes as I do work in a particular area which is what I have been doing - not a "one shot, go back and change all logging". +1 > WRT granularity, sure that would be a concern. It really comes back to having a good "logical" design of the logger name hierarchy. > > WRT coordination, yep - https://github.com/sebersole/hibernate-core/blob/wip/6.0/logger_id_ranges.adoc Awesome! Thanks, Sanne > > On Fri, Sep 28, 2018 at 10:35 AM Sanne Grinovero wrote: >> >> Hi Steve, >> >> I love the cathegories idea; I think we discussed it before. My only >> concern is that it's a lot of work to implement, but if you feel it's >> doable that's great. >> >> In terms of "changes needed" I'm not worried either. Like you said, 6 >> would have had different names for most cases; at least moving forward >> such names would be more stable even if we decide to move some code in >> the future. >> >> One doubt is the granularity. I guess the risk is that maintainers >> will tend to reuse the same limited set of cathegories; we will need >> to make sure there are enough cathegories so that people can still >> enable the single aspect they might be interested in debugging, but >> maybe that's not important as people can always post-filter things >> when the output gets too verbose. >> >> We will need a way to coordinate on valid ranges for the various >> @ValidIdRange. Infinispan used a wiki for this; the upside is that >> it's out of the repository: a good thing to avoid reuse across repo >> branches - e.g. it's not ideal to have to change ids when backporting >> - , but downside of requiring human care. >> >> Thanks, >> Sanne >> >> >> On Wed, 19 Sep 2018 at 14:31, Steve Ebersole wrote: >> > >> > Yes. As I mentioned in my original, this would mean potential changes for >> > people configuring logging. I've started doing this for new logging in 6 >> > and it works great. >> > >> > Mainly asking opinions about changing existing logging and whether the >> > benefits are worth the effort. >> > >> > And keep in mind that the many many changes in 6 already would require such >> > logging config changes anyway for those configuring logging >> > >> > >> > On Wed, Sep 19, 2018, 12:50 AM Vlad Mihalcea >> > wrote: >> > >> > > I think it's a good idea. >> > > >> > > However, will this break all current applications that use the package >> > > name log appenders? >> > > >> > > Vlad >> > > >> > > On Fri, Sep 14, 2018 at 7:20 PM, Steve Ebersole >> > > wrote: >> > > >> > >> Yes, I know no one likes talking about logging. "Its not important", >> > >> until >> > >> it is ;) >> > >> >> > >> TLDR I am considering moving to using "module names" for logger names >> > >> instead of Class names even for DEBUG/TRACE logging and see if anyone had >> > >> strong arguments to not do this.. >> > >> >> > >> Full version--- >> > >> >> > >> For some time I have been moving to an approach of defining message >> > >> loggers[1] using a single contract per function or "module" - e.g.: >> > >> >> > >> 1. the second level caching module uses the dedicated message logger >> > >> `ConnectionPoolingLogger` >> > >> 2. the ManagedBeanRegistry module uses the dedicated message logger >> > >> `BeansMessageLogger` >> > >> 3. etc >> > > >> > > >> > >> >> > >> Each of these define a dedicate instance instance they can use. E.g. >> > >> ConnectionPoolingLogger is defined as: >> > >> >> > >> ```` >> > >> @MessageLogger( projectCode = "HHH" ) >> > >> @ValidIdRange( min = 10001001, max = 10001500 ) >> > >> public interface ConnectionPoolingLogger extends BasicLogger { >> > >> >> > >> ConnectionPoolingLogger CONNECTIONS_LOGGER = Logger.getMessageLogger( >> > >> ConnectionPoolingLogger.class, >> > >> "org.hibernate.orm.connections.pooling" >> > >> ); >> > >> >> > >> ... >> > >> } >> > >> ```` >> > >> >> > >> I won't get into all the whys I do this unless someone cares ;) >> > >> >> > >> But I am contemplating doing the same for basic loggers so I wanted to ask >> > >> everyone else's opinion since this means a change in how you'd have to >> > >> configure logging for DEBUG/TRACE output. Usually you'd use the Class >> > >> name >> > >> as the logger name and use that to control logging in the back-end (log4j, >> > >> etc). If I do this, you'd have to instead use the module name. >> > >> >> > >> There are quite a few reasons I am considering this, including all of the >> > >> reasons I did it for message loggers in the first place. If I am >> > >> debugging the loading of a collection or an entity, today I'd have to know >> > >> all the packages involved (there is no common root name) and list them in >> > >> my log4j.properties; that is because the process is ultimately handled by >> > >> delegates or helpers in many different packages (`org.hibernate.loader`, >> > >> `org.hibernate.persister`, `org.hibernate.type`, ...). It sure would be >> > >> nice to just be able to say `org.hibernate.loading` or >> > >> `org.hibernate.loading.entity` or `org.hibernate.loading.collection` or >> > >> ... >> > >> for a number of reasons: >> > >> >> > >> 1. When we need to see logging from someone it is a lot easier to tell >> > >> the module name(s) you need enabled as opposed a list of package and >> > >> class >> > >> names. >> > >> 2. When running JPA TCK it is essentially impossible to attach debugger >> > >> to step through code when debugging a failure - you have to rely on >> > >> debugging through output. *Well that used to be the case, but the >> > >> latest TCK broke logging to STDOUT somehow so we ended up having to >> > >> try and >> > >> reproduce the failure in our testsuite - so then it does not matter >> > >> either >> > >> way ;)* >> > >> 3. Easier to document - >> > >> >> > >> http://docs.jboss.org/hibernate/orm/5.3/topical/html_single/logging/Logging.html >> > >> >> > >> Thoughts? >> > >> >> > >> >> > >> [1] JBoss Logging's `org.jboss.logging.annotations.MessageLogger` - which >> > >> we use for user-focused log messages. Should always be logged at >= INFO >> > >> [2] >> > >> [3] JBoss Logging's `org.jboss.logging.BasicLogger` - which we use for >> > >> developer-focused log messages (for debugging). Should always be logged >> > >> at >> > >> DEBUG or TRACE >> > >> _______________________________________________ >> > >> 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 gbadner at redhat.com Fri Sep 28 21:27:53 2018 From: gbadner at redhat.com (Gail Badner) Date: Fri, 28 Sep 2018 18:27:53 -0700 Subject: [hibernate-dev] What should happen to queued operations when a collection is detached? Message-ID: HHH-11209 involves a bug merging a detached entity with an uninitialized collection that has queued operations. After looking into this issue I found a bug where AbstractPersistentCollection#operationQueue was not being cleared after a commit, if there was no cascade mapped for the collection. I've fixed that in a PR. [1] After that fix, the detached entity in the test case attached to HHH-11209 has an uninitialized entity without any queued operations after commit, which can be merged successfully in a new session/transaction. There is still a problem when Hibernate tries to merge a detached entity has an uninitialized collection with queued operations though. My PR throws UnsupportedOperationException in this case, and there is a test case that reproduces it. I've been working on a fix to add support for this, but I have my doubts that it really should be supported. I see that prior to fixing HHH-5855 (which caused HHH-11209), Hibernate simply ignored the queued operations in the detached collection. [2]. The fix for HHH-5855 properly dealt with merging a managed collection that was uninitialized with queued operations. It introduced the bug where a NullPointerException would get thrown if that collection was detached. If we want to support merging the queued operations, then I would consider that an improvement. Would this be a worthwhile improvement? I'm guessing not, but I wanted to get some opinions. For now, I see a couple of ways to deal with this so that HHH-11209 can be wrapped up: 1) ignore queued operations in a detached collection when merging, as was done before HHH-5855 was fixed. 2) clear the queued operations when the collection is detached. Comments? Thanks, Gail [1] https://github.com/hibernate/hibernate-orm/pull/2460 [2] https://github.com/hibernate/hibernate-orm/commit/c1934b72edb4f781520937618b3b750bebb84576#diff-2c7912a47063b9ea81323bf9c6628895L651