Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

[Sanne Grinovero]

Hi Scott,

no I don't think that's possible. There are many ways of bootstrapping
Hibernate, and "using code" is also a valid option, which implies end
users have the option to read configuration properties from custom
sources or even hard-code configuration.

Granted in practice they'll likely use Spring or other frameworks to
boot it, but a list of such frameworks would necessarily be
open-ended.

Not least, I wouldn't want you to automatically add Hibernate ORM
dependencies as it's very likely in most of these cases that the end
user will want to use a different version of Hibernate ORM to match
the requirements of the framework do jour, or otherwise include a
custom version.

The only "safe default" would be to inspect the bytecode of the
deployment and see if both conditions are true:
 - any class refers to Hibernate (JPA) code / annotations
 - no Hibernate version is included

On top of this not being simple to perform, it would also not be a
safe operation as Hibernate evolves so you can't really be sure if
some future version has not been included.

I'd highly prefer the simplicity of WildFly behaving without any
complex guess work: inject Hibernate when asked for it. Doing this
based on the META-INF/persistence.xml presence seems a reasonable
compromise but anything more complex is something that people will
have to understand to control it..

Thanks,
Sanne


On 28 March 2017 at 16:46, Scott Marlow  wrote:
>
>
> On 03/28/2017 11:30 AM, Scott Marlow wrote:
>> Hi,
>>
>> Would it be possible for a WildFly deployment unit processor to detect
>> Hibernate ORM native applications, by detecting the presence of a
>> particular configuration file that is always present?  I'm not sure if
>> this is possible, but if it is, perhaps WildFly could automatically
>> add the (supported) Hibernate orm module to the native application, if
>> the deployment is clearly marked as a Hibernate native application, as
>> well as also exporting Javassist to the deployment.
>
> A related question, is there a standard Hibernate annotation class that
> native Hibernate applications always use that we could scan for the same
> reasons, as an alternative to scanning for Hibernate configuration files?
>
>>
>> Thoughts?
>>
>> Scott
>>
>>
>>
>> On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow  wrote:
> Right, Hibernate ORM's module should be the one exposing it, not the
> application nor JipiJapa.
 JipiJapa has zero to do with this, we will create a pr later today to
 remove the unneeded dependencies, which has nothing to do with this
 conversation.
>>> https://github.com/wildfly/wildfly/pull/9305 is for removing the
>>> unused Javassist dependency from JipiJapa.  Also removed a few other
>>> unused dependencies.
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

[Scott Marlow]

On 03/28/2017 11:30 AM, Scott Marlow wrote:
> Hi,
>
> Would it be possible for a WildFly deployment unit processor to detect
> Hibernate ORM native applications, by detecting the presence of a
> particular configuration file that is always present?  I'm not sure if
> this is possible, but if it is, perhaps WildFly could automatically
> add the (supported) Hibernate orm module to the native application, if
> the deployment is clearly marked as a Hibernate native application, as
> well as also exporting Javassist to the deployment.

A related question, is there a standard Hibernate annotation class that 
native Hibernate applications always use that we could scan for the same 
reasons, as an alternative to scanning for Hibernate configuration files?

>
> Thoughts?
>
> Scott
>
>
>
> On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow  wrote:
 Right, Hibernate ORM's module should be the one exposing it, not the
 application nor JipiJapa.
>>> JipiJapa has zero to do with this, we will create a pr later today to
>>> remove the unneeded dependencies, which has nothing to do with this
>>> conversation.
>> https://github.com/wildfly/wildfly/pull/9305 is for removing the
>> unused Javassist dependency from JipiJapa.  Also removed a few other
>> unused dependencies.

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

[Scott Marlow]

Hi,

Would it be possible for a WildFly deployment unit processor to detect
Hibernate ORM native applications, by detecting the presence of a
particular configuration file that is always present?  I'm not sure if
this is possible, but if it is, perhaps WildFly could automatically
add the (supported) Hibernate orm module to the native application, if
the deployment is clearly marked as a Hibernate native application, as
well as also exporting Javassist to the deployment.

Thoughts?

Scott



On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow  wrote:
>>> Right, Hibernate ORM's module should be the one exposing it, not the
>>> application nor JipiJapa.
>>
>> JipiJapa has zero to do with this, we will create a pr later today to
>> remove the unneeded dependencies, which has nothing to do with this
>> conversation.
>
> https://github.com/wildfly/wildfly/pull/9305 is for removing the
> unused Javassist dependency from JipiJapa.  Also removed a few other
> unused dependencies.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] NoORM IRC meeting minutes

[Guillaume Smet]

Hi,

Spring is here and so are the minutes of this week's NoORM IRC meeting:

16:06 < jbott> Meeting ended Tue Mar 28 14:06:02 2017 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:06 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.html
16:06 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.txt
16:06 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2017/hibernate-dev.2017-03-28-13.02.log.html

Have a nice day!

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - id type

[Steve Ebersole]

We've all "proposed" it at some point Sanne ;)  The bigger question is when
to do it since it means API changes.

But it sounds like everyone is on board for that for 6.0

On Tue, Mar 28, 2017, 6:54 AM Sanne Grinovero  wrote:

