[hibernate-dev] hibernate-dev Digest, Vol 76, Issue 18
Steve Ebersole
steve at hibernate.org
Mon Oct 15 13:39:30 EDT 2012
Hey Marc,
Trying to understand. Are you offering to host the Hibernate builds?
On 10/10/2012 10:44 AM, Marc Schipperheyn wrote:
> I have setup a jobs alternative on www.freelas.net. Right now we focus
> mainly on the Dutch and Brazilian markets but you can always publish jobs
> without a location.
> You can find a direct link to the English version here:
> http://www.freelas.net/nederland/NL_e<http://www.freelas.net/nederland/NL_nl>
> n/
> and a link to the Hibernate jobs section here:
> http://www.freelas.net/nederland/NL_en/account/tag/hibernate/355/<http://www.freelas.net/nederland/NL_nl/account/tag/hibernate/355/>
> and
> Hibernate Search section here:
> http://www.freelas.net/nederland/NL_en/account/tag/hibernate_search/483/<http://www.freelas.net/nederland/NL_nl/account/tag/hibernate_search/483/>
>
> The good thing about this site: it's built with Hibernate and Hibernate
> Search :-)
>
> Anyway, not intended as a spam promotion of the site but as a response to
> the jobs section message. I'd be happy to process suggestions.
>
> Marc
>
> On Wed, Oct 10, 2012 at 9:55 AM, <hibernate-dev-request at lists.jboss.org>wrote:
>
>> Send hibernate-dev mailing list submissions to
>> hibernate-dev at lists.jboss.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> or, via email, send a message with subject or body 'help' to
>> hibernate-dev-request at lists.jboss.org
>>
>> You can reach the person managing the list at
>> hibernate-dev-owner at lists.jboss.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of hibernate-dev digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Links to CI jobs on hibernate.org (Hardy Ferentschik)
>> 2. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
>> 3. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
>> 4. Re: Hibernate Search Spatial: Units? (Emmanuel Bernard)
>> 5. Re: Hibernate Search Spatial: Units? (Sanne Grinovero)
>> 6. Re: Bytecode enhancement (Steve Ebersole)
>> 7. Re: Bytecode enhancement (Steve Ebersole)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 10 Oct 2012 11:03:26 +0200
>> From: Hardy Ferentschik <hardy at hibernate.org>
>> Subject: Re: [hibernate-dev] Links to CI jobs on hibernate.org
>> To: Hibernate <hibernate-dev at lists.jboss.org>
>> Message-ID: <2640B82F-21F6-41F4-8F40-6C5F4018BCA2 at hibernate.org>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On 9 Jan 2012, at 7:44 PM, Steve Ebersole wrote:
>>
>>> Gunnar,
>>>
>>> Do you mean in the menu option? That's seems to be from whoever last
>>> updated the CI information. Hardy?
>> Might have been me. Once I was young and ambitious and thought we could
>> sort this mess out.
>> By now I gave up on these jobs.
>>
>> Any news regarding alternatives?
>>
>> --hardy
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 10 Oct 2012 10:31:19 +0100
>> From: Sanne Grinovero <sanne at hibernate.org>
>> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
>> To: Nicolas Helleringer <nicolas.helleringer at gmail.com>
>> Cc: Hibernate <hibernate-dev at lists.jboss.org>
>> Message-ID:
>> <CAFm4XO0Fh_bq2G=
>> b2zvhP0WX3oROu-xW1HvhBBWytZxdEYCCjw at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> The default name for @Spatial is the empty string (at least as defined
>> on the annotation before we override it to the entity mode).
>>
>> Considering we have @Spatials (plural) to support multiple coordinates
>> on a single entity, would it make sense to support
>>
>> onCoordinates(String... names)
>> ?
>>
>> This has the nice effect of supporting the method without any
>> parameter, so one can use
>>
>> Query luceneQuery = builder.spatial()
>> .onCoordinates()
>> .within( 50, Unit.KM )
>> ...
>>
>> to point to the default one (undefined, aka empty string)
>>
>> Can also target multiple constraints at once:
>>
>> Query luceneQuery = builder.spatial()
>> .onCoordinates( "home", "office" )
>> .within( 50, Unit.KM )
>> ...
>>
>> Looks not so good when mixing default and specific:
>>
>> Query luceneQuery = builder.spatial()
>> .onCoordinates( "", "office" )
>> .within( 50, Unit.KM )
>> ...
>>
>> But my guess is that when having multiple coordinates on an entity it
>> should be recommended to name them all explicitly; we could even
>> require this.
>> --
>>
>> +1 to not consider
>> "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
>> case I think we should update the tests using it to use the DSL.
>>
>> Sanne
>>
>> On 10 October 2012 08:44, Nicolas Helleringer
>> <nicolas.helleringer at gmail.com> wrote:
>>> 5 seems just fine to me
>>>
>>> Niko
>>>
>>> 2012/10/10 Emmanuel Bernard <emmanuel at hibernate.org>
>>>> I see a few options:
>>>>
>>>> 1. Make onCoordinates optional
>>>>
>>>> For me that does not look right and would make the dsl confusing but I'd
>>>> like to see additional feedback
>>>>
>>>> 2. Use a constant
>>>>
>>>> .onCoordinates(Statial.DEFAULT_COORDINATES_PROPERTY)
>>>>
>>>> 3. Use the class name ( that's what you did )
>>>>
>>>> 4. Use "" as the value
>>>>
>>>> .onCoordinates("")
>>>>
>>>> 5. Add a specific method
>>>>
>>>> .onDefaultCoordinates()
>>>>
>>>> So far 5 seems the most natural to me.
>>>>
>>>> Emmanuel
>>>>
>>>>
>>>> On 10 oct. 2012, at 09:20, Nicolas Helleringer
>>>> <nicolas.helleringer at gmail.com> wrote:
>>>>
>>>> This makes sense.
>>>> The DSL is clearly THE way to build spatial queries. It simple and
>>>> elegant.
>>>>
>>>> By the way, Emmanuel, I would like some help to remove the
>>>> .onCoordinates( PoI.class.getName() )
>>>>
>>>> in
>>>>
>>>> Query luceneQuery = builder.spatial()
>>>> .onCoordinates( PoI.class.getName() )
>>>> .within( 50, Unit.KM )
>>>> .ofLatitude( centerLatitude )
>>>> .andLongitude( centerLongitude )
>>>> .createQuery();
>>>>
>>>> when building a spatial query on a class with a @Spatial that does not
>>>> have a name attribute set and thus using the default value of
>>>> class.getName()
>>>>
>>>> Niko
>>>>
>>>>
>>>> 2012/10/10 Emmanuel Bernard <emmanuel at hibernate.org>
>>>>> I almost think that org.hibernate.search.spatial.SpatialQueryBuilder
>>>>> should be an internal class. Do we want to offer direct access to these
>>>>> instead of the dsl?
>>>>> The answer could be yes, but I'd like to see a use case.
>>>>>
>>>>> On 9 oct. 2012, at 18:45, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>>>
>>>>>> Hi Nicolas,
>>>>>>
>>>>>> In the QueryBuilder DSL a spatial Query has a nice option to define
>>>>>> which units are being used:
>>>>>>
>>>>>> org.apache.lucene.search.Query luceneQuery =
>>>>>> builder.spatial().onCoordinates( UserRange.class.getName() )
>>>>>> .within( 50, Unit.KM ).ofLatitude( centerLatitude
>>>>>> ).andLongitude(
>>>>>> centerLongitude ).createQuery();
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> org.hibernate.search.spatial.SpatialQueryBuilder.buildSpatialQueryByGrid(double,
>>>>>> double, double, String)
>>>>>> has a javadoc comment specifying the parameters are expected to be
>> KM.
>>>>>> I guess we should pick a strategy and be consistent with it; I think
>>>>>> we should add the Unit parameter to the SpatialQueryBuilder;
>>>>>>
>>>>>> Any thoughts about it? Can I assume you'll be able to look into that?
>>>>>>
>>>>>> Cheers,
>>>>>> Sanne
>>>>>>
>>>>>> Tracked by https://hibernate.onjira.com/browse/HSEARCH-1203
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 10 Oct 2012 10:52:44 +0100
>> From: Sanne Grinovero <sanne at hibernate.org>
>> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
>> To: Nicolas Helleringer <nicolas.helleringer at gmail.com>
>> Cc: Hibernate <hibernate-dev at lists.jboss.org>
>> Message-ID:
>> <
>> CAFm4XO26cB4MFc_FBOfkrJrvTKeF6Fet6s3LggDMwxyk0B2Q5w at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On 10 October 2012 10:31, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> The default name for @Spatial is the empty string (at least as defined
>>> on the annotation before we override it to the entity mode).
>>>
>>> Considering we have @Spatials (plural) to support multiple coordinates
>>> on a single entity, would it make sense to support
>>>
>>> onCoordinates(String... names)
>>> ?
>>>
>>> This has the nice effect of supporting the method without any
>>> parameter, so one can use
>>>
>>> Query luceneQuery = builder.spatial()
>>> .onCoordinates()
>>> .within( 50, Unit.KM )
>>> ...
>>>
>>> to point to the default one (undefined, aka empty string)
>>>
>>> Can also target multiple constraints at once:
>>>
>>> Query luceneQuery = builder.spatial()
>>> .onCoordinates( "home", "office" )
>>> .within( 50, Unit.KM )
>>> ...
>>>
>>> Looks not so good when mixing default and specific:
>>>
>>> Query luceneQuery = builder.spatial()
>>> .onCoordinates( "", "office" )
>>> .within( 50, Unit.KM )
>>> ...
>>>
>>> But my guess is that when having multiple coordinates on an entity it
>>> should be recommended to name them all explicitly; we could even
>>> require this.
>>> --
>>>
>>> +1 to not consider
>>> "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
>>> case I think we should update the tests using it to use the DSL.
>> About this, we should also not mention it in the docs: we're using it
>> in most examples, excluding only the paragraph introducing the Spacial
>> specific DSL.
>> We also refer to it frequently in 9.6, the low level details
>> explanation chapter.
>>
>>> Sanne
>>>
>>> On 10 October 2012 08:44, Nicolas Helleringer
>>> <nicolas.helleringer at gmail.com> wrote:
>>>> 5 seems just fine to me
>>>>
>>>> Niko
>>>>
>>>> 2012/10/10 Emmanuel Bernard <emmanuel at hibernate.org>
>>>>> I see a few options:
>>>>>
>>>>> 1. Make onCoordinates optional
>>>>>
>>>>> For me that does not look right and would make the dsl confusing but
>> I'd
>>>>> like to see additional feedback
>>>>>
>>>>> 2. Use a constant
>>>>>
>>>>> .onCoordinates(Statial.DEFAULT_COORDINATES_PROPERTY)
>>>>>
>>>>> 3. Use the class name ( that's what you did )
>>>>>
>>>>> 4. Use "" as the value
>>>>>
>>>>> .onCoordinates("")
>>>>>
>>>>> 5. Add a specific method
>>>>>
>>>>> .onDefaultCoordinates()
>>>>>
>>>>> So far 5 seems the most natural to me.
>>>>>
>>>>> Emmanuel
>>>>>
>>>>>
>>>>> On 10 oct. 2012, at 09:20, Nicolas Helleringer
>>>>> <nicolas.helleringer at gmail.com> wrote:
>>>>>
>>>>> This makes sense.
>>>>> The DSL is clearly THE way to build spatial queries. It simple and
>>>>> elegant.
>>>>>
>>>>> By the way, Emmanuel, I would like some help to remove the
>>>>> .onCoordinates( PoI.class.getName() )
>>>>>
>>>>> in
>>>>>
>>>>> Query luceneQuery = builder.spatial()
>>>>> .onCoordinates( PoI.class.getName() )
>>>>> .within( 50, Unit.KM )
>>>>> .ofLatitude( centerLatitude )
>>>>> .andLongitude( centerLongitude )
>>>>> .createQuery();
>>>>>
>>>>> when building a spatial query on a class with a @Spatial that does not
>>>>> have a name attribute set and thus using the default value of
>>>>> class.getName()
>>>>>
>>>>> Niko
>>>>>
>>>>>
>>>>> 2012/10/10 Emmanuel Bernard <emmanuel at hibernate.org>
>>>>>> I almost think that org.hibernate.search.spatial.SpatialQueryBuilder
>>>>>> should be an internal class. Do we want to offer direct access to
>> these
>>>>>> instead of the dsl?
>>>>>> The answer could be yes, but I'd like to see a use case.
>>>>>>
>>>>>> On 9 oct. 2012, at 18:45, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>>>>> Hi Nicolas,
>>>>>>>
>>>>>>> In the QueryBuilder DSL a spatial Query has a nice option to define
>>>>>>> which units are being used:
>>>>>>>
>>>>>>> org.apache.lucene.search.Query luceneQuery =
>>>>>>> builder.spatial().onCoordinates( UserRange.class.getName() )
>>>>>>> .within( 50, Unit.KM ).ofLatitude( centerLatitude
>>>>>>> ).andLongitude(
>>>>>>> centerLongitude ).createQuery();
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>> org.hibernate.search.spatial.SpatialQueryBuilder.buildSpatialQueryByGrid(double,
>>>>>>> double, double, String)
>>>>>>> has a javadoc comment specifying the parameters are expected to be
>> KM.
>>>>>>> I guess we should pick a strategy and be consistent with it; I think
>>>>>>> we should add the Unit parameter to the SpatialQueryBuilder;
>>>>>>>
>>>>>>> Any thoughts about it? Can I assume you'll be able to look into
>> that?
>>>>>>> Cheers,
>>>>>>> Sanne
>>>>>>>
>>>>>>> Tracked by https://hibernate.onjira.com/browse/HSEARCH-1203
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 10 Oct 2012 13:17:32 +0200
>> From: Emmanuel Bernard <emmanuel at hibernate.org>
>> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
>> To: Sanne Grinovero <sanne at hibernate.org>
>> Cc: Hibernate <hibernate-dev at lists.jboss.org>
>> Message-ID: <20121010111732.GA1075 at dhcp-193-234.cdg.redhat.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>>>> onCoordinates(String... names)
>> Does `onCoordinates()` means all coordinates or simply the default one. If
>> all, then
>> existing queries will break if you add an new coordinate property to an
>> entity.
>>
>> Also, I'm not sure there is a use case for targeting in the same query,
>> the various coordinates defined on a given entity. But I have no real
>> idea.
>>
>> Otherwise, I'm fairly neutral to the proposal.
>>
>>>> +1 to not consider
>>>> "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
>>>> case I think we should update the tests using it to use the DSL.
>>> About this, we should also not mention it in the docs: we're using it
>>> in most examples, excluding only the paragraph introducing the Spacial
>>> specific DSL.
>>> We also refer to it frequently in 9.6, the low level details
>>> explanation chapter.
>> Damn, I thought we discussed that already to remove it from the doc. But
>> maybe it was for the unit tests.
>> If we go for the private route, we need to move those classes to an
>> `impl` package. What's weird is that I thought I did it in the past :/
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 10 Oct 2012 12:27:51 +0100
>> From: Sanne Grinovero <sanne at hibernate.org>
>> Subject: Re: [hibernate-dev] Hibernate Search Spatial: Units?
>> To: Emmanuel Bernard <emmanuel at hibernate.org>
>> Cc: Hibernate <hibernate-dev at lists.jboss.org>
>> Message-ID:
>> <CAFm4XO1K6SLAcwcvy=
>> hsbGdjLbsgHPCe1xABn60ORFdkW08ZNg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On 10 October 2012 12:17, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>>> onCoordinates(String... names)
>>> Does `onCoordinates()` means all coordinates or simply the default one.
>> If all, then
>>> existing queries will break if you add an new coordinate property to an
>>> entity.
>> I would assume that empty would target the default one, as it's unnamed as
>> well.
>>
>>> Also, I'm not sure there is a use case for targeting in the same query,
>>> the various coordinates defined on a given entity. But I have no real
>>> idea.
>> I would be able to find a car park place to rent which is both close
>> to home and office.
>>
>>> Otherwise, I'm fairly neutral to the proposal.
>> I'm fairly neutral too, mostly wanted to explore this way to avoid the
>> extra method.
>>
>>>>> +1 to not consider
>>>>> "SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
>>>>> case I think we should update the tests using it to use the DSL.
>>>> About this, we should also not mention it in the docs: we're using it
>>>> in most examples, excluding only the paragraph introducing the Spacial
>>>> specific DSL.
>>>> We also refer to it frequently in 9.6, the low level details
>>>> explanation chapter.
>>> Damn, I thought we discussed that already to remove it from the doc. But
>>> maybe it was for the unit tests.
>>> If we go for the private route, we need to move those classes to an
>>> `impl` package. What's weird is that I thought I did it in the past :/
>> don't remember this but agree
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Wed, 10 Oct 2012 07:36:55 -0500
>> From: Steve Ebersole <steve at hibernate.org>
>> Subject: Re: [hibernate-dev] Bytecode enhancement
>> To: Emmanuel Bernard <emmanuel at hibernate.org>
>> Cc: Hibernate hibernate-dev <hibernate-dev at lists.jboss.org>
>> Message-ID: <50756BE7.7040607 at hibernate.org>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Its not quite that simple, again due to how we recurse. This would
>> need to be a "stack" stored on a ThreadLocal. Depends what you want to
>> store in here I guess, but like I said we already have "context
>> specific caches" and it would be good to consolidate all that
>> information into one place. What I mean by the current "context
>> specific caches" is the "extra" information passed to many of the
>> listeners. Take merging for example:
>>
>> interface MergeEventListener {
>> public void onMerge(MergeEvent event);
>> public void onMerge(MergeEvent event, Map copiedAlready);
>> }
>>
>> 'copiedAlready' is a context specific cache. It tracks entity
>> reference replacements. Many listeners have similar concept.
>>
>> Your proposal would certainly clean up those APIs.
>>
>> On Wed 10 Oct 2012 03:01:30 AM CDT, Emmanuel Bernard wrote:
>>> On Wed 2012-10-10 9:26, Emmanuel Bernard wrote:
>>>> Would using a service that store cache data structures by session work?
>> I am thinking out loud here trying to push the cache idea before discarding
>> it. That would require a weak-key concurrent map. The one I know is the one
>> Jason wrote as a proposal for SE. I. Cannot remember where we use it but it
>> must be in Search or in Validator.
>>> Actually that is simpler than that. Because the session cannot be used
>>> in more than one thread, only one call stack is active per session. We
>>> can keep the cache per session and lear it before every top level public
>> method
>>> of session (ie persist, flush, merge etc).
>> --
>> steve at hibernate.org
>> http://hibernate.org
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Wed, 10 Oct 2012 07:55:15 -0500
>> From: Steve Ebersole <steve at hibernate.org>
>> Subject: Re: [hibernate-dev] Bytecode enhancement
>> To: Emmanuel Bernard <emmanuel at hibernate.org>
>> Cc: Hibernate hibernate-dev <hibernate-dev at lists.jboss.org>
>> Message-ID: <50757033.8070202 at hibernate.org>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 10/10/2012 02:26 AM, Emmanuel Bernard wrote:
>>> Yes my proposal would imply we pass along the cache data structure
>> through all of our internal methods.
>>> My concerns about byte code enhancement are a bit diffuse but relate to:
>>>
>>> - does it add an extra build step to users?
>> No, we'd go all out and complete both runtime and buildtime enhancement
>> options.
>>
>>
>>> - how much configuration is needed in SE?
>> As far as I understand it, its just a matter of defining the agent as a
>> VM start option. This is all new to me too, so not sure of all the
>> specifics.
>>
>>
>>> - has JBoss AS finally implemented the temporary class loaders required
>> for runtime byte code enhancement (JPA contract)?
>>
>> Well there is already code in place, that you put in place, that does
>> the existing limited runtime enhancement we already support when
>> building a container managed EMF. Not sure why you did that nor what
>> containers do/don't support that.
>>
>>
>>> - how does that all play when entities are serialized?
>>> - can I unserialize entities on different a different VM?
>> Regarding ser/deser... If you are asking about physically, then yes it
>> should work as long as any fields we enhance into the entity are defined
>> as transient. If you mean logically, then I think yes as well. Anytime
>> an entity is serialized it would essentially become un-managed, which is
>> exactly what happens today too. And just like today as well,
>> reattachment would mean an implied dirtiness.
>>
>> Of course, we would be enhancing the entity to implement a particular
>> contract. Users would have the option to manually implement that
>> interface themselves and not even require bytecode enhancement at all.
>> This *could* have some nice benefits like smarter reattachment (rather
>> that implied dirtiness). Etc.
>>
>>
>>> But more importantly I had the feeling that the cache approach would
>> have less intrusive than the byte code enhancement approach but your email
>> made me change my mind. Propagating the cache would be more intrusive
>> assuming we don't want thread local, and we probably don't want these.
>>
>> ThreadLocals are nice... when they work. But I have seen lots of cases
>> were they maybe don't get cleared and all kinds of hard-to-debug
>> problems start to appear when threads are pooled. It certainly takes a
>> lot of defensiveness.
>>
>>
>>> Would using a service that store cache data structures by session work?
>> I am thinking out loud here trying to push the cache idea before discarding
>> it. That would require a weak-key concurrent map. The one I know is the one
>> Jason wrote as a proposal for SE. I. Cannot remember where we use it but it
>> must be in Search or in Validator.
>>
>> Well I have been thinking about "identifying" sessions by assigning them
>> a unique id (uuid?) when the session is started. That could help with
>> the requirement for a specific type of map. That said, not really sure
>> what this buys us. It still leaves open the same potential for leaks as
>> using a ThreadLocal (though not as potentially disruptive).
>>
>>
>> Have y'all seen any performance numbers that show the limits within
>> which this "context cache" alternative is actually beneficial? Seems to
>> me there will be a tipping point here beyond which it would actually
>> make performance worse.
>>
>> --
>> steve at hibernate.org
>> http://hibernate.org
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> End of hibernate-dev Digest, Vol 76, Issue 18
>> *********************************************
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve at hibernate.org
http://hibernate.org
More information about the hibernate-dev
mailing list