[hibernate-dev] Hibernate ORM 5.1.13.Final Released

[Gail Badner]

http://in.relation.to/2018/03/19/hibernate-orm-5113-final-release/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

[Steve Ebersole]

Great!

On Wed, Mar 21, 2018 at 6:21 PM Gail Badner  wrote:

> Worked like a charm.
> Thanks!
>
> On Wed, Mar 21, 2018 at 11:07 AM, Gail Badner  wrote:
>
>> OK, I'll give it a try. Thanks!
>>
>> On Wed, Mar 21, 2018 at 10:50 AM, Steve Ebersole 
>> wrote:
>>
>>> The easiest is to just skip the jar tasks using -x.  And aggregated
>>> javadocs task.  Unfortunately I think you would nee to list them all
>>> individually
>>>
>>> On Wed, Mar 21, 2018 at 12:42 PM Gail Badner  wrote:
>>>
 I still have the original jars. I was experimenting on a copy.

 How do I disable the up-to-date checks?

 On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole 
 wrote:

> You could have avoided that up front by disabling the up-to-date
> checks.  But now your original local jars are gone...
>
> That said, it really does not matter if the jars are the *same* (as in
> ==) - it just matters that they are functionally the same.  Checking out
> the tag/ref, changing the version and running the build should be good
> enough.
>
>
> On Wed, Mar 21, 2018, 2:42 AM Gail Badner  wrote:
>
>> I suppose another alternative is to make the distributions manually.
>>
>> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner 
>> wrote:
>>
>> > I am able to build the documentation using Andrea's suggestion and
>> now I'm
>> > struggling with gradle.
>> >
>> > I released the staging repository on nexus last night to make a
>> deadline.
>> >
>> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT,
>> which was
>> > probably a mistake.
>> >
>> > Today I went back to build the distributions. The problem is that
>> after
>> > setting the version back to 5.1.13.Final in build.gradle, gradle
>> > automatically recompiles and rebuilds the jars.
>> >
>> > That is (obviously) a problem because they won't be the same as
>> what was
>> > uploaded to nexus.
>> >
>> > I've been trying some things out on a copy of the directory so I
>> still
>> > have the original jars intact.
>> >
>> > I've tried --no-rebuild, but it doesn't seem to work.
>> >
>> > Worst case, I suppose I can re-release as 5.1.14.Final on
>> Wednesday, but I
>> > really don't want to do that.
>> >
>> > Any suggestions?
>> >
>> > Thanks!
>> > Gail
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

[Gail Badner]

Worked like a charm.
Thanks!

On Wed, Mar 21, 2018 at 11:07 AM, Gail Badner  wrote:

> OK, I'll give it a try. Thanks!
>
> On Wed, Mar 21, 2018 at 10:50 AM, Steve Ebersole 
> wrote:
>
>> The easiest is to just skip the jar tasks using -x.  And aggregated
>> javadocs task.  Unfortunately I think you would nee to list them all
>> individually
>>
>> On Wed, Mar 21, 2018 at 12:42 PM Gail Badner  wrote:
>>
>>> I still have the original jars. I was experimenting on a copy.
>>>
>>> How do I disable the up-to-date checks?
>>>
>>> On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole 
>>> wrote:
>>>
 You could have avoided that up front by disabling the up-to-date
 checks.  But now your original local jars are gone...

 That said, it really does not matter if the jars are the *same* (as in
 ==) - it just matters that they are functionally the same.  Checking out
 the tag/ref, changing the version and running the build should be good
 enough.


 On Wed, Mar 21, 2018, 2:42 AM Gail Badner  wrote:

