[hibernate-dev] Hibernate and JSR-107 (was Re: 5.1 tentative release date)

Steve Ebersole steve at hibernate.org
Wed Feb 24 11:34:07 EST 2016


That's awesome to hear Louis!

As for getting help with the Hibernate side, discussing here is probably
the best option IMO.  But really whatever feels most comfortable to you: you
can ask here, ping us on #hibernate-dev IRC or on our HipChat channel[1].

[1] https://hibernate.hipchat.com/chat/room/1238636

On Wed, Feb 24, 2016 at 9:49 AM Louis Jacomet <ljacomet at gmail.com> wrote:

> Hi all,
>
> I am interested in helping finalising that JSR-107 H2LC.
>
> I will start looking into the code Alex has on his branch on github and
> take it from there. I may need to ping hibernate devs directly at one point
> since I do not have a very good knowledge of Hibernate currently.
>
> Regards,
> Louis
>
> On Thu, Jan 14, 2016 at 3:45 PM Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Exactly,
>>
>> I'm struggling to find a JSR-107 second-level cache to plug in my
>> project. EHCache 3.x does not integrate with hibernate yet, neither does
>> hazelcast - they have a PR, but they'll merge it in the next couple of
>> months. Oracle Coherence I think is paid, so is IBM extremescale and
>> Grigain. JCS has a one-year old beta release, which I'm not sure is jcache
>> compliant, and Infinispan, as I understand, works as a separate service,
>> and I want to have it embedded in my spring project. This is really
>> embarrassing - a cache is essential to any application and seems like there
>> is no free, robust, open-source, embeddable, JSR-107-compatible cache
>> implementation.
>>
>> 2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> So then it sounds like "no" to this, which is fine.  We already have
>>> updated to a much newer Ehcache and as pointed out earlier the stability in
>>> the Ehcache API actually used in the integration means any 2.x version of
>>> Ehcache should be fine to drop in.
>>>
>>> Ehcache 3.x support will be based on that JSR 107 work...
>>>
>>>
>>> On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps at gmail.com>
>>> wrote:
>>>
>>>> Right, there was no plan to provide something for Ehcache3 quite yet.
>>>> That being said, I wonder whether we ever will. I have a 107 compliant
>>>> H2LC implementation. I also went over it with Sanne during Javaone and we
>>>> think it can be made into something suiting for bunch of providers.
>>>> Now, small caveat, while I still plan to work on this, as of this year
>>>> I'm not working for Terracotta anymore... Basically, that's whenever I'll
>>>> find time to do so.
>>>> cc'ed Louis, in case some he wants to provide some more formal
>>>> stance...
>>>> Alex
>>>>
>>>>
>>>> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> Petar, Alex Snaps (in CC) has been doing some work to update the
>>>>> version of Ehcache used in Hibernate ORM.  Alex, any updates?  As I
>>>>> understood it though Ehcache 3.x was not part of that effort, but Alex can
>>>>> of course say for sure.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>>>>>> hibernate-ehcache module updated in 5.1?
>>>>>>
>>>>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>>>>>
>>>>>>> I'll create a jira for the Javassist to be part of 5.1.
>>>>>>>
>>>>>>> Should we also look at changing Hibernate to not require Javassist
>>>>>>> classes be on the deployment classpath?  This might require cloning
>>>>>>> some
>>>>>>> Javassist runtime classes so that we don't get CNFE on
>>>>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>>>>>>> enhanced entity classes).
>>>>>>>
>>>>>>> [1] contains one of the CNFE's that I see with WildFly during
>>>>>>> deployment
>>>>>>> time (only if WildFly is hacked to not inject Javassist into the
>>>>>>> application classpath).  I am seeing
>>>>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>>>>>>> entity class with references to Javassist classes (see disassembled
>>>>>>> bytecode output [2]).  The generated class extends
>>>>>>> javassist.util.proxy.ProxyObject +
>>>>>>> javassist.util.proxy.MethodHandler. +
>>>>>>> javassist.util.proxy.RuntimeSupport +
>>>>>>> javassist.util.proxy.SerializedProxy.
>>>>>>>
>>>>>>> I'm sure that there are other Javassist classes that we probably also
>>>>>>> generate bytecode to depend on, in other places in Hibernate.
>>>>>>>
>>>>>>> I have no idea exactly how to resolve this.  I'm not sure if it would
>>>>>>> entail cloning the above javassist runtime classes into javassist.
>>>>>>> Or
>>>>>>> separating them into a different (Javassist) library, so at least the
>>>>>>> application doesn't include the other Javassist classes.
>>>>>>>
>>>>>>> Sanne had some ideas that he mentioned [3].  By only exposing the
>>>>>>> needed
>>>>>>> classloaders to the deployment, I think he meant the above idea of
>>>>>>> separating Javassist into different jars.  Or something like that.
>>>>>>>
>>>>>>> Jason Greene also liked Sanne's suggestion of not requiring
>>>>>>> applications
>>>>>>> to have Javassist on their classpath, as applications might also
>>>>>>> include
>>>>>>> their own copy of Javassist because they want to generate some
>>>>>>> bytecode
>>>>>>> also.
>>>>>>>
>>>>>>> What do others think about the idea of not requiring Javassist to be
>>>>>>> on
>>>>>>> the Hibernate application classpath?  Again, I'm not sure if this
>>>>>>> only a
>>>>>>> problem on WildFly.  If it is, I'm not sure why. :)
>>>>>>>
>>>>>>> Scott
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>>>>>>>
>>>>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>>>>>>
>>>>>>> [3]
>>>>>>> https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>>>>>>
>>>>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>>>>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>>>>>>> >
>>>>>>> >
>>>>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
>>>>>>> > <mailto:smarlow at redhat.com>> wrote:
>>>>>>> >
>>>>>>> >     Should we upgrade to javassist latest in 5.1 still?
>>>>>>> >
>>>>>>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>>>>>>> >      > Just a heads up that I tentatively set Jan 27th as the
>>>>>>> release
>>>>>>> >     date for
>>>>>>> >      > 5.1.  Please let me know if that does not work for anyone.
>>>>>>> Also
>>>>>>> >     please
>>>>>>> >      > keep that date in mind if there is anything you want to get
>>>>>>> into 5.1.
>>>>>>> >      > _______________________________________________
>>>>>>> >      > hibernate-dev mailing list
>>>>>>> >      > hibernate-dev at lists.jboss.org <mailto:
>>>>>>> hibernate-dev at lists.jboss.org>
>>>>>>>
>>>>>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>> >      >
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>
>>>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>


More information about the hibernate-dev mailing list