[hibernate-dev] 5.1 tentative release date

[Guillaume Smet]

Hi Steve and al.

Any chance we could make progress on HHH-7610
<https://hibernate.atlassian.net/browse/HHH-7610> and
https://github.com/hibernate/hibernate-orm/pull/1080 for 5.1?

I'll revisit the PR tomorrow to fix the conflicts.

-- 
Guillaume

On Tue, Jan 12, 2016 at 5:08 PM, Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 01/11/2016 11:04 AM, Steve Ebersole wrote:
> > On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>> wrote:
> >
> >     Should we also look at changing Hibernate to not require Javassist
> >     classes be on the deployment classpath?
> >
> >
> > I just don't see how that is ever going to be realistically possible.
> > If you have specific suggestions, we are all ears ;)
>
> I'm thinking that we should defer the Javassist upgrade until we figure
> out what we want to do exactly to address this problem.  I would expect
> that other modular classloading environments besides WildFly may also
> need a fix.
>
> For a possible workaround (for proxies), if we were able to clone the
> needed Javassist runtime classes, into the application classloader and
> generate proxies that use the cloned copies, I think that could help.
> We would have to clone them into a private package name (e.g. something
> like org.hibernate.javassist.runtime.*).  We would also have to generate
> the proxies using the cloned classes.
>
> There may be other ways to change Hibernate applications to not depend
> on the Javassist runtime classes.  For example if we change the bytecode
> that we generate, to not reference the Javassist runtime classes, that
> also would address this.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>