Frankly I don't know if it is enabled or how to enable it :) I'm using
spring-boot with log4j2 as a logging implementation and It was working
perfectly fine with hibernate 4.3.8.Final and hibernate-validator
5.1.3.Final
2015-04-01 13:45 GMT+03:00 Sanne Grinovero <sanne(a)hibernate.org>:
 Hi Petar,
 the version issue of jboss-logging is a known limitation; I've
 described some details on the wildfly-dev mailing list.
 I was expecting for people to choose the most up to date version of
 jboss-logging in case of conflicting versions though, or manage the
 version explicitly rather than leaving the choice to the build tool.
 The TRACE problem was not expected of course. May I assume you have
 the TRACE level enabled?
 Thanks,
 Sanne
 On 1 April 2015 at 11:32, Petar Tahchiev <paranoiabla(a)gmail.com> wrote:
 > One other thing I noticed:
 > hibernate-core-5 depends on
 >
 > <groupId>org.jboss.logging</groupId>
 > <artifactId>jboss-logging</artifactId>
 > <version>3.2.1.Final</version>
 >
 > and if you have hibernate-validator 5.1.3.Final (the last stable), it
 will
 > depend on
 >
 > <groupId>org.jboss.logging</groupId>
 > <artifactId>jboss-logging</artifactId>
 > <version>3.1.4.GA</version>
 >
 > So you will get an exception of method not found on some jboss-logging
 API.
 > I excluded the jboss-loggin from the hibernate-validator
 > dependency, but now I get a ton of these TRACE statements (literally
 every
 > millisecond):
 >
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 > 2015-04-01 13:28:02,090
 > org.hibernate.event.internal.DefaultPersistEventListener
 > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
 >
 >
 >  But at least it works.. I guess the only real solution is to have
 > hibernate-validator use the same jboss-logging version.
 >
 >
 > 2015-04-01 10:39 GMT+03:00 Gunnar Morling <gunnar(a)hibernate.org>:
 >
 >> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
 >>
 >> > Just to clarify...  I *think* that as long as we run the build with
 Java
 >> 8
 >> > and set the bootclasspath to 6 or 7 we should be fine.
 >> >
 >>
 >> Yes, setting the boot classpath to 6 (or 7) makes sure you only use
 classes
 >> present in that JDK (be it explicitly or implicitly as in the
 >> ConcurrentHashMap case), because it's that class library which will be
 used
 >> for compilation then. It is cumbersome to use though as you need to
 specify
 >> the location of a 6 or 7 JDK which makes the build less easily portable
 >> between machines.
 >>
 >> Currently, AnimalSniffer is in place to prevent this very category of
 error
 >> and I'm wondering why it didn't detect the "usage" of
KeySetView. It
 really
 >> should have detected it, assuming it analyses the byte code of classes.
 But
 >> this makes me wonder now whether it only analyses the source code
 actually.
 >> Then it wouldn't be usable to prevent this sort of issue.
 >>
 >> Coding against the ConcurrentMap interface is the best way to avoid the
 >> issue. But of course there is no guarantee that it happens again, unless
 >> e.g. having a build on CI which uses 6 or 7 on its boot classpath.
 >>
 >>
 >> > On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole
<steve(a)hibernate.org>
 >> > wrote:
 >> >
 >> > > Well the idea is to run the Gradle process with Java 8 (the build
 >> itself
 >> > > is a Java process too don't forget).  We pass in the older JDK
 >> > specifically
 >> > > to be able to set the bootclasspath for compilation and the
 executable
 >> > for
 >> > > running tests.  That's the theory.
 >> > >
 >> > > Interestingly I developed a simplified project to test these
 theories:
 >> > > 
https://github.com/sebersole/gradle-mixed-jdk  And of course this
 all
 >> > > works there.  As you'd expect right?
 >> > >
 >> > > I think the JAXB thing comes into play here as well.  Gradle does
 not
 >> > have
 >> > > any XJC support built in, so we have to make use of its Ant support
 to
 >> > run
 >> > > the XJC Ant tasks for JAXB model generation.  The problem there is
 >> that,
 >> > > afaik, there is no way to tell Gradle's AntBuilder to use a JDK
 other
 >> > than
 >> > > the one that launched Gradle.  I think this is why we see a JAXB
 model
 >> > > defined for Java 7, rather than Java 6, because we essentially run
 XJC
 >> > with
 >> > > Java 8.
 >> > >
 >> > > Anyway, this certainly makes the build more complex and we
 definitely
 >> > have
 >> > > to think through all these scenarios.  In fact after Beta1, one of
 my
 >> > todos
 >> > > is to build up the build "from scratch" using that
gradle-mixed-jdk
 >> > project
 >> > > as a basis.
 >> > >
 >> > > In general the plan though is to run all the tests (other than
 >> > > hibernate-java8, obviously) with the "baseline JDK, whether that
be
 >> Java
 >> > 6
 >> > > or 7.
 >> > >
 >> > > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <
 sanne(a)hibernate.org>
 >> > > wrote:
 >> > >
 >> > >> There are many similar issues discussed on the Lucene
developer's
 >> > >> mailing list, it's an interesting read:
 >> > >>  -
 >> > >>
 >> >
 >>
http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401...
 >> > >>
 >> > >> I see no alternative than to have those test jobs actually
 exercising
 >> > >> ORM with JDK6, or maybe even compile it all with JDK6 except the
 Java8
 >> > >> additional module to be compiled with JDK8 ?
 >> > >>
 >> > >>
 >> > >>
 >> > >> On 1 April 2015 at 00:36, Steve Ebersole
<steve(a)hibernate.org>
 wrote:
 >> > >> > Ahh, seems this may be an option to work around it:
 >> > >> >
 >> > >> > <quote>
 >> > >> > Using the general *Map* interface in place of the concrete
 >> > >> > *ConcurrentHashMap* type here side-steps the coupling to the
 Java 8
 >> > >> return
 >> > >> > type and will allow this code to be compiled with Java 8 and
run
 on
 >> > >> Java 7.
 >> > >> > </quote>
 >> > >> >
 >> > >> > I had missed that part.
 >> > >> >
 >> > >> >
 >> > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <
 >> steve(a)hibernate.org>
 >> > >> wrote:
 >> > >> >
 >> > >> >> When I say "internal" here, I mean internal to
java classes.
 >> > >> >>
 >> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <
 >> steve(a)hibernate.org
 >> > >
 >> > >> >> wrote:
 >> > >> >>
 >> > >> >>> Nope.  It just effects any code compiled with Java 8
even
 though
 >> the
 >> > >> >>> change is internal.  The problem is the generated
bytecode
 >> > >> incorporates
 >> > >> >>> this change.   Like I said, this should be compiled
with 1.6
 >> > >> compatibility,
 >> > >> >>> but that is apparently not working atm.  I am having
a struggle
 >> > >> getting a
 >> > >> >>> mixed JDK build working "just right".
 >> > >> >>>
 >> > >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <
 >> > >> paranoiabla(a)gmail.com>
 >> > >> >>> wrote:
 >> > >> >>>
 >> > >> >>>> According to this:
 >> > >> >>>>
 >> > >> >>>>
https://gist.github.com/AlainODea/1375759b8720a3f9f094
 >> > >> >>>>
 >> > >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()*
returns a
 >> Set<K>
 >> > >> while
 >> > >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a
 >> > >> >>>> ConcurrentHashMap.KeySetView<K,V>`.
 >> > >> >>>>
 >> > >> >>>> I think you're using some Java8 API.
 >> > >> >>>>
 >> > >> >>>>
 >> > >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <
 paranoiabla(a)gmail.com
 >> >:
 >> > >> >>>>
 >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java
-version
 >> > >> >>>>> java version "1.7.0_71"
 >> > >> >>>>> Java(TM) SE Runtime Environment (build
1.7.0_71-b14)
 >> > >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build
24.71-b01, mixed
 mode)
 >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a
 >> > >> >>>>> Linux petar-ThinkPad-X1-Carbon
3.16.0-33-generic #44-Ubuntu
 SMP
 >> > Thu
 >> > >> Mar
 >> > >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64
GNU/Linux
 >> > >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$
 >> > >> >>>>>
 >> > >> >>>>>
 >> > >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole
<
 steve(a)hibernate.org>:
 >> > >> >>>>>
 >> > >> >>>>>> What JRE are you trying to use?  This
error:
 >> > >> >>>>>>
 >> > >> >>>>>> java.lang.NoSuchMethodError:
java.util.concurrent.
 >> > >> >>>>>>
ConcurrentHashMap.keySet()Ljava/util/concurrent/
 >> > >> >>>>>> ConcurrentHashMap$KeySetView;
 >> > >> >>>>>>
 >> > >> >>>>>> is indicative of an issue in cross-jre
support due to a
 change
 >> > >> >>>>>> internal to java classes.
 >> > >> >>>>>>
 >> > >> >>>>>>
 >> > >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar
Tahchiev <
 >> > >> paranoiabla(a)gmail.com
 >> > >> >>>>>> > wrote:
 >> > >> >>>>>>
 >> > >> >>>>>>> Thanks Steve,
 >> > >> >>>>>>>
 >> > >> >>>>>>> I managed to migrate my configuration
to the new
 >> > >> >>>>>>> MetamodelImplementor. Now when I run
the scema export I
 get a
 >> > lot
 >> > >> of these
 >> > >> >>>>>>> warning:
 >> > >> >>>>>>>
 >> > >> >>>>>>> INFO : HHH000400: Using dialect:
 >> > >> org.hibernate.dialect.MySQL5Dialect
 >> > >> >>>>>>> WARN : JDBC Driver reports it stores
quoted identifiers in
 >> both
 >> > >> mixed
 >> > >> >>>>>>> and upper case
 >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for
class:
 >> > >> >>>>>>>
com.xxx.platform.core.model.cms.AbstractPageModel
 >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for
class:
 >> > >> >>>>>>>
com.xxx.platform.module.invoice.core.model.InvoicePageModel
 >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for
class:
 >> > >> >>>>>>>
 >> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
 >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for
class:
 >> > >> >>>>>>>
 >> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
 >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for
class:
 >> > >> >>>>>>>
 >> > >>
 com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
 >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for
class:
 >> > >> >>>>>>>
 >> > com.xxx.platform.module.search.core.model.SearchPageRedirectModel
 >> > >> >>>>>>> WARN : HHH000072: Duplicate joins for
class:
 >> > >> >>>>>>>
com.xxx.platform.module.promotion.core.model.PromotionModel
 >> > >> >>>>>>>
 >> > >> >>>>>>> and when I run some test I get the
following exception:
 >> > >> >>>>>>> java.lang.NoSuchMethodError:
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
 org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
 >> > >> >>>>>>>     at
 >> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
 >> > >> >>>>>>>     at
 >> > >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
 org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
 >> > >> >>>>>>>     at
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
 org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
 >> > >> >>>>>>>
 >> > >> >>>>>>>
 >> > >> >>>>>>>
 >> > >> >>>>>>>
 >> > >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve
Ebersole <
 steve(a)hibernate.org
 >> >:
 >> > >> >>>>>>>
 >> > >> >>>>>>>> I am told that the bug does not
affect the JBoss->Central
 >> sync
 >> > >> >>>>>>>> process.  So at some point the
artifacts should all be
 >> > available
 >> > >> in Central
 >> > >> >>>>>>>>
 >> > >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM,
Steve Ebersole <
 >> > >> steve(a)hibernate.org
 >> > >> >>>>>>>> > wrote:
 >> > >> >>>>>>>>
 >> > >> >>>>>>>>> hibernate-core seems to be
the only artifact that is
 >> available
 >> > >> in
 >> > >> >>>>>>>>> JBoss Nexus.
 >> > >> >>>>>>>>>
 >> > >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18
PM, Steve Ebersole <
 >> > >> >>>>>>>>> steve(a)hibernate.org>
wrote:
 >> > >> >>>>>>>>>
 >> > >> >>>>>>>>>> So apparently the
artifacts / repo issue is a Nexus bug
 >> that
 >> > is
 >> > >> >>>>>>>>>> effecting the JBoss repo
(and therefore us)...
 >> > >> >>>>>>>>>>
http://issues.sonatype.org/browse/NEXUS-7654
 >> > >> >>>>>>>>>>
 >> > >> >>>>>>>>>> As I pointed out in the
announcement, I am managing the
 >> > >> "migration
 >> > >> >>>>>>>>>> guide" in source
repo while I develop the Betas.  See
 >> > >> >>>>>>>>>>
 >> > >>
 >> >
 >>
 
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat...
 >> > >> >>>>>>>>>>  As far are the new
bootstrapping apis, see
 >> > >> >>>>>>>>>>
 >> > >>
 >> >
 >>
 
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot...
 >> > >> >>>>>>>>>> and
 >> > >> >>>>>>>>>>
 >> > >>
 >> >
 >>
 
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot...
 >> > >> >>>>>>>>>>
 >> > >> >>>>>>>>>> On Tue, Mar 31, 2015 at
5:07 PM, Petar Tahchiev <
 >> > >> >>>>>>>>>> paranoiabla(a)gmail.com>
wrote:
 >> > >> >>>>>>>>>>
 >> > >> >>>>>>>>>>> Hi guys,
 >> > >> >>>>>>>>>>>
 >> > >> >>>>>>>>>>> I just tried the
latest beta and I cannot compile my
 >> > project.
 >> > >> >>>>>>>>>>> With the
 >> > >> >>>>>>>>>>> latest hibernate
4.3.X I was able to do this:
 >> > >> >>>>>>>>>>> -------
 >> > >> >>>>>>>>>>>         final
org.hibernate.cfg.Configuration
 >> configuration
 >> > =
 >> > >> >>>>>>>>>>>
getHibernateConfiguration();
 >> > >> >>>>>>>>>>>        
configuration.buildMappings();
 >> > >> >>>>>>>>>>>         final
SchemaUpdate schemaUpdate = new
 >> > >> >>>>>>>>>>>
SchemaUpdate(configuration);
 >> > >> >>>>>>>>>>> -------
 >> > >> >>>>>>>>>>>
 >> > >> >>>>>>>>>>> however it seems that
the SchemaUpdate constructor has
 >> been
 >> > >> >>>>>>>>>>> removed and now
 >> > >> >>>>>>>>>>> a new one is added:
 >> > >> >>>>>>>>>>> --------
 >> > >> >>>>>>>>>>>     public
SchemaUpdate(MetadataImplementor metadata) {
 >> > >> >>>>>>>>>>>         this(
 >> > >> >>>>>>>>>>>
 >> metadata.getMetadataBuildingOptions().getServiceRegistry(),
 >> > >> >>>>>>>>>>> metadata );
 >> > >> >>>>>>>>>>>     }
 >> > >> >>>>>>>>>>> ---------
 >> > >> >>>>>>>>>>>
 >> > >> >>>>>>>>>>> Also the
configuration.buildMappings() method has been
 >> > >> >>>>>>>>>>> deprecated. Where do
 >> > >> >>>>>>>>>>> I get the
MetadataImplementor from? Also is there any
 >> > >> changelog I
 >> > >> >>>>>>>>>>> can refer
 >> > >> >>>>>>>>>>> to?
 >> > >> >>>>>>>>>>>
 >> > >> >>>>>>>>>>> Thanks.
 >> > >> >>>>>>>>>>> --
 >> > >> >>>>>>>>>>> Regards, Petar!
 >> > >> >>>>>>>>>>> Karlovo, Bulgaria.
 >> > >> >>>>>>>>>>> ---
 >> > >> >>>>>>>>>>> Public PGP Key at:
 >> > >> >>>>>>>>>>>
 >> > >> >>>>>>>>>>>
 >> > >>
 >> >
 >>
 
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 >> > >> >>>>>>>>>>> Key Fingerprint: A369
A7EE 61BC 93A3 CDFF  55A5 1965
 8550
 >> > C311
 >> > >> >>>>>>>>>>> 0611
 >> > >> >>>>>>>>>>>
_______________________________________________
 >> > >> >>>>>>>>>>> hibernate-dev mailing
list
 >> > >> >>>>>>>>>>>
hibernate-dev(a)lists.jboss.org
 >> > >> >>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
 >> > >> >>>>>>>>>>>
 >> > >> >>>>>>>>>>
 >> > >> >>>>>>>>>>
 >> > >> >>>>>>>>>
 >> > >> >>>>>>>>
 >> > >> >>>>>>>
 >> > >> >>>>>>>
 >> > >> >>>>>>> --
 >> > >> >>>>>>> Regards, Petar!
 >> > >> >>>>>>> Karlovo, Bulgaria.
 >> > >> >>>>>>> ---
 >> > >> >>>>>>> Public PGP Key at:
 >> > >> >>>>>>>
 >> > >>
 >> >
 >>
 
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 >> > >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3
CDFF  55A5 1965 8550
 C311
 >> > >> 0611
 >> > >> >>>>>>>
 >> > >> >>>>>>
 >> > >> >>>>>>
 >> > >> >>>>>
 >> > >> >>>>>
 >> > >> >>>>> --
 >> > >> >>>>> Regards, Petar!
 >> > >> >>>>> Karlovo, Bulgaria.
 >> > >> >>>>> ---
 >> > >> >>>>> Public PGP Key at:
 >> > >> >>>>>
 >> > >>
 >> >
 >>
 
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 >> > >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 
55A5 1965 8550
 C311
 >> > 0611
 >> > >> >>>>>
 >> > >> >>>>
 >> > >> >>>>
 >> > >> >>>>
 >> > >> >>>> --
 >> > >> >>>> Regards, Petar!
 >> > >> >>>> Karlovo, Bulgaria.
 >> > >> >>>> ---
 >> > >> >>>> Public PGP Key at:
 >> > >> >>>>
 >> > >>
 >> >
 >>
 
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 >> > >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5
1965 8550 C311
 >> 0611
 >> > >> >>>>
 >> > >> >>>
 >> > >> >>>
 >> > >> >>
 >> > >> > _______________________________________________
 >> > >> > hibernate-dev mailing list
 >> > >> > hibernate-dev(a)lists.jboss.org
 >> > >> > 
https://lists.jboss.org/mailman/listinfo/hibernate-dev
 >> > >>
 >> > >
 >> > >
 >> > _______________________________________________
 >> > hibernate-dev mailing list
 >> > hibernate-dev(a)lists.jboss.org
 >> > 
https://lists.jboss.org/mailman/listinfo/hibernate-dev
 >> >
 >> _______________________________________________
 >> hibernate-dev mailing list
 >> hibernate-dev(a)lists.jboss.org
 >> 
https://lists.jboss.org/mailman/listinfo/hibernate-dev
 >>
 >
 >
 >
 > --
 > Regards, Petar!
 > Karlovo, Bulgaria.
 > ---
 > Public PGP Key at:
 >
 
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
 > _______________________________________________
 > hibernate-dev mailing list
 > hibernate-dev(a)lists.jboss.org
 > 
https://lists.jboss.org/mailman/listinfo/hibernate-dev