> I suppose another alternative is to make the distributions manually.
>
> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner 
> wrote:
>
> > I am able to build the documentation using Andrea's suggestion and
> now I'm
> > struggling with gradle.
> >
> > I released the staging repository on nexus last night to make a
> deadline.
> >
> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which
> was
> > probably a mistake.
> >
> > Today I went back to build the distributions. The problem is that
> after
> > setting the version back to 5.1.13.Final in build.gradle, gradle
> > automatically recompiles and rebuilds the jars.
> >
> > That is (obviously) a problem because they won't be the same as what
> was
> > uploaded to nexus.
> >
> > I've been trying some things out on a copy of the directory so I
> still
> > have the original jars intact.
> >
> > I've tried --no-rebuild, but it doesn't seem to work.
> >
> > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday,
> but I
> > really don't want to do that.
> >
> > Any suggestions?
> >
> > Thanks!
> > Gail
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

>>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Defaultable service strategies

[Sanne Grinovero]

On 21 March 2018 at 19:15, Vlad Mihalcea  wrote:
>
> Sounds good to me.

+1 nice
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Defaultable service strategies

[Vlad Mihalcea]

Sounds good to me.

Vlad

On Wed, 21 Mar 2018, 20:48 Steve Ebersole,  wrote:

> Thoughts on allowing certain services to be defaulted to the single
> implementor registered with the `StrategySelector` service when there is
> just one?
>
> For example, when resolving the RegionFactory unless both (a)
> `hibernate.cache.region.factory_class` and (b) one of
> `hibernate.cache.use_second_level_cache` or
> `hibernate.cache.use_query_cache` are defined caching support will be
> disabled.  What I am proposing would kick in in this case and check to see
> if there is just a single RegionFactory registered with the
> StrategySelector and if so use that one.
>
> It would allow Hibernate to more seamlessly operate as a JPA provider too,
> as currently to use caching with JPA and Hibernate users have to do the
> normal JPA stuff and then also define these Hibernate settings.  It would
> be nicer if they could just do the JPA stuff.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Defaultable service strategies

[Steve Ebersole]

Thoughts on allowing certain services to be defaulted to the single
implementor registered with the `StrategySelector` service when there is
just one?

For example, when resolving the RegionFactory unless both (a)
`hibernate.cache.region.factory_class` and (b) one of
`hibernate.cache.use_second_level_cache` or
`hibernate.cache.use_query_cache` are defined caching support will be
disabled.  What I am proposing would kick in in this case and check to see
if there is just a single RegionFactory registered with the
StrategySelector and if so use that one.

It would allow Hibernate to more seamlessly operate as a JPA provider too,
as currently to use caching with JPA and Hibernate users have to do the
normal JPA stuff and then also define these Hibernate settings.  It would
be nicer if they could just do the JPA stuff.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

[Gail Badner]

OK, I'll give it a try. Thanks!

On Wed, Mar 21, 2018 at 10:50 AM, Steve Ebersole 
wrote:

> The easiest is to just skip the jar tasks using -x.  And aggregated
> javadocs task.  Unfortunately I think you would nee to list them all
> individually
>
> On Wed, Mar 21, 2018 at 12:42 PM Gail Badner  wrote:
>
>> I still have the original jars. I was experimenting on a copy.
>>
>> How do I disable the up-to-date checks?
>>
>> On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole 
>> wrote:
>>
>>> You could have avoided that up front by disabling the up-to-date
>>> checks.  But now your original local jars are gone...
>>>
>>> That said, it really does not matter if the jars are the *same* (as in
>>> ==) - it just matters that they are functionally the same.  Checking out
>>> the tag/ref, changing the version and running the build should be good
>>> enough.
>>>
>>>
>>> On Wed, Mar 21, 2018, 2:42 AM Gail Badner  wrote:
>>>
 I suppose another alternative is to make the distributions manually.

 On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner 
 wrote:

 > I am able to build the documentation using Andrea's suggestion and
 now I'm
 > struggling with gradle.
 >
 > I released the staging repository on nexus last night to make a
 deadline.
 >
 > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which
 was
 > probably a mistake.
 >
 > Today I went back to build the distributions. The problem is that
 after
 > setting the version back to 5.1.13.Final in build.gradle, gradle
 > automatically recompiles and rebuilds the jars.
 >
 > That is (obviously) a problem because they won't be the same as what
 was
 > uploaded to nexus.
 >
 > I've been trying some things out on a copy of the directory so I still
 > have the original jars intact.
 >
 > I've tried --no-rebuild, but it doesn't seem to work.
 >
 > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday,
 but I
 > really don't want to do that.
 >
 > Any suggestions?
 >
 > Thanks!
 > Gail
 >
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev

>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

[Steve Ebersole]

The easiest is to just skip the jar tasks using -x.  And aggregated
javadocs task.  Unfortunately I think you would nee to list them all
individually

On Wed, Mar 21, 2018 at 12:42 PM Gail Badner  wrote:

> I still have the original jars. I was experimenting on a copy.
>
> How do I disable the up-to-date checks?
>
> On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole 
> wrote:
>
>> You could have avoided that up front by disabling the up-to-date checks.
>> But now your original local jars are gone...
>>
>> That said, it really does not matter if the jars are the *same* (as in
>> ==) - it just matters that they are functionally the same.  Checking out
>> the tag/ref, changing the version and running the build should be good
>> enough.
>>
>>
>> On Wed, Mar 21, 2018, 2:42 AM Gail Badner  wrote:
>>
>>> I suppose another alternative is to make the distributions manually.
>>>
>>> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner  wrote:
>>>
>>> > I am able to build the documentation using Andrea's suggestion and now
>>> I'm
>>> > struggling with gradle.
>>> >
>>> > I released the staging repository on nexus last night to make a
>>> deadline.
>>> >
>>> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which
>>> was
>>> > probably a mistake.
>>> >
>>> > Today I went back to build the distributions. The problem is that after
>>> > setting the version back to 5.1.13.Final in build.gradle, gradle
>>> > automatically recompiles and rebuilds the jars.
>>> >
>>> > That is (obviously) a problem because they won't be the same as what
>>> was
>>> > uploaded to nexus.
>>> >
>>> > I've been trying some things out on a copy of the directory so I still
>>> > have the original jars intact.
>>> >
>>> > I've tried --no-rebuild, but it doesn't seem to work.
>>> >
>>> > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday,
>>> but I
>>> > really don't want to do that.
>>> >
>>> > Any suggestions?
>>> >
>>> > Thanks!
>>> > Gail
>>> >
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

[Gail Badner]

I still have the original jars. I was experimenting on a copy.

How do I disable the up-to-date checks?

On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole  wrote:

> You could have avoided that up front by disabling the up-to-date checks.
> But now your original local jars are gone...
>
> That said, it really does not matter if the jars are the *same* (as in ==)
> - it just matters that they are functionally the same.  Checking out the
> tag/ref, changing the version and running the build should be good enough.
>
>
> On Wed, Mar 21, 2018, 2:42 AM Gail Badner  wrote:
>
>> I suppose another alternative is to make the distributions manually.
>>
>> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner  wrote:
>>
>> > I am able to build the documentation using Andrea's suggestion and now
>> I'm
>> > struggling with gradle.
>> >
>> > I released the staging repository on nexus last night to make a
>> deadline.
>> >
>> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was
>> > probably a mistake.
>> >
>> > Today I went back to build the distributions. The problem is that after
>> > setting the version back to 5.1.13.Final in build.gradle, gradle
>> > automatically recompiles and rebuilds the jars.
>> >
>> > That is (obviously) a problem because they won't be the same as what was
>> > uploaded to nexus.
>> >
>> > I've been trying some things out on a copy of the directory so I still
>> > have the original jars intact.
>> >
>> > I've tried --no-rebuild, but it doesn't seem to work.
>> >
>> > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday,
>> but I
>> > really don't want to do that.
>> >
>> > Any suggestions?
>> >
>> > Thanks!
>> > Gail
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

[Steve Ebersole]

You could have avoided that up front by disabling the up-to-date checks.
But now your original local jars are gone...

That said, it really does not matter if the jars are the *same* (as in ==)
- it just matters that they are functionally the same.  Checking out the
tag/ref, changing the version and running the build should be good enough.


On Wed, Mar 21, 2018, 2:42 AM Gail Badner  wrote:

> I suppose another alternative is to make the distributions manually.
>
> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner  wrote:
>
> > I am able to build the documentation using Andrea's suggestion and now
> I'm
> > struggling with gradle.
> >
> > I released the staging repository on nexus last night to make a deadline.
> >
> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was
> > probably a mistake.
> >
> > Today I went back to build the distributions. The problem is that after
> > setting the version back to 5.1.13.Final in build.gradle, gradle
> > automatically recompiles and rebuilds the jars.
> >
> > That is (obviously) a problem because they won't be the same as what was
> > uploaded to nexus.
> >
> > I've been trying some things out on a copy of the directory so I still
> > have the original jars intact.
> >
> > I've tried --no-rebuild, but it doesn't seem to work.
> >
> > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, but
> I
> > really don't want to do that.
> >
> > Any suggestions?
> >
> > Thanks!
> > Gail
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [in.relation.to] Only display post summary in list pages

[Gunnar Morling]

Excellent, very nice! Thanks, Guilllaume!

2018-03-21 11:15 GMT+01:00 Guillaume Smet :

> As per Gunnar's request, you can now use the ++ marker to
> explicitly mark the end of the preamble (same as in Hugo).
>
> For an example:
> posts/Gunnar/2018-02-26-putting-bean-validation-
> constraints-to-multimaps.adoc
>
> --
> Guillaume
>
> On Tue, Mar 20, 2018 at 7:08 PM, Guillaume Smet 
> wrote:
>
> > On Tue, Mar 20, 2018 at 6:18 PM, Sanne Grinovero 
> > wrote:
> >
> >> Maybe you could improve it by forcing a "cut" before images, code
> >> snippets and such
> >>
> >
> > Made the extraction routine more Emmanuel compliant.
> >
> > There's still this weird post by Vlad on the front page but I prefer to
> > keep the logic as it is as it makes more sense for all the other posts.
> And
> > it's not that shocking.
> >
> > Just pushed it, we can refine the logic later if there are any more
> gripes.
> >
> > Thanks all for taking a look.
> >
> > --
> > Guillaume
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Release Announcement: General Availability of JDK 10

[Rory O'Donnell]

Hi Sanne,

A number of items to share with you today :

*1) JDK 10 General Availability *

JDK 10, the first release produced under the six-month rapid-cadence 
release model [1][2], is now Generally Available.
We've identified no P1 bugs since we promoted build 46 almost two weeks 
ago, so that is the official GA release, ready for production use.
GPL'd binaries from Oracle are available here: http://jdk.java.net/10

This release includes twelve features:

  * 286: Local-Variable Type Inference 
  * 296: Consolidate the JDK Forest into a Single Repository

  * 304: Garbage-Collector Interface 
  * 307: Parallel Full GC for G1 
  * 310: Application Class-Data Sharing 
  * 312: Thread-Local Handshakes 
  * 313: Remove the Native-Header Generation Tool (javah)

  * 314: Additional Unicode Language-Tag Extensions

  * 316: Heap Allocation on Alternative Memory Devices

  * 317: Experimental Java-Based JIT Compiler

  * 319: Root Certificates 
  * 322: Time-Based Release Versioning 


*2) JDK 11 EA build 5, under both the GPL and Oracle EA licenses, are 
now available at **http://jdk.java.net/11**.*

  * Schedule, status & features
  o http://openjdk.java.net/projects/jdk/11/
  * Release Notes:
  o http://jdk.java.net/11/release-notes
  * Summary of changes
  o https://download.java.net/java/early_access/jdk11/5/jdk-11+5.html