> +1, as proposed a long time ago :)
>
> On 28 March 2017 at 07:52, Vlad Mihalcea  wrote:
> > +1
> >
> > I remember that Spring Data CRUDRepository has this restriction that ID
> > extends Serializable just because Hibernate required it so. I agree that
> we
> > should drop this restriction and allow non-Serializable @Id as other JPA
> > providers.
> >
> > On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov <
> > christian.bei...@gmail.com> wrote:
> >
> >> +1 for that. Stumbled over that once or twice in the past and wondered
> >> what the reasons were.
> >>
> >>
> >> Mit freundlichen Grüßen,
> >> 
> >> *Christian Beikov*
> >> Am 27.03.2017 um 19:37 schrieb Steve Ebersole:
> >> > In all versions of Hibernate to-date we have required that the Java
> type
> >> of
> >> > an id be Serializable.  Strictly speaking JPA has no such restriction
> -
> >> it
> >> > says ids can be any Object type *unless* the entity is to be
> serialized,
> >> in
> >> > which case the id must be Serializable (duh).
> >> >
> >> > As we transition into 6.0, I wonder if we want to loosen this
> restriction
> >> > and allow the id to be any Object type as well.  There really is no
> valid
> >> > reason (beyond the obvious case explicitly discussed in the JPA spec)
> for
> >> > requiring the id to be Serializable.
> >> >
> >> > WDYT?
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - id type

[Sanne Grinovero]

+1, as proposed a long time ago :)

On 28 March 2017 at 07:52, Vlad Mihalcea  wrote:
> +1
>
> I remember that Spring Data CRUDRepository has this restriction that ID
> extends Serializable just because Hibernate required it so. I agree that we
> should drop this restriction and allow non-Serializable @Id as other JPA
> providers.
>
> On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
>> +1 for that. Stumbled over that once or twice in the past and wondered
>> what the reasons were.
>>
>>
>> Mit freundlichen Grüßen,
>> 
>> *Christian Beikov*
>> Am 27.03.2017 um 19:37 schrieb Steve Ebersole:
>> > In all versions of Hibernate to-date we have required that the Java type
>> of
>> > an id be Serializable.  Strictly speaking JPA has no such restriction -
>> it
>> > says ids can be any Object type *unless* the entity is to be serialized,
>> in
>> > which case the id must be Serializable (duh).
>> >
>> > As we transition into 6.0, I wonder if we want to loosen this restriction
>> > and allow the id to be any Object type as well.  There really is no valid
>> > reason (beyond the obvious case explicitly discussed in the JPA spec) for
>> > requiring the id to be Serializable.
>> >
>> > WDYT?
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Hibernat OGM contrib repository

[Sanne Grinovero]

Regarding the License I think we have no choice, we have to use the
same license as alternatively we'd need to get permission to change
the license as it's existing code.
I'm assuming we have no interest in that, and if we had this process
would take some time so we'd have to propose such a change as an
independent step from the repository move.

Regarding group-id : I see no reason to change it but have no strong
opinion on that. I'd similarly suggest to make such changes as a
follow-up though, and not treat it as a blocker.
(If we decide to change it, it would be a breaking change so we'd need
redirection poms so we might as well do it later)

Thanks,
Sanne


On 28 March 2017 at 11:28, Davide D'Alto  wrote:
> Hi all,
> I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib
>
> I have a couple of quesitons before moving it in an official repository:
>
> - Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>
> - What about the license? Can I re-use the same in Hibernate OGM?
>
> I still need to update the README, this is the related PR for OGM:
> https://github.com/hibernate/hibernate-ogm/pull/850
>
> Thanks,
> Davide
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Hibernat OGM contrib repository

[Yoann Rodiere]

Hi,

I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib


Great, thanks :)

Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>

+1 for org.hibernate.ogm.contrib. I would say let's use a different group
ID when the release cycles are different. Which is the case here.

What about the license? Can I re-use the same in Hibernate OGM?

I would say you will *have* to use the same, or a compatible one, unless
you want to ask permission to every single past contributor (which I think
is required to re-license a codebase)...


Yoann Rodière 
Hibernate NoORM Team

On 28 March 2017 at 12:28, Davide D'Alto  wrote:

> Hi all,
> I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib
>
> I have a couple of quesitons before moving it in an official repository:
>
> - Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>
> - What about the license? Can I re-use the same in Hibernate OGM?
>
> I still need to update the README, this is the related PR for OGM:
> https://github.com/hibernate/hibernate-ogm/pull/850
>
> Thanks,
> Davide
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Question about current flush ordering

[Vlad Mihalcea]

Hi,

There is this issue that has puzzled me for many years related to
ActionQueue ordering:

- OrphanRemovalAction.class,
- AbstractEntityInsertAction.class,
- EntityUpdateAction.class,
- QueuedOperationCollectionAction.class,
- CollectionRemoveAction.class,
- CollectionUpdateAction.class,
- CollectionRecreateAction.class,
- EntityDeleteAction.class,
Why is it that we execute the OrphanRemovalAction firsts, but the
EntityDeleteAction last?

Shouldn't the EntityDeleteAction be executed before Insert or Update?

There musts be a reason for choosing this ordering, but I can't figure out
why the EntityDeleteAction was chosen to be executed last.

Vlad
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - id type

[Vlad Mihalcea]

+1

I remember that Spring Data CRUDRepository has this restriction that ID
extends Serializable just because Hibernate required it so. I agree that we
should drop this restriction and allow non-Serializable @Id as other JPA
providers.

On Mon, Mar 27, 2017 at 9:54 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> +1 for that. Stumbled over that once or twice in the past and wondered
> what the reasons were.
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 27.03.2017 um 19:37 schrieb Steve Ebersole:
> > In all versions of Hibernate to-date we have required that the Java type
> of
> > an id be Serializable.  Strictly speaking JPA has no such restriction -
> it
> > says ids can be any Object type *unless* the entity is to be serialized,
> in
> > which case the id must be Serializable (duh).
> >
> > As we transition into 6.0, I wonder if we want to loosen this restriction
> > and allow the id to be any Object type as well.  There really is no valid
> > reason (beyond the obvious case explicitly discussed in the JPA spec) for
> > requiring the id to be Serializable.
> >
> > WDYT?
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev