On 28 March 2017 at 17:28, Steve Ebersole wrote:
>
>
> On Tue, Mar 28, 2017 at 11:12 AM Sanne Grinovero
> wrote:
>>
>> 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
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
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 i
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
>> 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/pu
On Thu, Oct 27, 2016 at 10:14 AM, Steve Ebersole wrote:
> Dunno. To me this is a bug that Jipijapa/WF/DUP adds this dependency at
> all. How that gets resolved or not is completely up to Jipijapa/WF/DUP as
> it is the one(s) doing this. There is nothing Hibernate can do here.
>
>
I updated the
I updated https://github.com/wildfly/wildfly/pull/8474 to make a push
for applying the pull request and also mentioned the desire to update
JPADependencyProcessor to not inject Javassist into applications.
Perhaps others from the WildFly team will disagree with me and make an
exception to break app
On Thu, Oct 27, 2016 at 10:09 AM, Gunnar Morling wrote:
> 2016-10-27 15:55 GMT+02:00 Scott Marlow :
>>
>> I remember now why I didn't remove the JPADependencyProcessor
>> injection of Javassist in
>> https://github.com/wildfly/wildfly/pull/8474, it would cause a failure
>> in applications that emb
2016-10-27 15:55 GMT+02:00 Scott Marlow :
> I remember now why I didn't remove the JPADependencyProcessor
> injection of Javassist in
> https://github.com/wildfly/wildfly/pull/8474, it would cause a failure
> in applications that embeds a copy of the ORM jars but the application
> doesn't have the
Dunno. To me this is a bug that Jipijapa/WF/DUP adds this dependency at
all. How that gets resolved or not is completely up to Jipijapa/WF/DUP as
it is the one(s) doing this. There is nothing Hibernate can do here.
On Thu, Oct 27, 2016 at 9:11 AM Scott Marlow wrote:
> We can call it a bad de
We can call it a bad deployment, however, at the same time, we don't
want to break application compatibility in a way that requires the
application to be cracked open and modified (even if the fix is just a
simple MANIFEST.MF change).
On Thu, Oct 27, 2016 at 10:07 AM, Steve Ebersole wrote:
> I wo
I would argue that that is a bad deployment. IMO if you supply your own
Hibernate jars, you'd be responsible for supplying its dependency jars as
well. Javassist is currently a non-optional dependency of ORM.
On Thu, Oct 27, 2016 at 8:55 AM Scott Marlow wrote:
> I remember now why I didn't rem
I remember now why I didn't remove the JPADependencyProcessor
injection of Javassist in
https://github.com/wildfly/wildfly/pull/8474, it would cause a failure
in applications that embeds a copy of the ORM jars but the application
doesn't have the Javassisst jars on its classpath. Currently,
JPADep
2016-10-27 14:59 GMT+02:00 Scott Marlow :
> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling
> wrote:
> > Hi,
>
> Hi,
>
> >
> > 2016-10-27 4:27 GMT+02:00 Scott Marlow :
> >>
> >>
> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM
> module
> >> > (the WF module) export Javassi
On 27 October 2016 at 13:38, Scott Marlow wrote:
> Only a WildFly deployment unit processor (DUP) can add dependencies to
> an application deployment. Jipijapa is not a DUP.
Ah, thanks Scott that helps to understand this all.
Still, I agree with Gunnar that any additional dependencies belong in
On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling wrote:
> Hi,
Hi,
>
> 2016-10-27 4:27 GMT+02:00 Scott Marlow :
>>
>>
>> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module
>> > (the WF module) export Javassist. Not the application.
>
>
> Right, Hibernate ORM's module shoul
Only a WildFly deployment unit processor (DUP) can add dependencies to
an application deployment. Jipijapa is not a DUP.
On Thu, Oct 27, 2016 at 6:12 AM, Sanne Grinovero wrote:
> Ok well that's also odd isn't it?
>
>
> On 27 Oct 2016 10:38, "Gunnar Morling" wrote:
>>
>> No, JPADependencyProcess
JPADependencyProcessor deals with adding JPA dependencies generally (i.e.
it works for whatever JPA provider is configured), so it seems reasonable
by itself.
But as said shouldn't be adding the dependency to Javassist as that's
better left to the module(s) of the specific provider(s) needing it.
Ok well that's also odd isn't it?
On 27 Oct 2016 10:38, "Gunnar Morling" wrote:
> No, JPADependencyProcessor - which is adding the dependency - is part of
> "wildfly-jpa", not "jipijapa-hibernate".
>
> 2016-10-27 11:23 GMT+02:00 Sanne Grinovero :
>
>> We could fix 1) as well by incorporating the
No, JPADependencyProcessor - which is adding the dependency - is part of
"wildfly-jpa", not "jipijapa-hibernate".
2016-10-27 11:23 GMT+02:00 Sanne Grinovero :
> We could fix 1) as well by incorporating the sources for
> jipijapa-hibernate52 in ORM.
>
> I think it belongs within Hibernate, as it w
We could fix 1) as well by incorporating the sources for
jipijapa-hibernate52 in ORM.
I think it belongs within Hibernate, as it won't be the last time that a
new ORM version requires some adaptation of bootstrap.
On 27 Oct 2016 09:51, "Gunnar Morling" wrote:
> Hi,
>
> 2016-10-27 4:27 GMT+02:00
Hi,
2016-10-27 4:27 GMT+02:00 Scott Marlow :
>
> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module
> (the WF module) export Javassist. Not the application.
>
Right, Hibernate ORM's module should be the one exposing it, not the
application nor JipiJapa.
This allows the
> Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module
(the WF module) export Javassist. Not the application.
>
I agree, that is what our WF pull request did, which I think is an
incremental improvement but that wasn't approved for the reason I gave.
>> Is the ORM testsuite b
On Wed, Oct 26, 2016 at 8:33 PM Scott Marlow wrote:
> On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling
> wrote:
> > Couldn't this be achieved by having the ORM module re-export the
> Javassist
> > module it depends on (in the module.xml of ORM, that is)?
> >
> >
> >
> > That way JipiJapa wou
On Wed, Oct 26, 2016 at 6:58 PM, Gunnar Morling wrote:
> Hi,
>
> 2016-10-27 0:44 GMT+02:00 Scott Marlow :
>>
>> Just to be clear, Jipijapa doesn't use Javassist at all.
>
>
> Ok. What is the reason then that it is declaring this module dependency?
No reason, looks like an unneeded dependency that
Hi,
2016-10-27 0:44 GMT+02:00 Scott Marlow :
> Just to be clear, Jipijapa doesn't use Javassist at all.
Ok. What is the reason then that it is declaring this module dependency?
> For JPA
> deployments that are using Hibernate, the (WildFly) JPA container is
> exporting the org.javassist:mod
Just to be clear, Jipijapa doesn't use Javassist at all. For JPA
deployments that are using Hibernate, the (WildFly) JPA container is
exporting the org.javassist:module to the application deployment
classloader, so that the Javassist proxy runtime classes can be
referenced by application classes t
Would be interesting to know why JipiJapa is depending on it. In a quick
search I couldn't spot any actual usages.
JPADependencyProcessor adds a dependency to "org.javassist", maybe that
could be avoided by having the ORM module re-export the version of JipiJipa
it is using? For that he module ZIP
28 matches
Mail list logo