*3) The Z Garbage Collector Project, early access builds available : *

The first EA binary from from The Z Garbage Collector Project, also 
known as ZGC, is now available. ZGC is a scalable low latency garbage 
collector. For information on how to enable and use ZGC, please see the 
project wiki.

  * Project page: http://openjdk.java.net/projects/zgc/
  * Wiki: https://wiki.openjdk.java.net/display/zgc/Main

*4) Quality Outreach Report for **March 2018 **is available
*

  * 
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2018

*5) **Java Client Roadmap Update
*

  * We posted a blog [3] and related white paper [4] detailing our plans
for the Java Client.

Rgds,Rory

[1] https://mreinhold.org/blog/forward-faster
[2] 
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
[3] Blog: 
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates
[4] Whitepaper: 
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [in.relation.to] Only display post summary in list pages

[Sanne Grinovero]

Great, thanks again Guillaume!

On 21 March 2018 at 10:15, Guillaume Smet  wrote:

> As per Gunnar's request, you can now use the ++ marker to
> explicitly mark the end of the preamble (same as in Hugo).
>
> For an example: posts/Gunnar/2018-02-26-putting-bean-validation-
> constraints-to-multimaps.adoc
>
> --
> Guillaume
>
> On Tue, Mar 20, 2018 at 7:08 PM, Guillaume Smet 
> wrote:
>
>> On Tue, Mar 20, 2018 at 6:18 PM, Sanne Grinovero 
>> wrote:
>>
>>> Maybe you could improve it by forcing a "cut" before images, code
>>> snippets and such
>>>
>>
>> Made the extraction routine more Emmanuel compliant.
>>
>> There's still this weird post by Vlad on the front page but I prefer to
>> keep the logic as it is as it makes more sense for all the other posts. And
>> it's not that shocking.
>>
>> Just pushed it, we can refine the logic later if there are any more
>> gripes.
>>
>> Thanks all for taking a look.
>>
>> --
>> Guillaume
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [in.relation.to] Only display post summary in list pages

[Guillaume Smet]

As per Gunnar's request, you can now use the ++ marker to
explicitly mark the end of the preamble (same as in Hugo).

For an example:
posts/Gunnar/2018-02-26-putting-bean-validation-constraints-to-multimaps.adoc

-- 
Guillaume

On Tue, Mar 20, 2018 at 7:08 PM, Guillaume Smet 
wrote:

> On Tue, Mar 20, 2018 at 6:18 PM, Sanne Grinovero 
> wrote:
>
>> Maybe you could improve it by forcing a "cut" before images, code
>> snippets and such
>>
>
> Made the extraction routine more Emmanuel compliant.
>
> There's still this weird post by Vlad on the front page but I prefer to
> keep the logic as it is as it makes more sense for all the other posts. And
> it's not that shocking.
>
> Just pushed it, we can refine the logic later if there are any more gripes.
>
> Thanks all for taking a look.
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Problem with releasing 5.1.13.Final

[Gail Badner]

I suppose another alternative is to make the distributions manually.

On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner  wrote:

> I am able to build the documentation using Andrea's suggestion and now I'm
> struggling with gradle.
>
> I released the staging repository on nexus last night to make a deadline.
>
> I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was
> probably a mistake.
>
> Today I went back to build the distributions. The problem is that after
> setting the version back to 5.1.13.Final in build.gradle, gradle
> automatically recompiles and rebuilds the jars.
>
> That is (obviously) a problem because they won't be the same as what was
> uploaded to nexus.
>
> I've been trying some things out on a copy of the directory so I still
> have the original jars intact.
>
> I've tried --no-rebuild, but it doesn't seem to work.
>
> Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, but I
> really don't want to do that.
>
> Any suggestions?
>
> Thanks!
> Gail
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev