3:19 p.m.
Hi,
As discussed by some of us during the No ORM meeting in May, it'd be great
if there was a module ZIP allowing people to easily upgrade Hibernate ORM
in the WildFly version they are using.
Just the other day there was a blog post published [1] describing how to
use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
existing module.xml files. We could do better than that, leaving the
original version intact and providing a new one with a specific slot
("5.2") in the ZIP.
That'd also be helpful for other projects such as Hibernate OGM which
already provide a module ZIP for WF but currently need to package ORM, too,
in case they need features from a later ORM version.
If we all agree that's a good thing to have, I can help with making it
happen.
Thanks,
--Gunnar
[1]
http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
3:51 p.m.
Too bad we can't just publish a Docker image.
Is this something we'd publish somewhere (Nexus/Artifactory)? I know
nothing about building a WF module ZIP. But if you are willing to do the
work and it helps OGM etc, of course we would incorporate it.
On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi,
As discussed by some of us during the No ORM meeting in May, it'd be great
if there was a module ZIP allowing people to easily upgrade Hibernate ORM
in the WildFly version they are using.
Just the other day there was a blog post published [1] describing how to
use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
existing module.xml files. We could do better than that, leaving the
original version intact and providing a new one with a specific slot
("5.2") in the ZIP.
That'd also be helpful for other projects such as Hibernate OGM which
already provide a module ZIP for WF but currently need to package ORM, too,
in case they need features from a later ORM version.
If we all agree that's a good thing to have, I can help with making it
happen.
Thanks,
--Gunnar
[1]
http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:11 a.m.
2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
Too bad we can't just publish a Docker image.
We could do that, but I think we should have a solution for non-Docker
users, too.
Is this something we'd publish somewhere (Nexus/Artifactory)?
Yes, we'd publish it in Nexus and also BinTray/SourceForge.
People would download it, unzip it into the "modules" directory of their WF
instance and could start using the new ORM version (provided the larger
scheme of integration hasn't changed, so the JipiJapa bits in WF continue
to work as is).
I know nothing about building a WF module ZIP. But if you are
willing
to do the work and it helps OGM etc, of course we would incorporate it.
Ok, cool. I'll take a look then.
On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
> Hi,
>
> As discussed by some of us during the No ORM meeting in May, it'd be great
> if there was a module ZIP allowing people to easily upgrade Hibernate ORM
> in the WildFly version they are using.
>
> Just the other day there was a blog post published [1] describing how to
> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
> existing module.xml files. We could do better than that, leaving the
> original version intact and providing a new one with a specific slot
> ("5.2") in the ZIP.
>
> That'd also be helpful for other projects such as Hibernate OGM which
> already provide a module ZIP for WF but currently need to package ORM,
> too,
> in case they need features from a later ORM version.
>
> If we all agree that's a good thing to have, I can help with making it
> happen.
>
> Thanks,
>
> --Gunnar
>
> [1]
>
> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
4:59 p.m.
On 8 June 2016 at 08:11, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2016-06-07 15:51 GMT+02:00 Steve Ebersole
<steve(a)hibernate.org>:
> Too bad we can't just publish a Docker image.
>
We could do that, but I think we should have a solution for non-Docker
users, too.
What's the point to package a library in a Docker image?
>
> Is this something we'd publish somewhere (Nexus/Artifactory)?
>
Yes, we'd publish it in Nexus and also BinTray/SourceForge.
People would download it, unzip it into the "modules" directory of their WF
instance and could start using the new ORM version (provided the larger
scheme of integration hasn't changed, so the JipiJapa bits in WF continue
to work as is).
> I know nothing about building a WF module ZIP. But if you are willing
> to do the work and it helps OGM etc, of course we would incorporate it.
>
Ok, cool. I'll take a look then.
On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
>> Hi,
>>
>> As discussed by some of us during the No ORM meeting in May, it'd be great
>> if there was a module ZIP allowing people to easily upgrade Hibernate ORM
>> in the WildFly version they are using.
>>
>> Just the other day there was a blog post published [1] describing how to
>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
>> existing module.xml files. We could do better than that, leaving the
>> original version intact and providing a new one with a specific slot
>> ("5.2") in the ZIP.
>>
>> That'd also be helpful for other projects such as Hibernate OGM which
>> already provide a module ZIP for WF but currently need to package ORM,
>> too,
>> in case they need features from a later ORM version.
>>
>> If we all agree that's a good thing to have, I can help with making it
>> happen.
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>>
>> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:01 p.m.
I don't know. I was just thinking of distribution. I really know very
little about WF modules
On Wed, Jun 8, 2016 at 9:59 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 8 June 2016 at 08:11, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>
>> Too bad we can't just publish a Docker image.
>>
>
> We could do that, but I think we should have a solution for non-Docker
> users, too.
What's the point to package a library in a Docker image?
>
>>
>> Is this something we'd publish somewhere (Nexus/Artifactory)?
>>
>
> Yes, we'd publish it in Nexus and also BinTray/SourceForge.
>
> People would download it, unzip it into the "modules" directory of their
WF
> instance and could start using the new ORM version (provided the larger
> scheme of integration hasn't changed, so the JipiJapa bits in WF continue
> to work as is).
>
>
>> I know nothing about building a WF module ZIP. But if you are willing
>> to do the work and it helps OGM etc, of course we would incorporate it.
>>
>
> Ok, cool. I'll take a look then.
>
> On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar(a)hibernate.org>
wrote:
>>
>>> Hi,
>>>
>>> As discussed by some of us during the No ORM meeting in May, it'd be
great
>>> if there was a module ZIP allowing people to easily upgrade Hibernate
ORM
>>> in the WildFly version they are using.
>>>
>>> Just the other day there was a blog post published [1] describing how
to
>>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
>>> existing module.xml files. We could do better than that, leaving the
>>> original version intact and providing a new one with a specific slot
>>> ("5.2") in the ZIP.
>>>
>>> That'd also be helpful for other projects such as Hibernate OGM which
>>> already provide a module ZIP for WF but currently need to package ORM,
>>> too,
>>> in case they need features from a later ORM version.
>>>
>>> If we all agree that's a good thing to have, I can help with making it
>>> happen.
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1]
>>>
>>>
http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:08 p.m.
It'd not only be a library, but an image containing WF with the latest
Hibernate ORM. But as said, the module ZIP is more versatile and is what
I'd do.
2016-06-08 16:59 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
On 8 June 2016 at 08:11, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>
>> Too bad we can't just publish a Docker image.
>>
>
> We could do that, but I think we should have a solution for non-Docker
> users, too.
What's the point to package a library in a Docker image?
>
>>
>> Is this something we'd publish somewhere (Nexus/Artifactory)?
>>
>
> Yes, we'd publish it in Nexus and also BinTray/SourceForge.
>
> People would download it, unzip it into the "modules" directory of their
WF
> instance and could start using the new ORM version (provided the larger
> scheme of integration hasn't changed, so the JipiJapa bits in WF continue
> to work as is).
>
>
>> I know nothing about building a WF module ZIP. But if you are willing
>> to do the work and it helps OGM etc, of course we would incorporate it.
>>
>
> Ok, cool. I'll take a look then.
>
> On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar(a)hibernate.org>
wrote:
>>
>>> Hi,
>>>
>>> As discussed by some of us during the No ORM meeting in May, it'd be
great
>>> if there was a module ZIP allowing people to easily upgrade Hibernate
ORM
>>> in the WildFly version they are using.
>>>
>>> Just the other day there was a blog post published [1] describing how
to
>>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
>>> existing module.xml files. We could do better than that, leaving the
>>> original version intact and providing a new one with a specific slot
>>> ("5.2") in the ZIP.
>>>
>>> That'd also be helpful for other projects such as Hibernate OGM which
>>> already provide a module ZIP for WF but currently need to package ORM,
>>> too,
>>> in case they need features from a later ORM version.
>>>
>>> If we all agree that's a good thing to have, I can help with making it
>>> happen.
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1]
>>>
>>>
http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:16 p.m.
On 8 June 2016 at 16:08, Gunnar Morling <gunnar(a)hibernate.org> wrote:
It'd not only be a library, but an image containing WF with the
latest
Hibernate ORM. But as said, the module ZIP is more versatile and is what I'd
do.
+1 for the priority on ZIP files.
I had not understood that you meant to re-distribute a customized WF
image so I was quite confused :)
2016-06-08 16:59 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>
> On 8 June 2016 at 08:11, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
> >
> >> Too bad we can't just publish a Docker image.
> >>
> >
> > We could do that, but I think we should have a solution for non-Docker
> > users, too.
>
> What's the point to package a library in a Docker image?
>
> >
> >>
> >> Is this something we'd publish somewhere (Nexus/Artifactory)?
> >>
> >
> > Yes, we'd publish it in Nexus and also BinTray/SourceForge.
> >
> > People would download it, unzip it into the "modules" directory of
their
> > WF
> > instance and could start using the new ORM version (provided the larger
> > scheme of integration hasn't changed, so the JipiJapa bits in WF
> > continue
> > to work as is).
> >
> >
> >> I know nothing about building a WF module ZIP. But if you are
> >> willing
> >> to do the work and it helps OGM etc, of course we would incorporate it.
> >>
> >
> > Ok, cool. I'll take a look then.
> >
> > On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar(a)hibernate.org>
> > wrote:
> >>
> >>> Hi,
> >>>
> >>> As discussed by some of us during the No ORM meeting in May, it'd
be
> >>> great
> >>> if there was a module ZIP allowing people to easily upgrade Hibernate
> >>> ORM
> >>> in the WildFly version they are using.
> >>>
> >>> Just the other day there was a blog post published [1] describing how
> >>> to
> >>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on
> >>> the
> >>> existing module.xml files. We could do better than that, leaving the
> >>> original version intact and providing a new one with a specific slot
> >>> ("5.2") in the ZIP.
> >>>
> >>> That'd also be helpful for other projects such as Hibernate OGM
which
> >>> already provide a module ZIP for WF but currently need to package ORM,
> >>> too,
> >>> in case they need features from a later ORM version.
> >>>
> >>> If we all agree that's a good thing to have, I can help with making
it
> >>> happen.
> >>>
> >>> Thanks,
> >>>
> >>> --Gunnar
> >>>
> >>> [1]
> >>>
> >>>
> >>>
http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:53 a.m.
Scott, all,
As discussed I've started to work on a module ZIP which can be used to add
Hibernate ORM 5.1 to an existing WildFly 10.0 instance (which comes with
ORM 5.0). As module slot I'm using "5.1".
Now I assumed that it'd be enough to set this property in persistence.xml:
jboss.as.jpa.providerModule=org.hibernate:5.1
Indeed I'm seeing that my new module is added as a dependency to the
deployment, but the default ORM ("org.hibernate:main") is still being
added, too. As a result I'm getting an exception due to incompatible
Integrator classes (the 5.0 ORM tries to load the 5.1 integrator for Envers
which is failing due to the incompatible class hierarchies).
Do you have any idea why this is happening? I see that the module
org.jboss.as.ejb3 has a dependency to module org.hibernate (no slot, i.e.
"main"). May this be the cause? If so, what would I have to do to enable
only my 5.1 module and not the default 5.0 one for a given deployment? Or
any other idea?
Thanks,
--Gunnar
2016-06-08 17:16 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
On 8 June 2016 at 16:08, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> It'd not only be a library, but an image containing WF with the latest
> Hibernate ORM. But as said, the module ZIP is more versatile and is what
I'd
> do.
+1 for the priority on ZIP files.
I had not understood that you meant to re-distribute a customized WF
image so I was quite confused :)
>
> 2016-06-08 16:59 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>>
>> On 8 June 2016 at 08:11, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>> >
>> >> Too bad we can't just publish a Docker image.
>> >>
>> >
>> > We could do that, but I think we should have a solution for non-Docker
>> > users, too.
>>
>> What's the point to package a library in a Docker image?
>>
>> >
>> >>
>> >> Is this something we'd publish somewhere (Nexus/Artifactory)?
>> >>
>> >
>> > Yes, we'd publish it in Nexus and also BinTray/SourceForge.
>> >
>> > People would download it, unzip it into the "modules" directory
of
their
>> > WF
>> > instance and could start using the new ORM version (provided the
larger
>> > scheme of integration hasn't changed, so the JipiJapa bits in WF
>> > continue
>> > to work as is).
>> >
>> >
>> >> I know nothing about building a WF module ZIP. But if you are
>> >> willing
>> >> to do the work and it helps OGM etc, of course we would incorporate
it.
>> >>
>> >
>> > Ok, cool. I'll take a look then.
>> >
>> > On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar(a)hibernate.org>
>> > wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> As discussed by some of us during the No ORM meeting in May,
it'd be
>> >>> great
>> >>> if there was a module ZIP allowing people to easily upgrade
Hibernate
>> >>> ORM
>> >>> in the WildFly version they are using.
>> >>>
>> >>> Just the other day there was a blog post published [1] describing
how
>> >>> to
>> >>> use Hibernate ORM 5.2 in WF 10, essentially via Search &
Replace on
>> >>> the
>> >>> existing module.xml files. We could do better than that, leaving
the
>> >>> original version intact and providing a new one with a specific
slot
>> >>> ("5.2") in the ZIP.
>> >>>
>> >>> That'd also be helpful for other projects such as Hibernate
OGM
which
>> >>> already provide a module ZIP for WF but currently need to package
ORM,
>> >>> too,
>> >>> in case they need features from a later ORM version.
>> >>>
>> >>> If we all agree that's a good thing to have, I can help with
making
it
>> >>> happen.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> --Gunnar
>> >>>
>> >>> [1]
>> >>>
>> >>>
>> >>>
http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev(a)lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
2:15 p.m.
Ok, so this was caused by the module dependency
from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to
create a 5.1-specific adapter module, too, and require that to be
configured by users via jboss.as.jpa.adapterModule.
2016-06-25 11:53 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
Scott, all,
As discussed I've started to work on a module ZIP which can be used to add
Hibernate ORM 5.1 to an existing WildFly 10.0 instance (which comes with
ORM 5.0). As module slot I'm using "5.1".
Now I assumed that it'd be enough to set this property in persistence.xml:
jboss.as.jpa.providerModule=org.hibernate:5.1
Indeed I'm seeing that my new module is added as a dependency to the
deployment, but the default ORM ("org.hibernate:main") is still being
added, too. As a result I'm getting an exception due to incompatible
Integrator classes (the 5.0 ORM tries to load the 5.1 integrator for Envers
which is failing due to the incompatible class hierarchies).
Do you have any idea why this is happening? I see that the module
org.jboss.as.ejb3 has a dependency to module org.hibernate (no slot, i.e.
"main"). May this be the cause? If so, what would I have to do to enable
only my 5.1 module and not the default 5.0 one for a given deployment? Or
any other idea?
Thanks,
--Gunnar
2016-06-08 17:16 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
> On 8 June 2016 at 16:08, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> > It'd not only be a library, but an image containing WF with the latest
> > Hibernate ORM. But as said, the module ZIP is more versatile and is
> what I'd
> > do.
>
> +1 for the priority on ZIP files.
>
> I had not understood that you meant to re-distribute a customized WF
> image so I was quite confused :)
>
> >
> > 2016-06-08 16:59 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
> >>
> >> On 8 June 2016 at 08:11, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> >> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
> >> >
> >> >> Too bad we can't just publish a Docker image.
> >> >>
> >> >
> >> > We could do that, but I think we should have a solution for
> non-Docker
> >> > users, too.
> >>
> >> What's the point to package a library in a Docker image?
> >>
> >> >
> >> >>
> >> >> Is this something we'd publish somewhere (Nexus/Artifactory)?
> >> >>
> >> >
> >> > Yes, we'd publish it in Nexus and also BinTray/SourceForge.
> >> >
> >> > People would download it, unzip it into the "modules"
directory of
> their
> >> > WF
> >> > instance and could start using the new ORM version (provided the
> larger
> >> > scheme of integration hasn't changed, so the JipiJapa bits in WF
> >> > continue
> >> > to work as is).
> >> >
> >> >
> >> >> I know nothing about building a WF module ZIP. But if you are
> >> >> willing
> >> >> to do the work and it helps OGM etc, of course we would
incorporate
> it.
> >> >>
> >> >
> >> > Ok, cool. I'll take a look then.
> >> >
> >> > On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling
<gunnar(a)hibernate.org>
> >> > wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> As discussed by some of us during the No ORM meeting in May,
it'd
> be
> >> >>> great
> >> >>> if there was a module ZIP allowing people to easily upgrade
> Hibernate
> >> >>> ORM
> >> >>> in the WildFly version they are using.
> >> >>>
> >> >>> Just the other day there was a blog post published [1]
describing
> how
> >> >>> to
> >> >>> use Hibernate ORM 5.2 in WF 10, essentially via Search &
Replace on
> >> >>> the
> >> >>> existing module.xml files. We could do better than that,
leaving
> the
> >> >>> original version intact and providing a new one with a
specific
> slot
> >> >>> ("5.2") in the ZIP.
> >> >>>
> >> >>> That'd also be helpful for other projects such as Hibernate
OGM
> which
> >> >>> already provide a module ZIP for WF but currently need to
package
> ORM,
> >> >>> too,
> >> >>> in case they need features from a later ORM version.
> >> >>>
> >> >>> If we all agree that's a good thing to have, I can help
with
> making it
> >> >>> happen.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> --Gunnar
> >> >>>
> >> >>> [1]
> >> >>>
> >> >>>
> >> >>>
> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
> >> >>> _______________________________________________
> >> >>> hibernate-dev mailing list
> >> >>> hibernate-dev(a)lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>>
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>
11:12 p.m.
On 25 June 2016 at 13:15, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Ok, so this was caused by the module dependency
from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to
create a 5.1-specific adapter module, too, and require that to be
configured by users via jboss.as.jpa.adapterModule.
If you include the adaptor module with the ORM modules, it should be
auto-discovered.
See how OGM does it.
I'm not sure I understood why you were being exposed to the
jipijapa-hibernate5 module though?
This shouldn't activate automatically when you change the
providerModule setting.
--Sanne
3:39 p.m.
On 06/25/2016 05:12 PM, Sanne Grinovero wrote:
On 25 June 2016 at 13:15, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> Ok, so this was caused by the module dependency
> from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to
> create a 5.1-specific adapter module, too, and require that to be
> configured by users via jboss.as.jpa.adapterModule.
What happens if we copy the contents of the
org.hibernate.jipijapa-hibernate5 module, to
org.hibernate.jipijapa-hibernate5-1. Change
org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and change ORM
5.1 to depend on org.hibernate.jipijapa-hibernate5-1.
If you include the adaptor module with the ORM modules, it should be
auto-discovered.
The ORM 5.0 module.xml has the following so that service loading can do
the discovery:
"
<module name="org.hibernate.jipijapa-hibernate5"
services="import"/>
"
See how OGM does it.
I'm not sure I understood why you were being exposed to the
jipijapa-hibernate5 module though?
I'm guessing but most likely by copying the above module reference to
"org.hibernate.jipijapa-hibernate5" into the ORM 5.1 module.xml.
This shouldn't activate automatically when you change the
providerModule setting.
--Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4 p.m.
Hey,
I've sent PR https://github.com/hibernate/hibernate-orm/pull/1455 earlier
today for this.
What happens if we copy the contents of the
org.hibernate.jipijapa-hibernate5
module, to org.hibernate.jipijapa-hibernate5-1.
Change org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and
change ORM 5.1 to depend on org.hibernate.jipijapa-hibernate5-1.
Yes, that's what I ended up doing. At first I wasn't aware of that circular
dependency between the two modules, thus missing to update one of the
references to the 5.1 slot and hence pulling in the WF-provided ORM.
I'm guessing but most likely by copying the above module
reference to
"org.hibernate.jipijapa-hibernate5" into the ORM 5.1
module.xml.
Exactly.
Alternatively, I just could add the JipiJapa adapter JAR to my ORM 5.1
module, itself. But I decided to stick to the original WF structure as
close as possible.
That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks a
bit scary. My simple test passes, not sure whether that may be a problem in
other cases, though?
--Gunnar
2016-06-27 15:39 GMT+02:00 Scott Marlow <smarlow(a)redhat.com>:
>
>
> On 06/25/2016 05:12 PM, Sanne Grinovero wrote:
> > On 25 June 2016 at 13:15, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> >> Ok, so this was caused by the module dependency
> >> from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to
> >> create a 5.1-specific adapter module, too, and require that to be
> >> configured by users via jboss.as.jpa.adapterModule.
>
> What happens if we copy the contents of the
> org.hibernate.jipijapa-hibernate5 module, to
> org.hibernate.jipijapa-hibernate5-1. Change
> org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and change ORM
> 5.1 to depend on org.hibernate.jipijapa-hibernate5-1.
>
> >
> > If you include the adaptor module with the ORM modules, it should be
> > auto-discovered.
>
> The ORM 5.0 module.xml has the following so that service loading can do
> the discovery:
>
> "
> <module name="org.hibernate.jipijapa-hibernate5"
services="import"/>
> "
>
> >
> > See how OGM does it.
> >
> > I'm not sure I understood why you were being exposed to the
> > jipijapa-hibernate5 module though?
>
I'm guessing but most likely by copying the above module
reference to
> "org.hibernate.jipijapa-hibernate5" into the ORM 5.1
module.xml.
>
> > This shouldn't activate automatically when you change the
> > providerModule setting.
> >
> > --Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
5:05 p.m.
On 27 June 2016 at 15:00, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hey,
I've sent PR https://github.com/hibernate/hibernate-orm/pull/1455 earlier
today for this.
> What happens if we copy the contents of the
> org.hibernate.jipijapa-hibernate5 module, to
> org.hibernate.jipijapa-hibernate5-1.
> Change org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and
> change ORM 5.1 to depend on org.hibernate.jipijapa-hibernate5-1.
Yes, that's what I ended up doing. At first I wasn't aware of that circular
dependency between the two modules, thus missing to update one of the
references to the 5.1 slot and hence pulling in the WF-provided ORM.
> I'm guessing but most likely by copying the above module reference to
> "org.hibernate.jipijapa-hibernate5" into the ORM 5.1 module.xml.
Exactly.
Alternatively, I just could add the JipiJapa adapter JAR to my ORM 5.1
module, itself. But I decided to stick to the original WF structure as close
as possible.
+1 the ORM module is exposed to user code, while we don't want to
expose these classes.
That dependency to org.hibernate:main from org.jboss.as.ejb3 still
looks a
bit scary. My simple test passes, not sure whether that may be a problem in
other cases, though?
Great catch! Sound very dangerous indeed, at least for our plans.
Could you raise it on the wildfly-dev mailing list to be cleaned up?
--Sanne
--Gunnar
2016-06-27 15:39 GMT+02:00 Scott Marlow <smarlow(a)redhat.com>:
>
>
>
> On 06/25/2016 05:12 PM, Sanne Grinovero wrote:
> > On 25 June 2016 at 13:15, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> >> Ok, so this was caused by the module dependency
> >> from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need
> >> to
> >> create a 5.1-specific adapter module, too, and require that to be
> >> configured by users via jboss.as.jpa.adapterModule.
>
> What happens if we copy the contents of the
> org.hibernate.jipijapa-hibernate5 module, to
> org.hibernate.jipijapa-hibernate5-1. Change
> org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and change ORM
> 5.1 to depend on org.hibernate.jipijapa-hibernate5-1.
>
> >
> > If you include the adaptor module with the ORM modules, it should be
> > auto-discovered.
>
> The ORM 5.0 module.xml has the following so that service loading can do
> the discovery:
>
> "
> <module name="org.hibernate.jipijapa-hibernate5"
services="import"/>
> "
>
> >
> > See how OGM does it.
> >
> > I'm not sure I understood why you were being exposed to the
> > jipijapa-hibernate5 module though?
>
> I'm guessing but most likely by copying the above module reference to
> "org.hibernate.jipijapa-hibernate5" into the ORM 5.1 module.xml.
>
> > This shouldn't activate automatically when you change the
> > providerModule setting.
> >
> > --Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:23 p.m.
That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks
a bit scary. My simple test passes, not sure whether that may be a
problem in other cases, though?
Sorry, I missed this part of your email. EJB3 timers are using
Hibernate [1].
Scott
[1]
https://github.com/wildfly/wildfly/commit/01924ed3a38e0a4d8ef7fa54a59f12a...
5:44 p.m.
On 27 June 2016 at 16:23, Scott Marlow <smarlow(a)redhat.com> wrote:
>
> That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks
> a bit scary. My simple test passes, not sure whether that may be a
> problem in other cases, though?
>
Sorry, I missed this part of your email. EJB3 timers are using Hibernate
Thanks Scott, that sounds reassuring. May we assume that this is not
exported in any way to user's classpath?
Also, I see no instance of a "import org.hibernate" string in those
sources. Am I understanding correctly that the dependency is there
just to have a JPA implementation,
and while it happens to be tested with Hibernate, the dependency is
actually flexible?
Thanks,
Sanne
6:03 p.m.
On 06/27/2016 11:44 AM, Sanne Grinovero wrote:
On 27 June 2016 at 16:23, Scott Marlow <smarlow(a)redhat.com>
wrote:
>>
>> That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks
>> a bit scary. My simple test passes, not sure whether that may be a
>> problem in other cases, though?
>>
>
> Sorry, I missed this part of your email. EJB3 timers are using Hibernate
Thanks Scott, that sounds reassuring. May we assume that this is not
exported in any way to user's classpath?
Doesn't appear to be exported to the clients classpath.
Also, I see no instance of a "import org.hibernate" string in those
sources. Am I understanding correctly that the dependency is there
just to have a JPA implementation,
and while it happens to be tested with Hibernate, the dependency is
actually flexible?
org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
[1] appears to be purely JPA based. DDL/DML appears to be in [2].
Scott
[1]
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
[2]
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
2853
days inactive
2873
days old
15 comments
4 participants
participants (4)
-
Gunnar Morling -
Sanne Grinovero -
Scott Marlow -
Steve Ebersole