> 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
Hi all,
there's a conflict in the Javassist versions of the WildFly modules of
Hibernate ORM 5.2.4.Final, but I'm not sure how to proceed as I'm not
familiar with this functionality.
The module declares *both*:
- a dependency to the WildFly provided Javassist:
- inclusion of Hibernate's own ve
For details:
http://in.relation.to/2016/10/26/hibernate-orm-524-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Please do not push anything to master branch.
Thanks,
Andrea
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Static update strings appear to cover only the following situations:
1) there are no uninitialized properties (so all updateable attributes
should be updated);
2) all lazy properties are uninitialized (so only
non-lazy, updateable attributes should be updated).
As of 5.1, we have "lazy groups". It
10 matches
Mail list logo
