1:10 p.m.
On 06/06/2013 05:26 PM, Sanne Grinovero wrote:
Hibernate Search has many additional dependencies on top of just
ORM..
would the WildFly team be happy with that?
I always assumed that would not be considered acceptable.
Its not every dependency that needs to be put into the Hibernate ORM
static module, just the ones that the ORM service loader needs to see.
Are the additional dependencies also loaded as ORM services?
I'm not against saying no to including Hibernate Search jars in
application deployments. That would be the easiest.
The best reason that I have heard for including Hibernate ORM jars with
the application, is that they want to stay with that version of
Hibernate while moving forward to a newer application server version
that may be bundling a newer Hibernate version. If found it problematic
to support deployments having their own Hibernate ORM jars, when there
are bidirectional 1-1 dependencies on the static Hibernate ORM module
referencing code that we use with Hibernate ORM.
Also with such a solution people won't have flexibility on the
version; I know people don't have it with ORM either - unless they
bring their own - but to make upgrades possible in existing projects
it is extremely useful to be able to update one dependency at a time,
which I suspect would not be possible anymore:
upgrade ORM first, run the tests, upgrade Search, run the tests.
Nailing down one version - by using the ORM provided by an application
server - makes this harder, but nailing down both versions forces
people to upgrade both at the same time: if there's an issue it will
be much harder to figure out the area.
We could look again at some of the suggestions on
http://jboss-as7-development.1055759.n5.nabble.com/Modularity-is-the-spaw...
for changing how we do service loading in Hibernate. I don't think any
of the suggestions helped the last time we tried to improve service
loading (modular classloading doesn't have inverse dependencies and we
can't pass classloaders into the Hibernate ORM service loading code).
But, maybe I'm wrong and we could make a change somewhere for improvement.
Sanne
On 6 June 2013 18:42, Scott Marlow <smarlow(a)redhat.com> wrote:
> On 06/06/2013 11:49 AM, Emmanuel Bernard wrote:
>> On Thu 2013-06-06 11:31, Scott Marlow wrote:
>>>
>>> If the static Hibernate Search module, depends on a static Hibernate
>>> ORM module in WildFly 8, I think that is fine, but applications
>>> wouldn't be able to include their own Hibernate Search jars (since
>>> the static Hibernate ORM module only sees services in the static
>>> Hibernate Search module).
>>
>> That's one deployment and the one I did first (see my other email).
>>
>>>
>>> For WildFly 8, do we want to allow applications to bundle its own
>>> version of Hibernate Search that could work with bundled Hibernate
>>> ORM jars?
>>
>> It's a bit confusing to me this whole business but AFAIU but if we
>> could, yes that would be good.
>>
>
> To handle application deployments that contain their own Hibernate
> Search jars, we would need to make an adjustment. Instead of having the
> Hibernate ORM module depend on the Hibernate Search module (this is what
> we currently do in AS7 via 1-1 bidirectional dependencies), we would
> need to include the Hibernate Search jars in the Hibernate ORM module.
> This is specific to WildFly 8 (assuming my WF8 patch is merged in).
>
> If we don't put Hibernate Search into the ORM module, we will face the
> same blocking issue that I saw very late on AS7, which is the JipiJapa
> integration code module (used to be in AS7 codebase) depends on the
> static Hibernate ORM module which conflicts with the Hibernate ORM jars
> loaded by the application classloader.
>
> Also, keep in mind that In AS7, there was no JipiJapa project, so
> applications couldn't easily include the JipiJapa integration classes
> (point being that there were several blocking issues that prevented
> Hibernate 4.x jars from being in the deployment). Of course, Hibernate
> 3 jars were different as there is no Hibernate 3 static module in AS8
> (so applications could include Hibernate 3 jars).
>
> There were some other ways of dealing with service loading mentioned on
> the "stinking donkey" thread [1] last year, but I'm not sure if any of
> the alternatives would help application deployments to include Hibernate
> ORM/Search/other jars.
>
> [1]
>
http://jboss-as7-development.1055759.n5.nabble.com/Modularity-is-the-spaw...
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev