From gbadner at redhat.com  Wed Jun  1 00:40:34 2016
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 31 May 2016 21:40:34 -0700
Subject: [hibernate-dev] 5.1 branch backporting
In-Reply-To: <CAL00eSRhi=VG5U83aOebOOiktWotW-vpMPjFZx7gX5QAgbDi1g@mail.gmail.com>
References: <CA+gWKMA_wn7BMp0T-g980=Gn11JMnOtL591HtCDQbOT=wmO0RA@mail.gmail.com>
	<CAL00eSRhi=VG5U83aOebOOiktWotW-vpMPjFZx7gX5QAgbDi1g@mail.gmail.com>
Message-ID: <CAFDzhiTAB2TDDT-gvvqt_7srKnaMzuQpbuBTY=Uy52fq2xfAxQ@mail.gmail.com>

I need to get clarification myself. I'll get back to you shortly.

On Tue, May 31, 2016 at 5:13 AM, andrea boriero <andrea at hibernate.org>
wrote:

> I think at the moment if an issue affects 5.1 we should apply the fix.
>
> But I may be wrong.
>
> On 31 May 2016 at 12:53, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
> > Hi,
> >
> > I have backported some fixed to 5.1, and I'm not sure if that was the
> right
> > thing to do.
> > I know that for 5.0 we should ask Gail if to backport anything
> >
> > Now that we moved to 5.2, should we also ask Gail when to backport
> > something to 5.1 too?
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From mihalcea.vlad at gmail.com  Wed Jun  1 10:09:54 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 1 Jun 2016 17:09:54 +0300
Subject: [hibernate-dev] UserType backward incompatibility in 5.2
Message-ID: <CA+gWKMCHKz6Uy3VqjeTnSNF5_OMc3J-e93Ou5qZ0-g1GqsG=fA@mail.gmail.com>

Hi,

I think that HEM introduced a backward incompatibility for UserTypes
because the contract has changed for nullSafeGet and nullSafeSet.
Instead of a SessionImplementor, we now need to provide a
SharedSessionContractImplementor.

This is going to break all UserTypes classes that were implemented by our
users.
Is this issue known?

Vlad

From vm at sykora.cz  Thu Jun  2 08:45:05 2016
From: vm at sykora.cz (Vladimir Martinek)
Date: Thu, 2 Jun 2016 14:45:05 +0200
Subject: [hibernate-dev] Relations are not loaded when using Fetch Profiles
Message-ID: <57502A51.802@sykora.cz>

Fetch profiles fail to load certain relations because of invalid cycle 
detection in MetamodelGraphWalker. Below is an example.

I have compared the behaviour of Fetch Profiles and standard EAGER 
relations (EAGER does not suffer from this problem). The 
MetamodelGraphWalker graph walker produces the same results, the SQL is 
the same (missing relation).

With EAGER the relation is loaded in second pass, via 
SessionImpl.internalLoad(). There it is decided what LoadType is used - 
for eager it uses INTERNAL_LOAD_EAGER, for lazy INTERNAL_LOAD_LAZY. It 
does not take into account the fetch profiles here!

The last place I can get hold of fetch profiles in in 
AbstractLoadPlanBasedEntityLoader line 82. After that the fetch profile 
information is lost, never making it anywhere near to 
SessionImpl.internalLoad().

I would like to implement this, but to do that, I need someone to point 
me in the right direction. Most of all I need answers to following 
questions:

1) Is it right to assume the fetch profiles should be evaluated in 
SessionImpl.internalLoad() and appropriate LoadType used when detected a 
relation affected by a fetch profile?
2) If so, what is the intended way of getting the fetch profile 
information to SessionImpl.internalLoad()?

Also, a colleague of mine attempted to implement FetchType.SELECT fetch 
strategy and ended up with precisely the same problem. I believe solving 
my issue would pave way for quick FetchType.SELECT implementation (which 
we could also use on our project).


Thank you

Vladimir Martinek


Example:

Have 5 entities - Start, Via1, Via2, Mid and Finish with following 
relations (all LAZY):

Start n:1 Via1 n:1 Mid n:1 Finish
Start n:1 Via2 n:1 Mid n:1 Finish

Now, trying to use Fetch Profiles to load Start entity and all of its 
relations. I would expect Hibernate to execute following SQL select:

SELECT * FROM Start s
LEFT OUTER JOIN Via1 v1 (path Start-Via1)
LEFT OUTER JOIN Mid
JOIN Finish

LEFT OUTER JOIN Via2 (path Start-Via2)
LEFT OUTER JOIN Mid
JOIN Finish

Unfortunately, ii ompletely omits the second join from Mid to Finish, 
what I am getting is:

SELECT * FROM Start s
LEFT OUTER JOIN Via1 v1 (path Start-Via1)
LEFT OUTER JOIN Mid
JOIN Finish

LEFT OUTER JOIN Via2 (path Start-Via2)
LEFT OUTER JOIN Mid

I dug deeper into this and found cycle detection in 
MetamodelGraphWalker, line 144. Basically, when MetamodelGraphWalker 
detects a relation that has already been visited, it considers it a 
cycle. But in my case it is not a cycle - I just came to the same 
relation twice using two different paths.



From steve at hibernate.org  Thu Jun  2 12:34:03 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 02 Jun 2016 16:34:03 +0000
Subject: [hibernate-dev] Hibernate ORM 5.2.0 release
Message-ID: <CAFdSV9uxGy7YAiegkNVF4LqdorPbW5eDKLHY0katb4_UVmecug@mail.gmail.com>

http://in.relation.to/2016/06/01/hibernate-orm-520-final-release/

From paranoiabla at gmail.com  Sun Jun  5 10:17:36 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Sun, 5 Jun 2016 17:17:36 +0300
Subject: [hibernate-dev] Collection was not processed by flush()
Message-ID: <CAKnbemWXysiBcoESUxzpj16_7VQENqR52xD7Oj3+QQMVB1G5Og@mail.gmail.com>

Hello,

I'm using hibernate version 5.1.0.Final and spring-data-rest and I have a
StockRepository which is exposed via rest and when I try to create a new
stock entry I get the following exception:

2016-06-05 17:02:43,917 org.hibernate.AssertionFailure
[http-nio-127.0.0.1-8112-exec-2] ERROR: HHH000099: an assertion failure
occured (this may indicate a bug in Hibernate, but is more likely due to
unsafe use of the session): org.hibernate.AssertionFailure: collection [
com.nemesis.platform.module.commerce.core.entity.i18n.CurrencyEntity.name]
was not processed by flush()
2016-06-05 17:02:43,920
org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/storefront].[repositoryRestDispatcherServlet]
[http-nio-127.0.0.1-8112-exec-2] ERROR: Servlet.service() for servlet
[repositoryRestDispatcherServlet] in context with path [/storefront] threw
exception [Request processing failed; nested exception is
org.springframework.transaction.TransactionSystemException: Could not
commit JPA transaction; nested exception is
javax.persistence.RollbackException: Error while committing the
transaction] with root cause
org.hibernate.AssertionFailure: collection [
com.nemesis.platform.module.commerce.core.entity.i18n.CurrencyEntity.name]
was not processed by flush()
    at
org.hibernate.engine.spi.CollectionEntry.postFlush(CollectionEntry.java:214)
    at
org.hibernate.event.internal.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:369)
    at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:40)
    at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1295)
    at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:468)
    at
org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3135)
    at
org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2352)
    at
org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:485)
    at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:147)
    at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$100(JdbcResourceLocalTransactionCoordinatorImpl.java:38)
    at
org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:231)
    at
org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:65)
    at
org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:61)
    at
org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:517)
    at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
    at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
    at sun.reflect.GeneratedMethodAccessor191.invoke(Unknown Source)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
    at
org.springframework.batch.core.configuration.annotation.SimpleBatchConfiguration$PassthruAdvice.invoke(SimpleBatchConfiguration.java:127)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
    at com.sun.proxy.$Proxy349.commit(Unknown Source)
    at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:485)
    at
org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291)
    at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at
org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:131)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
    at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
    at com.sun.proxy.$Proxy304.save(Unknown Source)
    at
org.springframework.data.repository.support.CrudRepositoryInvoker.invokeSave(CrudRepositoryInvoker.java:100)
    at
org.springframework.data.rest.core.support.UnwrappingRepositoryInvokerFactory$UnwrappingRepositoryInvoker.invokeSave(UnwrappingRepositoryInvokerFactory.java:225)
    at
org.springframework.data.querydsl.QuerydslRepositoryInvokerAdapter.invokeSave(QuerydslRepositoryInvokerAdapter.java:158)
    at
org.springframework.data.rest.webmvc.RepositoryEntityController.createAndReturn(RepositoryEntityController.java:514)
    at
org.springframework.data.rest.webmvc.RepositoryEntityController.postCollectionResource(RepositoryEntityController.java:276)
    at sun.reflect.GeneratedMethodAccessor325.invoke(Unknown Source)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at
org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
    at
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
    at
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
    at
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:832)
    at
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:743)
    at
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
    at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:961)
    at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:895)
    at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:967)
    at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:869)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
    at
org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.boot.actuate.autoconfigure.EndpointWebMvcAutoConfiguration$ApplicationContextHeaderFilter.doFilterInternal(EndpointWebMvcAutoConfiguration.java:261)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.web.filter.CorsFilter.doFilterInternal(CorsFilter.java:92)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:115)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:316)
    at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:126)
    at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:90)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:114)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:122)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:48)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:158)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
com.nemesis.platform.core.filter.RestAuthenticationFilter.doFilterInternal(RestAuthenticationFilter.java:70)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:120)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:91)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:53)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
    at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:213)
    at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
    at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
    at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:87)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:77)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
com.nemesis.platform.module.cms.storefront.filter.PathLocaleFilter.doFilterInternal(PathLocaleFilter.java:87)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:126)
    at
org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:65)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.web.filter.CorsFilter.doFilterInternal(CorsFilter.java:92)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.springframework.boot.actuate.autoconfigure.MetricsFilter.doFilterInternal(MetricsFilter.java:103)
    at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
    at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
    at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
    at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
    at
org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:676)
    at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
    at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
    at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
    at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
    at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095)
    at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
    at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1502)
    at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1458)
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:745)


I'm writing here because the message says this might indicate a bug in
hibernate.

-- 
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

From sanne at hibernate.org  Sun Jun  5 12:00:20 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 5 Jun 2016 17:00:20 +0100
Subject: [hibernate-dev] Revert API change in org.hibernate.Query
Message-ID: <CAFm4XO1dwGguf8HoOTur=58zB7uwf+22oJxttgp0AZXvQGdH0Q@mail.gmail.com>

I just noticed that the org.hibernate.Query interface was deprecated
in 5.2, with the suggestion to use org.hibernate.query.Query now.
That's ok, but it seems the "deprecation process" also forced some API
changes already on the deprecated interface which seem might have been
unintentional.

The builder methods on org.hibernate.Query used to allow returning
"this" to chain methods,
although this seems no longer possible as the API now declares the
return type should be the new one, org.hibernate.query.Query.

Could we fix this by relaxing the return to the older deprecated method?

in practice:

 org.hibernate.query.Query<R> setFirstResult(int startPosition);

should be:

 org.hibernate.Query<R> setFirstResult(int startPosition);

Thanks,
Sanne

From gbadner at redhat.com  Tue Jun  7 00:00:04 2016
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 6 Jun 2016 21:00:04 -0700
Subject: [hibernate-dev] Relations are not loaded when using Fetch
	Profiles
In-Reply-To: <57502A51.802@sykora.cz>
References: <57502A51.802@sykora.cz>
Message-ID: <CAFDzhiRuTk22tmGtkc4LpL26LVV63-mFuz2JmdbrxBvA+M6OJw@mail.gmail.com>

Please create a Jira issue and attach a runnable test case.
Thanks,
Gail

On Thu, Jun 2, 2016 at 5:45 AM, Vladimir Martinek <vm at sykora.cz> wrote:

> Fetch profiles fail to load certain relations because of invalid cycle
> detection in MetamodelGraphWalker. Below is an example.
>
> I have compared the behaviour of Fetch Profiles and standard EAGER
> relations (EAGER does not suffer from this problem). The
> MetamodelGraphWalker graph walker produces the same results, the SQL is
> the same (missing relation).
>
> With EAGER the relation is loaded in second pass, via
> SessionImpl.internalLoad(). There it is decided what LoadType is used -
> for eager it uses INTERNAL_LOAD_EAGER, for lazy INTERNAL_LOAD_LAZY. It
> does not take into account the fetch profiles here!
>
> The last place I can get hold of fetch profiles in in
> AbstractLoadPlanBasedEntityLoader line 82. After that the fetch profile
> information is lost, never making it anywhere near to
> SessionImpl.internalLoad().
>
> I would like to implement this, but to do that, I need someone to point
> me in the right direction. Most of all I need answers to following
> questions:
>
> 1) Is it right to assume the fetch profiles should be evaluated in
> SessionImpl.internalLoad() and appropriate LoadType used when detected a
> relation affected by a fetch profile?
> 2) If so, what is the intended way of getting the fetch profile
> information to SessionImpl.internalLoad()?
>
> Also, a colleague of mine attempted to implement FetchType.SELECT fetch
> strategy and ended up with precisely the same problem. I believe solving
> my issue would pave way for quick FetchType.SELECT implementation (which
> we could also use on our project).
>
>
> Thank you
>
> Vladimir Martinek
>
>
> Example:
>
> Have 5 entities - Start, Via1, Via2, Mid and Finish with following
> relations (all LAZY):
>
> Start n:1 Via1 n:1 Mid n:1 Finish
> Start n:1 Via2 n:1 Mid n:1 Finish
>
> Now, trying to use Fetch Profiles to load Start entity and all of its
> relations. I would expect Hibernate to execute following SQL select:
>
> SELECT * FROM Start s
> LEFT OUTER JOIN Via1 v1 (path Start-Via1)
> LEFT OUTER JOIN Mid
> JOIN Finish
>
> LEFT OUTER JOIN Via2 (path Start-Via2)
> LEFT OUTER JOIN Mid
> JOIN Finish
>
> Unfortunately, ii ompletely omits the second join from Mid to Finish,
> what I am getting is:
>
> SELECT * FROM Start s
> LEFT OUTER JOIN Via1 v1 (path Start-Via1)
> LEFT OUTER JOIN Mid
> JOIN Finish
>
> LEFT OUTER JOIN Via2 (path Start-Via2)
> LEFT OUTER JOIN Mid
>
> I dug deeper into this and found cycle detection in
> MetamodelGraphWalker, line 144. Basically, when MetamodelGraphWalker
> detects a relation that has already been visited, it considers it a
> cycle. But in my case it is not a cycle - I just came to the same
> relation twice using two different paths.
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue Jun  7 02:47:28 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 7 Jun 2016 09:47:28 +0300
Subject: [hibernate-dev] Jira issues to integrate in 5.1
Message-ID: <CA+gWKMDP4kdmRmDzgDQQAEYB2_8KezNPkHYvRFjh28LLGm7kbw@mail.gmail.com>

Hi,

Because 5.1 is the last version supporting 1.6, I think it's worth to
integrate as many fixes as we can that are now only available on the 5.2
branch.

Therefore, I collected a list of issues so that you can tell me which ones
you'd like me to cherry pick on 5.1:

https://hibernate.atlassian.net/browse/HHH-1594
https://hibernate.atlassian.net/browse/HHH-7355
https://hibernate.atlassian.net/browse/HHH-6781
https://hibernate.atlassian.net/browse/HHH-10773
https://hibernate.atlassian.net/browse/HHH-10754
https://hibernate.atlassian.net/browse/HHH-9951
https://hibernate.atlassian.net/browse/HHH-9894

Thanks,
Vlad

From sanne at hibernate.org  Tue Jun  7 04:42:09 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 7 Jun 2016 09:42:09 +0100
Subject: [hibernate-dev] Deprecation of Maven coordinates: where's
	hibernate-entitymanager ?
Message-ID: <CAFm4XO0e4Zg9w6-AWE7V08FAfihU=523eHu_a9Op4qwbiOPaNw@mail.gmail.com>

I've seen quite some people struggling with the upgrade to Hibernate
ORM 5.2 as they think that hibernate-entitymanager was either
mistakenly not uploaded, or wasn't synched to Maven Central yet.

Could we restore the pom.xml for this artifact and have it redirect to
hibernate-orm ?

Doing so we'll be able to get a proper warning to people consuming
Hibernate via dependency management tools.

We have a similar pom in Hibernate Search, feel free to copy it:
https://github.com/hibernate/hibernate-search/blob/master/legacy/pom.xml#L23-L29

Thanks,
Sanne

From vm at sykora.cz  Tue Jun  7 05:37:50 2016
From: vm at sykora.cz (Vladimir Martinek)
Date: Tue, 7 Jun 2016 11:37:50 +0200
Subject: [hibernate-dev] Relations are not loaded when using Fetch
 Profiles
In-Reply-To: <CAFDzhiRuTk22tmGtkc4LpL26LVV63-mFuz2JmdbrxBvA+M6OJw@mail.gmail.com>
References: <57502A51.802@sykora.cz>
	<CAFDzhiRuTk22tmGtkc4LpL26LVV63-mFuz2JmdbrxBvA+M6OJw@mail.gmail.com>
Message-ID: <575695EE.3050807@sykora.cz>

HHH-10745, runnable test case attached to that issue 
(org.hibernate.test.fetchprofiles.cycle.tar.gz).

Thank you

Vladimir



On 06/07/2016 06:00 AM, Gail Badner wrote:
> Please create a Jira issue and attach a runnable test case.
> Thanks,
> Gail
>
> On Thu, Jun 2, 2016 at 5:45 AM, Vladimir Martinek <vm at sykora.cz 
> <mailto:vm at sykora.cz>> wrote:
>
>     Fetch profiles fail to load certain relations because of invalid cycle
>     detection in MetamodelGraphWalker. Below is an example.
>
>     I have compared the behaviour of Fetch Profiles and standard EAGER
>     relations (EAGER does not suffer from this problem). The
>     MetamodelGraphWalker graph walker produces the same results, the
>     SQL is
>     the same (missing relation).
>
>     With EAGER the relation is loaded in second pass, via
>     SessionImpl.internalLoad(). There it is decided what LoadType is
>     used -
>     for eager it uses INTERNAL_LOAD_EAGER, for lazy INTERNAL_LOAD_LAZY. It
>     does not take into account the fetch profiles here!
>
>     The last place I can get hold of fetch profiles in in
>     AbstractLoadPlanBasedEntityLoader line 82. After that the fetch
>     profile
>     information is lost, never making it anywhere near to
>     SessionImpl.internalLoad().
>
>     I would like to implement this, but to do that, I need someone to
>     point
>     me in the right direction. Most of all I need answers to following
>     questions:
>
>     1) Is it right to assume the fetch profiles should be evaluated in
>     SessionImpl.internalLoad() and appropriate LoadType used when
>     detected a
>     relation affected by a fetch profile?
>     2) If so, what is the intended way of getting the fetch profile
>     information to SessionImpl.internalLoad()?
>
>     Also, a colleague of mine attempted to implement FetchType.SELECT
>     fetch
>     strategy and ended up with precisely the same problem. I believe
>     solving
>     my issue would pave way for quick FetchType.SELECT implementation
>     (which
>     we could also use on our project).
>
>
>     Thank you
>
>     Vladimir Martinek
>
>
>     Example:
>
>     Have 5 entities - Start, Via1, Via2, Mid and Finish with following
>     relations (all LAZY):
>
>     Start n:1 Via1 n:1 Mid n:1 Finish
>     Start n:1 Via2 n:1 Mid n:1 Finish
>
>     Now, trying to use Fetch Profiles to load Start entity and all of its
>     relations. I would expect Hibernate to execute following SQL select:
>
>     SELECT * FROM Start s
>     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>     LEFT OUTER JOIN Mid
>     JOIN Finish
>
>     LEFT OUTER JOIN Via2 (path Start-Via2)
>     LEFT OUTER JOIN Mid
>     JOIN Finish
>
>     Unfortunately, ii ompletely omits the second join from Mid to Finish,
>     what I am getting is:
>
>     SELECT * FROM Start s
>     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>     LEFT OUTER JOIN Mid
>     JOIN Finish
>
>     LEFT OUTER JOIN Via2 (path Start-Via2)
>     LEFT OUTER JOIN Mid
>
>     I dug deeper into this and found cycle detection in
>     MetamodelGraphWalker, line 144. Basically, when MetamodelGraphWalker
>     detects a relation that has already been visited, it considers it a
>     cycle. But in my case it is not a cycle - I just came to the same
>     relation twice using two different paths.
>
>
>     _______________________________________________
>     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
>
>


-- 

*Ing. Vladim?r Martinek*
Programmer

T: +420 723 908 968
@: vm at sykora.cz

Sykora Data Center s.r.o.
28. ??jna 1512/123, 702 00 Ostrava
www.sykora.cz


From mihalcea.vlad at gmail.com  Tue Jun  7 05:50:16 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 7 Jun 2016 12:50:16 +0300
Subject: [hibernate-dev] Stream result change proposal
Message-ID: <CA+gWKMDVwbAeWpaAnH57eYp_XhASZ=roAKZFUK4m4vAeLatfeA@mail.gmail.com>

Hi,

While writing documentation for the new 5.2 Query.stream() API, I realized
that we don't return a Stream<T>, but a Stream<Object[]> which could
confuse users.
This is because ScrollableResultsImpl does something like this:

if ( result != null && result.getClass().isArray() ) {
   currentRow = (Object[]) result;
}
else {
   currentRow = new Object[] {result};
}

The result is the actual entity that we queries, while the currentRow
is an Object[].

I think we might want to change the stream result so that we return
the result for each available entry.

Vlad

From mihalcea.vlad at gmail.com  Tue Jun  7 05:57:24 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 7 Jun 2016 12:57:24 +0300
Subject: [hibernate-dev] Stream result change proposal
In-Reply-To: <CA+gWKMDVwbAeWpaAnH57eYp_XhASZ=roAKZFUK4m4vAeLatfeA@mail.gmail.com>
References: <CA+gWKMDVwbAeWpaAnH57eYp_XhASZ=roAKZFUK4m4vAeLatfeA@mail.gmail.com>
Message-ID: <CA+gWKMC6zW240UDBMcM=sYk8Z8a=ddp4mH9BLzGxk8wUJ-bz4g@mail.gmail.com>

To get a picture of why we need this, consider the following example from
the docs:

Stream<Object[]> persons = session.createQuery(
   "select p " +
   "from Person p " +
   "where p.name like :name" )
.setParameter( "name", "J%" )
.stream();

Map<Phone, List<Call>> callRegistry = persons
   .map( row -> Person.class.cast( row[0] ) )
   .flatMap( person -> person.getPhones().stream() )
   .flatMap( phone -> phone.getCalls().stream() )
   .collect(Collectors.groupingBy(Call::getPhone));


The .map( row -> Person.class.cast( row[0] ) ) call should be avoided and
we should return a Stream<Person> in this case.

Vlad

On Tue, Jun 7, 2016 at 12:50 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> While writing documentation for the new 5.2 Query.stream() API, I realized
> that we don't return a Stream<T>, but a Stream<Object[]> which could
> confuse users.
> This is because ScrollableResultsImpl does something like this:
>
> if ( result != null && result.getClass().isArray() ) {
>    currentRow = (Object[]) result;
> }
> else {
>    currentRow = new Object[] {result};
> }
>
> The result is the actual entity that we queries, while the currentRow is an Object[].
>
> I think we might want to change the stream result so that we return the result for each available entry.
>
> Vlad
>

From andrea at hibernate.org  Tue Jun  7 06:07:08 2016
From: andrea at hibernate.org (andrea boriero)
Date: Tue, 7 Jun 2016 11:07:08 +0100
Subject: [hibernate-dev] Stream result change proposal
In-Reply-To: <CA+gWKMC6zW240UDBMcM=sYk8Z8a=ddp4mH9BLzGxk8wUJ-bz4g@mail.gmail.com>
References: <CA+gWKMDVwbAeWpaAnH57eYp_XhASZ=roAKZFUK4m4vAeLatfeA@mail.gmail.com>
	<CA+gWKMC6zW240UDBMcM=sYk8Z8a=ddp4mH9BLzGxk8wUJ-bz4g@mail.gmail.com>
Message-ID: <CAL00eSRh8zXOB6-RXQYxvRnyOQFqekLahR_M0CCCEDAV1fv_3w@mail.gmail.com>

it sounds reasonable to me

On 7 June 2016 at 10:57, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> To get a picture of why we need this, consider the following example from
> the docs:
>
> Stream<Object[]> persons = session.createQuery(
>    "select p " +
>    "from Person p " +
>    "where p.name like :name" )
> .setParameter( "name", "J%" )
> .stream();
>
> Map<Phone, List<Call>> callRegistry = persons
>    .map( row -> Person.class.cast( row[0] ) )
>    .flatMap( person -> person.getPhones().stream() )
>    .flatMap( phone -> phone.getCalls().stream() )
>    .collect(Collectors.groupingBy(Call::getPhone));
>
>
> The .map( row -> Person.class.cast( row[0] ) ) call should be avoided and
> we should return a Stream<Person> in this case.
>
> Vlad
>
> On Tue, Jun 7, 2016 at 12:50 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
> > Hi,
> >
> > While writing documentation for the new 5.2 Query.stream() API, I
> realized
> > that we don't return a Stream<T>, but a Stream<Object[]> which could
> > confuse users.
> > This is because ScrollableResultsImpl does something like this:
> >
> > if ( result != null && result.getClass().isArray() ) {
> >    currentRow = (Object[]) result;
> > }
> > else {
> >    currentRow = new Object[] {result};
> > }
> >
> > The result is the actual entity that we queries, while the currentRow is
> an Object[].
> >
> > I think we might want to change the stream result so that we return the
> result for each available entry.
> >
> > Vlad
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jun  7 08:41:34 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 07 Jun 2016 12:41:34 +0000
Subject: [hibernate-dev] Revert API change in org.hibernate.Query
In-Reply-To: <CAFm4XO1dwGguf8HoOTur=58zB7uwf+22oJxttgp0AZXvQGdH0Q@mail.gmail.com>
References: <CAFm4XO1dwGguf8HoOTur=58zB7uwf+22oJxttgp0AZXvQGdH0Q@mail.gmail.com>
Message-ID: <CAFdSV9saGYHbW=GsVcqZXgWbUh8C=8hqRmgFkcj=JwtfTRxwcA@mail.gmail.com>

If you send a PR I will include it.

On Sun, Jun 5, 2016 at 11:00 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> I just noticed that the org.hibernate.Query interface was deprecated
> in 5.2, with the suggestion to use org.hibernate.query.Query now.
> That's ok, but it seems the "deprecation process" also forced some API
> changes already on the deprecated interface which seem might have been
> unintentional.
>
> The builder methods on org.hibernate.Query used to allow returning
> "this" to chain methods,
> although this seems no longer possible as the API now declares the
> return type should be the new one, org.hibernate.query.Query.
>
> Could we fix this by relaxing the return to the older deprecated method?
>
> in practice:
>
>  org.hibernate.query.Query<R> setFirstResult(int startPosition);
>
> should be:
>
>  org.hibernate.Query<R> setFirstResult(int startPosition);
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jun  7 08:47:45 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 07 Jun 2016 12:47:45 +0000
Subject: [hibernate-dev] Deprecation of Maven coordinates: where's
 hibernate-entitymanager ?
In-Reply-To: <CAFm4XO0e4Zg9w6-AWE7V08FAfihU=523eHu_a9Op4qwbiOPaNw@mail.gmail.com>
References: <CAFm4XO0e4Zg9w6-AWE7V08FAfihU=523eHu_a9Op4qwbiOPaNw@mail.gmail.com>
Message-ID: <CAFdSV9v1cr-o0MK0AOQX08sW+96miA854Et1xcFf1xVpQKrAyw@mail.gmail.com>

I have mentioned this before.  We cannot automate this through Gradle (long
story, feel free to see my Gradle Jiras and forum posts for details).  And
I am not going to make this a manual step for each and every release.

On Tue, Jun 7, 2016 at 3:42 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> I've seen quite some people struggling with the upgrade to Hibernate
> ORM 5.2 as they think that hibernate-entitymanager was either
> mistakenly not uploaded, or wasn't synched to Maven Central yet.
>
> Could we restore the pom.xml for this artifact and have it redirect to
> hibernate-orm ?
>
> Doing so we'll be able to get a proper warning to people consuming
> Hibernate via dependency management tools.
>
> We have a similar pom in Hibernate Search, feel free to copy it:
>
> https://github.com/hibernate/hibernate-search/blob/master/legacy/pom.xml#L23-L29
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jun  7 09:05:46 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 07 Jun 2016 13:05:46 +0000
Subject: [hibernate-dev] Relations are not loaded when using Fetch
	Profiles
In-Reply-To: <575695EE.3050807@sykora.cz>
References: <57502A51.802@sykora.cz>
	<CAFDzhiRuTk22tmGtkc4LpL26LVV63-mFuz2JmdbrxBvA+M6OJw@mail.gmail.com>
	<575695EE.3050807@sykora.cz>
Message-ID: <CAFdSV9ugYcHoB0SbGUN87tLvXi5yVL7diT3Z-oLgciA8pu6YFQ@mail.gmail.com>

There is a huge difference in join-fetch and what we detail for "EAGER".
Join-fetch is also an eager fetch.  There are 2 pieces of information in
regards to fetching: when, how?

EAGER merely describes when: now.

What you describe as "EAGER" is really a N+1 fetch.  So the relation is
fetched immediately, but as "subsequent select".  A join-fetch is still
EAGER, but now the relation is fetch via join in the initial query.  Very
different behavior.

On Tue, Jun 7, 2016 at 4:38 AM Vladimir Martinek <vm at sykora.cz> wrote:

> HHH-10745, runnable test case attached to that issue
> (org.hibernate.test.fetchprofiles.cycle.tar.gz).
>
> Thank you
>
> Vladimir
>
>
>
> On 06/07/2016 06:00 AM, Gail Badner wrote:
> > Please create a Jira issue and attach a runnable test case.
> > Thanks,
> > Gail
> >
> > On Thu, Jun 2, 2016 at 5:45 AM, Vladimir Martinek <vm at sykora.cz
> > <mailto:vm at sykora.cz>> wrote:
> >
> >     Fetch profiles fail to load certain relations because of invalid
> cycle
> >     detection in MetamodelGraphWalker. Below is an example.
> >
> >     I have compared the behaviour of Fetch Profiles and standard EAGER
> >     relations (EAGER does not suffer from this problem). The
> >     MetamodelGraphWalker graph walker produces the same results, the
> >     SQL is
> >     the same (missing relation).
> >
> >     With EAGER the relation is loaded in second pass, via
> >     SessionImpl.internalLoad(). There it is decided what LoadType is
> >     used -
> >     for eager it uses INTERNAL_LOAD_EAGER, for lazy INTERNAL_LOAD_LAZY.
> It
> >     does not take into account the fetch profiles here!
> >
> >     The last place I can get hold of fetch profiles in in
> >     AbstractLoadPlanBasedEntityLoader line 82. After that the fetch
> >     profile
> >     information is lost, never making it anywhere near to
> >     SessionImpl.internalLoad().
> >
> >     I would like to implement this, but to do that, I need someone to
> >     point
> >     me in the right direction. Most of all I need answers to following
> >     questions:
> >
> >     1) Is it right to assume the fetch profiles should be evaluated in
> >     SessionImpl.internalLoad() and appropriate LoadType used when
> >     detected a
> >     relation affected by a fetch profile?
> >     2) If so, what is the intended way of getting the fetch profile
> >     information to SessionImpl.internalLoad()?
> >
> >     Also, a colleague of mine attempted to implement FetchType.SELECT
> >     fetch
> >     strategy and ended up with precisely the same problem. I believe
> >     solving
> >     my issue would pave way for quick FetchType.SELECT implementation
> >     (which
> >     we could also use on our project).
> >
> >
> >     Thank you
> >
> >     Vladimir Martinek
> >
> >
> >     Example:
> >
> >     Have 5 entities - Start, Via1, Via2, Mid and Finish with following
> >     relations (all LAZY):
> >
> >     Start n:1 Via1 n:1 Mid n:1 Finish
> >     Start n:1 Via2 n:1 Mid n:1 Finish
> >
> >     Now, trying to use Fetch Profiles to load Start entity and all of its
> >     relations. I would expect Hibernate to execute following SQL select:
> >
> >     SELECT * FROM Start s
> >     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
> >     LEFT OUTER JOIN Mid
> >     JOIN Finish
> >
> >     LEFT OUTER JOIN Via2 (path Start-Via2)
> >     LEFT OUTER JOIN Mid
> >     JOIN Finish
> >
> >     Unfortunately, ii ompletely omits the second join from Mid to Finish,
> >     what I am getting is:
> >
> >     SELECT * FROM Start s
> >     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
> >     LEFT OUTER JOIN Mid
> >     JOIN Finish
> >
> >     LEFT OUTER JOIN Via2 (path Start-Via2)
> >     LEFT OUTER JOIN Mid
> >
> >     I dug deeper into this and found cycle detection in
> >     MetamodelGraphWalker, line 144. Basically, when MetamodelGraphWalker
> >     detects a relation that has already been visited, it considers it a
> >     cycle. But in my case it is not a cycle - I just came to the same
> >     relation twice using two different paths.
> >
> >
> >     _______________________________________________
> >     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
> >
> >
>
>
> --
>
> *Ing. Vladim?r Martinek*
> Programmer
>
> T: +420 723 908 968
> @: vm at sykora.cz
>
> Sykora Data Center s.r.o.
> 28. ??jna 1512/123, 702 00 Ostrava
> www.sykora.cz
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Tue Jun  7 09:19:11 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 7 Jun 2016 15:19:11 +0200
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in WildFly
Message-ID: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>

Hi,

As discussed by some of us during the No ORM meeting in May, it'd be great
if there was a module ZIP allowing people to easily upgrade Hibernate ORM
in the WildFly version they are using.

Just the other day there was a blog post published [1] describing how to
use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
existing module.xml files. We could do better than that, leaving the
original version intact and providing a new one with a specific slot
("5.2") in the ZIP.

That'd also be helpful for other projects such as Hibernate OGM which
already provide a module ZIP for WF but currently need to package ORM, too,
in case they need features from a later ORM version.

If we all agree that's a good thing to have, I can help with making it
happen.

Thanks,

--Gunnar

[1]
http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html

From emmanuel at hibernate.org  Tue Jun  7 09:20:09 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 7 Jun 2016 15:20:09 +0200
Subject: [hibernate-dev] Collection was not processed by flush()
In-Reply-To: <CAKnbemWXysiBcoESUxzpj16_7VQENqR52xD7Oj3+QQMVB1G5Og@mail.gmail.com>
References: <CAKnbemWXysiBcoESUxzpj16_7VQENqR52xD7Oj3+QQMVB1G5Og@mail.gmail.com>
Message-ID: <20160607132009.GF43559@hibernate.org>

We probably should change this message.
When was the last time this message was due to a bug in our logic?
I can't remember a time when this was the case personally.

Thoughts?

On Sun 2016-06-05 17:17, Petar Tahchiev wrote:
> Hello,
> 
> I'm using hibernate version 5.1.0.Final and spring-data-rest and I have a
> StockRepository which is exposed via rest and when I try to create a new
> stock entry I get the following exception:
> 
> 2016-06-05 17:02:43,917 org.hibernate.AssertionFailure
> [http-nio-127.0.0.1-8112-exec-2] ERROR: HHH000099: an assertion failure
> occured (this may indicate a bug in Hibernate, but is more likely due to
> unsafe use of the session): org.hibernate.AssertionFailure: collection [
> com.nemesis.platform.module.commerce.core.entity.i18n.CurrencyEntity.name]
> was not processed by flush()
> 2016-06-05 17:02:43,920
> org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/storefront].[repositoryRestDispatcherServlet]
> [http-nio-127.0.0.1-8112-exec-2] ERROR: Servlet.service() for servlet
> [repositoryRestDispatcherServlet] in context with path [/storefront] threw
> exception [Request processing failed; nested exception is
> org.springframework.transaction.TransactionSystemException: Could not
> commit JPA transaction; nested exception is
> javax.persistence.RollbackException: Error while committing the
> transaction] with root cause
> org.hibernate.AssertionFailure: collection [
> com.nemesis.platform.module.commerce.core.entity.i18n.CurrencyEntity.name]
> was not processed by flush()
>     at
> org.hibernate.engine.spi.CollectionEntry.postFlush(CollectionEntry.java:214)
>     at
> org.hibernate.event.internal.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:369)
>     at
> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:40)
>     at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1295)
>     at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:468)
>     at
> org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3135)
>     at
> org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2352)
>     at
> org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:485)
>     at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:147)
>     at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$100(JdbcResourceLocalTransactionCoordinatorImpl.java:38)
>     at
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:231)
>     at
> org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:65)
>     at
> org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:61)
>     at
> org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:517)
>     at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
>     at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
>     at sun.reflect.GeneratedMethodAccessor191.invoke(Unknown Source)
>     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
>     at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
>     at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
>     at
> org.springframework.batch.core.configuration.annotation.SimpleBatchConfiguration$PassthruAdvice.invoke(SimpleBatchConfiguration.java:127)
>     at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
>     at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
>     at com.sun.proxy.$Proxy349.commit(Unknown Source)
>     at
> org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:485)
>     at
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291)
>     at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
>     at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
>     at
> org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
>     at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
>     at
> org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:131)
>     at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
>     at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
>     at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
>     at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
>     at com.sun.proxy.$Proxy304.save(Unknown Source)
>     at
> org.springframework.data.repository.support.CrudRepositoryInvoker.invokeSave(CrudRepositoryInvoker.java:100)
>     at
> org.springframework.data.rest.core.support.UnwrappingRepositoryInvokerFactory$UnwrappingRepositoryInvoker.invokeSave(UnwrappingRepositoryInvokerFactory.java:225)
>     at
> org.springframework.data.querydsl.QuerydslRepositoryInvokerAdapter.invokeSave(QuerydslRepositoryInvokerAdapter.java:158)
>     at
> org.springframework.data.rest.webmvc.RepositoryEntityController.createAndReturn(RepositoryEntityController.java:514)
>     at
> org.springframework.data.rest.webmvc.RepositoryEntityController.postCollectionResource(RepositoryEntityController.java:276)
>     at sun.reflect.GeneratedMethodAccessor325.invoke(Unknown Source)
>     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
>     at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
>     at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
>     at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:832)
>     at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:743)
>     at
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
>     at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:961)
>     at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:895)
>     at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:967)
>     at
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:869)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
>     at
> org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.boot.actuate.autoconfigure.EndpointWebMvcAutoConfiguration$ApplicationContextHeaderFilter.doFilterInternal(EndpointWebMvcAutoConfiguration.java:261)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.web.filter.CorsFilter.doFilterInternal(CorsFilter.java:92)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:115)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:316)
>     at
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:126)
>     at
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:90)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:114)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:122)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:48)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:158)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> com.nemesis.platform.core.filter.RestAuthenticationFilter.doFilterInternal(RestAuthenticationFilter.java:70)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:120)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:91)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:53)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
>     at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:213)
>     at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
>     at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
>     at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:87)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:77)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> com.nemesis.platform.module.cms.storefront.filter.PathLocaleFilter.doFilterInternal(PathLocaleFilter.java:87)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:126)
>     at
> org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:65)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.web.filter.CorsFilter.doFilterInternal(CorsFilter.java:92)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.springframework.boot.actuate.autoconfigure.MetricsFilter.doFilterInternal(MetricsFilter.java:103)
>     at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
>     at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
>     at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
>     at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
>     at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
>     at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
>     at
> org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:676)
>     at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
>     at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
>     at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
>     at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
>     at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095)
>     at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
>     at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1502)
>     at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1458)
>     at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>     at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>     at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>     at java.lang.Thread.run(Thread.java:745)
> 
> 
> I'm writing here because the message says this might indicate a bug in
> hibernate.
> 
> -- 
> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Jun  7 09:20:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 07 Jun 2016 13:20:38 +0000
Subject: [hibernate-dev] Stream result change proposal
In-Reply-To: <CAL00eSRh8zXOB6-RXQYxvRnyOQFqekLahR_M0CCCEDAV1fv_3w@mail.gmail.com>
References: <CA+gWKMDVwbAeWpaAnH57eYp_XhASZ=roAKZFUK4m4vAeLatfeA@mail.gmail.com>
	<CA+gWKMC6zW240UDBMcM=sYk8Z8a=ddp4mH9BLzGxk8wUJ-bz4g@mail.gmail.com>
	<CAL00eSRh8zXOB6-RXQYxvRnyOQFqekLahR_M0CCCEDAV1fv_3w@mail.gmail.com>
Message-ID: <CAFdSV9u325sNDMzX7i41eiE8QzAt_fHYEf67Adv50U7i-OH5sg@mail.gmail.com>

So long as we limit that to the Stream access, +1

On Tue, Jun 7, 2016 at 5:07 AM andrea boriero <andrea at hibernate.org> wrote:

> it sounds reasonable to me
>
> On 7 June 2016 at 10:57, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
> > To get a picture of why we need this, consider the following example from
> > the docs:
> >
> > Stream<Object[]> persons = session.createQuery(
> >    "select p " +
> >    "from Person p " +
> >    "where p.name like :name" )
> > .setParameter( "name", "J%" )
> > .stream();
> >
> > Map<Phone, List<Call>> callRegistry = persons
> >    .map( row -> Person.class.cast( row[0] ) )
> >    .flatMap( person -> person.getPhones().stream() )
> >    .flatMap( phone -> phone.getCalls().stream() )
> >    .collect(Collectors.groupingBy(Call::getPhone));
> >
> >
> > The .map( row -> Person.class.cast( row[0] ) ) call should be avoided and
> > we should return a Stream<Person> in this case.
> >
> > Vlad
> >
> > On Tue, Jun 7, 2016 at 12:50 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > While writing documentation for the new 5.2 Query.stream() API, I
> > realized
> > > that we don't return a Stream<T>, but a Stream<Object[]> which could
> > > confuse users.
> > > This is because ScrollableResultsImpl does something like this:
> > >
> > > if ( result != null && result.getClass().isArray() ) {
> > >    currentRow = (Object[]) result;
> > > }
> > > else {
> > >    currentRow = new Object[] {result};
> > > }
> > >
> > > The result is the actual entity that we queries, while the currentRow
> is
> > an Object[].
> > >
> > > I think we might want to change the stream result so that we return the
> > result for each available entry.
> > >
> > > Vlad
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From steve at hibernate.org  Tue Jun  7 09:25:30 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 07 Jun 2016 13:25:30 +0000
Subject: [hibernate-dev] Collection was not processed by flush()
In-Reply-To: <20160607132009.GF43559@hibernate.org>
References: <CAKnbemWXysiBcoESUxzpj16_7VQENqR52xD7Oj3+QQMVB1G5Og@mail.gmail.com>
	<20160607132009.GF43559@hibernate.org>
Message-ID: <CAFdSV9tOfiqvOrTxAvZa=kp=3CuC1e+7p+yhuij_wkuyavTm=Q@mail.gmail.com>

I agree that the wording should be changed.  That sentiment is true of
many, many exceptions.


On Tue, Jun 7, 2016 at 8:21 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> We probably should change this message.
> When was the last time this message was due to a bug in our logic?
> I can't remember a time when this was the case personally.
>
> Thoughts?
>
> On Sun 2016-06-05 17:17, Petar Tahchiev wrote:
> > Hello,
> >
> > I'm using hibernate version 5.1.0.Final and spring-data-rest and I have a
> > StockRepository which is exposed via rest and when I try to create a new
> > stock entry I get the following exception:
> >
> > 2016-06-05 17:02:43,917 org.hibernate.AssertionFailure
> > [http-nio-127.0.0.1-8112-exec-2] ERROR: HHH000099: an assertion failure
> > occured (this may indicate a bug in Hibernate, but is more likely due to
> > unsafe use of the session): org.hibernate.AssertionFailure: collection [
> >
> com.nemesis.platform.module.commerce.core.entity.i18n.CurrencyEntity.name]
> > was not processed by flush()
> > 2016-06-05 17:02:43,920
> >
> org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/storefront].[repositoryRestDispatcherServlet]
> > [http-nio-127.0.0.1-8112-exec-2] ERROR: Servlet.service() for servlet
> > [repositoryRestDispatcherServlet] in context with path [/storefront]
> threw
> > exception [Request processing failed; nested exception is
> > org.springframework.transaction.TransactionSystemException: Could not
> > commit JPA transaction; nested exception is
> > javax.persistence.RollbackException: Error while committing the
> > transaction] with root cause
> > org.hibernate.AssertionFailure: collection [
> >
> com.nemesis.platform.module.commerce.core.entity.i18n.CurrencyEntity.name]
> > was not processed by flush()
> >     at
> >
> org.hibernate.engine.spi.CollectionEntry.postFlush(CollectionEntry.java:214)
> >     at
> >
> org.hibernate.event.internal.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:369)
> >     at
> >
> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:40)
> >     at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1295)
> >     at
> org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:468)
> >     at
> >
> org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3135)
> >     at
> >
> org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2352)
> >     at
> >
> org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:485)
> >     at
> >
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:147)
> >     at
> >
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$100(JdbcResourceLocalTransactionCoordinatorImpl.java:38)
> >     at
> >
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:231)
> >     at
> >
> org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:65)
> >     at
> >
> org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:61)
> >     at
> >
> org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:517)
> >     at
> >
> org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
> >     at
> >
> org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
> >     at sun.reflect.GeneratedMethodAccessor191.invoke(Unknown Source)
> >     at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >     at java.lang.reflect.Method.invoke(Method.java:498)
> >     at
> >
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
> >     at
> >
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
> >     at
> >
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> >     at
> >
> org.springframework.batch.core.configuration.annotation.SimpleBatchConfiguration$PassthruAdvice.invoke(SimpleBatchConfiguration.java:127)
> >     at
> >
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> >
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
> >     at com.sun.proxy.$Proxy349.commit(Unknown Source)
> >     at
> >
> org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:485)
> >     at
> >
> org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291)
> >     at
> >
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> >     at
> >
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> >
> org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
> >     at
> >
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> >
> org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:131)
> >     at
> >
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> >
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> >     at
> >
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> >
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
> >     at com.sun.proxy.$Proxy304.save(Unknown Source)
> >     at
> >
> org.springframework.data.repository.support.CrudRepositoryInvoker.invokeSave(CrudRepositoryInvoker.java:100)
> >     at
> >
> org.springframework.data.rest.core.support.UnwrappingRepositoryInvokerFactory$UnwrappingRepositoryInvoker.invokeSave(UnwrappingRepositoryInvokerFactory.java:225)
> >     at
> >
> org.springframework.data.querydsl.QuerydslRepositoryInvokerAdapter.invokeSave(QuerydslRepositoryInvokerAdapter.java:158)
> >     at
> >
> org.springframework.data.rest.webmvc.RepositoryEntityController.createAndReturn(RepositoryEntityController.java:514)
> >     at
> >
> org.springframework.data.rest.webmvc.RepositoryEntityController.postCollectionResource(RepositoryEntityController.java:276)
> >     at sun.reflect.GeneratedMethodAccessor325.invoke(Unknown Source)
> >     at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >     at java.lang.reflect.Method.invoke(Method.java:498)
> >     at
> >
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
> >     at
> >
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
> >     at
> >
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
> >     at
> >
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:832)
> >     at
> >
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:743)
> >     at
> >
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
> >     at
> >
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:961)
> >     at
> >
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:895)
> >     at
> >
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:967)
> >     at
> >
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:869)
> >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
> >     at
> >
> org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843)
> >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.boot.actuate.autoconfigure.EndpointWebMvcAutoConfiguration$ApplicationContextHeaderFilter.doFilterInternal(EndpointWebMvcAutoConfiguration.java:261)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.web.filter.CorsFilter.doFilterInternal(CorsFilter.java:92)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:115)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:316)
> >     at
> >
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:126)
> >     at
> >
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:90)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:114)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:122)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:48)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:158)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> com.nemesis.platform.core.filter.RestAuthenticationFilter.doFilterInternal(RestAuthenticationFilter.java:70)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:120)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:91)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:53)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> >
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:213)
> >     at
> >
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
> >     at
> >
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
> >     at
> >
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:87)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:77)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> com.nemesis.platform.module.cms.storefront.filter.PathLocaleFilter.doFilterInternal(PathLocaleFilter.java:87)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:126)
> >     at
> >
> org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:65)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.web.filter.CorsFilter.doFilterInternal(CorsFilter.java:92)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.springframework.boot.actuate.autoconfigure.MetricsFilter.doFilterInternal(MetricsFilter.java:103)
> >     at
> >
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> >     at
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> >     at
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> >     at
> > org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:676)
> >     at
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> >     at
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> >     at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> >     at
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
> >     at
> >
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095)
> >     at
> >
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
> >     at
> > org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1502)
> >     at
> > org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.run(NioEndpoint.java:1458)
> >     at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >     at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >     at
> >
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> >     at java.lang.Thread.run(Thread.java:745)
> >
> >
> > I'm writing here because the message says this might indicate a bug in
> > hibernate.
> >
> > --
> > 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
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From ljacomet at gmail.com  Tue Jun  7 09:30:38 2016
From: ljacomet at gmail.com (Louis Jacomet)
Date: Tue, 07 Jun 2016 13:30:38 +0000
Subject: [hibernate-dev] Jira issues to integrate in 5.1
In-Reply-To: <CA+gWKMDP4kdmRmDzgDQQAEYB2_8KezNPkHYvRFjh28LLGm7kbw@mail.gmail.com>
References: <CA+gWKMDP4kdmRmDzgDQQAEYB2_8KezNPkHYvRFjh28LLGm7kbw@mail.gmail.com>
Message-ID: <CANjx1tWJWHGSNHjNVP_wSnsgD2kyH2kdNLeeh-Emt7Eecdi5LQ@mail.gmail.com>

Hello,

What about backporting the JCache module?
Since JCache is Java 1.6, that could make it available to more users.
I believe there have been small API changes between 5.1 and 5.2 but still
the porting should be easy enough and I am willing to help for that.

Regards,
Louis

On Tue, Jun 7, 2016 at 8:47 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> Because 5.1 is the last version supporting 1.6, I think it's worth to
> integrate as many fixes as we can that are now only available on the 5.2
> branch.
>
> Therefore, I collected a list of issues so that you can tell me which ones
> you'd like me to cherry pick on 5.1:
>
> https://hibernate.atlassian.net/browse/HHH-1594
> https://hibernate.atlassian.net/browse/HHH-7355
> https://hibernate.atlassian.net/browse/HHH-6781
> https://hibernate.atlassian.net/browse/HHH-10773
> https://hibernate.atlassian.net/browse/HHH-10754
> https://hibernate.atlassian.net/browse/HHH-9951
> https://hibernate.atlassian.net/browse/HHH-9894
>
> Thanks,
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From vm at sykora.cz  Tue Jun  7 09:50:26 2016
From: vm at sykora.cz (Vladimir Martinek)
Date: Tue, 7 Jun 2016 15:50:26 +0200
Subject: [hibernate-dev] Relations are not loaded when using Fetch
 Profiles
In-Reply-To: <CAFdSV9ugYcHoB0SbGUN87tLvXi5yVL7diT3Z-oLgciA8pu6YFQ@mail.gmail.com>
References: <57502A51.802@sykora.cz>
	<CAFDzhiRuTk22tmGtkc4LpL26LVV63-mFuz2JmdbrxBvA+M6OJw@mail.gmail.com>
	<575695EE.3050807@sykora.cz>
	<CAFdSV9ugYcHoB0SbGUN87tLvXi5yVL7diT3Z-oLgciA8pu6YFQ@mail.gmail.com>
Message-ID: <5756D122.7070306@sykora.cz>

Hello,

actually I would like to learn how the FetchMode.JOIN is supposed to 
work in case of cycles (not really cycles but MetamodelGraphWalker 
considers them cycles).

Check the test case please - it gets LazyInitializationException on a 
relation despite that relation being marked as JOIN FETCH in the fetch 
profile.

How is this intended to work? Is it a problem of MetamodelGraphWalker 
and its cycle detection? Or is it planned limitation of FetchMode.JOIN?

I can help to fix this, but in order to do that I need to know how this 
is expected to work.

Please disregard EAGER. I only mentioned FetchType.EAGER because I 
noticed it can cope with the same cyclic relations - and yes, you are 
right, those are fetched in subsequent selects. But we can't use EAGER 
(performance reasons).

Thank you

Vladimir




On 06/07/2016 03:05 PM, Steve Ebersole wrote:
> There is a huge difference in join-fetch and what we detail for 
> "EAGER".  Join-fetch is also an eager fetch. There are 2 pieces of 
> information in regards to fetching: when, how?
>
> EAGER merely describes when: now.
>
> What you describe as "EAGER" is really a N+1 fetch.  So the relation 
> is fetched immediately, but as "subsequent select". A join-fetch is 
> still EAGER, but now the relation is fetch via join in the initial 
> query. Very different behavior.
>
> On Tue, Jun 7, 2016 at 4:38 AM Vladimir Martinek <vm at sykora.cz 
> <mailto:vm at sykora.cz>> wrote:
>
>     HHH-10745, runnable test case attached to that issue
>     (org.hibernate.test.fetchprofiles.cycle.tar.gz).
>
>     Thank you
>
>     Vladimir
>
>
>
>     On 06/07/2016 06:00 AM, Gail Badner wrote:
>     > Please create a Jira issue and attach a runnable test case.
>     > Thanks,
>     > Gail
>     >
>     > On Thu, Jun 2, 2016 at 5:45 AM, Vladimir Martinek <vm at sykora.cz
>     <mailto:vm at sykora.cz>
>     > <mailto:vm at sykora.cz <mailto:vm at sykora.cz>>> wrote:
>     >
>     >     Fetch profiles fail to load certain relations because of
>     invalid cycle
>     >     detection in MetamodelGraphWalker. Below is an example.
>     >
>     >     I have compared the behaviour of Fetch Profiles and standard
>     EAGER
>     >     relations (EAGER does not suffer from this problem). The
>     >     MetamodelGraphWalker graph walker produces the same results, the
>     >     SQL is
>     >     the same (missing relation).
>     >
>     >     With EAGER the relation is loaded in second pass, via
>     >     SessionImpl.internalLoad(). There it is decided what LoadType is
>     >     used -
>     >     for eager it uses INTERNAL_LOAD_EAGER, for lazy
>     INTERNAL_LOAD_LAZY. It
>     >     does not take into account the fetch profiles here!
>     >
>     >     The last place I can get hold of fetch profiles in in
>     >     AbstractLoadPlanBasedEntityLoader line 82. After that the fetch
>     >     profile
>     >     information is lost, never making it anywhere near to
>     >     SessionImpl.internalLoad().
>     >
>     >     I would like to implement this, but to do that, I need
>     someone to
>     >     point
>     >     me in the right direction. Most of all I need answers to
>     following
>     >     questions:
>     >
>     >     1) Is it right to assume the fetch profiles should be
>     evaluated in
>     >     SessionImpl.internalLoad() and appropriate LoadType used when
>     >     detected a
>     >     relation affected by a fetch profile?
>     >     2) If so, what is the intended way of getting the fetch profile
>     >     information to SessionImpl.internalLoad()?
>     >
>     >     Also, a colleague of mine attempted to implement
>     FetchType.SELECT
>     >     fetch
>     >     strategy and ended up with precisely the same problem. I believe
>     >     solving
>     >     my issue would pave way for quick FetchType.SELECT
>     implementation
>     >     (which
>     >     we could also use on our project).
>     >
>     >
>     >     Thank you
>     >
>     >     Vladimir Martinek
>     >
>     >
>     >     Example:
>     >
>     >     Have 5 entities - Start, Via1, Via2, Mid and Finish with
>     following
>     >     relations (all LAZY):
>     >
>     >     Start n:1 Via1 n:1 Mid n:1 Finish
>     >     Start n:1 Via2 n:1 Mid n:1 Finish
>     >
>     >     Now, trying to use Fetch Profiles to load Start entity and
>     all of its
>     >     relations. I would expect Hibernate to execute following SQL
>     select:
>     >
>     >     SELECT * FROM Start s
>     >     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>     >     LEFT OUTER JOIN Mid
>     >     JOIN Finish
>     >
>     >     LEFT OUTER JOIN Via2 (path Start-Via2)
>     >     LEFT OUTER JOIN Mid
>     >     JOIN Finish
>     >
>     >     Unfortunately, ii ompletely omits the second join from Mid
>     to Finish,
>     >     what I am getting is:
>     >
>     >     SELECT * FROM Start s
>     >     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>     >     LEFT OUTER JOIN Mid
>     >     JOIN Finish
>     >
>     >     LEFT OUTER JOIN Via2 (path Start-Via2)
>     >     LEFT OUTER JOIN Mid
>     >
>     >     I dug deeper into this and found cycle detection in
>     >     MetamodelGraphWalker, line 144. Basically, when
>     MetamodelGraphWalker
>     >     detects a relation that has already been visited, it
>     considers it a
>     >     cycle. But in my case it is not a cycle - I just came to the
>     same
>     >     relation twice using two different paths.
>     >
>     >
>     >     _______________________________________________
>     >     hibernate-dev mailing list
>     > hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     >
>     >
>
>
>     --
>
>     *Ing. Vladim?r Martinek*
>     Programmer
>
>     T: +420 723 908 968
>     @: vm at sykora.cz <mailto:vm at sykora.cz>
>
>     Sykora Data Center s.r.o.
>     28. ??jna 1512/123, 702 00 Ostrava
>     www.sykora.cz <http://www.sykora.cz>
>
>     _______________________________________________
>     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
>


-- 

*Ing. Vladim?r Martinek*
Programmer

T: +420 723 908 968
@: vm at sykora.cz

Sykora Data Center s.r.o.
28. ??jna 1512/123, 702 00 Ostrava
www.sykora.cz


From steve at hibernate.org  Tue Jun  7 09:51:37 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 07 Jun 2016 13:51:37 +0000
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
Message-ID: <CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>

Too bad we can't just publish a Docker image.

Is this something we'd publish somewhere (Nexus/Artifactory)?  I know
nothing about building a WF module ZIP.  But if you are willing to do the
work and it helps OGM etc, of course we would incorporate it.

On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> As discussed by some of us during the No ORM meeting in May, it'd be great
> if there was a module ZIP allowing people to easily upgrade Hibernate ORM
> in the WildFly version they are using.
>
> Just the other day there was a blog post published [1] describing how to
> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
> existing module.xml files. We could do better than that, leaving the
> original version intact and providing a new one with a specific slot
> ("5.2") in the ZIP.
>
> That'd also be helpful for other projects such as Hibernate OGM which
> already provide a module ZIP for WF but currently need to package ORM, too,
> in case they need features from a later ORM version.
>
> If we all agree that's a good thing to have, I can help with making it
> happen.
>
> Thanks,
>
> --Gunnar
>
> [1]
> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From guillaume.smet at gmail.com  Tue Jun  7 09:55:36 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 7 Jun 2016 15:55:36 +0200
Subject: [hibernate-dev] NoORM IRC meeting transcripts
Message-ID: <CALt0+o-_p7oG-QswS3i6=x07gzNefV8W1f979sMZupTmZri8Zg@mail.gmail.com>

Hi everyone!

Here are the transcripts of this week's NoORM IRC meeting:
15:54 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-07-13.04.html
15:54 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-07-13.04.txt
15:54 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-07-13.04.log.html

See you next time!

-- 
Guillaume

From steve at hibernate.org  Tue Jun  7 13:49:26 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 07 Jun 2016 17:49:26 +0000
Subject: [hibernate-dev] 5.2 or 6.0
Message-ID: <CAFdSV9v5m9kmgd-wyRRWCg062W1EyNFvh5OAZqj0PSp6r_LU9w@mail.gmail.com>

Currently we are still working on 6.0 "on top" of 5.2, meaning that all of
the changes we are proposing to ORM for 6.0 are kept in a separate
repo/project using ORM 5.2 as a dependency.

As I work on 6.0 I have come across a change that I would like to make that
requires that I change something in ORM proper.  The specific change is
that I would like to remove static access
to org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry
and org.hibernate.type.descriptor.java.JavaTypeDescriptorRegistry and have
these scoped as part of the SessionFactory instead (technically as part of
the org.hibernate.metamodel.internal.MetamodelImpl associated with a
SessionFactory).

There are 2 ways I can go about this:

   1. branch 5.2 and start 6.0 dev on master
   2. make this change in master for inclusion in both 5.2 and 6.0

(2) is certainly the more convenient approach.  But even beyond convenient,
I have seen some bugs from the fact that these are statically typed -
theoretically they should be scoped to the SF since the SF can mutate them.

However making that change in 5.2 has some risks depending upon whether
apps/integrations use it.  Anyone aware of any integration(s) accessing
these 2 registries?

From gunnar at hibernate.org  Wed Jun  8 02:50:33 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 8 Jun 2016 08:50:33 +0200
Subject: [hibernate-dev] 5.2 or 6.0
In-Reply-To: <CAFdSV9v5m9kmgd-wyRRWCg062W1EyNFvh5OAZqj0PSp6r_LU9w@mail.gmail.com>
References: <CAFdSV9v5m9kmgd-wyRRWCg062W1EyNFvh5OAZqj0PSp6r_LU9w@mail.gmail.com>
Message-ID: <CADGJaX9ir8rF-x6oGk+Vi8muec_8XFEh3EG0mq8WvHXcVxYvUg@mail.gmail.com>

JavaTypeDescriptorRegistry is used by Hibernate OGM in
(o.h.o.type.impl.TypeTranslatorImpl).

>From my side, the proposed change is good, esp. if it fixes some existing
bugs. It'd lock down OGM to a specific minor of ORM, but that'll happen
anyways once we make use of the changes around schema tooling done in ORM
5.1.

--Gunnar


2016-06-07 19:49 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Currently we are still working on 6.0 "on top" of 5.2, meaning that all of
> the changes we are proposing to ORM for 6.0 are kept in a separate
> repo/project using ORM 5.2 as a dependency.
>
> As I work on 6.0 I have come across a change that I would like to make that
> requires that I change something in ORM proper.  The specific change is
> that I would like to remove static access
> to org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry
> and org.hibernate.type.descriptor.java.JavaTypeDescriptorRegistry and have
> these scoped as part of the SessionFactory instead (technically as part of
> the org.hibernate.metamodel.internal.MetamodelImpl associated with a
> SessionFactory).
>
> There are 2 ways I can go about this:
>
>    1. branch 5.2 and start 6.0 dev on master
>    2. make this change in master for inclusion in both 5.2 and 6.0
>
> (2) is certainly the more convenient approach.  But even beyond convenient,
> I have seen some bugs from the fact that these are statically typed -
> theoretically they should be scoped to the SF since the SF can mutate them.
>
> However making that change in 5.2 has some risks depending upon whether
> apps/integrations use it.  Anyone aware of any integration(s) accessing
> these 2 registries?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Jun  8 03:09:04 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 8 Jun 2016 10:09:04 +0300
Subject: [hibernate-dev] Regarding release versioning
Message-ID: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>

Hi,

I have seen the frustration from the Spring Data team trying to keep up
with our code changes that break their integrations,
and I was wondering if we should use some Release candidates prior to
releasing a start of a branch, even if it's a minor one.
This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like
that to mark it as an intermediary release that's aimed for early
adopters/integrators.

Do you think this is feasible or is there something to prevent us from
doing this?

Vlad

From gunnar at hibernate.org  Wed Jun  8 03:11:25 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 8 Jun 2016 09:11:25 +0200
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
Message-ID: <CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>

2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Too bad we can't just publish a Docker image.
>

We could do that, but I think we should have a solution for non-Docker
users, too.

>
> Is this something we'd publish somewhere (Nexus/Artifactory)?
>

Yes, we'd publish it in Nexus and also BinTray/SourceForge.

People would download it, unzip it into the "modules" directory of their WF
instance and could start using the new ORM version (provided the larger
scheme of integration hasn't changed, so the JipiJapa bits in WF continue
to work as is).


>   I know nothing about building a WF module ZIP.  But if you are willing
> to do the work and it helps OGM etc, of course we would incorporate it.
>

Ok, cool. I'll take a look then.

On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Hi,
>>
>> As discussed by some of us during the No ORM meeting in May, it'd be great
>> if there was a module ZIP allowing people to easily upgrade Hibernate ORM
>> in the WildFly version they are using.
>>
>> Just the other day there was a blog post published [1] describing how to
>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
>> existing module.xml files. We could do better than that, leaving the
>> original version intact and providing a new one with a specific slot
>> ("5.2") in the ZIP.
>>
>> That'd also be helpful for other projects such as Hibernate OGM which
>> already provide a module ZIP for WF but currently need to package ORM,
>> too,
>> in case they need features from a later ORM version.
>>
>> If we all agree that's a good thing to have, I can help with making it
>> happen.
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>>
>> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From vm at sykora.cz  Wed Jun  8 03:28:51 2016
From: vm at sykora.cz (Vladimir Martinek)
Date: Wed, 8 Jun 2016 09:28:51 +0200
Subject: [hibernate-dev] Relations are not loaded when using Fetch
 Profiles
In-Reply-To: <CAFdSV9uJ_J+yZNkBs4VBso-Nf1gaB8HYjE2WLsU8A0UJ5+beEQ@mail.gmail.com>
References: <57502A51.802@sykora.cz>
	<CAFDzhiRuTk22tmGtkc4LpL26LVV63-mFuz2JmdbrxBvA+M6OJw@mail.gmail.com>
	<575695EE.3050807@sykora.cz>
	<CAFdSV9ugYcHoB0SbGUN87tLvXi5yVL7diT3Z-oLgciA8pu6YFQ@mail.gmail.com>
	<5756D122.7070306@sykora.cz>
	<CAFdSV9uJ_J+yZNkBs4VBso-Nf1gaB8HYjE2WLsU8A0UJ5+beEQ@mail.gmail.com>
Message-ID: <5757C933.2090702@sykora.cz>

MetamodelGraphWalker line 144. My relation is in 
MetamodelGraphWalker.visitedAssociationKeys, so it gets skipped and thus 
not make it in the final big SQL SELECT.

Why don't you take a look at the test case I provided - just run it and 
see the LazyInitializationException error, it will all be instantly 
clear.  I am talking about LAZY relations in combination with 
FetchProfile using FetchMode.JOIN. Please disregard EAGER (for now, we 
may come to that later once we agree on what is the problem :)

We prefer to have all relations LAZY on our project (performance 
reasons) and use FetchProfiles. The actual FetchMode (whether it is 
JOIN, SELECT) does not matter to us, all we need is the relations to be 
loaded in single EntityManager.find call. Unfortunately the only 
FetchMode implemented now is JOIN and that one has this unpleasant bug 
in it.

Thank you

Vladimir


On 06/07/2016 04:01 PM, Steve Ebersole wrote:
> MetamodelGraphWalker does not consider them cycles.  Where do you see 
> MetamodelGraphWalker making that decision? MetamodelGraphWalker simply 
> walks your model mappings.  It delegates to pluggable strategies.  So 
> I assume you really mean one of the AssociationVisitationStrategy 
> implementations is considering them cycles.  And even then I am not so 
> sure that is what happens...
>
> So to be clear we are talking about 2 different EAGER fetch strategies 
> here: join and select.
>
> For join, we'd build one big SQL SELECT joining the relations 
> together. You can see this by switching your associations from lazy to 
> all being eager and specifying join fetching.
>
> For select, we'd build one SQL SELECT for the root entity being loaded 
> (and any join fetched relations).  From there, any select-fetched 
> relations would be loaded individually by separate select (that's kind 
> of the definition of N+1).
>
>
>
> On Tue, Jun 7, 2016 at 8:50 AM Vladimir Martinek <vm at sykora.cz 
> <mailto:vm at sykora.cz>> wrote:
>
>     Hello,
>
>     actually I would like to learn how the FetchMode.JOIN is supposed
>     to work in case of cycles (not really cycles but
>     MetamodelGraphWalker considers them cycles).
>
>     Check the test case please - it gets LazyInitializationException
>     on a relation despite that relation being marked as JOIN FETCH in
>     the fetch profile.
>
>     How is this intended to work? Is it a problem of
>     MetamodelGraphWalker and its cycle detection? Or is it planned
>     limitation of FetchMode.JOIN?
>
>     I can help to fix this, but in order to do that I need to know how
>     this is expected to work.
>
>     Please disregard EAGER. I only mentioned FetchType.EAGER because I
>     noticed it can cope with the same cyclic relations - and yes, you
>     are right, those are fetched in subsequent selects. But we can't
>     use EAGER (performance reasons).
>
>     Thank you
>
>     Vladimir
>
>
>
>
>
>     On 06/07/2016 03:05 PM, Steve Ebersole wrote:
>>     There is a huge difference in join-fetch and what we detail for
>>     "EAGER".  Join-fetch is also an eager fetch.  There are 2 pieces
>>     of information in regards to fetching: when, how?
>>
>>     EAGER merely describes when: now.
>>
>>     What you describe as "EAGER" is really a N+1 fetch.  So the
>>     relation is fetched immediately, but as "subsequent select".  A
>>     join-fetch is still EAGER, but now the relation is fetch via join
>>     in the initial query.  Very different behavior.
>>
>>     On Tue, Jun 7, 2016 at 4:38 AM Vladimir Martinek <vm at sykora.cz
>>     <mailto:vm at sykora.cz>> wrote:
>>
>>         HHH-10745, runnable test case attached to that issue
>>         (org.hibernate.test.fetchprofiles.cycle.tar.gz).
>>
>>         Thank you
>>
>>         Vladimir
>>
>>
>>
>>         On 06/07/2016 06:00 AM, Gail Badner wrote:
>>         > Please create a Jira issue and attach a runnable test case.
>>         > Thanks,
>>         > Gail
>>         >
>>         > On Thu, Jun 2, 2016 at 5:45 AM, Vladimir Martinek
>>         <vm at sykora.cz <mailto:vm at sykora.cz>
>>         > <mailto:vm at sykora.cz <mailto:vm at sykora.cz>>> wrote:
>>         >
>>         >     Fetch profiles fail to load certain relations because
>>         of invalid cycle
>>         >     detection in MetamodelGraphWalker. Below is an example.
>>         >
>>         >     I have compared the behaviour of Fetch Profiles and
>>         standard EAGER
>>         >     relations (EAGER does not suffer from this problem). The
>>         >     MetamodelGraphWalker graph walker produces the same
>>         results, the
>>         >     SQL is
>>         >     the same (missing relation).
>>         >
>>         >     With EAGER the relation is loaded in second pass, via
>>         >     SessionImpl.internalLoad(). There it is decided what
>>         LoadType is
>>         >     used -
>>         >     for eager it uses INTERNAL_LOAD_EAGER, for lazy
>>         INTERNAL_LOAD_LAZY. It
>>         >     does not take into account the fetch profiles here!
>>         >
>>         >     The last place I can get hold of fetch profiles in in
>>         >     AbstractLoadPlanBasedEntityLoader line 82. After that
>>         the fetch
>>         >     profile
>>         >     information is lost, never making it anywhere near to
>>         >     SessionImpl.internalLoad().
>>         >
>>         >     I would like to implement this, but to do that, I need
>>         someone to
>>         >     point
>>         >     me in the right direction. Most of all I need answers
>>         to following
>>         >     questions:
>>         >
>>         >     1) Is it right to assume the fetch profiles should be
>>         evaluated in
>>         >     SessionImpl.internalLoad() and appropriate LoadType
>>         used when
>>         >     detected a
>>         >     relation affected by a fetch profile?
>>         >     2) If so, what is the intended way of getting the fetch
>>         profile
>>         >     information to SessionImpl.internalLoad()?
>>         >
>>         >     Also, a colleague of mine attempted to implement
>>         FetchType.SELECT
>>         >     fetch
>>         >     strategy and ended up with precisely the same problem.
>>         I believe
>>         >     solving
>>         >     my issue would pave way for quick FetchType.SELECT
>>         implementation
>>         >     (which
>>         >     we could also use on our project).
>>         >
>>         >
>>         >     Thank you
>>         >
>>         >     Vladimir Martinek
>>         >
>>         >
>>         >     Example:
>>         >
>>         >     Have 5 entities - Start, Via1, Via2, Mid and Finish
>>         with following
>>         >     relations (all LAZY):
>>         >
>>         >     Start n:1 Via1 n:1 Mid n:1 Finish
>>         >     Start n:1 Via2 n:1 Mid n:1 Finish
>>         >
>>         >     Now, trying to use Fetch Profiles to load Start entity
>>         and all of its
>>         >     relations. I would expect Hibernate to execute
>>         following SQL select:
>>         >
>>         >     SELECT * FROM Start s
>>         >     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>>         >     LEFT OUTER JOIN Mid
>>         >     JOIN Finish
>>         >
>>         >     LEFT OUTER JOIN Via2 (path Start-Via2)
>>         >     LEFT OUTER JOIN Mid
>>         >     JOIN Finish
>>         >
>>         >     Unfortunately, ii ompletely omits the second join from
>>         Mid to Finish,
>>         >     what I am getting is:
>>         >
>>         >     SELECT * FROM Start s
>>         >     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>>         >     LEFT OUTER JOIN Mid
>>         >     JOIN Finish
>>         >
>>         >     LEFT OUTER JOIN Via2 (path Start-Via2)
>>         >     LEFT OUTER JOIN Mid
>>         >
>>         >     I dug deeper into this and found cycle detection in
>>         >     MetamodelGraphWalker, line 144. Basically, when
>>         MetamodelGraphWalker
>>         >     detects a relation that has already been visited, it
>>         considers it a
>>         >     cycle. But in my case it is not a cycle - I just came
>>         to the same
>>         >     relation twice using two different paths.
>>         >
>>         >
>>         >  _______________________________________________
>>         >     hibernate-dev mailing list
>>         > hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>
>>         <mailto:hibernate-dev at lists.jboss.org
>>         <mailto:hibernate-dev at lists.jboss.org>>
>>         > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>         >
>>         >
>>
>>
>>         --
>>
>>         *Ing. Vladim?r Martinek*
>>         Programmer
>>
>>         T: +420 723 908 968
>>         @: vm at sykora.cz <mailto:vm at sykora.cz>
>>
>>         Sykora Data Center s.r.o.
>>         28. ??jna 1512/123, 702 00 Ostrava
>>         www.sykora.cz <http://www.sykora.cz>
>>
>>         _______________________________________________
>>         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
>>
>
>
>     -- 
>
>     *Ing. Vladim?r Martinek*
>     Programmer
>
>     T: +420 723 908 968
>     @: vm at sykora.cz <mailto:vm at sykora.cz>
>
>     Sykora Data Center s.r.o.
>     28. ??jna 1512/123, 702 00 Ostrava
>     www.sykora.cz <http://www.sykora.cz>
>


-- 

*Ing. Vladim?r Martinek*
Programmer

T: +420 723 908 968
@: vm at sykora.cz

Sykora Data Center s.r.o.
28. ??jna 1512/123, 702 00 Ostrava
www.sykora.cz


From emmanuel at hibernate.org  Wed Jun  8 03:31:41 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 8 Jun 2016 09:31:41 +0200
Subject: [hibernate-dev] 5.2 or 6.0
In-Reply-To: <CADGJaX9ir8rF-x6oGk+Vi8muec_8XFEh3EG0mq8WvHXcVxYvUg@mail.gmail.com>
References: <CAFdSV9v5m9kmgd-wyRRWCg062W1EyNFvh5OAZqj0PSp6r_LU9w@mail.gmail.com>
	<CADGJaX9ir8rF-x6oGk+Vi8muec_8XFEh3EG0mq8WvHXcVxYvUg@mail.gmail.com>
Message-ID: <E520BEC8-778C-4DD5-A29F-29DFB42BC2B6@hibernate.org>

Does the HQL to native query mechanic use this too?

> On 08 Jun 2016, at 08:50, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> JavaTypeDescriptorRegistry is used by Hibernate OGM in
> (o.h.o.type.impl.TypeTranslatorImpl).
> 
>> From my side, the proposed change is good, esp. if it fixes some existing
> bugs. It'd lock down OGM to a specific minor of ORM, but that'll happen
> anyways once we make use of the changes around schema tooling done in ORM
> 5.1.
> 
> --Gunnar
> 
> 
> 2016-06-07 19:49 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> 
>> Currently we are still working on 6.0 "on top" of 5.2, meaning that all of
>> the changes we are proposing to ORM for 6.0 are kept in a separate
>> repo/project using ORM 5.2 as a dependency.
>> 
>> As I work on 6.0 I have come across a change that I would like to make that
>> requires that I change something in ORM proper.  The specific change is
>> that I would like to remove static access
>> to org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry
>> and org.hibernate.type.descriptor.java.JavaTypeDescriptorRegistry and have
>> these scoped as part of the SessionFactory instead (technically as part of
>> the org.hibernate.metamodel.internal.MetamodelImpl associated with a
>> SessionFactory).
>> 
>> There are 2 ways I can go about this:
>> 
>>   1. branch 5.2 and start 6.0 dev on master
>>   2. make this change in master for inclusion in both 5.2 and 6.0
>> 
>> (2) is certainly the more convenient approach.  But even beyond convenient,
>> I have seen some bugs from the fact that these are statically typed -
>> theoretically they should be scoped to the SF since the SF can mutate them.
>> 
>> However making that change in 5.2 has some risks depending upon whether
>> apps/integrations use it.  Anyone aware of any integration(s) accessing
>> these 2 registries?
>> _______________________________________________
>> hibernate-dev mailing list
>> 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



From emmanuel at hibernate.org  Wed Jun  8 04:37:24 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 8 Jun 2016 10:37:24 +0200
Subject: [hibernate-dev] Collection was not processed by flush()
In-Reply-To: <CAFdSV9tOfiqvOrTxAvZa=kp=3CuC1e+7p+yhuij_wkuyavTm=Q@mail.gmail.com>
References: <CAKnbemWXysiBcoESUxzpj16_7VQENqR52xD7Oj3+QQMVB1G5Og@mail.gmail.com>
	<20160607132009.GF43559@hibernate.org>
	<CAFdSV9tOfiqvOrTxAvZa=kp=3CuC1e+7p+yhuij_wkuyavTm=Q@mail.gmail.com>
Message-ID: <2AB75149-37D1-4828-896F-AB7FF6EAD83A@hibernate.org>

My modest contribution

https://hibernate.atlassian.net/browse/HHH-10813
https://github.com/hibernate/hibernate-orm/pull/1408

Emmanuel

> On 07 Jun 2016, at 15:25, Steve Ebersole <steve at hibernate.org> wrote:
> 
> I agree that the wording should be changed.  That sentiment is true of many, many exceptions.
> 
> 
> On Tue, Jun 7, 2016 at 8:21 AM Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>> wrote:
> We probably should change this message.
> When was the last time this message was due to a bug in our logic?
> I can't remember a time when this was the case personally.
> 
> Thoughts?
> 
> On Sun 2016-06-05 17:17, Petar Tahchiev wrote:
> > Hello,
> >
> > I'm using hibernate version 5.1.0.Final and spring-data-rest and I have a
> > StockRepository which is exposed via rest and when I try to create a new
> > stock entry I get the following exception:
> >
> > 2016-06-05 17:02:43,917 org.hibernate.AssertionFailure
> > [http-nio-127.0.0.1-8112-exec-2] ERROR: HHH000099: an assertion failure
> > occured (this may indicate a bug in Hibernate, but is more likely due to
> > unsafe use of the session): org.hibernate.AssertionFailure: collection [
> > com.nemesis.platform.module.commerce.core.entity.i18n.CurrencyEntity.name <http://com.nemesis.platform.module.commerce.core.entity.i18n.currencyentity.name/>]
> > was not processed by flush()
> > 2016-06-05 17:02:43,920
> > org.apache.catalina.core.ContainerBase.[Tomcat].[localhost].[/storefront].[repositoryRestDispatcherServlet]
> > [http-nio-127.0.0.1-8112-exec-2] ERROR: Servlet.service() for servlet
> > [repositoryRestDispatcherServlet] in context with path [/storefront] threw
> > exception [Request processing failed; nested exception is
> > org.springframework.transaction.TransactionSystemException: Could not
> > commit JPA transaction; nested exception is
> > javax.persistence.RollbackException: Error while committing the
> > transaction] with root cause
> > org.hibernate.AssertionFailure: collection [
> > com.nemesis.platform.module.commerce.core.entity.i18n.CurrencyEntity.name <http://com.nemesis.platform.module.commerce.core.entity.i18n.currencyentity.name/>]
> > was not processed by flush()
> >     at
> > org.hibernate.engine.spi.CollectionEntry.postFlush(CollectionEntry.java:214)
> >     at
> > org.hibernate.event.internal.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:369)
> >     at
> > org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:40)
> >     at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1295)
> >     at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:468)
> >     at
> > org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3135)
> >     at
> > org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2352)
> >     at
> > org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:485)
> >     at
> > org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.beforeCompletionCallback(JdbcResourceLocalTransactionCoordinatorImpl.java:147)
> >     at
> > org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl.access$100(JdbcResourceLocalTransactionCoordinatorImpl.java:38)
> >     at
> > org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.commit(JdbcResourceLocalTransactionCoordinatorImpl.java:231)
> >     at
> > org.hibernate.engine.transaction.internal.TransactionImpl.commit(TransactionImpl.java:65)
> >     at
> > org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:61)
> >     at
> > org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:517)
> >     at
> > org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761)
> >     at
> > org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730)
> >     at sun.reflect.GeneratedMethodAccessor191.invoke(Unknown Source)
> >     at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >     at java.lang.reflect.Method.invoke(Method.java:498)
> >     at
> > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
> >     at
> > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
> >     at
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> >     at
> > org.springframework.batch.core.configuration.annotation.SimpleBatchConfiguration$PassthruAdvice.invoke(SimpleBatchConfiguration.java:127)
> >     at
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
> >     at com.sun.proxy.$Proxy349.commit(Unknown Source)
> >     at
> > org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:485)
> >     at
> > org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291)
> >     at
> > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> >     at
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> > org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
> >     at
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> > org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:131)
> >     at
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> >     at
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> >     at
> > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
> >     at com.sun.proxy.$Proxy304.save(Unknown Source)
> >     at
> > org.springframework.data.repository.support.CrudRepositoryInvoker.invokeSave(CrudRepositoryInvoker.java:100)
> >     at
> > org.springframework.data.rest.core.support.UnwrappingRepositoryInvokerFactory$UnwrappingRepositoryInvoker.invokeSave(UnwrappingRepositoryInvokerFactory.java:225)
> >     at
> > org.springframework.data.querydsl.QuerydslRepositoryInvokerAdapter.invokeSave(QuerydslRepositoryInvokerAdapter.java:158)
> >     at
> > org.springframework.data.rest.webmvc.RepositoryEntityController.createAndReturn(RepositoryEntityController.java:514)
> >     at
> > org.springframework.data.rest.webmvc.RepositoryEntityController.postCollectionResource(RepositoryEntityController.java:276)
> >     at sun.reflect.GeneratedMethodAccessor325.invoke(Unknown Source)
> >     at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >     at java.lang.reflect.Method.invoke(Method.java:498)
> >     at
> > org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
> >     at
> > org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
> >     at
> > org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110)
> >     at
> > org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:832)
> >     at
> > org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:743)
> >     at
> > org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
> >     at
> > org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:961)
> >     at
> > org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:895)
> >     at
> > org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:967)
> >     at
> > org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:869)
> >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
> >     at
> > org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:843)
> >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.boot.actuate.autoconfigure.EndpointWebMvcAutoConfiguration$ApplicationContextHeaderFilter.doFilterInternal(EndpointWebMvcAutoConfiguration.java:261)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.web.filter.CorsFilter.doFilterInternal(CorsFilter.java:92)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:115)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:316)
> >     at
> > org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:126)
> >     at
> > org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:90)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:114)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:122)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:48)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:158)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > com.nemesis.platform.core.filter.RestAuthenticationFilter.doFilterInternal(RestAuthenticationFilter.java:70)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:120)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:91)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:53)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
> >     at
> > org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:213)
> >     at
> > org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
> >     at
> > org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
> >     at
> > org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:87)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:77)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > com.nemesis.platform.module.cms.storefront.filter.PathLocaleFilter.doFilterInternal(PathLocaleFilter.java:87)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:126)
> >     at
> > org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:65)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.web.filter.CorsFilter.doFilterInternal(CorsFilter.java:92)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.springframework.boot.actuate.autoconfigure.MetricsFilter.doFilterInternal(MetricsFilter.java:103)
> >     at
> > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
> >     at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
> >     at
> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
> >     at
> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
> >     at
> > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> >     at
> > org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:676)
> >     at
> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
> >     at
> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> >     at
> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
> >     at
> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
> >     at
> > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095)
> >     at
> > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
> >     at
> > org.apache.tomcat.util.net <http://org.apache.tomcat.util.net/>.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1502)
> >     at
> > org.apache.tomcat.util.net <http://org.apache.tomcat.util.net/>.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1458)
> >     at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> >     at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> >     at
> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> >     at java.lang.Thread.run(Thread.java:745)
> >
> >
> > I'm writing here because the message says this might indicate a bug in
> > hibernate.
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 <http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611>
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> > _______________________________________________
> > 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 <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> _______________________________________________
> 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 <https://lists.jboss.org/mailman/listinfo/hibernate-dev>


From mihalcea.vlad at gmail.com  Wed Jun  8 07:46:49 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 8 Jun 2016 14:46:49 +0300
Subject: [hibernate-dev] SQL query interceptor
Message-ID: <CA+gWKMAVUt52xDJ3oXZY1E7Z_Uw0PPy_YaXYg-3Qp3OH+gYn4Q@mail.gmail.com>

Hi,

During testing, it's very useful to have an SQL query interceptor that we
can inspect to see if the generated SQL query contains a certain SQL clause.
There are multiple ways we could implement this kind of feature:

1. We could add a public String[] getSQLQueries(); in the Statistics
interface.
2. We could define a SQLStatementInterceptor interface that can be provided
via some configuration property.
   The SqlStatementLogger.logStatement could call the
SQLStatementInterceptor as well.
3. We could provide a way to provide a custom SQLStatementLogger class, so
that users can intercept statements via their custom SQLStatementLogger.

Currently, the only solution is to overwrite the sqlStatementLogger field
of the JdbcServicesImpl via Reflection, which is rather a hack.
What do you think?

Vlad

From sanne at hibernate.org  Wed Jun  8 08:55:00 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 8 Jun 2016 13:55:00 +0100
Subject: [hibernate-dev] Regarding release versioning
In-Reply-To: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
References: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
Message-ID: <CAFm4XO3X8maN5=0oybj_h5YjgxuYxpwfsjwzbcuTAGZ79NcttQ@mail.gmail.com>

+1

I've also hit some incompatible API changes which I only figured out
too late (when attempting to upgrade Hibernate Search).

I could have pre-tested snapshot builds but didn't have time for that
- and didn't expect 5.2 to be released without a Beta period, or I
would have made time for that.


On 8 June 2016 at 08:09, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> I have seen the frustration from the Spring Data team trying to keep up
> with our code changes that break their integrations,
> and I was wondering if we should use some Release candidates prior to
> releasing a start of a branch, even if it's a minor one.
> This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like
> that to mark it as an intermediary release that's aimed for early
> adopters/integrators.
>
> Do you think this is feasible or is there something to prevent us from
> doing this?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Wed Jun  8 09:19:14 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 8 Jun 2016 16:19:14 +0300
Subject: [hibernate-dev] RequiresDialects vs RequiresDialect
Message-ID: <CA+gWKMC0pULEpeDs6ymuMbObicCi+kwLssPEbNzh2HARoqP3PQ@mail.gmail.com>

Hi,

While writing a cross-dialect test, I bumped into the following issue:

https://hibernate.atlassian.net/browse/HHH-10814

The question is why do we have a @RequiresDialects annotation:

@RequiresDialects({
    @RequiresDialect(PostgreSQL81Dialect.class),
    @RequiresDialect(Oracle8iDialect.class)
})

when @RequiresDialect can take multiple dialects as well:

@RequiresDialect({ Oracle8iDialect.class, PostgreSQL81Dialect.class} )

Vlad

From andrea at hibernate.org  Wed Jun  8 09:31:36 2016
From: andrea at hibernate.org (andrea boriero)
Date: Wed, 8 Jun 2016 14:31:36 +0100
Subject: [hibernate-dev] RequiresDialects vs RequiresDialect
In-Reply-To: <CA+gWKMC0pULEpeDs6ymuMbObicCi+kwLssPEbNzh2HARoqP3PQ@mail.gmail.com>
References: <CA+gWKMC0pULEpeDs6ymuMbObicCi+kwLssPEbNzh2HARoqP3PQ@mail.gmail.com>
Message-ID: <CAL00eSTh-aghCw3LbSXsF=qS=Wx-3oAoC-vEmJQ0nKVpR2TbuA@mail.gmail.com>

the annotation was introduced with
https://hibernate.atlassian.net/browse/HHH-6841

the reason seems to provide the ability add different reasons for each
Dialect.

On 8 June 2016 at 14:19, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> While writing a cross-dialect test, I bumped into the following issue:
>
> https://hibernate.atlassian.net/browse/HHH-10814
>
> The question is why do we have a @RequiresDialects annotation:
>
> @RequiresDialects({
>     @RequiresDialect(PostgreSQL81Dialect.class),
>     @RequiresDialect(Oracle8iDialect.class)
> })
>
> when @RequiresDialect can take multiple dialects as well:
>
> @RequiresDialect({ Oracle8iDialect.class, PostgreSQL81Dialect.class} )
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jun  8 10:06:07 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jun 2016 14:06:07 +0000
Subject: [hibernate-dev] Regarding release versioning
In-Reply-To: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
References: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
Message-ID: <CAFdSV9t7ws6WMOMDayxKrxNyng7YuaqX9yjDu1bcDM2JFV4TTQ@mail.gmail.com>

Well the reasoning was discussed on this list and everyone agreed :)  It
was part of a larger discussion about releases and maintaining maintenance
branches.  But if everyone, I am ok with doing CR (only) for minor releases.

Part of the reasoning was that technically speaking a Final really ought to
be a simple retagging of the last CR.  But that is virtually impossible to
do without branching the minor release as soon as we cut the CR.  At the
very least we really cannot push commits to whatever branch holds the CR
until the Final.  That is all based on the principle that the "approved CR"
ought to be exactly the same as the Final it leads to.  If we are going
back to this then I vote that we also go for a hybrid approach to this
where Final is an approximation of the "approved CR", likely with
additional fixes.

On Wed, Jun 8, 2016 at 2:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I have seen the frustration from the Spring Data team trying to keep up
> with our code changes that break their integrations,
> and I was wondering if we should use some Release candidates prior to
> releasing a start of a branch, even if it's a minor one.
> This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like
> that to mark it as an intermediary release that's aimed for early
> adopters/integrators.
>
> Do you think this is feasible or is there something to prevent us from
> doing this?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jun  8 10:06:24 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jun 2016 14:06:24 +0000
Subject: [hibernate-dev] Regarding release versioning
In-Reply-To: <CAFm4XO3X8maN5=0oybj_h5YjgxuYxpwfsjwzbcuTAGZ79NcttQ@mail.gmail.com>
References: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
	<CAFm4XO3X8maN5=0oybj_h5YjgxuYxpwfsjwzbcuTAGZ79NcttQ@mail.gmail.com>
Message-ID: <CAFdSV9uTK=LZ_C91CB68v3yuan1ReRa0mopjZinWVxrCLURsGA@mail.gmail.com>

Sanne, you just said it.. the reason you did not test with 5.2 before it
was released is time.  Me doing a CR release does not change that.  The
stuff that "bit you" in 5.2 was available for testing for well over a month
prior to releasing 5.2.  And it's not like 5.2 was released without
discussion; heck we even pushed it back a few times to get a few extras
in.  All discussed on the dev list.

On Wed, Jun 8, 2016 at 7:55 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> +1
>
> I've also hit some incompatible API changes which I only figured out
> too late (when attempting to upgrade Hibernate Search).
>
> I could have pre-tested snapshot builds but didn't have time for that
> - and didn't expect 5.2 to be released without a Beta period, or I
> would have made time for that.
>
>
> On 8 June 2016 at 08:09, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> > Hi,
> >
> > I have seen the frustration from the Spring Data team trying to keep up
> > with our code changes that break their integrations,
> > and I was wondering if we should use some Release candidates prior to
> > releasing a start of a branch, even if it's a minor one.
> > This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like
> > that to mark it as an intermediary release that's aimed for early
> > adopters/integrators.
> >
> > Do you think this is feasible or is there something to prevent us from
> > doing this?
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From steve at hibernate.org  Wed Jun  8 10:07:25 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jun 2016 14:07:25 +0000
Subject: [hibernate-dev] SQL query interceptor
In-Reply-To: <CA+gWKMAVUt52xDJ3oXZY1E7Z_Uw0PPy_YaXYg-3Qp3OH+gYn4Q@mail.gmail.com>
References: <CA+gWKMAVUt52xDJ3oXZY1E7Z_Uw0PPy_YaXYg-3Qp3OH+gYn4Q@mail.gmail.com>
Message-ID: <CAFdSV9vfC3Lo5AqDvbbiqcXg2Vt7QJDtzWvAj_WPp_ZrxMi-GA@mail.gmail.com>

You mean like a org.hibernate.resource.jdbc.spi.StatementInspector?

On Wed, Jun 8, 2016 at 6:47 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> During testing, it's very useful to have an SQL query interceptor that we
> can inspect to see if the generated SQL query contains a certain SQL
> clause.
> There are multiple ways we could implement this kind of feature:
>
> 1. We could add a public String[] getSQLQueries(); in the Statistics
> interface.
> 2. We could define a SQLStatementInterceptor interface that can be provided
> via some configuration property.
>    The SqlStatementLogger.logStatement could call the
> SQLStatementInterceptor as well.
> 3. We could provide a way to provide a custom SQLStatementLogger class, so
> that users can intercept statements via their custom SQLStatementLogger.
>
> Currently, the only solution is to overwrite the sqlStatementLogger field
> of the JdbcServicesImpl via Reflection, which is rather a hack.
> What do you think?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Jun  8 10:10:23 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 8 Jun 2016 17:10:23 +0300
Subject: [hibernate-dev] SQL query interceptor
In-Reply-To: <CAFdSV9vfC3Lo5AqDvbbiqcXg2Vt7QJDtzWvAj_WPp_ZrxMi-GA@mail.gmail.com>
References: <CA+gWKMAVUt52xDJ3oXZY1E7Z_Uw0PPy_YaXYg-3Qp3OH+gYn4Q@mail.gmail.com>
	<CAFdSV9vfC3Lo5AqDvbbiqcXg2Vt7QJDtzWvAj_WPp_ZrxMi-GA@mail.gmail.com>
Message-ID: <CA+gWKMBt5ec8eJdkqVH10gamSVtmHjj-fs94Ah5q5LvXcZWYgw@mail.gmail.com>

Thanks for the tip. I didn't know about it. I'll give it a try then.

On Wed, Jun 8, 2016 at 5:07 PM, Steve Ebersole <steve at hibernate.org> wrote:

> You mean like a org.hibernate.resource.jdbc.spi.StatementInspector?
>
> On Wed, Jun 8, 2016 at 6:47 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> During testing, it's very useful to have an SQL query interceptor that we
>> can inspect to see if the generated SQL query contains a certain SQL
>> clause.
>> There are multiple ways we could implement this kind of feature:
>>
>> 1. We could add a public String[] getSQLQueries(); in the Statistics
>> interface.
>> 2. We could define a SQLStatementInterceptor interface that can be
>> provided
>> via some configuration property.
>>    The SqlStatementLogger.logStatement could call the
>> SQLStatementInterceptor as well.
>> 3. We could provide a way to provide a custom SQLStatementLogger class, so
>> that users can intercept statements via their custom SQLStatementLogger.
>>
>> Currently, the only solution is to overwrite the sqlStatementLogger field
>> of the JdbcServicesImpl via Reflection, which is rather a hack.
>> What do you think?
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From chris at hibernate.org  Wed Jun  8 10:14:55 2016
From: chris at hibernate.org (Chris Cranford)
Date: Wed, 8 Jun 2016 09:14:55 -0500
Subject: [hibernate-dev] Regarding release versioning
In-Reply-To: <CAFdSV9t7ws6WMOMDayxKrxNyng7YuaqX9yjDu1bcDM2JFV4TTQ@mail.gmail.com>
References: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
	<CAFdSV9t7ws6WMOMDayxKrxNyng7YuaqX9yjDu1bcDM2JFV4TTQ@mail.gmail.com>
Message-ID: <d5069929-b380-5920-e19d-7774f1bc07d8@hibernate.org>

+1 for the hybrid approach if we feel we need minor release CRs.


On 06/08/2016 09:06 AM, Steve Ebersole wrote:
> back to this then I vote that we also go for a hybrid approach to this
> where Final is an approximation of the "approved CR", likely with
> additional fixes.
>


From mihalcea.vlad at gmail.com  Wed Jun  8 10:20:36 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 8 Jun 2016 17:20:36 +0300
Subject: [hibernate-dev] Regarding release versioning
In-Reply-To: <CAFdSV9uTK=LZ_C91CB68v3yuan1ReRa0mopjZinWVxrCLURsGA@mail.gmail.com>
References: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
	<CAFm4XO3X8maN5=0oybj_h5YjgxuYxpwfsjwzbcuTAGZ79NcttQ@mail.gmail.com>
	<CAFdSV9uTK=LZ_C91CB68v3yuan1ReRa0mopjZinWVxrCLURsGA@mail.gmail.com>
Message-ID: <CA+gWKMCQkc9Kd7RjoKAP5Q1QQj=zEoqUW9YuHit0B8jP-qX1Lg@mail.gmail.com>

I think it's just about what our users expect from a Final release. If we
mark a release with the CR suffix, people will know this might have bugs
and they can help us identify them before we release the Final version.
If there is a backward incompatibility issue, we catch it in the CR release
and, by the time we release Final, we know we got it fixed.

So, with a CR, we just buy more time. Not only that we have OGM and Search
to provide feedback on the latest CR releases, but even the Spring Data
team tries to integrate our latest artifacts into their platform.

Many end-user applications will never try the CR releases, so they will
just go to Final versions which are more stable.

Vlad

On Wed, Jun 8, 2016 at 5:06 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Sanne, you just said it.. the reason you did not test with 5.2 before it
> was released is time.  Me doing a CR release does not change that.  The
> stuff that "bit you" in 5.2 was available for testing for well over a month
> prior to releasing 5.2.  And it's not like 5.2 was released without
> discussion; heck we even pushed it back a few times to get a few extras
> in.  All discussed on the dev list.
>
>
> On Wed, Jun 8, 2016 at 7:55 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> +1
>>
>> I've also hit some incompatible API changes which I only figured out
>> too late (when attempting to upgrade Hibernate Search).
>>
>> I could have pre-tested snapshot builds but didn't have time for that
>> - and didn't expect 5.2 to be released without a Beta period, or I
>> would have made time for that.
>>
>>
>> On 8 June 2016 at 08:09, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>> > Hi,
>> >
>> > I have seen the frustration from the Spring Data team trying to keep up
>> > with our code changes that break their integrations,
>> > and I was wondering if we should use some Release candidates prior to
>> > releasing a start of a branch, even if it's a minor one.
>> > This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like
>> > that to mark it as an intermediary release that's aimed for early
>> > adopters/integrators.
>> >
>> > Do you think this is feasible or is there something to prevent us from
>> > doing this?
>> >
>> > Vlad
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > 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
>>
>

From steve at hibernate.org  Wed Jun  8 10:32:16 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jun 2016 14:32:16 +0000
Subject: [hibernate-dev] Regarding release versioning
In-Reply-To: <CA+gWKMCQkc9Kd7RjoKAP5Q1QQj=zEoqUW9YuHit0B8jP-qX1Lg@mail.gmail.com>
References: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
	<CAFm4XO3X8maN5=0oybj_h5YjgxuYxpwfsjwzbcuTAGZ79NcttQ@mail.gmail.com>
	<CAFdSV9uTK=LZ_C91CB68v3yuan1ReRa0mopjZinWVxrCLURsGA@mail.gmail.com>
	<CA+gWKMCQkc9Kd7RjoKAP5Q1QQj=zEoqUW9YuHit0B8jP-qX1Lg@mail.gmail.com>
Message-ID: <CAFdSV9tyz0qxwA8f9EWZnXHpAwsDiRCpwxm+yADOmX78zp9a0g@mail.gmail.com>

On Wed, Jun 8, 2016 at 9:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> If there is a backward incompatibility issue, we catch it in the CR
> release and, by the time we release Final, we know we got it fixed.
>

If I had to guess, this is what Spring Data devs are more interested in.
We have been doing a lot of refactoring in 5.x.



> So, with a CR, we just buy more time. Not only that we have OGM and Search
> to provide feedback on the latest CR releases, but even the Spring Data
> team tries to integrate our latest artifacts into their platform.
>

But see "buying more time" is not necessarily a good thing.  Because really
here that means allow the release to take more time:

   - allow it more bake time - obviously that's ok, within reason
   - more discussion - again ok, within bounds.  For example, each and
   every one of the major changes in 5.2 was discussed in specific on dev
   channels as it was being designed and developed.  Again, its all about
   moderation
   - more time to physically do releases - it takes me roughly half a day
   to do a release.  Between running the release build, fighting Nexus,
   changing the website, announcing, etc.  Those half days add up


So let's be careful here.  Go back to the original discussion.  We used to,
quite bluntly, waste a lot of time just doing release-y things.  It sucks
when I barely have time to dev as it is, and now I have to take some of
that time and invest it back into release-y stuff.


Many end-user applications will never try the CR releases, so they will
> just go to Final versions which are more stable.
>

Exact same argument for SNAPSHOT :)

From mihalcea.vlad at gmail.com  Wed Jun  8 10:46:11 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 8 Jun 2016 17:46:11 +0300
Subject: [hibernate-dev] Regarding release versioning
In-Reply-To: <CAFdSV9tyz0qxwA8f9EWZnXHpAwsDiRCpwxm+yADOmX78zp9a0g@mail.gmail.com>
References: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
	<CAFm4XO3X8maN5=0oybj_h5YjgxuYxpwfsjwzbcuTAGZ79NcttQ@mail.gmail.com>
	<CAFdSV9uTK=LZ_C91CB68v3yuan1ReRa0mopjZinWVxrCLURsGA@mail.gmail.com>
	<CA+gWKMCQkc9Kd7RjoKAP5Q1QQj=zEoqUW9YuHit0B8jP-qX1Lg@mail.gmail.com>
	<CAFdSV9tyz0qxwA8f9EWZnXHpAwsDiRCpwxm+yADOmX78zp9a0g@mail.gmail.com>
Message-ID: <CA+gWKMBctyzWEi9rOpjcbNMNicVUp4cks=QYcA3RAB2n_=yyNw@mail.gmail.com>

So I think we all agree that a hybrid approach is a good think, but the
only drawback is that the release takes time and Steve is the only one in
charge to make this release.

Is it possible to have one more person that is allowed to initiate a
RC release?
The release burden should be shared.

Vlad

On Wed, Jun 8, 2016 at 5:32 PM, Steve Ebersole <steve at hibernate.org> wrote:

> On Wed, Jun 8, 2016 at 9:20 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> If there is a backward incompatibility issue, we catch it in the CR
>> release and, by the time we release Final, we know we got it fixed.
>>
>
> If I had to guess, this is what Spring Data devs are more interested in.
> We have been doing a lot of refactoring in 5.x.
>
>
>
>> So, with a CR, we just buy more time. Not only that we have OGM and
>> Search to provide feedback on the latest CR releases, but even the Spring
>> Data team tries to integrate our latest artifacts into their platform.
>>
>
> But see "buying more time" is not necessarily a good thing.  Because
> really here that means allow the release to take more time:
>
>    - allow it more bake time - obviously that's ok, within reason
>    - more discussion - again ok, within bounds.  For example, each and
>    every one of the major changes in 5.2 was discussed in specific on dev
>    channels as it was being designed and developed.  Again, its all about
>    moderation
>    - more time to physically do releases - it takes me roughly half a day
>    to do a release.  Between running the release build, fighting Nexus,
>    changing the website, announcing, etc.  Those half days add up
>
>
> So let's be careful here.  Go back to the original discussion.  We used
> to, quite bluntly, waste a lot of time just doing release-y things.  It
> sucks when I barely have time to dev as it is, and now I have to take some
> of that time and invest it back into release-y stuff.
>
>
> Many end-user applications will never try the CR releases, so they will
>> just go to Final versions which are more stable.
>>
>
> Exact same argument for SNAPSHOT :)
>

From sanne at hibernate.org  Wed Jun  8 10:56:12 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 8 Jun 2016 15:56:12 +0100
Subject: [hibernate-dev] Regarding release versioning
In-Reply-To: <CAFdSV9t7ws6WMOMDayxKrxNyng7YuaqX9yjDu1bcDM2JFV4TTQ@mail.gmail.com>
References: <CA+gWKMBppGWYJ9xqJaWiah-h8jYhkz-91Obq_dHmroA0ApPwrw@mail.gmail.com>
	<CAFdSV9t7ws6WMOMDayxKrxNyng7YuaqX9yjDu1bcDM2JFV4TTQ@mail.gmail.com>
Message-ID: <CAFm4XO0LoSQ4CM9txHDeWPTqzCTeHWs2za259-CrnMTL1o95mw@mail.gmail.com>

On 8 June 2016 at 15:06, Steve Ebersole <steve at hibernate.org> wrote:
> Well the reasoning was discussed on this list and everyone agreed :)  It
> was part of a larger discussion about releases and maintaining maintenance
> branches.  But if everyone, I am ok with doing CR (only) for minor releases.
>
> Part of the reasoning was that technically speaking a Final really ought to
> be a simple retagging of the last CR.  But that is virtually impossible to
> do without branching the minor release as soon as we cut the CR.  At the
> very least we really cannot push commits to whatever branch holds the CR
> until the Final.  That is all based on the principle that the "approved CR"
> ought to be exactly the same as the Final it leads to.  If we are going
> back to this then I vote that we also go for a hybrid approach to this
> where Final is an approximation of the "approved CR", likely with
> additional fixes.

Since we use Git it's easy to create a branch from a commit which
isn't on the head.

You could tag the CR, and people can continue pushing on master, then
eventually decide if you want to branch from the CR to re-tag it as
Final, or do something different.

+1 for a non-strict Hybrid approach, you can branch at any time and
cherry pick what you decide is needed.

>
> On Wed, Jun 8, 2016 at 2:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I have seen the frustration from the Spring Data team trying to keep up
>> with our code changes that break their integrations,
>> and I was wondering if we should use some Release candidates prior to
>> releasing a start of a branch, even if it's a minor one.
>> This way, instead of 5.2.0, we could release 5.2.0.RC1 or something like
>> that to mark it as an intermediary release that's aimed for early
>> adopters/integrators.
>>
>> Do you think this is feasible or is there something to prevent us from
>> doing this?
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> 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

From sanne at hibernate.org  Wed Jun  8 10:59:19 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 8 Jun 2016 15:59:19 +0100
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
Message-ID: <CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>

On 8 June 2016 at 08:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Too bad we can't just publish a Docker image.
>>
>
> We could do that, but I think we should have a solution for non-Docker
> users, too.

What's the point to package a library in a Docker image?

>
>>
>> Is this something we'd publish somewhere (Nexus/Artifactory)?
>>
>
> Yes, we'd publish it in Nexus and also BinTray/SourceForge.
>
> People would download it, unzip it into the "modules" directory of their WF
> instance and could start using the new ORM version (provided the larger
> scheme of integration hasn't changed, so the JipiJapa bits in WF continue
> to work as is).
>
>
>>   I know nothing about building a WF module ZIP.  But if you are willing
>> to do the work and it helps OGM etc, of course we would incorporate it.
>>
>
> Ok, cool. I'll take a look then.
>
> On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>>> Hi,
>>>
>>> As discussed by some of us during the No ORM meeting in May, it'd be great
>>> if there was a module ZIP allowing people to easily upgrade Hibernate ORM
>>> in the WildFly version they are using.
>>>
>>> Just the other day there was a blog post published [1] describing how to
>>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
>>> existing module.xml files. We could do better than that, leaving the
>>> original version intact and providing a new one with a specific slot
>>> ("5.2") in the ZIP.
>>>
>>> That'd also be helpful for other projects such as Hibernate OGM which
>>> already provide a module ZIP for WF but currently need to package ORM,
>>> too,
>>> in case they need features from a later ORM version.
>>>
>>> If we all agree that's a good thing to have, I can help with making it
>>> happen.
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1]
>>>
>>> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> 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

From steve at hibernate.org  Wed Jun  8 11:01:46 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 08 Jun 2016 15:01:46 +0000
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
Message-ID: <CAFdSV9sVCg+=-2h2AW6G55PRaCCfZa=k9sA=zEVFtYsCsMgArw@mail.gmail.com>

I don't know. I was just thinking of distribution.  I really know very
little about WF modules

On Wed, Jun 8, 2016 at 9:59 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 8 June 2016 at 08:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >
> >> Too bad we can't just publish a Docker image.
> >>
> >
> > We could do that, but I think we should have a solution for non-Docker
> > users, too.
>
> What's the point to package a library in a Docker image?
>
> >
> >>
> >> Is this something we'd publish somewhere (Nexus/Artifactory)?
> >>
> >
> > Yes, we'd publish it in Nexus and also BinTray/SourceForge.
> >
> > People would download it, unzip it into the "modules" directory of their
> WF
> > instance and could start using the new ORM version (provided the larger
> > scheme of integration hasn't changed, so the JipiJapa bits in WF continue
> > to work as is).
> >
> >
> >>   I know nothing about building a WF module ZIP.  But if you are willing
> >> to do the work and it helps OGM etc, of course we would incorporate it.
> >>
> >
> > Ok, cool. I'll take a look then.
> >
> > On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> As discussed by some of us during the No ORM meeting in May, it'd be
> great
> >>> if there was a module ZIP allowing people to easily upgrade Hibernate
> ORM
> >>> in the WildFly version they are using.
> >>>
> >>> Just the other day there was a blog post published [1] describing how
> to
> >>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
> >>> existing module.xml files. We could do better than that, leaving the
> >>> original version intact and providing a new one with a specific slot
> >>> ("5.2") in the ZIP.
> >>>
> >>> That'd also be helpful for other projects such as Hibernate OGM which
> >>> already provide a module ZIP for WF but currently need to package ORM,
> >>> too,
> >>> in case they need features from a later ORM version.
> >>>
> >>> If we all agree that's a good thing to have, I can help with making it
> >>> happen.
> >>>
> >>> Thanks,
> >>>
> >>> --Gunnar
> >>>
> >>> [1]
> >>>
> >>>
> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> 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
>

From gunnar at hibernate.org  Wed Jun  8 11:08:12 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 8 Jun 2016 17:08:12 +0200
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
Message-ID: <CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>

It'd not only be a library, but an image containing WF with the latest
Hibernate ORM. But as said, the module ZIP is more versatile and is what
I'd do.

2016-06-08 16:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 8 June 2016 at 08:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >
> >> Too bad we can't just publish a Docker image.
> >>
> >
> > We could do that, but I think we should have a solution for non-Docker
> > users, too.
>
> What's the point to package a library in a Docker image?
>
> >
> >>
> >> Is this something we'd publish somewhere (Nexus/Artifactory)?
> >>
> >
> > Yes, we'd publish it in Nexus and also BinTray/SourceForge.
> >
> > People would download it, unzip it into the "modules" directory of their
> WF
> > instance and could start using the new ORM version (provided the larger
> > scheme of integration hasn't changed, so the JipiJapa bits in WF continue
> > to work as is).
> >
> >
> >>   I know nothing about building a WF module ZIP.  But if you are willing
> >> to do the work and it helps OGM etc, of course we would incorporate it.
> >>
> >
> > Ok, cool. I'll take a look then.
> >
> > On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> As discussed by some of us during the No ORM meeting in May, it'd be
> great
> >>> if there was a module ZIP allowing people to easily upgrade Hibernate
> ORM
> >>> in the WildFly version they are using.
> >>>
> >>> Just the other day there was a blog post published [1] describing how
> to
> >>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on the
> >>> existing module.xml files. We could do better than that, leaving the
> >>> original version intact and providing a new one with a specific slot
> >>> ("5.2") in the ZIP.
> >>>
> >>> That'd also be helpful for other projects such as Hibernate OGM which
> >>> already provide a module ZIP for WF but currently need to package ORM,
> >>> too,
> >>> in case they need features from a later ORM version.
> >>>
> >>> If we all agree that's a good thing to have, I can help with making it
> >>> happen.
> >>>
> >>> Thanks,
> >>>
> >>> --Gunnar
> >>>
> >>> [1]
> >>>
> >>>
> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> 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
>

From sanne at hibernate.org  Wed Jun  8 11:16:15 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 8 Jun 2016 16:16:15 +0100
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
Message-ID: <CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>

On 8 June 2016 at 16:08, Gunnar Morling <gunnar at hibernate.org> wrote:
> It'd not only be a library, but an image containing WF with the latest
> Hibernate ORM. But as said, the module ZIP is more versatile and is what I'd
> do.

+1 for the priority on ZIP files.

I had not understood that you meant to re-distribute a customized WF
image so I was quite confused :)

>
> 2016-06-08 16:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 8 June 2016 at 08:11, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> >
>> >> Too bad we can't just publish a Docker image.
>> >>
>> >
>> > We could do that, but I think we should have a solution for non-Docker
>> > users, too.
>>
>> What's the point to package a library in a Docker image?
>>
>> >
>> >>
>> >> Is this something we'd publish somewhere (Nexus/Artifactory)?
>> >>
>> >
>> > Yes, we'd publish it in Nexus and also BinTray/SourceForge.
>> >
>> > People would download it, unzip it into the "modules" directory of their
>> > WF
>> > instance and could start using the new ORM version (provided the larger
>> > scheme of integration hasn't changed, so the JipiJapa bits in WF
>> > continue
>> > to work as is).
>> >
>> >
>> >>   I know nothing about building a WF module ZIP.  But if you are
>> >> willing
>> >> to do the work and it helps OGM etc, of course we would incorporate it.
>> >>
>> >
>> > Ok, cool. I'll take a look then.
>> >
>> > On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> As discussed by some of us during the No ORM meeting in May, it'd be
>> >>> great
>> >>> if there was a module ZIP allowing people to easily upgrade Hibernate
>> >>> ORM
>> >>> in the WildFly version they are using.
>> >>>
>> >>> Just the other day there was a blog post published [1] describing how
>> >>> to
>> >>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on
>> >>> the
>> >>> existing module.xml files. We could do better than that, leaving the
>> >>> original version intact and providing a new one with a specific slot
>> >>> ("5.2") in the ZIP.
>> >>>
>> >>> That'd also be helpful for other projects such as Hibernate OGM which
>> >>> already provide a module ZIP for WF but currently need to package ORM,
>> >>> too,
>> >>> in case they need features from a later ORM version.
>> >>>
>> >>> If we all agree that's a good thing to have, I can help with making it
>> >>> happen.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> --Gunnar
>> >>>
>> >>> [1]
>> >>>
>> >>>
>> >>> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> 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
>
>

From sanne at hibernate.org  Wed Jun  8 11:30:26 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 8 Jun 2016 16:30:26 +0100
Subject: [hibernate-dev] Deprecation of Maven coordinates: where's
 hibernate-entitymanager ?
In-Reply-To: <CAFdSV9v1cr-o0MK0AOQX08sW+96miA854Et1xcFf1xVpQKrAyw@mail.gmail.com>
References: <CAFm4XO0e4Zg9w6-AWE7V08FAfihU=523eHu_a9Op4qwbiOPaNw@mail.gmail.com>
	<CAFdSV9v1cr-o0MK0AOQX08sW+96miA854Et1xcFf1xVpQKrAyw@mail.gmail.com>
Message-ID: <CAFm4XO2Z0sdWJF5hsCBAzUoKoxrv1FQo_ZFrW6a5+_bF8qgX-A@mail.gmail.com>

Ok, I didn't expect that those issues with Gradle would still be unresolved.

Thanks

On 7 June 2016 at 13:47, Steve Ebersole <steve at hibernate.org> wrote:
> I have mentioned this before.  We cannot automate this through Gradle (long
> story, feel free to see my Gradle Jiras and forum posts for details).  And I
> am not going to make this a manual step for each and every release.
>
> On Tue, Jun 7, 2016 at 3:42 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> I've seen quite some people struggling with the upgrade to Hibernate
>> ORM 5.2 as they think that hibernate-entitymanager was either
>> mistakenly not uploaded, or wasn't synched to Maven Central yet.
>>
>> Could we restore the pom.xml for this artifact and have it redirect to
>> hibernate-orm ?
>>
>> Doing so we'll be able to get a proper warning to people consuming
>> Hibernate via dependency management tools.
>>
>> We have a similar pom in Hibernate Search, feel free to copy it:
>>
>> https://github.com/hibernate/hibernate-search/blob/master/legacy/pom.xml#L23-L29
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From vm at sykora.cz  Wed Jun  8 16:31:35 2016
From: vm at sykora.cz (Vladimir Martinek)
Date: Wed, 8 Jun 2016 22:31:35 +0200
Subject: [hibernate-dev] Relations are not loaded when using Fetch
 Profiles
In-Reply-To: <CAFdSV9sonop2nM9GoGsmaeah_K6TF+hjUO4_KUR3FZXjOWLDyA@mail.gmail.com>
References: <57502A51.802@sykora.cz>
	<CAFDzhiRuTk22tmGtkc4LpL26LVV63-mFuz2JmdbrxBvA+M6OJw@mail.gmail.com>
	<575695EE.3050807@sykora.cz>
	<CAFdSV9ugYcHoB0SbGUN87tLvXi5yVL7diT3Z-oLgciA8pu6YFQ@mail.gmail.com>
	<5756D122.7070306@sykora.cz>
	<CAFdSV9uJ_J+yZNkBs4VBso-Nf1gaB8HYjE2WLsU8A0UJ5+beEQ@mail.gmail.com>
	<5757C933.2090702@sykora.cz>
	<CAFdSV9sonop2nM9GoGsmaeah_K6TF+hjUO4_KUR3FZXjOWLDyA@mail.gmail.com>
Message-ID: <575880A7.6040301@sykora.cz>

Steve,

thank you very much. The test is extremely simple and as a programmer I 
thought those few lines of code would clear up any confusion.
It's perfectly OK to postpone the discussion and I will be very happy to 
continue once the problem is reproduced and understood.

Once again thank you for all your effort.

Vladimir


On 8.6.2016 16:08, Steve Ebersole wrote:
> Will do.  Was hoping to discuss.  But if I have to dig through your 
> test instead I certainly will, as soon as I get time.
>
> On Wed, Jun 8, 2016 at 2:29 AM Vladimir Martinek <vm at sykora.cz 
> <mailto:vm at sykora.cz>> wrote:
>
>     MetamodelGraphWalker line 144. My relation is in
>     MetamodelGraphWalker.visitedAssociationKeys, so it gets skipped
>     and thus not make it in the final big SQL SELECT.
>
>     Why don't you take a look at the test case I provided - just run
>     it and see the LazyInitializationException error, it will all be
>     instantly clear.  I am talking about LAZY relations in combination
>     with FetchProfile using FetchMode.JOIN. Please disregard EAGER
>     (for now, we may come to that later once we agree on what is the
>     problem :)
>
>     We prefer to have all relations LAZY on our project (performance
>     reasons) and use FetchProfiles. The actual FetchMode (whether it
>     is JOIN, SELECT) does not matter to us, all we need is the
>     relations to be loaded in single EntityManager.find call.
>     Unfortunately the only FetchMode implemented now is JOIN and that
>     one has this unpleasant bug in it.
>
>     Thank you
>
>
>     Vladimir
>
>
>     On 06/07/2016 04:01 PM, Steve Ebersole wrote:
>>     MetamodelGraphWalker does not consider them cycles.  Where do you
>>     see MetamodelGraphWalker making that decision? 
>>     MetamodelGraphWalker simply walks your model mappings.  It
>>     delegates to pluggable strategies.  So I assume you really mean
>>     one of the AssociationVisitationStrategy implementations is
>>     considering them cycles.  And even then I am not so sure that is
>>     what happens...
>>
>>     So to be clear we are talking about 2 different EAGER fetch
>>     strategies here: join and select.
>>
>>     For join, we'd build one big SQL SELECT joining the relations
>>     together.  You can see this by switching your associations from
>>     lazy to all being eager and specifying join fetching.
>>
>>     For select, we'd build one SQL SELECT for the root entity being
>>     loaded (and any join fetched relations).  From there, any
>>     select-fetched relations would be loaded individually by separate
>>     select (that's kind of the definition of N+1).
>>
>>
>>
>>     On Tue, Jun 7, 2016 at 8:50 AM Vladimir Martinek <vm at sykora.cz
>>     <mailto:vm at sykora.cz>> wrote:
>>
>>         Hello,
>>
>>         actually I would like to learn how the FetchMode.JOIN is
>>         supposed to work in case of cycles (not really cycles but
>>         MetamodelGraphWalker considers them cycles).
>>
>>         Check the test case please - it gets
>>         LazyInitializationException on a relation despite that
>>         relation being marked as JOIN FETCH in the fetch profile.
>>
>>         How is this intended to work? Is it a problem of
>>         MetamodelGraphWalker and its cycle detection? Or is it
>>         planned limitation of FetchMode.JOIN?
>>
>>         I can help to fix this, but in order to do that I need to
>>         know how this is expected to work.
>>
>>         Please disregard EAGER. I only mentioned FetchType.EAGER
>>         because I noticed it can cope with the same cyclic relations
>>         - and yes, you are right, those are fetched in subsequent
>>         selects. But we can't use EAGER (performance reasons).
>>
>>         Thank you
>>
>>         Vladimir
>>
>>
>>
>>
>>
>>         On 06/07/2016 03:05 PM, Steve Ebersole wrote:
>>>         There is a huge difference in join-fetch and what we detail
>>>         for "EAGER". Join-fetch is also an eager fetch.  There are 2
>>>         pieces of information in regards to fetching: when, how?
>>>
>>>         EAGER merely describes when: now.
>>>
>>>         What you describe as "EAGER" is really a N+1 fetch.  So the
>>>         relation is fetched immediately, but as "subsequent
>>>         select".  A join-fetch is still EAGER, but now the relation
>>>         is fetch via join in the initial query.  Very different
>>>         behavior.
>>>
>>>         On Tue, Jun 7, 2016 at 4:38 AM Vladimir Martinek
>>>         <vm at sykora.cz <mailto:vm at sykora.cz>> wrote:
>>>
>>>             HHH-10745, runnable test case attached to that issue
>>>             (org.hibernate.test.fetchprofiles.cycle.tar.gz).
>>>
>>>             Thank you
>>>
>>>             Vladimir
>>>
>>>
>>>
>>>             On 06/07/2016 06:00 AM, Gail Badner wrote:
>>>             > Please create a Jira issue and attach a runnable test
>>>             case.
>>>             > Thanks,
>>>             > Gail
>>>             >
>>>             > On Thu, Jun 2, 2016 at 5:45 AM, Vladimir Martinek
>>>             <vm at sykora.cz <mailto:vm at sykora.cz>
>>>             > <mailto:vm at sykora.cz <mailto:vm at sykora.cz>>> wrote:
>>>             >
>>>             >     Fetch profiles fail to load certain relations
>>>             because of invalid cycle
>>>             >     detection in MetamodelGraphWalker. Below is an
>>>             example.
>>>             >
>>>             >     I have compared the behaviour of Fetch Profiles
>>>             and standard EAGER
>>>             >     relations (EAGER does not suffer from this
>>>             problem). The
>>>             >     MetamodelGraphWalker graph walker produces the
>>>             same results, the
>>>             >     SQL is
>>>             >     the same (missing relation).
>>>             >
>>>             >     With EAGER the relation is loaded in second pass, via
>>>             >     SessionImpl.internalLoad(). There it is decided
>>>             what LoadType is
>>>             >     used -
>>>             >     for eager it uses INTERNAL_LOAD_EAGER, for lazy
>>>             INTERNAL_LOAD_LAZY. It
>>>             >     does not take into account the fetch profiles here!
>>>             >
>>>             >     The last place I can get hold of fetch profiles in in
>>>             >     AbstractLoadPlanBasedEntityLoader line 82. After
>>>             that the fetch
>>>             >     profile
>>>             >     information is lost, never making it anywhere near to
>>>             >     SessionImpl.internalLoad().
>>>             >
>>>             >     I would like to implement this, but to do that, I
>>>             need someone to
>>>             >     point
>>>             >     me in the right direction. Most of all I need
>>>             answers to following
>>>             >     questions:
>>>             >
>>>             >     1) Is it right to assume the fetch profiles should
>>>             be evaluated in
>>>             >     SessionImpl.internalLoad() and appropriate
>>>             LoadType used when
>>>             >     detected a
>>>             >     relation affected by a fetch profile?
>>>             >     2) If so, what is the intended way of getting the
>>>             fetch profile
>>>             >     information to SessionImpl.internalLoad()?
>>>             >
>>>             >     Also, a colleague of mine attempted to implement
>>>             FetchType.SELECT
>>>             >     fetch
>>>             >     strategy and ended up with precisely the same
>>>             problem. I believe
>>>             >     solving
>>>             >     my issue would pave way for quick FetchType.SELECT
>>>             implementation
>>>             >     (which
>>>             >     we could also use on our project).
>>>             >
>>>             >
>>>             >     Thank you
>>>             >
>>>             >     Vladimir Martinek
>>>             >
>>>             >
>>>             >     Example:
>>>             >
>>>             >     Have 5 entities - Start, Via1, Via2, Mid and
>>>             Finish with following
>>>             >     relations (all LAZY):
>>>             >
>>>             >     Start n:1 Via1 n:1 Mid n:1 Finish
>>>             >     Start n:1 Via2 n:1 Mid n:1 Finish
>>>             >
>>>             >     Now, trying to use Fetch Profiles to load Start
>>>             entity and all of its
>>>             >     relations. I would expect Hibernate to execute
>>>             following SQL select:
>>>             >
>>>             >     SELECT * FROM Start s
>>>             >     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>>>             >     LEFT OUTER JOIN Mid
>>>             >     JOIN Finish
>>>             >
>>>             >     LEFT OUTER JOIN Via2 (path Start-Via2)
>>>             >     LEFT OUTER JOIN Mid
>>>             >     JOIN Finish
>>>             >
>>>             >     Unfortunately, ii ompletely omits the second join
>>>             from Mid to Finish,
>>>             >     what I am getting is:
>>>             >
>>>             >     SELECT * FROM Start s
>>>             >     LEFT OUTER JOIN Via1 v1 (path Start-Via1)
>>>             >     LEFT OUTER JOIN Mid
>>>             >     JOIN Finish
>>>             >
>>>             >     LEFT OUTER JOIN Via2 (path Start-Via2)
>>>             >     LEFT OUTER JOIN Mid
>>>             >
>>>             >     I dug deeper into this and found cycle detection in
>>>             >     MetamodelGraphWalker, line 144. Basically, when
>>>             MetamodelGraphWalker
>>>             >     detects a relation that has already been visited,
>>>             it considers it a
>>>             >     cycle. But in my case it is not a cycle - I just
>>>             came to the same
>>>             >     relation twice using two different paths.
>>>             >
>>>             >
>>>             >  _______________________________________________
>>>             >     hibernate-dev mailing list
>>>             > hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>
>>>             <mailto:hibernate-dev at lists.jboss.org
>>>             <mailto:hibernate-dev at lists.jboss.org>>
>>>             > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>             >
>>>             >
>>>
>>>
>>>             --
>>>
>>>             *Ing. Vladim?r Martinek*
>>>             Programmer
>>>
>>>             T: +420 723 908 968
>>>             @: vm at sykora.cz <mailto:vm at sykora.cz>
>>>
>>>             Sykora Data Center s.r.o.
>>>             28. ??jna 1512/123, 702 00 Ostrava
>>>             www.sykora.cz <http://www.sykora.cz>
>>>
>>>             _______________________________________________
>>>             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
>>>
>>
>>
>>         -- 
>>
>>         *Ing. Vladim?r Martinek*
>>         Programmer
>>
>>         T: +420 723 908 968
>>         @: vm at sykora.cz <mailto:vm at sykora.cz>
>>
>>         Sykora Data Center s.r.o.
>>         28. ??jna 1512/123, 702 00 Ostrava
>>         www.sykora.cz <http://www.sykora.cz>
>>
>
>
>     -- 
>
>     *Ing. Vladim?r Martinek*
>     Programmer
>
>     T: +420 723 908 968
>     @: vm at sykora.cz <mailto:vm at sykora.cz>
>
>     Sykora Data Center s.r.o.
>     28. ??jna 1512/123, 702 00 Ostrava
>     www.sykora.cz <http://www.sykora.cz>
>


-- 

*Ing. Vladim?r Martinek*
Programmer

T: +420 723 908 968
@: vm at sykora.cz

Sykora Data Center s.r.o.
28. ??jna 1512/123, 702 00 Ostrava
www.sykora.cz


From mihalcea.vlad at gmail.com  Thu Jun  9 11:13:00 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 9 Jun 2016 18:13:00 +0300
Subject: [hibernate-dev] Follow on locking usability enhancement for Oracle
Message-ID: <CA+gWKMDChFWvK6+8jR-dDDiDcD0UG2Hpyr9qRm5_SYTsajv4rQ@mail.gmail.com>

Hi,

After reviewing the PR for https://hibernate.atlassian.net/browse/HHH-9486,
I realized we could indeed improve the follow on locking for Oracle.

The issue with Oracle is partly explained in the Oracle docs:

https://docs.oracle.com/database/121/SQLRF/statements_10002.htm#sthref7465

The basic idea is that FOR UPDATE does not work with GROUP BY, DISTINCT,
and also nested selects which is what we use for pagination.
For those, the setMaxResults works, but not setFirstResult. Also, ORDER BY
causes some issues too.

This way, we could do something like this:

1. In Dialect, we deprecate useFollowOnLocking and add a new method to take
QueryParameters

@Deprecated
public boolean useFollowOnLocking() {
    return useFollowOnLocking( null );
}

public boolean useFollowOnLocking(QueryParameters parameters) {
    return false;
}

2. In Oracle82Dialect:

@Override
public boolean useFollowOnLocking(QueryParameters parameters) {

    String lowerCaseSQL = parameters.getFilteredSQL().toLowerCase();

    return parameters.hasRowSelection() && (
        parameters.getRowSelection().getFirstRow() != null ||
        lowerCaseSQL.contains( "distinct" ) ||
        lowerCaseSQL.contains( "group by" ) ||
        lowerCaseSQL.contains( "order by" )
    );
}

3. We could also add a way for the user to override this behavior in
Dialect if he knows that the underlying statement works.
Although we include all those safety checks, we might miss some use case,
and this way the user can have a better control on the follow on locking
approach.

For this we could add a setFollowOnLocking on LockOptions.

List<Product> products = session.createQuery(
    "select p from Product p order by p.id", Product.class )
.setLockOptions( new LockOptions( LockMode.PESSIMISTIC_WRITE
).setFollowOnLocking( true ) )
.setMaxResults( 10 )
.getResultList();

If the user specified an explicit setFollowOnLocking, then we ignore the
Dialect logic and just go with his option even if that means that he might
get an exception.

What do you think fo this?


Vlad

From steve at hibernate.org  Thu Jun  9 20:20:31 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 10 Jun 2016 00:20:31 +0000
Subject: [hibernate-dev] 5.2 or 6.0
In-Reply-To: <E520BEC8-778C-4DD5-A29F-29DFB42BC2B6@hibernate.org>
References: <CAFdSV9v5m9kmgd-wyRRWCg062W1EyNFvh5OAZqj0PSp6r_LU9w@mail.gmail.com>
	<CADGJaX9ir8rF-x6oGk+Vi8muec_8XFEh3EG0mq8WvHXcVxYvUg@mail.gmail.com>
	<E520BEC8-778C-4DD5-A29F-29DFB42BC2B6@hibernate.org>
Message-ID: <CAFdSV9sUecwZkJFGfKhWGSuYcs-s-9AGfWuxMO26YvZ_UUG4vg@mail.gmail.com>

For what it is worth, the specific changes I have in mind are to scope the
following delegates to our JPA javax.persistence.metamodel.Metamodel impl,
and to expose them via our extension contracts:


   1.
   org.hibernate.type.proposed.spi.descriptor.java.JavaTypeDescriptorRegistry
   2.
   org.hibernate.type.proposed.spi.descriptor.sql.SqlTypeDescriptorRegistry
   3. org.hibernate.type.proposed.spi.basic.BasicTypeFactory - which is a
   redesign of the current org.hibernate.type.BasicTypeRegistry based on
   idea of "composing"a BasicType from JavaTypeDescriptor,
   SqlTypeDescriptor and AttributeConverter

(1) and (2) are exposed by a new
org.hibernate.type.proposed.spi.descriptor.TypeDescriptorRegistryAccess
interface that org.hibernate.Metamodel extends (along with
javax.persistence.metamodel.Metamodel).

For 5.2 I'd also likely not do (3), instead just moving BasicTypeRegistry
there and refactoring BasicTypeRegistry -> BasicTypeFactory in 6.0

On Wed, Jun 8, 2016 at 4:57 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Does the HQL to native query mechanic use this too?
>
> > On 08 Jun 2016, at 08:50, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > JavaTypeDescriptorRegistry is used by Hibernate OGM in
> > (o.h.o.type.impl.TypeTranslatorImpl).
> >
> >> From my side, the proposed change is good, esp. if it fixes some
> existing
> > bugs. It'd lock down OGM to a specific minor of ORM, but that'll happen
> > anyways once we make use of the changes around schema tooling done in ORM
> > 5.1.
> >
> > --Gunnar
> >
> >
> > 2016-06-07 19:49 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >
> >> Currently we are still working on 6.0 "on top" of 5.2, meaning that all
> of
> >> the changes we are proposing to ORM for 6.0 are kept in a separate
> >> repo/project using ORM 5.2 as a dependency.
> >>
> >> As I work on 6.0 I have come across a change that I would like to make
> that
> >> requires that I change something in ORM proper.  The specific change is
> >> that I would like to remove static access
> >> to org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry
> >> and org.hibernate.type.descriptor.java.JavaTypeDescriptorRegistry and
> have
> >> these scoped as part of the SessionFactory instead (technically as part
> of
> >> the org.hibernate.metamodel.internal.MetamodelImpl associated with a
> >> SessionFactory).
> >>
> >> There are 2 ways I can go about this:
> >>
> >>   1. branch 5.2 and start 6.0 dev on master
> >>   2. make this change in master for inclusion in both 5.2 and 6.0
> >>
> >> (2) is certainly the more convenient approach.  But even beyond
> convenient,
> >> I have seen some bugs from the fact that these are statically typed -
> >> theoretically they should be scoped to the SF since the SF can mutate
> them.
> >>
> >> However making that change in 5.2 has some risks depending upon whether
> >> apps/integrations use it.  Anyone aware of any integration(s) accessing
> >> these 2 registries?
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> 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
>
>

From gunnar at hibernate.org  Fri Jun 10 01:36:02 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 10 Jun 2016 07:36:02 +0200
Subject: [hibernate-dev] 5.2 or 6.0
In-Reply-To: <E520BEC8-778C-4DD5-A29F-29DFB42BC2B6@hibernate.org>
References: <CAFdSV9v5m9kmgd-wyRRWCg062W1EyNFvh5OAZqj0PSp6r_LU9w@mail.gmail.com>
	<CADGJaX9ir8rF-x6oGk+Vi8muec_8XFEh3EG0mq8WvHXcVxYvUg@mail.gmail.com>
	<E520BEC8-778C-4DD5-A29F-29DFB42BC2B6@hibernate.org>
Message-ID: <CADGJaX8snXPTM0yY_h=TmV9JEJQm7rS89ph67s_uhvcFo3j27w@mail.gmail.com>

> Does the HQL to native query mechanic use this too?

Indirectly. It's used for converting query parameters, if that helps.

2016-06-08 9:31 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> Does the HQL to native query mechanic use this too?
>
> > On 08 Jun 2016, at 08:50, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > JavaTypeDescriptorRegistry is used by Hibernate OGM in
> > (o.h.o.type.impl.TypeTranslatorImpl).
> >
> >> From my side, the proposed change is good, esp. if it fixes some
> existing
> > bugs. It'd lock down OGM to a specific minor of ORM, but that'll happen
> > anyways once we make use of the changes around schema tooling done in ORM
> > 5.1.
> >
> > --Gunnar
> >
> >
> > 2016-06-07 19:49 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >
> >> Currently we are still working on 6.0 "on top" of 5.2, meaning that all
> of
> >> the changes we are proposing to ORM for 6.0 are kept in a separate
> >> repo/project using ORM 5.2 as a dependency.
> >>
> >> As I work on 6.0 I have come across a change that I would like to make
> that
> >> requires that I change something in ORM proper.  The specific change is
> >> that I would like to remove static access
> >> to org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry
> >> and org.hibernate.type.descriptor.java.JavaTypeDescriptorRegistry and
> have
> >> these scoped as part of the SessionFactory instead (technically as part
> of
> >> the org.hibernate.metamodel.internal.MetamodelImpl associated with a
> >> SessionFactory).
> >>
> >> There are 2 ways I can go about this:
> >>
> >>   1. branch 5.2 and start 6.0 dev on master
> >>   2. make this change in master for inclusion in both 5.2 and 6.0
> >>
> >> (2) is certainly the more convenient approach.  But even beyond
> convenient,
> >> I have seen some bugs from the fact that these are statically typed -
> >> theoretically they should be scoped to the SF since the SF can mutate
> them.
> >>
> >> However making that change in 5.2 has some risks depending upon whether
> >> apps/integrations use it.  Anyone aware of any integration(s) accessing
> >> these 2 registries?
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> 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
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Fri Jun 10 06:00:23 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 10 Jun 2016 12:00:23 +0200
Subject: [hibernate-dev] Collection was not processed by flush()
In-Reply-To: <2AB75149-37D1-4828-896F-AB7FF6EAD83A@hibernate.org>
References: <CAKnbemWXysiBcoESUxzpj16_7VQENqR52xD7Oj3+QQMVB1G5Og@mail.gmail.com>
	<20160607132009.GF43559@hibernate.org>
	<CAFdSV9tOfiqvOrTxAvZa=kp=3CuC1e+7p+yhuij_wkuyavTm=Q@mail.gmail.com>
	<2AB75149-37D1-4828-896F-AB7FF6EAD83A@hibernate.org>
Message-ID: <20160610100014.GB19659@nineveh.local>

Hi,

On Wed, 08-Jun-2016 10:37, Emmanuel Bernard wrote:
> My modest contribution
> 
> https://hibernate.atlassian.net/browse/HHH-10813
> https://github.com/hibernate/hibernate-orm/pull/1408

A truly tricky one ;-) - sorry could not resist.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20160610/629f9ec9/attachment.bin 

From steve at hibernate.org  Fri Jun 10 15:27:20 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 10 Jun 2016 19:27:20 +0000
Subject: [hibernate-dev] 5.2 or 6.0
In-Reply-To: <CADGJaX8snXPTM0yY_h=TmV9JEJQm7rS89ph67s_uhvcFo3j27w@mail.gmail.com>
References: <CAFdSV9v5m9kmgd-wyRRWCg062W1EyNFvh5OAZqj0PSp6r_LU9w@mail.gmail.com>
	<CADGJaX9ir8rF-x6oGk+Vi8muec_8XFEh3EG0mq8WvHXcVxYvUg@mail.gmail.com>
	<E520BEC8-778C-4DD5-A29F-29DFB42BC2B6@hibernate.org>
	<CADGJaX8snXPTM0yY_h=TmV9JEJQm7rS89ph67s_uhvcFo3j27w@mail.gmail.com>
Message-ID: <CAFdSV9u6c43Jem9YAqgRo6fFTYkrM6nf1W0UtBUukVNurC3YHg@mail.gmail.com>

https://github.com/hibernate/hibernate-orm/pull/1411

is the minimalist change I want to do.

On Fri, Jun 10, 2016 at 12:36 AM Gunnar Morling <gunnar at hibernate.org>
wrote:

> > Does the HQL to native query mechanic use this too?
>
> Indirectly. It's used for converting query parameters, if that helps.
>
> 2016-06-08 9:31 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> > Does the HQL to native query mechanic use this too?
> >
> > > On 08 Jun 2016, at 08:50, Gunnar Morling <gunnar at hibernate.org> wrote:
> > >
> > > JavaTypeDescriptorRegistry is used by Hibernate OGM in
> > > (o.h.o.type.impl.TypeTranslatorImpl).
> > >
> > >> From my side, the proposed change is good, esp. if it fixes some
> > existing
> > > bugs. It'd lock down OGM to a specific minor of ORM, but that'll happen
> > > anyways once we make use of the changes around schema tooling done in
> ORM
> > > 5.1.
> > >
> > > --Gunnar
> > >
> > >
> > > 2016-06-07 19:49 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> > >
> > >> Currently we are still working on 6.0 "on top" of 5.2, meaning that
> all
> > of
> > >> the changes we are proposing to ORM for 6.0 are kept in a separate
> > >> repo/project using ORM 5.2 as a dependency.
> > >>
> > >> As I work on 6.0 I have come across a change that I would like to make
> > that
> > >> requires that I change something in ORM proper.  The specific change
> is
> > >> that I would like to remove static access
> > >> to org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry
> > >> and org.hibernate.type.descriptor.java.JavaTypeDescriptorRegistry and
> > have
> > >> these scoped as part of the SessionFactory instead (technically as
> part
> > of
> > >> the org.hibernate.metamodel.internal.MetamodelImpl associated with a
> > >> SessionFactory).
> > >>
> > >> There are 2 ways I can go about this:
> > >>
> > >>   1. branch 5.2 and start 6.0 dev on master
> > >>   2. make this change in master for inclusion in both 5.2 and 6.0
> > >>
> > >> (2) is certainly the more convenient approach.  But even beyond
> > convenient,
> > >> I have seen some bugs from the fact that these are statically typed -
> > >> theoretically they should be scoped to the SF since the SF can mutate
> > them.
> > >>
> > >> However making that change in 5.2 has some risks depending upon
> whether
> > >> apps/integrations use it.  Anyone aware of any integration(s)
> accessing
> > >> these 2 registries?
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> 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
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From sanne at hibernate.org  Fri Jun 10 17:38:37 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 10 Jun 2016 22:38:37 +0100
Subject: [hibernate-dev] Java 9: progress on compatibility
Message-ID: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>

Hi all,
please try to have a look at this page when you have a moment:
 - http://ci.hibernate.org/view/JDK9/

Hibernate Search is working, and it shouldn't be too hard to get the
others "green" as well.

I've disabled some integration tests to get there, notably:
 - OSGi tests: Karaf is not ready for it.
 - Documentation build: Asciidoc will probably need an update.
 - WildFly integration tests: the WildFly team is aware, will need a
minor upgrade.

I don't believe these issues are relevant, so I'm satisfied that all
other tests working fine mean that the project will pretty much work
out of the box for end users - at worst their container won't work,
but that's not our responsibility to test for.

Could you all contribute a bit to get all projects show "green" on this page?

Some "workarounds" you might want to apply:
 - the Logger interfaces won't compile because of a known issue, this
can be worked around for now by having the compilation phase also
explicitly depend on this artifact:
https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
 - you'll have a ClassNotFoundException on JAXB usage unless you set
this JVM flag: https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
(This one is not a bug but will be required to be set by end users as
well - or we provide our own XML parser, that might be more user
friendly).

As far as I know, other issues with the build tools have been solved
already - including Gradle.

Thanks,
Sanne

From steve at hibernate.org  Sat Jun 11 13:25:55 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 11 Jun 2016 17:25:55 +0000
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
Message-ID: <CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>

The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about that?

On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi all,
> please try to have a look at this page when you have a moment:
>  - http://ci.hibernate.org/view/JDK9/
>
> Hibernate Search is working, and it shouldn't be too hard to get the
> others "green" as well.
>
> I've disabled some integration tests to get there, notably:
>  - OSGi tests: Karaf is not ready for it.
>  - Documentation build: Asciidoc will probably need an update.
>  - WildFly integration tests: the WildFly team is aware, will need a
> minor upgrade.
>
> I don't believe these issues are relevant, so I'm satisfied that all
> other tests working fine mean that the project will pretty much work
> out of the box for end users - at worst their container won't work,
> but that's not our responsibility to test for.
>
> Could you all contribute a bit to get all projects show "green" on this
> page?
>
> Some "workarounds" you might want to apply:
>  - the Logger interfaces won't compile because of a known issue, this
> can be worked around for now by having the compilation phase also
> explicitly depend on this artifact:
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>  - you'll have a ClassNotFoundException on JAXB usage unless you set
> this JVM flag:
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
> (This one is not a bug but will be required to be set by end users as
> well - or we provide our own XML parser, that might be more user
> friendly).
>
> As far as I know, other issues with the build tools have been solved
> already - including Gradle.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sat Jun 11 13:47:26 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 11 Jun 2016 18:47:26 +0100
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
Message-ID: <CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>

On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org> wrote:
> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about that?

Not sure, that's a new one :)
It could be related to https://issues.gradle.org/browse/GRADLE-3287 ?

Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
terminal at the moment, I could try later.

>
> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi all,
>> please try to have a look at this page when you have a moment:
>>  - http://ci.hibernate.org/view/JDK9/
>>
>> Hibernate Search is working, and it shouldn't be too hard to get the
>> others "green" as well.
>>
>> I've disabled some integration tests to get there, notably:
>>  - OSGi tests: Karaf is not ready for it.
>>  - Documentation build: Asciidoc will probably need an update.
>>  - WildFly integration tests: the WildFly team is aware, will need a
>> minor upgrade.
>>
>> I don't believe these issues are relevant, so I'm satisfied that all
>> other tests working fine mean that the project will pretty much work
>> out of the box for end users - at worst their container won't work,
>> but that's not our responsibility to test for.
>>
>> Could you all contribute a bit to get all projects show "green" on this
>> page?
>>
>> Some "workarounds" you might want to apply:
>>  - the Logger interfaces won't compile because of a known issue, this
>> can be worked around for now by having the compilation phase also
>> explicitly depend on this artifact:
>>
>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>>  - you'll have a ClassNotFoundException on JAXB usage unless you set
>> this JVM flag:
>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>> (This one is not a bug but will be required to be set by end users as
>> well - or we provide our own XML parser, that might be more user
>> friendly).
>>
>> As far as I know, other issues with the build tools have been solved
>> already - including Gradle.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Sun Jun 12 15:56:35 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 12 Jun 2016 20:56:35 +0100
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
Message-ID: <CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>

On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org> wrote:
> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org> wrote:
>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about that?
>
> Not sure, that's a new one :)
> It could be related to https://issues.gradle.org/browse/GRADLE-3287 ?
>
> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
> terminal at the moment, I could try later.

I've upgraded to Gradle 2.13, the pull request is here:
 - https://github.com/hibernate/hibernate-orm/pull/1417#

It solved that specific issue, but it's not enough. I'm still trying
to hack a workaround for the next step, but in the meantime that PR
could be considered independently.

I could use some pointers with Gradle and the custom plugins we use;
essentially we need to pass some additional JVM flags, including to
javac, like here:
 - https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b

But the failure happens during:
 Execution failed for task ':hibernate-core:xjc'

and I'm not sure how to override the JVM flags for that plugin execution.

Thanks,
Sanne


>
>>
>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>>
>>> Hi all,
>>> please try to have a look at this page when you have a moment:
>>>  - http://ci.hibernate.org/view/JDK9/
>>>
>>> Hibernate Search is working, and it shouldn't be too hard to get the
>>> others "green" as well.
>>>
>>> I've disabled some integration tests to get there, notably:
>>>  - OSGi tests: Karaf is not ready for it.
>>>  - Documentation build: Asciidoc will probably need an update.
>>>  - WildFly integration tests: the WildFly team is aware, will need a
>>> minor upgrade.
>>>
>>> I don't believe these issues are relevant, so I'm satisfied that all
>>> other tests working fine mean that the project will pretty much work
>>> out of the box for end users - at worst their container won't work,
>>> but that's not our responsibility to test for.
>>>
>>> Could you all contribute a bit to get all projects show "green" on this
>>> page?
>>>
>>> Some "workarounds" you might want to apply:
>>>  - the Logger interfaces won't compile because of a known issue, this
>>> can be worked around for now by having the compilation phase also
>>> explicitly depend on this artifact:
>>>
>>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>>>  - you'll have a ClassNotFoundException on JAXB usage unless you set
>>> this JVM flag:
>>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>>> (This one is not a bug but will be required to be set by end users as
>>> well - or we provide our own XML parser, that might be more user
>>> friendly).
>>>
>>> As far as I know, other issues with the build tools have been solved
>>> already - including Gradle.
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Sun Jun 12 16:18:10 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 12 Jun 2016 21:18:10 +0100
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
Message-ID: <CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>

Some more progress by simply setting this environment variable:
  GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
-XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
-XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
-XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
java.xml.bind"

But it's getting tricky:

Caused by: compile error: javassist.NotFoundException: java.lang.String
   at javassist.compiler.Javac.compileBody(Javac.java:229)
   at javassist.CtBehavior.setBody(CtBehavior.java:438)
   ... 76 more

This seems to be caused by the following plugin, which I'm not familiar with:
 - org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
Is this something which we could disable/skip/remove for now, or
update to not require Javassist?

Thanks,
sanne

On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org> wrote:
> On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org> wrote:
>> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org> wrote:
>>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about that?
>>
>> Not sure, that's a new one :)
>> It could be related to https://issues.gradle.org/browse/GRADLE-3287 ?
>>
>> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
>> terminal at the moment, I could try later.
>
> I've upgraded to Gradle 2.13, the pull request is here:
>  - https://github.com/hibernate/hibernate-orm/pull/1417#
>
> It solved that specific issue, but it's not enough. I'm still trying
> to hack a workaround for the next step, but in the meantime that PR
> could be considered independently.
>
> I could use some pointers with Gradle and the custom plugins we use;
> essentially we need to pass some additional JVM flags, including to
> javac, like here:
>  - https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
>
> But the failure happens during:
>  Execution failed for task ':hibernate-core:xjc'
>
> and I'm not sure how to override the JVM flags for that plugin execution.
>
> Thanks,
> Sanne
>
>
>>
>>>
>>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <sanne at hibernate.org> wrote:
>>>>
>>>> Hi all,
>>>> please try to have a look at this page when you have a moment:
>>>>  - http://ci.hibernate.org/view/JDK9/
>>>>
>>>> Hibernate Search is working, and it shouldn't be too hard to get the
>>>> others "green" as well.
>>>>
>>>> I've disabled some integration tests to get there, notably:
>>>>  - OSGi tests: Karaf is not ready for it.
>>>>  - Documentation build: Asciidoc will probably need an update.
>>>>  - WildFly integration tests: the WildFly team is aware, will need a
>>>> minor upgrade.
>>>>
>>>> I don't believe these issues are relevant, so I'm satisfied that all
>>>> other tests working fine mean that the project will pretty much work
>>>> out of the box for end users - at worst their container won't work,
>>>> but that's not our responsibility to test for.
>>>>
>>>> Could you all contribute a bit to get all projects show "green" on this
>>>> page?
>>>>
>>>> Some "workarounds" you might want to apply:
>>>>  - the Logger interfaces won't compile because of a known issue, this
>>>> can be worked around for now by having the compilation phase also
>>>> explicitly depend on this artifact:
>>>>
>>>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>>>>  - you'll have a ClassNotFoundException on JAXB usage unless you set
>>>> this JVM flag:
>>>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>>>> (This one is not a bug but will be required to be set by end users as
>>>> well - or we provide our own XML parser, that might be more user
>>>> friendly).
>>>>
>>>> As far as I know, other issues with the build tools have been solved
>>>> already - including Gradle.
>>>>
>>>> Thanks,
>>>> Sanne
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Sun Jun 12 20:15:55 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 13 Jun 2016 01:15:55 +0100
Subject: [hibernate-dev] Revert API change in org.hibernate.Query
In-Reply-To: <CAFdSV9saGYHbW=GsVcqZXgWbUh8C=8hqRmgFkcj=JwtfTRxwcA@mail.gmail.com>
References: <CAFm4XO1dwGguf8HoOTur=58zB7uwf+22oJxttgp0AZXvQGdH0Q@mail.gmail.com>
	<CAFdSV9saGYHbW=GsVcqZXgWbUh8C=8hqRmgFkcj=JwtfTRxwcA@mail.gmail.com>
Message-ID: <CAFm4XO1GXUnG8P20EFH2p2WhGNJcNCyuax2EaeTNamgX9+uU+w@mail.gmail.com>

On 7 June 2016 at 13:41, Steve Ebersole <steve at hibernate.org> wrote:
> If you send a PR I will include it.

Thanks Steve, I finally got to it:
 - https://hibernate.atlassian.net/browse/HHH-10839
 - https://github.com/hibernate/hibernate-orm/pull/1418



>
> On Sun, Jun 5, 2016 at 11:00 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> I just noticed that the org.hibernate.Query interface was deprecated
>> in 5.2, with the suggestion to use org.hibernate.query.Query now.
>> That's ok, but it seems the "deprecation process" also forced some API
>> changes already on the deprecated interface which seem might have been
>> unintentional.
>>
>> The builder methods on org.hibernate.Query used to allow returning
>> "this" to chain methods,
>> although this seems no longer possible as the API now declares the
>> return type should be the new one, org.hibernate.query.Query.
>>
>> Could we fix this by relaxing the return to the older deprecated method?
>>
>> in practice:
>>
>>  org.hibernate.query.Query<R> setFirstResult(int startPosition);
>>
>> should be:
>>
>>  org.hibernate.Query<R> setFirstResult(int startPosition);
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From manderse at redhat.com  Sun Jun 12 18:35:47 2016
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 13 Jun 2016 00:35:47 +0200
Subject: [hibernate-dev] Eclipse Che - quickstart for Hibernate
	contributions?
In-Reply-To: <CAFm4XO2o9u6Su-Tg4U4MjOu=VUHqc8a842yB5FmEs845KH60OQ@mail.gmail.com>
References: <CAFm4XO2o9u6Su-Tg4U4MjOu=VUHqc8a842yB5FmEs845KH60OQ@mail.gmail.com>
Message-ID: <0C2C26FA-229B-4FD4-B42A-FAB97430B108@redhat.com>

Hi Sanne,

sorry for missing this mail - fell into my "read when on long 
flights"-folder.

Those projects are setup by volunteers using Che and then shared.

I've cc'ed you in a thread/mail to them on this subject - I'm also 
meeting with them this week so might get a more direct answer there.

/max

> Hi Max,
>
> I just noticed that several popular open source projects, including
> our "sister projects" WildFly and Vert.X have some kind of public
> workspace to help people getting started to contribute:
>
> http://www.eclipse.org/che/getting-started/
>
> Would you know what it would take to include some of our projects 
> there?
>
> Thanks,
> Sanne


/max
http://about.me/maxandersen

From gunnar at hibernate.org  Mon Jun 13 02:34:44 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 13 Jun 2016 08:34:44 +0200
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
Message-ID: <CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>

Hey,

I hit the same issue with the injection plug-in in HV.

It was used for obtaining the version of HV at runtime. I worked around it
by obtaining that from the package instead [1]:

    return SomeHvClass.class.getPackage().getImplementationVersion();

If that's all what the injection plug-in is used for in ORM as well (and
you don't depend on that version info e.g. during testing in the IDE, where
there is no JAR manifest yet which is the source of the version with that
approach), you could do the same there.

--Gunnar

[1]
https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34


2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Some more progress by simply setting this environment variable:
>
> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
> java.xml.bind"
>
> But it's getting tricky:
>
> Caused by: compile error: javassist.NotFoundException: java.lang.String
>    at javassist.compiler.Javac.compileBody(Javac.java:229)
>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
>    ... 76 more
>
> This seems to be caused by the following plugin, which I'm not familiar
> with:
>  -
> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
> Is this something which we could disable/skip/remove for now, or
> update to not require Javassist?
>
> Thanks,
> sanne
>
> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org> wrote:
> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org> wrote:
> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org> wrote:
> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about that?
> >>
> >> Not sure, that's a new one :)
> >> It could be related to https://issues.gradle.org/browse/GRADLE-3287 ?
> >>
> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
> >> terminal at the moment, I could try later.
> >
> > I've upgraded to Gradle 2.13, the pull request is here:
> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
> >
> > It solved that specific issue, but it's not enough. I'm still trying
> > to hack a workaround for the next step, but in the meantime that PR
> > could be considered independently.
> >
> > I could use some pointers with Gradle and the custom plugins we use;
> > essentially we need to pass some additional JVM flags, including to
> > javac, like here:
> >  -
> https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
> >
> > But the failure happens during:
> >  Execution failed for task ':hibernate-core:xjc'
> >
> > and I'm not sure how to override the JVM flags for that plugin execution.
> >
> > Thanks,
> > Sanne
> >
> >
> >>
> >>>
> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>>>
> >>>> Hi all,
> >>>> please try to have a look at this page when you have a moment:
> >>>>  - http://ci.hibernate.org/view/JDK9/
> >>>>
> >>>> Hibernate Search is working, and it shouldn't be too hard to get the
> >>>> others "green" as well.
> >>>>
> >>>> I've disabled some integration tests to get there, notably:
> >>>>  - OSGi tests: Karaf is not ready for it.
> >>>>  - Documentation build: Asciidoc will probably need an update.
> >>>>  - WildFly integration tests: the WildFly team is aware, will need a
> >>>> minor upgrade.
> >>>>
> >>>> I don't believe these issues are relevant, so I'm satisfied that all
> >>>> other tests working fine mean that the project will pretty much work
> >>>> out of the box for end users - at worst their container won't work,
> >>>> but that's not our responsibility to test for.
> >>>>
> >>>> Could you all contribute a bit to get all projects show "green" on
> this
> >>>> page?
> >>>>
> >>>> Some "workarounds" you might want to apply:
> >>>>  - the Logger interfaces won't compile because of a known issue, this
> >>>> can be worked around for now by having the compilation phase also
> >>>> explicitly depend on this artifact:
> >>>>
> >>>>
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
> >>>>  - you'll have a ClassNotFoundException on JAXB usage unless you set
> >>>> this JVM flag:
> >>>>
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
> >>>> (This one is not a bug but will be required to be set by end users as
> >>>> well - or we provide our own XML parser, that might be more user
> >>>> friendly).
> >>>>
> >>>> As far as I know, other issues with the build tools have been solved
> >>>> already - including Gradle.
> >>>>
> >>>> Thanks,
> >>>> Sanne
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> 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
>

From sanne at hibernate.org  Mon Jun 13 03:49:00 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 13 Jun 2016 08:49:00 +0100
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
Message-ID: <CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>

On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hey,
>
> I hit the same issue with the injection plug-in in HV.
>
> It was used for obtaining the version of HV at runtime. I worked around it
> by obtaining that from the package instead [1]:
>
>     return SomeHvClass.class.getPackage().getImplementationVersion();

Right, that looks a lot like
 - https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
;)

>
> If that's all what the injection plug-in is used for in ORM as well (and you
> don't depend on that version info e.g. during testing in the IDE, where
> there is no JAR manifest yet which is the source of the version with that
> approach), you could do the same there.
>
> --Gunnar
>
> [1]
> https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
>
>
> 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Some more progress by simply setting this environment variable:
>>
>> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
>> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
>> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
>> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
>> java.xml.bind"
>>
>> But it's getting tricky:
>>
>> Caused by: compile error: javassist.NotFoundException: java.lang.String
>>    at javassist.compiler.Javac.compileBody(Javac.java:229)
>>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
>>    ... 76 more
>>
>> This seems to be caused by the following plugin, which I'm not familiar
>> with:
>>  -
>> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
>> Is this something which we could disable/skip/remove for now, or
>> update to not require Javassist?
>>
>> Thanks,
>> sanne
>>
>> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org> wrote:
>> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org> wrote:
>> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org> wrote:
>> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about that?
>> >>
>> >> Not sure, that's a new one :)
>> >> It could be related to https://issues.gradle.org/browse/GRADLE-3287 ?
>> >>
>> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
>> >> terminal at the moment, I could try later.
>> >
>> > I've upgraded to Gradle 2.13, the pull request is here:
>> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
>> >
>> > It solved that specific issue, but it's not enough. I'm still trying
>> > to hack a workaround for the next step, but in the meantime that PR
>> > could be considered independently.
>> >
>> > I could use some pointers with Gradle and the custom plugins we use;
>> > essentially we need to pass some additional JVM flags, including to
>> > javac, like here:
>> >  -
>> > https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
>> >
>> > But the failure happens during:
>> >  Execution failed for task ':hibernate-core:xjc'
>> >
>> > and I'm not sure how to override the JVM flags for that plugin
>> > execution.
>> >
>> > Thanks,
>> > Sanne
>> >
>> >
>> >>
>> >>>
>> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <sanne at hibernate.org>
>> >>> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>> please try to have a look at this page when you have a moment:
>> >>>>  - http://ci.hibernate.org/view/JDK9/
>> >>>>
>> >>>> Hibernate Search is working, and it shouldn't be too hard to get the
>> >>>> others "green" as well.
>> >>>>
>> >>>> I've disabled some integration tests to get there, notably:
>> >>>>  - OSGi tests: Karaf is not ready for it.
>> >>>>  - Documentation build: Asciidoc will probably need an update.
>> >>>>  - WildFly integration tests: the WildFly team is aware, will need a
>> >>>> minor upgrade.
>> >>>>
>> >>>> I don't believe these issues are relevant, so I'm satisfied that all
>> >>>> other tests working fine mean that the project will pretty much work
>> >>>> out of the box for end users - at worst their container won't work,
>> >>>> but that's not our responsibility to test for.
>> >>>>
>> >>>> Could you all contribute a bit to get all projects show "green" on
>> >>>> this
>> >>>> page?
>> >>>>
>> >>>> Some "workarounds" you might want to apply:
>> >>>>  - the Logger interfaces won't compile because of a known issue, this
>> >>>> can be worked around for now by having the compilation phase also
>> >>>> explicitly depend on this artifact:
>> >>>>
>> >>>>
>> >>>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>> >>>>  - you'll have a ClassNotFoundException on JAXB usage unless you set
>> >>>> this JVM flag:
>> >>>>
>> >>>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>> >>>> (This one is not a bug but will be required to be set by end users as
>> >>>> well - or we provide our own XML parser, that might be more user
>> >>>> friendly).
>> >>>>
>> >>>> As far as I know, other issues with the build tools have been solved
>> >>>> already - including Gradle.
>> >>>>
>> >>>> Thanks,
>> >>>> Sanne
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> 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
>
>

From gunnar at hibernate.org  Mon Jun 13 03:59:41 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 13 Jun 2016 09:59:41 +0200
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
Message-ID: <CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>

Yep, we discussed that approach last year already:
http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html

2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hey,
> >
> > I hit the same issue with the injection plug-in in HV.
> >
> > It was used for obtaining the version of HV at runtime. I worked around
> it
> > by obtaining that from the package instead [1]:
> >
> >     return SomeHvClass.class.getPackage().getImplementationVersion();
>
> Right, that looks a lot like
>  -
> https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
> ;)
>
> >
> > If that's all what the injection plug-in is used for in ORM as well (and
> you
> > don't depend on that version info e.g. during testing in the IDE, where
> > there is no JAR manifest yet which is the source of the version with that
> > approach), you could do the same there.
> >
> > --Gunnar
> >
> > [1]
> >
> https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
> >
> >
> > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> Some more progress by simply setting this environment variable:
> >>
> >>
> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
> >> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
> >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
> >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
> >> java.xml.bind"
> >>
> >> But it's getting tricky:
> >>
> >> Caused by: compile error: javassist.NotFoundException: java.lang.String
> >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
> >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
> >>    ... 76 more
> >>
> >> This seems to be caused by the following plugin, which I'm not familiar
> >> with:
> >>  -
> >>
> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
> >> Is this something which we could disable/skip/remove for now, or
> >> update to not require Javassist?
> >>
> >> Thanks,
> >> sanne
> >>
> >> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org> wrote:
> >> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about
> that?
> >> >>
> >> >> Not sure, that's a new one :)
> >> >> It could be related to https://issues.gradle.org/browse/GRADLE-3287
> ?
> >> >>
> >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
> >> >> terminal at the moment, I could try later.
> >> >
> >> > I've upgraded to Gradle 2.13, the pull request is here:
> >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
> >> >
> >> > It solved that specific issue, but it's not enough. I'm still trying
> >> > to hack a workaround for the next step, but in the meantime that PR
> >> > could be considered independently.
> >> >
> >> > I could use some pointers with Gradle and the custom plugins we use;
> >> > essentially we need to pass some additional JVM flags, including to
> >> > javac, like here:
> >> >  -
> >> >
> https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
> >> >
> >> > But the failure happens during:
> >> >  Execution failed for task ':hibernate-core:xjc'
> >> >
> >> > and I'm not sure how to override the JVM flags for that plugin
> >> > execution.
> >> >
> >> > Thanks,
> >> > Sanne
> >> >
> >> >
> >> >>
> >> >>>
> >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <sanne at hibernate.org>
> >> >>> wrote:
> >> >>>>
> >> >>>> Hi all,
> >> >>>> please try to have a look at this page when you have a moment:
> >> >>>>  - http://ci.hibernate.org/view/JDK9/
> >> >>>>
> >> >>>> Hibernate Search is working, and it shouldn't be too hard to get
> the
> >> >>>> others "green" as well.
> >> >>>>
> >> >>>> I've disabled some integration tests to get there, notably:
> >> >>>>  - OSGi tests: Karaf is not ready for it.
> >> >>>>  - Documentation build: Asciidoc will probably need an update.
> >> >>>>  - WildFly integration tests: the WildFly team is aware, will need
> a
> >> >>>> minor upgrade.
> >> >>>>
> >> >>>> I don't believe these issues are relevant, so I'm satisfied that
> all
> >> >>>> other tests working fine mean that the project will pretty much
> work
> >> >>>> out of the box for end users - at worst their container won't work,
> >> >>>> but that's not our responsibility to test for.
> >> >>>>
> >> >>>> Could you all contribute a bit to get all projects show "green" on
> >> >>>> this
> >> >>>> page?
> >> >>>>
> >> >>>> Some "workarounds" you might want to apply:
> >> >>>>  - the Logger interfaces won't compile because of a known issue,
> this
> >> >>>> can be worked around for now by having the compilation phase also
> >> >>>> explicitly depend on this artifact:
> >> >>>>
> >> >>>>
> >> >>>>
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
> >> >>>>  - you'll have a ClassNotFoundException on JAXB usage unless you
> set
> >> >>>> this JVM flag:
> >> >>>>
> >> >>>>
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
> >> >>>> (This one is not a bug but will be required to be set by end users
> as
> >> >>>> well - or we provide our own XML parser, that might be more user
> >> >>>> friendly).
> >> >>>>
> >> >>>> As far as I know, other issues with the build tools have been
> solved
> >> >>>> already - including Gradle.
> >> >>>>
> >> >>>> Thanks,
> >> >>>> Sanne
> >> >>>> _______________________________________________
> >> >>>> hibernate-dev mailing list
> >> >>>> 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
> >
> >
>

From sanne at hibernate.org  Mon Jun 13 05:32:54 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 13 Jun 2016 10:32:54 +0100
Subject: [hibernate-dev] Eclipse Che - quickstart for Hibernate
	contributions?
In-Reply-To: <0C2C26FA-229B-4FD4-B42A-FAB97430B108@redhat.com>
References: <CAFm4XO2o9u6Su-Tg4U4MjOu=VUHqc8a842yB5FmEs845KH60OQ@mail.gmail.com>
	<0C2C26FA-229B-4FD4-B42A-FAB97430B108@redhat.com>
Message-ID: <CAFm4XO22XL6cOMX8GL=6kidQ1L-w1SgnWUry0JWtk+xTwe-A+w@mail.gmail.com>

Thanks Max!

no worries, we have no rush. Just seems nice to be listed there as well ;)

My evil plan includes to make it easy to write a unit test to somehow
associate to the process of reporting an issue on JIRA.. it would be
great if you could discuss this use case when you meet with them face
to face?

I'll be watching the other thread you started; including Pete as I
discussed this with him too.

Cheers,
Sanne

On 12 June 2016 at 23:35, Max Rydahl Andersen <manderse at redhat.com> wrote:
> Hi Sanne,
>
> sorry for missing this mail - fell into my "read when on long
> flights"-folder.
>
> Those projects are setup by volunteers using Che and then shared.
>
> I've cc'ed you in a thread/mail to them on this subject - I'm also meeting
> with them this week so might get a more direct answer there.
>
> /max
>
>
>> Hi Max,
>>
>> I just noticed that several popular open source projects, including
>> our "sister projects" WildFly and Vert.X have some kind of public
>> workspace to help people getting started to contribute:
>>
>> http://www.eclipse.org/che/getting-started/
>>
>> Would you know what it would take to include some of our projects there?
>>
>> Thanks,
>> Sanne
>
>
>
> /max
> http://about.me/maxandersen

From sanne at hibernate.org  Tue Jun 14 12:33:20 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 14 Jun 2016 17:33:20 +0100
Subject: [hibernate-dev] No Hibernate Search version compatible with
	Hibernate ORM 5.2.0.Final
Message-ID: <CAFm4XO2r_BXySW8z-XevWWKYyKwKSdgYPFx0PZ2AE0fRhwfLSA@mail.gmail.com>

There have been various complaints that people can't upgrade to the
latest Hibernate ORM because they don't have a compatible version of
Hibernate Search.

Rejected 3 issues on JIRA as duplicates of:
https://hibernate.atlassian.net/browse/HSEARCH-2296

We never guaranteed compatibility beyond the micro-range, still we
probably should do something about this as I hate rejecting issues.

Status reminder:
 - we're not ready to release a "Final" version of Hibernate Search
branch 5.6 because the Elasticsearch work isn't complete.
 - the changes needed to be compatible with Hibernate ORM 5.2 are
breaking, i.e. it won't work with Hibernate ORM 5.0 and 5.1 if I apply
them.
 - Hibernate Search 5.5 (the previous stable branch) works fine with
both ORM 5.0.x and 5.1.x.
 - Breaking compatibility with ORM 5.1 means to break compatibility
with WildFly 10 (unless they also upgrade or we start shipping
alternative ORM modules).

On top of this, Hibernate OGM was wishing to have an upgrade to ORM
5.1.x. I don't see how we can squeeze that in.

The only solution I see is that people will have to be patient and use
ORM 5.0 / 5.1 for now.

Better ideas?

I have a branch of Search which is making progress towards ORM 5.2
compatibility.. not fully complete but it's very clear already that we
can't keep compatibility open for a wider range of ORM versions. Feel
free to try ;)

Also related, the proposal here:
 - https://hibernate.atlassian.net/browse/HHH-10793

Thanks,
Sanne

From steve at hibernate.org  Wed Jun 15 14:29:20 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Jun 2016 18:29:20 +0000
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
	<CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
Message-ID: <CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>

WRT JAXB (XJC) I am completely lost.

Sanne I tried your solution of specifying an addmod for jaxb to GRADLE_OPTS
but get the same result (ExceptionInInitializerError) with and without that
change.  So not sure how you got that to work.

I did try the alternative we discussed of defining an explicit build
dependency on JAXB (which again has no effect):


xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'


For some background, XJC is currently performed via Gradle's AntBuilder
support using the jaxb2_commons Ant task
(org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using Sun's
com.sun.tools.xjc.XJCTask directly.  Neither make any difference.  The
fundamental problem is that for Ant execution Gradle simply reuses its VM.
So to get this applied (iiuc) the only real option is to configure the
Gradle launch to include the addmod (which makes it more odd that
GRADLE_OPTS did not work for me).

The other option is to write a new Gradle XjcTask that executes the XJC
tool directly.  That we can use Gradle to help us fork and pass the addmod
option to the forked process.  I think :)


On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Yep, we discussed that approach last year already:
> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
>
> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org> wrote:
> > > Hey,
> > >
> > > I hit the same issue with the injection plug-in in HV.
> > >
> > > It was used for obtaining the version of HV at runtime. I worked around
> > it
> > > by obtaining that from the package instead [1]:
> > >
> > >     return SomeHvClass.class.getPackage().getImplementationVersion();
> >
> > Right, that looks a lot like
> >  -
> >
> https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
> > ;)
> >
> > >
> > > If that's all what the injection plug-in is used for in ORM as well
> (and
> > you
> > > don't depend on that version info e.g. during testing in the IDE, where
> > > there is no JAR manifest yet which is the source of the version with
> that
> > > approach), you could do the same there.
> > >
> > > --Gunnar
> > >
> > > [1]
> > >
> >
> https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
> > >
> > >
> > > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> > >>
> > >> Some more progress by simply setting this environment variable:
> > >>
> > >>
> >
> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
> > >> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
> > >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
> > >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
> > >> java.xml.bind"
> > >>
> > >> But it's getting tricky:
> > >>
> > >> Caused by: compile error: javassist.NotFoundException:
> java.lang.String
> > >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
> > >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
> > >>    ... 76 more
> > >>
> > >> This seems to be caused by the following plugin, which I'm not
> familiar
> > >> with:
> > >>  -
> > >>
> >
> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
> > >> Is this something which we could disable/skip/remove for now, or
> > >> update to not require Javassist?
> > >>
> > >> Thanks,
> > >> sanne
> > >>
> > >> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> > >> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> > >> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org>
> > wrote:
> > >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about
> > that?
> > >> >>
> > >> >> Not sure, that's a new one :)
> > >> >> It could be related to
> https://issues.gradle.org/browse/GRADLE-3287
> > ?
> > >> >>
> > >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
> > >> >> terminal at the moment, I could try later.
> > >> >
> > >> > I've upgraded to Gradle 2.13, the pull request is here:
> > >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
> > >> >
> > >> > It solved that specific issue, but it's not enough. I'm still trying
> > >> > to hack a workaround for the next step, but in the meantime that PR
> > >> > could be considered independently.
> > >> >
> > >> > I could use some pointers with Gradle and the custom plugins we use;
> > >> > essentially we need to pass some additional JVM flags, including to
> > >> > javac, like here:
> > >> >  -
> > >> >
> >
> https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
> > >> >
> > >> > But the failure happens during:
> > >> >  Execution failed for task ':hibernate-core:xjc'
> > >> >
> > >> > and I'm not sure how to override the JVM flags for that plugin
> > >> > execution.
> > >> >
> > >> > Thanks,
> > >> > Sanne
> > >> >
> > >> >
> > >> >>
> > >> >>>
> > >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <
> sanne at hibernate.org>
> > >> >>> wrote:
> > >> >>>>
> > >> >>>> Hi all,
> > >> >>>> please try to have a look at this page when you have a moment:
> > >> >>>>  - http://ci.hibernate.org/view/JDK9/
> > >> >>>>
> > >> >>>> Hibernate Search is working, and it shouldn't be too hard to get
> > the
> > >> >>>> others "green" as well.
> > >> >>>>
> > >> >>>> I've disabled some integration tests to get there, notably:
> > >> >>>>  - OSGi tests: Karaf is not ready for it.
> > >> >>>>  - Documentation build: Asciidoc will probably need an update.
> > >> >>>>  - WildFly integration tests: the WildFly team is aware, will
> need
> > a
> > >> >>>> minor upgrade.
> > >> >>>>
> > >> >>>> I don't believe these issues are relevant, so I'm satisfied that
> > all
> > >> >>>> other tests working fine mean that the project will pretty much
> > work
> > >> >>>> out of the box for end users - at worst their container won't
> work,
> > >> >>>> but that's not our responsibility to test for.
> > >> >>>>
> > >> >>>> Could you all contribute a bit to get all projects show "green"
> on
> > >> >>>> this
> > >> >>>> page?
> > >> >>>>
> > >> >>>> Some "workarounds" you might want to apply:
> > >> >>>>  - the Logger interfaces won't compile because of a known issue,
> > this
> > >> >>>> can be worked around for now by having the compilation phase also
> > >> >>>> explicitly depend on this artifact:
> > >> >>>>
> > >> >>>>
> > >> >>>>
> >
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
> > >> >>>>  - you'll have a ClassNotFoundException on JAXB usage unless you
> > set
> > >> >>>> this JVM flag:
> > >> >>>>
> > >> >>>>
> > https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
> > >> >>>> (This one is not a bug but will be required to be set by end
> users
> > as
> > >> >>>> well - or we provide our own XML parser, that might be more user
> > >> >>>> friendly).
> > >> >>>>
> > >> >>>> As far as I know, other issues with the build tools have been
> > solved
> > >> >>>> already - including Gradle.
> > >> >>>>
> > >> >>>> Thanks,
> > >> >>>> Sanne
> > >> >>>> _______________________________________________
> > >> >>>> hibernate-dev mailing list
> > >> >>>> 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
> > >
> > >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jun 15 15:04:30 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Jun 2016 19:04:30 +0000
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
	<CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
	<CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
Message-ID: <CAFdSV9tOXayCCWLupZP=tJePFx7t-O-c_P52eG4ugrxJhMSCig@mail.gmail.com>

I started a discussion on Gradle forums to start getting some resolution to
this:

https://discuss.gradle.org/t/does-gradle-3-m1-honor-gradle-opts/18070

On Wed, Jun 15, 2016 at 1:29 PM Steve Ebersole <steve at hibernate.org> wrote:

> WRT JAXB (XJC) I am completely lost.
>
> Sanne I tried your solution of specifying an addmod for jaxb to
> GRADLE_OPTS but get the same result (ExceptionInInitializerError) with and
> without that change.  So not sure how you got that to work.
>
> I did try the alternative we discussed of defining an explicit build
> dependency on JAXB (which again has no effect):
>
>
> xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
> xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
> xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
> xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'
>
>
> For some background, XJC is currently performed via Gradle's AntBuilder
> support using the jaxb2_commons Ant task
> (org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using Sun's
> com.sun.tools.xjc.XJCTask directly.  Neither make any difference.  The
> fundamental problem is that for Ant execution Gradle simply reuses its VM.
> So to get this applied (iiuc) the only real option is to configure the
> Gradle launch to include the addmod (which makes it more odd that
> GRADLE_OPTS did not work for me).
>
> The other option is to write a new Gradle XjcTask that executes the XJC
> tool directly.  That we can use Gradle to help us fork and pass the addmod
> option to the forked process.  I think :)
>
>
> On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Yep, we discussed that approach last year already:
>> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
>>
>> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> > On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > > Hey,
>> > >
>> > > I hit the same issue with the injection plug-in in HV.
>> > >
>> > > It was used for obtaining the version of HV at runtime. I worked
>> around
>> > it
>> > > by obtaining that from the package instead [1]:
>> > >
>> > >     return SomeHvClass.class.getPackage().getImplementationVersion();
>> >
>> > Right, that looks a lot like
>> >  -
>> >
>> https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
>> > ;)
>> >
>> > >
>> > > If that's all what the injection plug-in is used for in ORM as well
>> (and
>> > you
>> > > don't depend on that version info e.g. during testing in the IDE,
>> where
>> > > there is no JAR manifest yet which is the source of the version with
>> that
>> > > approach), you could do the same there.
>> > >
>> > > --Gunnar
>> > >
>> > > [1]
>> > >
>> >
>> https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
>> > >
>> > >
>> > > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> > >>
>> > >> Some more progress by simply setting this environment variable:
>> > >>
>> > >>
>> >
>> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
>> > >> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
>> > >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
>> > >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
>> > >> java.xml.bind"
>> > >>
>> > >> But it's getting tricky:
>> > >>
>> > >> Caused by: compile error: javassist.NotFoundException:
>> java.lang.String
>> > >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
>> > >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
>> > >>    ... 76 more
>> > >>
>> > >> This seems to be caused by the following plugin, which I'm not
>> familiar
>> > >> with:
>> > >>  -
>> > >>
>> >
>> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
>> > >> Is this something which we could disable/skip/remove for now, or
>> > >> update to not require Javassist?
>> > >>
>> > >> Thanks,
>> > >> sanne
>> > >>
>> > >> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> > >> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> > >> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> > >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about
>> > that?
>> > >> >>
>> > >> >> Not sure, that's a new one :)
>> > >> >> It could be related to
>> https://issues.gradle.org/browse/GRADLE-3287
>> > ?
>> > >> >>
>> > >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
>> > >> >> terminal at the moment, I could try later.
>> > >> >
>> > >> > I've upgraded to Gradle 2.13, the pull request is here:
>> > >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
>> > >> >
>> > >> > It solved that specific issue, but it's not enough. I'm still
>> trying
>> > >> > to hack a workaround for the next step, but in the meantime that PR
>> > >> > could be considered independently.
>> > >> >
>> > >> > I could use some pointers with Gradle and the custom plugins we
>> use;
>> > >> > essentially we need to pass some additional JVM flags, including to
>> > >> > javac, like here:
>> > >> >  -
>> > >> >
>> >
>> https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
>> > >> >
>> > >> > But the failure happens during:
>> > >> >  Execution failed for task ':hibernate-core:xjc'
>> > >> >
>> > >> > and I'm not sure how to override the JVM flags for that plugin
>> > >> > execution.
>> > >> >
>> > >> > Thanks,
>> > >> > Sanne
>> > >> >
>> > >> >
>> > >> >>
>> > >> >>>
>> > >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero <
>> sanne at hibernate.org>
>> > >> >>> wrote:
>> > >> >>>>
>> > >> >>>> Hi all,
>> > >> >>>> please try to have a look at this page when you have a moment:
>> > >> >>>>  - http://ci.hibernate.org/view/JDK9/
>> > >> >>>>
>> > >> >>>> Hibernate Search is working, and it shouldn't be too hard to get
>> > the
>> > >> >>>> others "green" as well.
>> > >> >>>>
>> > >> >>>> I've disabled some integration tests to get there, notably:
>> > >> >>>>  - OSGi tests: Karaf is not ready for it.
>> > >> >>>>  - Documentation build: Asciidoc will probably need an update.
>> > >> >>>>  - WildFly integration tests: the WildFly team is aware, will
>> need
>> > a
>> > >> >>>> minor upgrade.
>> > >> >>>>
>> > >> >>>> I don't believe these issues are relevant, so I'm satisfied that
>> > all
>> > >> >>>> other tests working fine mean that the project will pretty much
>> > work
>> > >> >>>> out of the box for end users - at worst their container won't
>> work,
>> > >> >>>> but that's not our responsibility to test for.
>> > >> >>>>
>> > >> >>>> Could you all contribute a bit to get all projects show "green"
>> on
>> > >> >>>> this
>> > >> >>>> page?
>> > >> >>>>
>> > >> >>>> Some "workarounds" you might want to apply:
>> > >> >>>>  - the Logger interfaces won't compile because of a known issue,
>> > this
>> > >> >>>> can be worked around for now by having the compilation phase
>> also
>> > >> >>>> explicitly depend on this artifact:
>> > >> >>>>
>> > >> >>>>
>> > >> >>>>
>> >
>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>> > >> >>>>  - you'll have a ClassNotFoundException on JAXB usage unless you
>> > set
>> > >> >>>> this JVM flag:
>> > >> >>>>
>> > >> >>>>
>> > https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>> > >> >>>> (This one is not a bug but will be required to be set by end
>> users
>> > as
>> > >> >>>> well - or we provide our own XML parser, that might be more user
>> > >> >>>> friendly).
>> > >> >>>>
>> > >> >>>> As far as I know, other issues with the build tools have been
>> > solved
>> > >> >>>> already - including Gradle.
>> > >> >>>>
>> > >> >>>> Thanks,
>> > >> >>>> Sanne
>> > >> >>>> _______________________________________________
>> > >> >>>> hibernate-dev mailing list
>> > >> >>>> 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
>> > >
>> > >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Wed Jun 15 16:13:08 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 15 Jun 2016 21:13:08 +0100
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
	<CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
	<CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
Message-ID: <CAFm4XO0WAwrkR+vJMgxnuugnT+B09LVuHJAe54Oawi900pta8g@mail.gmail.com>

On 15 June 2016 at 19:29, Steve Ebersole <steve at hibernate.org> wrote:
> WRT JAXB (XJC) I am completely lost.
>
> Sanne I tried your solution of specifying an addmod for jaxb to GRADLE_OPTS
> but get the same result (ExceptionInInitializerError) with and without that
> change.  So not sure how you got that to work.

Steve, sorry if that wasn't clear: this didn't work for me either.
I used the GRADLE_OPTS to bypass other issues which I had before
reaching this point, but then I got stuck on the 'xjc' plugin, and
that's were I asked if we could bypass/skip/rewrite the plugin.

>
> I did try the alternative we discussed of defining an explicit build
> dependency on JAXB (which again has no effect):
>
>
> xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
> xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
> xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
> xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'
>
>
> For some background, XJC is currently performed via Gradle's AntBuilder
> support using the jaxb2_commons Ant task
> (org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using Sun's
> com.sun.tools.xjc.XJCTask directly.  Neither make any difference.  The
> fundamental problem is that for Ant execution Gradle simply reuses its VM.
> So to get this applied (iiuc) the only real option is to configure the
> Gradle launch to include the addmod (which makes it more odd that
> GRADLE_OPTS did not work for me).
>
> The other option is to write a new Gradle XjcTask that executes the XJC tool
> directly.  That we can use Gradle to help us fork and pass the addmod option
> to the forked process.  I think :)
>
>
> On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Yep, we discussed that approach last year already:
>> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
>>
>> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> > On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > > Hey,
>> > >
>> > > I hit the same issue with the injection plug-in in HV.
>> > >
>> > > It was used for obtaining the version of HV at runtime. I worked
>> > > around
>> > it
>> > > by obtaining that from the package instead [1]:
>> > >
>> > >     return SomeHvClass.class.getPackage().getImplementationVersion();
>> >
>> > Right, that looks a lot like
>> >  -
>> >
>> > https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
>> > ;)
>> >
>> > >
>> > > If that's all what the injection plug-in is used for in ORM as well
>> > > (and
>> > you
>> > > don't depend on that version info e.g. during testing in the IDE,
>> > > where
>> > > there is no JAR manifest yet which is the source of the version with
>> > > that
>> > > approach), you could do the same there.
>> > >
>> > > --Gunnar
>> > >
>> > > [1]
>> > >
>> >
>> > https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
>> > >
>> > >
>> > > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> > >>
>> > >> Some more progress by simply setting this environment variable:
>> > >>
>> > >>
>> >
>> > GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
>> > >> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
>> > >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
>> > >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
>> > >> java.xml.bind"
>> > >>
>> > >> But it's getting tricky:
>> > >>
>> > >> Caused by: compile error: javassist.NotFoundException:
>> > >> java.lang.String
>> > >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
>> > >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
>> > >>    ... 76 more
>> > >>
>> > >> This seems to be caused by the following plugin, which I'm not
>> > >> familiar
>> > >> with:
>> > >>  -
>> > >>
>> >
>> > org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
>> > >> Is this something which we could disable/skip/remove for now, or
>> > >> update to not require Javassist?
>> > >>
>> > >> Thanks,
>> > >> sanne
>> > >>
>> > >> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org>
>> > >> wrote:
>> > >> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> > >> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> > >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea about
>> > that?
>> > >> >>
>> > >> >> Not sure, that's a new one :)
>> > >> >> It could be related to
>> > >> >> https://issues.gradle.org/browse/GRADLE-3287
>> > ?
>> > >> >>
>> > >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
>> > >> >> terminal at the moment, I could try later.
>> > >> >
>> > >> > I've upgraded to Gradle 2.13, the pull request is here:
>> > >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
>> > >> >
>> > >> > It solved that specific issue, but it's not enough. I'm still
>> > >> > trying
>> > >> > to hack a workaround for the next step, but in the meantime that PR
>> > >> > could be considered independently.
>> > >> >
>> > >> > I could use some pointers with Gradle and the custom plugins we
>> > >> > use;
>> > >> > essentially we need to pass some additional JVM flags, including to
>> > >> > javac, like here:
>> > >> >  -
>> > >> >
>> >
>> > https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
>> > >> >
>> > >> > But the failure happens during:
>> > >> >  Execution failed for task ':hibernate-core:xjc'
>> > >> >
>> > >> > and I'm not sure how to override the JVM flags for that plugin
>> > >> > execution.
>> > >> >
>> > >> > Thanks,
>> > >> > Sanne
>> > >> >
>> > >> >
>> > >> >>
>> > >> >>>
>> > >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero
>> > >> >>> <sanne at hibernate.org>
>> > >> >>> wrote:
>> > >> >>>>
>> > >> >>>> Hi all,
>> > >> >>>> please try to have a look at this page when you have a moment:
>> > >> >>>>  - http://ci.hibernate.org/view/JDK9/
>> > >> >>>>
>> > >> >>>> Hibernate Search is working, and it shouldn't be too hard to get
>> > the
>> > >> >>>> others "green" as well.
>> > >> >>>>
>> > >> >>>> I've disabled some integration tests to get there, notably:
>> > >> >>>>  - OSGi tests: Karaf is not ready for it.
>> > >> >>>>  - Documentation build: Asciidoc will probably need an update.
>> > >> >>>>  - WildFly integration tests: the WildFly team is aware, will
>> > >> >>>> need
>> > a
>> > >> >>>> minor upgrade.
>> > >> >>>>
>> > >> >>>> I don't believe these issues are relevant, so I'm satisfied that
>> > all
>> > >> >>>> other tests working fine mean that the project will pretty much
>> > work
>> > >> >>>> out of the box for end users - at worst their container won't
>> > >> >>>> work,
>> > >> >>>> but that's not our responsibility to test for.
>> > >> >>>>
>> > >> >>>> Could you all contribute a bit to get all projects show "green"
>> > >> >>>> on
>> > >> >>>> this
>> > >> >>>> page?
>> > >> >>>>
>> > >> >>>> Some "workarounds" you might want to apply:
>> > >> >>>>  - the Logger interfaces won't compile because of a known issue,
>> > this
>> > >> >>>> can be worked around for now by having the compilation phase
>> > >> >>>> also
>> > >> >>>> explicitly depend on this artifact:
>> > >> >>>>
>> > >> >>>>
>> > >> >>>>
>> >
>> > https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>> > >> >>>>  - you'll have a ClassNotFoundException on JAXB usage unless you
>> > set
>> > >> >>>> this JVM flag:
>> > >> >>>>
>> > >> >>>>
>> > https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>> > >> >>>> (This one is not a bug but will be required to be set by end
>> > >> >>>> users
>> > as
>> > >> >>>> well - or we provide our own XML parser, that might be more user
>> > >> >>>> friendly).
>> > >> >>>>
>> > >> >>>> As far as I know, other issues with the build tools have been
>> > solved
>> > >> >>>> already - including Gradle.
>> > >> >>>>
>> > >> >>>> Thanks,
>> > >> >>>> Sanne
>> > >> >>>> _______________________________________________
>> > >> >>>> hibernate-dev mailing list
>> > >> >>>> 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
>> > >
>> > >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Jun 15 16:14:19 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Jun 2016 20:14:19 +0000
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFm4XO0WAwrkR+vJMgxnuugnT+B09LVuHJAe54Oawi900pta8g@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
	<CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
	<CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
	<CAFm4XO0WAwrkR+vJMgxnuugnT+B09LVuHJAe54Oawi900pta8g@mail.gmail.com>
Message-ID: <CAFdSV9sH5hBLmFoSZfm76htv43uzQqRJKVeEC_pCaiEqHPt1YQ@mail.gmail.com>

No worries, I understand.

On Wed, Jun 15, 2016 at 3:13 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 15 June 2016 at 19:29, Steve Ebersole <steve at hibernate.org> wrote:
> > WRT JAXB (XJC) I am completely lost.
> >
> > Sanne I tried your solution of specifying an addmod for jaxb to
> GRADLE_OPTS
> > but get the same result (ExceptionInInitializerError) with and without
> that
> > change.  So not sure how you got that to work.
>
> Steve, sorry if that wasn't clear: this didn't work for me either.
> I used the GRADLE_OPTS to bypass other issues which I had before
> reaching this point, but then I got stuck on the 'xjc' plugin, and
> that's were I asked if we could bypass/skip/rewrite the plugin.
>
> >
> > I did try the alternative we discussed of defining an explicit build
> > dependency on JAXB (which again has no effect):
> >
> >
> > xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
> > xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'
> >
> >
> > For some background, XJC is currently performed via Gradle's AntBuilder
> > support using the jaxb2_commons Ant task
> > (org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using Sun's
> > com.sun.tools.xjc.XJCTask directly.  Neither make any difference.  The
> > fundamental problem is that for Ant execution Gradle simply reuses its
> VM.
> > So to get this applied (iiuc) the only real option is to configure the
> > Gradle launch to include the addmod (which makes it more odd that
> > GRADLE_OPTS did not work for me).
> >
> > The other option is to write a new Gradle XjcTask that executes the XJC
> tool
> > directly.  That we can use Gradle to help us fork and pass the addmod
> option
> > to the forked process.  I think :)
> >
> >
> > On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> Yep, we discussed that approach last year already:
> >> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
> >>
> >> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> > On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > > Hey,
> >> > >
> >> > > I hit the same issue with the injection plug-in in HV.
> >> > >
> >> > > It was used for obtaining the version of HV at runtime. I worked
> >> > > around
> >> > it
> >> > > by obtaining that from the package instead [1]:
> >> > >
> >> > >     return
> SomeHvClass.class.getPackage().getImplementationVersion();
> >> >
> >> > Right, that looks a lot like
> >> >  -
> >> >
> >> >
> https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
> >> > ;)
> >> >
> >> > >
> >> > > If that's all what the injection plug-in is used for in ORM as well
> >> > > (and
> >> > you
> >> > > don't depend on that version info e.g. during testing in the IDE,
> >> > > where
> >> > > there is no JAR manifest yet which is the source of the version with
> >> > > that
> >> > > approach), you could do the same there.
> >> > >
> >> > > --Gunnar
> >> > >
> >> > > [1]
> >> > >
> >> >
> >> >
> https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
> >> > >
> >> > >
> >> > > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >> > >>
> >> > >> Some more progress by simply setting this environment variable:
> >> > >>
> >> > >>
> >> >
> >> >
> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
> >> > >> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
> >> > >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
> >> > >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
> >> > >> java.xml.bind"
> >> > >>
> >> > >> But it's getting tricky:
> >> > >>
> >> > >> Caused by: compile error: javassist.NotFoundException:
> >> > >> java.lang.String
> >> > >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
> >> > >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
> >> > >>    ... 76 more
> >> > >>
> >> > >> This seems to be caused by the following plugin, which I'm not
> >> > >> familiar
> >> > >> with:
> >> > >>  -
> >> > >>
> >> >
> >> >
> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
> >> > >> Is this something which we could disable/skip/remove for now, or
> >> > >> update to not require Javassist?
> >> > >>
> >> > >> Thanks,
> >> > >> sanne
> >> > >>
> >> > >> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org>
> >> > >> wrote:
> >> > >> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org>
> >> > wrote:
> >> > >> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org>
> >> > wrote:
> >> > >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea
> about
> >> > that?
> >> > >> >>
> >> > >> >> Not sure, that's a new one :)
> >> > >> >> It could be related to
> >> > >> >> https://issues.gradle.org/browse/GRADLE-3287
> >> > ?
> >> > >> >>
> >> > >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
> >> > >> >> terminal at the moment, I could try later.
> >> > >> >
> >> > >> > I've upgraded to Gradle 2.13, the pull request is here:
> >> > >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
> >> > >> >
> >> > >> > It solved that specific issue, but it's not enough. I'm still
> >> > >> > trying
> >> > >> > to hack a workaround for the next step, but in the meantime that
> PR
> >> > >> > could be considered independently.
> >> > >> >
> >> > >> > I could use some pointers with Gradle and the custom plugins we
> >> > >> > use;
> >> > >> > essentially we need to pass some additional JVM flags, including
> to
> >> > >> > javac, like here:
> >> > >> >  -
> >> > >> >
> >> >
> >> >
> https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
> >> > >> >
> >> > >> > But the failure happens during:
> >> > >> >  Execution failed for task ':hibernate-core:xjc'
> >> > >> >
> >> > >> > and I'm not sure how to override the JVM flags for that plugin
> >> > >> > execution.
> >> > >> >
> >> > >> > Thanks,
> >> > >> > Sanne
> >> > >> >
> >> > >> >
> >> > >> >>
> >> > >> >>>
> >> > >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero
> >> > >> >>> <sanne at hibernate.org>
> >> > >> >>> wrote:
> >> > >> >>>>
> >> > >> >>>> Hi all,
> >> > >> >>>> please try to have a look at this page when you have a moment:
> >> > >> >>>>  - http://ci.hibernate.org/view/JDK9/
> >> > >> >>>>
> >> > >> >>>> Hibernate Search is working, and it shouldn't be too hard to
> get
> >> > the
> >> > >> >>>> others "green" as well.
> >> > >> >>>>
> >> > >> >>>> I've disabled some integration tests to get there, notably:
> >> > >> >>>>  - OSGi tests: Karaf is not ready for it.
> >> > >> >>>>  - Documentation build: Asciidoc will probably need an update.
> >> > >> >>>>  - WildFly integration tests: the WildFly team is aware, will
> >> > >> >>>> need
> >> > a
> >> > >> >>>> minor upgrade.
> >> > >> >>>>
> >> > >> >>>> I don't believe these issues are relevant, so I'm satisfied
> that
> >> > all
> >> > >> >>>> other tests working fine mean that the project will pretty
> much
> >> > work
> >> > >> >>>> out of the box for end users - at worst their container won't
> >> > >> >>>> work,
> >> > >> >>>> but that's not our responsibility to test for.
> >> > >> >>>>
> >> > >> >>>> Could you all contribute a bit to get all projects show
> "green"
> >> > >> >>>> on
> >> > >> >>>> this
> >> > >> >>>> page?
> >> > >> >>>>
> >> > >> >>>> Some "workarounds" you might want to apply:
> >> > >> >>>>  - the Logger interfaces won't compile because of a known
> issue,
> >> > this
> >> > >> >>>> can be worked around for now by having the compilation phase
> >> > >> >>>> also
> >> > >> >>>> explicitly depend on this artifact:
> >> > >> >>>>
> >> > >> >>>>
> >> > >> >>>>
> >> >
> >> >
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
> >> > >> >>>>  - you'll have a ClassNotFoundException on JAXB usage unless
> you
> >> > set
> >> > >> >>>> this JVM flag:
> >> > >> >>>>
> >> > >> >>>>
> >> >
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
> >> > >> >>>> (This one is not a bug but will be required to be set by end
> >> > >> >>>> users
> >> > as
> >> > >> >>>> well - or we provide our own XML parser, that might be more
> user
> >> > >> >>>> friendly).
> >> > >> >>>>
> >> > >> >>>> As far as I know, other issues with the build tools have been
> >> > solved
> >> > >> >>>> already - including Gradle.
> >> > >> >>>>
> >> > >> >>>> Thanks,
> >> > >> >>>> Sanne
> >> > >> >>>> _______________________________________________
> >> > >> >>>> hibernate-dev mailing list
> >> > >> >>>> 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
> >> > >
> >> > >
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Jun 16 10:18:15 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 16 Jun 2016 17:18:15 +0300
Subject: [hibernate-dev] Handling connections properly during testing with
	Java 1.8
Message-ID: <CA+gWKMDdUtAcO8SHfJP_0dx3yo=rS7JR4LsPgJf9WN182BWy5A@mail.gmail.com>

Hi,

Now that we moved to Java 1.8, would you like to add a task so that we
manage the Session/Transaction automatically using a test utility like the
ones I added in the documentation tests:

doInHibernate( this::sessionFactory, session -> {
   Person person = new Person();
   person.id = 1L;
   session.persist( person );

   person.phones.add( "027-123-4567" );
   person.phones.add( "028-234-9876" );
   session.flush();

   person.getPhones().remove( 0 );
} );

Or for JPA:

doInJPA( this::entityManagerFactory, entityManager -> {
   Person person = new Person( 1L );
   entityManager.persist( person );


   person.addPhone( new Phone( 1L, "landline", "028-234-9876" ) );
   person.addPhone( new Phone( 2L, "mobile", "072-122-9876" ) );
   entityManager.flush();

   person.removePhone( person.getPhones().get( 0 ) );
} );


1. The tests will be less verbose.
2. There are times when a test fails on MySQL and then the suite stops
because the connection is not closed properly and the DROP command hangs.

What do you think?

Vlad

From steve at hibernate.org  Thu Jun 16 11:11:20 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 16 Jun 2016 15:11:20 +0000
Subject: [hibernate-dev] Handling connections properly during testing
 with Java 1.8
In-Reply-To: <CA+gWKMDdUtAcO8SHfJP_0dx3yo=rS7JR4LsPgJf9WN182BWy5A@mail.gmail.com>
References: <CA+gWKMDdUtAcO8SHfJP_0dx3yo=rS7JR4LsPgJf9WN182BWy5A@mail.gmail.com>
Message-ID: <CAFdSV9t7EB8FnhYiY7FDBV8+01jVyqJntXTgbjRfgeqZb0ovDQ@mail.gmail.com>

Not sure what you are asking specifically.  You mean a task to change each
and every test in the Hibernate testsuite?


On Thu, Jun 16, 2016 at 9:18 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> Now that we moved to Java 1.8, would you like to add a task so that we
> manage the Session/Transaction automatically using a test utility like the
> ones I added in the documentation tests:
>
> doInHibernate( this::sessionFactory, session -> {
>    Person person = new Person();
>    person.id = 1L;
>    session.persist( person );
>
>    person.phones.add( "027-123-4567" );
>    person.phones.add( "028-234-9876" );
>    session.flush();
>
>    person.getPhones().remove( 0 );
> } );
>
> Or for JPA:
>
> doInJPA( this::entityManagerFactory, entityManager -> {
>    Person person = new Person( 1L );
>    entityManager.persist( person );
>
>
>    person.addPhone( new Phone( 1L, "landline", "028-234-9876" ) );
>    person.addPhone( new Phone( 2L, "mobile", "072-122-9876" ) );
>    entityManager.flush();
>
>    person.removePhone( person.getPhones().get( 0 ) );
> } );
>
>
> 1. The tests will be less verbose.
> 2. There are times when a test fails on MySQL and then the suite stops
> because the connection is not closed properly and the DROP command hangs.
>
> What do you think?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Jun 16 11:25:16 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 16 Jun 2016 18:25:16 +0300
Subject: [hibernate-dev] Handling connections properly during testing
 with Java 1.8
In-Reply-To: <CAFdSV9t7EB8FnhYiY7FDBV8+01jVyqJntXTgbjRfgeqZb0ovDQ@mail.gmail.com>
References: <CA+gWKMDdUtAcO8SHfJP_0dx3yo=rS7JR4LsPgJf9WN182BWy5A@mail.gmail.com>
	<CAFdSV9t7EB8FnhYiY7FDBV8+01jVyqJntXTgbjRfgeqZb0ovDQ@mail.gmail.com>
Message-ID: <CA+gWKMDiD5VAduyW81nWU95KqFyDTn_OT+SkTzybnbNZaYZEgw@mail.gmail.com>

At first, we could add support for this method and start applying it for
new tests.
If we ever have time to migrate old tests, we should consider changing old
tests as well.

Vlad

On Thu, Jun 16, 2016 at 6:11 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Not sure what you are asking specifically.  You mean a task to change each
> and every test in the Hibernate testsuite?
>
>
> On Thu, Jun 16, 2016 at 9:18 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> Now that we moved to Java 1.8, would you like to add a task so that we
>> manage the Session/Transaction automatically using a test utility like the
>> ones I added in the documentation tests:
>>
>> doInHibernate( this::sessionFactory, session -> {
>>    Person person = new Person();
>>    person.id = 1L;
>>    session.persist( person );
>>
>>    person.phones.add( "027-123-4567" );
>>    person.phones.add( "028-234-9876" );
>>    session.flush();
>>
>>    person.getPhones().remove( 0 );
>> } );
>>
>> Or for JPA:
>>
>> doInJPA( this::entityManagerFactory, entityManager -> {
>>    Person person = new Person( 1L );
>>    entityManager.persist( person );
>>
>>
>>    person.addPhone( new Phone( 1L, "landline", "028-234-9876" ) );
>>    person.addPhone( new Phone( 2L, "mobile", "072-122-9876" ) );
>>    entityManager.flush();
>>
>>    person.removePhone( person.getPhones().get( 0 ) );
>> } );
>>
>>
>> 1. The tests will be less verbose.
>> 2. There are times when a test fails on MySQL and then the suite stops
>> because the connection is not closed properly and the DROP command hangs.
>>
>> What do you think?
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Thu Jun 16 11:41:11 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 16 Jun 2016 15:41:11 +0000
Subject: [hibernate-dev] Handling connections properly during testing
 with Java 1.8
In-Reply-To: <CA+gWKMDiD5VAduyW81nWU95KqFyDTn_OT+SkTzybnbNZaYZEgw@mail.gmail.com>
References: <CA+gWKMDdUtAcO8SHfJP_0dx3yo=rS7JR4LsPgJf9WN182BWy5A@mail.gmail.com>
	<CAFdSV9t7EB8FnhYiY7FDBV8+01jVyqJntXTgbjRfgeqZb0ovDQ@mail.gmail.com>
	<CA+gWKMDiD5VAduyW81nWU95KqFyDTn_OT+SkTzybnbNZaYZEgw@mail.gmail.com>
Message-ID: <CAFdSV9tXQ4mue_GW2syQ1THJQs_Dp4VPe12nKH66VmLhRw82rw@mail.gmail.com>

I look forward to "ever [having] time" :)

But I am fine with adding support for it and using them in new tests.
Remember too that Session, etal are AutoCloseable now too.


On Thu, Jun 16, 2016 at 10:25 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> At first, we could add support for this method and start applying it for
> new tests.
> If we ever have time to migrate old tests, we should consider changing old
> tests as well.
>
> Vlad
>
> On Thu, Jun 16, 2016 at 6:11 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Not sure what you are asking specifically.  You mean a task to change
>> each and every test in the Hibernate testsuite?
>>
>>
>> On Thu, Jun 16, 2016 at 9:18 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Now that we moved to Java 1.8, would you like to add a task so that we
>>> manage the Session/Transaction automatically using a test utility like
>>> the
>>> ones I added in the documentation tests:
>>>
>>> doInHibernate( this::sessionFactory, session -> {
>>>    Person person = new Person();
>>>    person.id = 1L;
>>>    session.persist( person );
>>>
>>>    person.phones.add( "027-123-4567" );
>>>    person.phones.add( "028-234-9876" );
>>>    session.flush();
>>>
>>>    person.getPhones().remove( 0 );
>>> } );
>>>
>>> Or for JPA:
>>>
>>> doInJPA( this::entityManagerFactory, entityManager -> {
>>>    Person person = new Person( 1L );
>>>    entityManager.persist( person );
>>>
>>>
>>>    person.addPhone( new Phone( 1L, "landline", "028-234-9876" ) );
>>>    person.addPhone( new Phone( 2L, "mobile", "072-122-9876" ) );
>>>    entityManager.flush();
>>>
>>>    person.removePhone( person.getPhones().get( 0 ) );
>>> } );
>>>
>>>
>>> 1. The tests will be less verbose.
>>> 2. There are times when a test fails on MySQL and then the suite stops
>>> because the connection is not closed properly and the DROP command hangs.
>>>
>>> What do you think?
>>>
>>> Vlad
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From emmanuel at hibernate.org  Fri Jun 17 11:51:00 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 17 Jun 2016 17:51:00 +0200
Subject: [hibernate-dev] Cleaning up non final versions from download pages
Message-ID: <20160617155100.GA18153@hibernate.org>

I've cleaned up the non final versions of OGM 5.0 from the website
download pages.
There is a displayed: false flag on the yml release document.

I could not find any reason why the alpha, beta and cr were shown in the
list.

Emmanuel

From steve at hibernate.org  Fri Jun 17 20:22:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 18 Jun 2016 00:22:47 +0000
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFdSV9sH5hBLmFoSZfm76htv43uzQqRJKVeEC_pCaiEqHPt1YQ@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
	<CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
	<CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
	<CAFm4XO0WAwrkR+vJMgxnuugnT+B09LVuHJAe54Oawi900pta8g@mail.gmail.com>
	<CAFdSV9sH5hBLmFoSZfm76htv43uzQqRJKVeEC_pCaiEqHPt1YQ@mail.gmail.com>
Message-ID: <CAFdSV9snk7iMhS2fVaOqDknByD9nDt1G9r9WFF4UK8EnAhwGaw@mail.gmail.com>

For the most part we have gotten ORM buildable with Java 9.  Some "open
items":

   1. Javassist does not seem to support Java 9 much, if at all.  I had to
   disable some tests in hibernate-core that test enhancement as well as tests
   for hibernate-hikari since it uses Javassist extensively too.
    hibernate-envers has a bunch of test failures that seem related to
   Javassist as well.
   2. The tests for hibernate-osgi simply hang.  Something in that test
   stack does not like Java 9.

Longer term we need to decide how we want to handle non standard modules
moving forward.  This mostly came up in regards to JAXB and XJC.  For the
moment I added a set of non-transitive dependencies for JAXB and XJC to
hibernate-core and hibernate-jpamodelgen.  Since the hibernate-core one is
non-transitive I then had to add a similar fragment to each and every
module that depends on hibernate-core tries to run tests using it.  This
gets fugly :)  For reference the fragment looks like:

// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

// Java 9 ftw!
if ( JavaVersion.current().isJava9Compatible() ) {
    // The JDK used to run Gradle is Java 9+, and we assume that that
is the same
    //    JDK for executing tasks
    compile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
    compile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
    compile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
    compile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
    compile( 'javax:javaee-api:7.0' )

    testCompile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
    testCompile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
    testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
    testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
    testCompile( 'javax:javaee-api:7.0' )

    testRuntime( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
    testRuntime( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
    testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
    testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
    testRuntime( 'javax:javaee-api:7.0' )
}
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


I decided to do this non-transitively since users may (probably) would want
to use a better JAXB impl.  Not sure the best way to handle this.

On Wed, Jun 15, 2016 at 3:14 PM Steve Ebersole <steve at hibernate.org> wrote:

> No worries, I understand.
>
> On Wed, Jun 15, 2016 at 3:13 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 15 June 2016 at 19:29, Steve Ebersole <steve at hibernate.org> wrote:
>> > WRT JAXB (XJC) I am completely lost.
>> >
>> > Sanne I tried your solution of specifying an addmod for jaxb to
>> GRADLE_OPTS
>> > but get the same result (ExceptionInInitializerError) with and without
>> that
>> > change.  So not sure how you got that to work.
>>
>> Steve, sorry if that wasn't clear: this didn't work for me either.
>> I used the GRADLE_OPTS to bypass other issues which I had before
>> reaching this point, but then I got stuck on the 'xjc' plugin, and
>> that's were I asked if we could bypass/skip/rewrite the plugin.
>>
>> >
>> > I did try the alternative we discussed of defining an explicit build
>> > dependency on JAXB (which again has no effect):
>> >
>> >
>> > xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
>> > xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'
>> >
>> >
>> > For some background, XJC is currently performed via Gradle's AntBuilder
>> > support using the jaxb2_commons Ant task
>> > (org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using Sun's
>> > com.sun.tools.xjc.XJCTask directly.  Neither make any difference.  The
>> > fundamental problem is that for Ant execution Gradle simply reuses its
>> VM.
>> > So to get this applied (iiuc) the only real option is to configure the
>> > Gradle launch to include the addmod (which makes it more odd that
>> > GRADLE_OPTS did not work for me).
>> >
>> > The other option is to write a new Gradle XjcTask that executes the XJC
>> tool
>> > directly.  That we can use Gradle to help us fork and pass the addmod
>> option
>> > to the forked process.  I think :)
>> >
>> >
>> > On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >>
>> >> Yep, we discussed that approach last year already:
>> >> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
>> >>
>> >> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> > On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >> > > Hey,
>> >> > >
>> >> > > I hit the same issue with the injection plug-in in HV.
>> >> > >
>> >> > > It was used for obtaining the version of HV at runtime. I worked
>> >> > > around
>> >> > it
>> >> > > by obtaining that from the package instead [1]:
>> >> > >
>> >> > >     return
>> SomeHvClass.class.getPackage().getImplementationVersion();
>> >> >
>> >> > Right, that looks a lot like
>> >> >  -
>> >> >
>> >> >
>> https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
>> >> > ;)
>> >> >
>> >> > >
>> >> > > If that's all what the injection plug-in is used for in ORM as well
>> >> > > (and
>> >> > you
>> >> > > don't depend on that version info e.g. during testing in the IDE,
>> >> > > where
>> >> > > there is no JAR manifest yet which is the source of the version
>> with
>> >> > > that
>> >> > > approach), you could do the same there.
>> >> > >
>> >> > > --Gunnar
>> >> > >
>> >> > > [1]
>> >> > >
>> >> >
>> >> >
>> https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
>> >> > >
>> >> > >
>> >> > > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> > >>
>> >> > >> Some more progress by simply setting this environment variable:
>> >> > >>
>> >> > >>
>> >> >
>> >> >
>> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
>> >> > >> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
>> >> > >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
>> >> > >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
>> >> > >> java.xml.bind"
>> >> > >>
>> >> > >> But it's getting tricky:
>> >> > >>
>> >> > >> Caused by: compile error: javassist.NotFoundException:
>> >> > >> java.lang.String
>> >> > >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
>> >> > >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
>> >> > >>    ... 76 more
>> >> > >>
>> >> > >> This seems to be caused by the following plugin, which I'm not
>> >> > >> familiar
>> >> > >> with:
>> >> > >>  -
>> >> > >>
>> >> >
>> >> >
>> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
>> >> > >> Is this something which we could disable/skip/remove for now, or
>> >> > >> update to not require Javassist?
>> >> > >>
>> >> > >> Thanks,
>> >> > >> sanne
>> >> > >>
>> >> > >> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org>
>> >> > >> wrote:
>> >> > >> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org>
>> >> > wrote:
>> >> > >> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org>
>> >> > wrote:
>> >> > >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea
>> about
>> >> > that?
>> >> > >> >>
>> >> > >> >> Not sure, that's a new one :)
>> >> > >> >> It could be related to
>> >> > >> >> https://issues.gradle.org/browse/GRADLE-3287
>> >> > ?
>> >> > >> >>
>> >> > >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at a
>> >> > >> >> terminal at the moment, I could try later.
>> >> > >> >
>> >> > >> > I've upgraded to Gradle 2.13, the pull request is here:
>> >> > >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
>> >> > >> >
>> >> > >> > It solved that specific issue, but it's not enough. I'm still
>> >> > >> > trying
>> >> > >> > to hack a workaround for the next step, but in the meantime
>> that PR
>> >> > >> > could be considered independently.
>> >> > >> >
>> >> > >> > I could use some pointers with Gradle and the custom plugins we
>> >> > >> > use;
>> >> > >> > essentially we need to pass some additional JVM flags,
>> including to
>> >> > >> > javac, like here:
>> >> > >> >  -
>> >> > >> >
>> >> >
>> >> >
>> https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
>> >> > >> >
>> >> > >> > But the failure happens during:
>> >> > >> >  Execution failed for task ':hibernate-core:xjc'
>> >> > >> >
>> >> > >> > and I'm not sure how to override the JVM flags for that plugin
>> >> > >> > execution.
>> >> > >> >
>> >> > >> > Thanks,
>> >> > >> > Sanne
>> >> > >> >
>> >> > >> >
>> >> > >> >>
>> >> > >> >>>
>> >> > >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero
>> >> > >> >>> <sanne at hibernate.org>
>> >> > >> >>> wrote:
>> >> > >> >>>>
>> >> > >> >>>> Hi all,
>> >> > >> >>>> please try to have a look at this page when you have a
>> moment:
>> >> > >> >>>>  - http://ci.hibernate.org/view/JDK9/
>> >> > >> >>>>
>> >> > >> >>>> Hibernate Search is working, and it shouldn't be too hard to
>> get
>> >> > the
>> >> > >> >>>> others "green" as well.
>> >> > >> >>>>
>> >> > >> >>>> I've disabled some integration tests to get there, notably:
>> >> > >> >>>>  - OSGi tests: Karaf is not ready for it.
>> >> > >> >>>>  - Documentation build: Asciidoc will probably need an
>> update.
>> >> > >> >>>>  - WildFly integration tests: the WildFly team is aware, will
>> >> > >> >>>> need
>> >> > a
>> >> > >> >>>> minor upgrade.
>> >> > >> >>>>
>> >> > >> >>>> I don't believe these issues are relevant, so I'm satisfied
>> that
>> >> > all
>> >> > >> >>>> other tests working fine mean that the project will pretty
>> much
>> >> > work
>> >> > >> >>>> out of the box for end users - at worst their container won't
>> >> > >> >>>> work,
>> >> > >> >>>> but that's not our responsibility to test for.
>> >> > >> >>>>
>> >> > >> >>>> Could you all contribute a bit to get all projects show
>> "green"
>> >> > >> >>>> on
>> >> > >> >>>> this
>> >> > >> >>>> page?
>> >> > >> >>>>
>> >> > >> >>>> Some "workarounds" you might want to apply:
>> >> > >> >>>>  - the Logger interfaces won't compile because of a known
>> issue,
>> >> > this
>> >> > >> >>>> can be worked around for now by having the compilation phase
>> >> > >> >>>> also
>> >> > >> >>>> explicitly depend on this artifact:
>> >> > >> >>>>
>> >> > >> >>>>
>> >> > >> >>>>
>> >> >
>> >> >
>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>> >> > >> >>>>  - you'll have a ClassNotFoundException on JAXB usage unless
>> you
>> >> > set
>> >> > >> >>>> this JVM flag:
>> >> > >> >>>>
>> >> > >> >>>>
>> >> >
>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>> >> > >> >>>> (This one is not a bug but will be required to be set by end
>> >> > >> >>>> users
>> >> > as
>> >> > >> >>>> well - or we provide our own XML parser, that might be more
>> user
>> >> > >> >>>> friendly).
>> >> > >> >>>>
>> >> > >> >>>> As far as I know, other issues with the build tools have been
>> >> > solved
>> >> > >> >>>> already - including Gradle.
>> >> > >> >>>>
>> >> > >> >>>> Thanks,
>> >> > >> >>>> Sanne
>> >> > >> >>>> _______________________________________________
>> >> > >> >>>> hibernate-dev mailing list
>> >> > >> >>>> 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
>> >> > >
>> >> > >
>> >> >
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gbadner at redhat.com  Fri Jun 17 22:11:49 2016
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 17 Jun 2016 19:11:49 -0700
Subject: [hibernate-dev] Is
	org.hibernate.cache.spi.OptimisticCacheSource#getVersionComparator
	obsolete?
Message-ID: <CAFDzhiShHqL9fC6parpfcBRGSKtokqXpU8VoQWiKSiEhUdvAuw@mail.gmail.com>

It is implemented by AbstractEntityPersister, but as of 5.0.9 (using
Infinispan 7.2.5.Final) I see no references to this method in Hibernate
ORM, other than in Javadoc for OptimisticCacheSource#isVersioned  [1] that
says:

"If true, it is illegal for {@link #getVersionComparator} to return null"
[1]

Long story short, if OptimisticCacheSource#getVersionComparator is
obsolete, then there is no reason to create a meaningful Comparator for
Sybase timestamps for HHH-10413.

The long story...

Sybase timestamp can be used as an entity version which is treated as
byte[]. This seems to have caused problems in the past when caching,
because an array does not have a Comparator.

I tried creating a simple comparator that uses Byte#compareTo(Byte), but
unfortunately this does not work for Sybase timestamps, because
Byte#compareTo(Byte)
uses a signed comparison. Sybase timestamps require an unsigned comparison.

I can change the comparator to do unsigned comparisons of byte elements.
One thing to consider is that the same comparator will also be used for
when sorting actions by byte[] IDs.

We discussed earlier that it doesn't make sense to compare IDs that are
arrays. If
OptimisticCacheSource#getVersionComparator is obsolete, then I can simply
use IncomparableComparator#INSTANCE.

If OptimisticCacheSource#getVersionComparator is not obsolete, then is it
worth creating a special BinaryTimestampType that implements
VersionType<byte[]> (instead of BinaryType implementing
VersionType<byte[]>) with a comparator that does unsigned comparisons?

I'm also trying to wrap up HHH-8999, which is also impacted by this.

Regards,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/spi/OptimisticCacheSource.java#L24-L25

From mincong.h at gmail.com  Sat Jun 18 11:05:03 2016
From: mincong.h at gmail.com (Mincong Huang)
Date: Sat, 18 Jun 2016 17:05:03 +0200
Subject: [hibernate-dev] [Question] Target runtime WildFly is unpacked after
	maven tests
Message-ID: <CACWxqgC5rJAdS=wzQs83dQL1cp+ivxXCVzraqYOmzepFhbhA1Q@mail.gmail.com>

Hi everybody,

I'm Mincong, your intern from Google Summer of Code. I'm working on
a new implement of mass indexer for Hibernate Search but I get some
difficulties to configure correctly the test cases. It seems that the tests
try to run before the WF10 setup. I've post this question on Stack Overflow
[1]. The question itself is really long, so please click the link to see
it. Any
tip will be helpful.

Thank you and have a good weekend :)

Mincong

[1]:
http://stackoverflow.com/questions/37898297/target-runtime-wildfly-is-unpacked-after-maven-tests

From steve at hibernate.org  Sat Jun 18 12:14:29 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 18 Jun 2016 16:14:29 +0000
Subject: [hibernate-dev] Is
 org.hibernate.cache.spi.OptimisticCacheSource#getVersionComparator
 obsolete?
In-Reply-To: <CAFDzhiShHqL9fC6parpfcBRGSKtokqXpU8VoQWiKSiEhUdvAuw@mail.gmail.com>
References: <CAFDzhiShHqL9fC6parpfcBRGSKtokqXpU8VoQWiKSiEhUdvAuw@mail.gmail.com>
Message-ID: <CAFdSV9uFFK+Uzc0fdzB3VOB+rkyMwXDw4BBKLT1C5wngv=LdRg@mail.gmail.com>

TIMESTAMP is a deprecated synonym for the TSQL rownumber datatype, at least
on SQL Server.  Not sure specifically about Sybase.  So I'll use "rownumber"
here...

As we discussed in HipChat yesterday OptimisticCacheSource was added a long
time ago to facilitate leveraging JBossCache's MVCC support for versioned
data.  The idea was to allow JBossCache to reuse a versioned entity's
version as its MVCC version via the comparator.

JBossCache is of course no more, now morphed into Infinispan.  To my
knowledge, Infinispan does not have the same MVCC support if any.  Either
way, hibernate-infinispan does not support MVCC in the Infinispan cache by
leveraging the entity version.  Radim, Galder - is this something we want
to consider?

Depending on the version (and I forget the exact version this changed) the
role played by OptimisticCacheSource is actually now handled by
org.hibernate.cache.spi.CacheDataDescription.
So that is one of the reasons you do not find any uses of
OptimisticCacheSource#getVersionComparator.  Do a usage search for
CacheDataDescription#getVersionComparator instead.

Same question, different contract.

Some of the cache providers do leverage this version comparator (via
CacheDataDescription#getVersionComparator) for read-write locking.  So
really the question is whether we want to allow the combination of:


   1.  these cache providers with those access strategies using the version
   comparator
   2. versions based on TSQL rowversion datatype.

Aside from a general dislike of versions based on TSQL rowversion datatype
(for many reasons), there is no fundamental reason to not allow it as a
comparator (provided we find the right comparison algorithm).  If you have
found the secret incantation for writing a proper Java Comparator based on
the TSQL rowversion datatype, then I think we should just implement that.

From steve at hibernate.org  Sat Jun 18 12:33:17 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 18 Jun 2016 16:33:17 +0000
Subject: [hibernate-dev] HIbernate ORM CI builds
Message-ID: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>

We have been having a lot of timeouts on the ORM CI builds.  Mainly this is
due to ancillary tasks.  Currently the ORM jobs execute:

   1. clean
   2. test
   3. check
   4. :documentation:aggregateJavadocs
   5. publish

A huge chunk of the time is taken up in (3) which performs (a) checkstyle
and (b) findbugs.  Also, I am not sure of the benefit of building
aggregated javadocs for each and every CI build.  So I propose we break
these up as follows:


   1. A check job
   2. A clean/test/publish job
   3. (?) aggregated javadocs job (?)

This would allow us to split the cost of the Job timeout across the jobs.
In fact we might even consider making some of these into nightly job(s).
Initially in setting up this server we decided to just have singular,
all-encompassing jobs because moving to a new dedicated set of hardware
(dedicated to Hibernate team) was supposed to free us from jobs fighting
for resources.  But as our jobs have grown on the dedicated hardware we are
seeing some of the same.  For certain we want a clean/test/publish job that
is run on every push.  To me the others are more flexible in terms of
scheduling.  We could have a separate check job that is run on each push,
or it could be a nightly job.  We might even decide to leave off building
aggregated javadocs as an automated job/task, or we might decide to make it
a nightly job as well (maybe even with full documentation builds).

WDYT?

From steve at hibernate.org  Sat Jun 18 12:37:31 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 18 Jun 2016 16:37:31 +0000
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFdSV9snk7iMhS2fVaOqDknByD9nDt1G9r9WFF4UK8EnAhwGaw@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
	<CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
	<CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
	<CAFm4XO0WAwrkR+vJMgxnuugnT+B09LVuHJAe54Oawi900pta8g@mail.gmail.com>
	<CAFdSV9sH5hBLmFoSZfm76htv43uzQqRJKVeEC_pCaiEqHPt1YQ@mail.gmail.com>
	<CAFdSV9snk7iMhS2fVaOqDknByD9nDt1G9r9WFF4UK8EnAhwGaw@mail.gmail.com>
Message-ID: <CAFdSV9sdn9BitwgvSoMyhMkyix=m2gore5QskuPm18j949obPQ@mail.gmail.com>

Sanne I do not have rights to edit your ORM JDK 9 job.  I wanted to look at
the job config to make sure it is ok, but I cannot even see it.

On Fri, Jun 17, 2016 at 7:22 PM Steve Ebersole <steve at hibernate.org> wrote:

> For the most part we have gotten ORM buildable with Java 9.  Some "open
> items":
>
>    1. Javassist does not seem to support Java 9 much, if at all.  I had
>    to disable some tests in hibernate-core that test enhancement as well as
>    tests for hibernate-hikari since it uses Javassist extensively too.
>     hibernate-envers has a bunch of test failures that seem related to
>    Javassist as well.
>    2. The tests for hibernate-osgi simply hang.  Something in that test
>    stack does not like Java 9.
>
> Longer term we need to decide how we want to handle non standard modules
> moving forward.  This mostly came up in regards to JAXB and XJC.  For the
> moment I added a set of non-transitive dependencies for JAXB and XJC to
> hibernate-core and hibernate-jpamodelgen.  Since the hibernate-core one is
> non-transitive I then had to add a similar fragment to each and every
> module that depends on hibernate-core tries to run tests using it.  This
> gets fugly :)  For reference the fragment looks like:
>
> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> // Java 9 ftw!
> if ( JavaVersion.current().isJava9Compatible() ) {
>     // The JDK used to run Gradle is Java 9+, and we assume that that is the same
>     //    JDK for executing tasks
>     compile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
>     compile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
>     compile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
>     compile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
>     compile( 'javax:javaee-api:7.0' )
>
>     testCompile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
>     testCompile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
>     testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
>     testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
>     testCompile( 'javax:javaee-api:7.0' )
>
>     testRuntime( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
>     testRuntime( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
>     testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
>     testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
>     testRuntime( 'javax:javaee-api:7.0' )
> }
> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> I decided to do this non-transitively since users may (probably) would
> want to use a better JAXB impl.  Not sure the best way to handle this.
>
> On Wed, Jun 15, 2016 at 3:14 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> No worries, I understand.
>>
>> On Wed, Jun 15, 2016 at 3:13 PM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> On 15 June 2016 at 19:29, Steve Ebersole <steve at hibernate.org> wrote:
>>> > WRT JAXB (XJC) I am completely lost.
>>> >
>>> > Sanne I tried your solution of specifying an addmod for jaxb to
>>> GRADLE_OPTS
>>> > but get the same result (ExceptionInInitializerError) with and without
>>> that
>>> > change.  So not sure how you got that to work.
>>>
>>> Steve, sorry if that wasn't clear: this didn't work for me either.
>>> I used the GRADLE_OPTS to bypass other issues which I had before
>>> reaching this point, but then I got stuck on the 'xjc' plugin, and
>>> that's were I asked if we could bypass/skip/rewrite the plugin.
>>>
>>> >
>>> > I did try the alternative we discussed of defining an explicit build
>>> > dependency on JAXB (which again has no effect):
>>> >
>>> >
>>> > xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
>>> > xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
>>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
>>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'
>>> >
>>> >
>>> > For some background, XJC is currently performed via Gradle's AntBuilder
>>> > support using the jaxb2_commons Ant task
>>> > (org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using Sun's
>>> > com.sun.tools.xjc.XJCTask directly.  Neither make any difference.  The
>>> > fundamental problem is that for Ant execution Gradle simply reuses its
>>> VM.
>>> > So to get this applied (iiuc) the only real option is to configure the
>>> > Gradle launch to include the addmod (which makes it more odd that
>>> > GRADLE_OPTS did not work for me).
>>> >
>>> > The other option is to write a new Gradle XjcTask that executes the
>>> XJC tool
>>> > directly.  That we can use Gradle to help us fork and pass the addmod
>>> option
>>> > to the forked process.  I think :)
>>> >
>>> >
>>> > On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>> >>
>>> >> Yep, we discussed that approach last year already:
>>> >> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
>>> >>
>>> >> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >>
>>> >> > On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>> >> > > Hey,
>>> >> > >
>>> >> > > I hit the same issue with the injection plug-in in HV.
>>> >> > >
>>> >> > > It was used for obtaining the version of HV at runtime. I worked
>>> >> > > around
>>> >> > it
>>> >> > > by obtaining that from the package instead [1]:
>>> >> > >
>>> >> > >     return
>>> SomeHvClass.class.getPackage().getImplementationVersion();
>>> >> >
>>> >> > Right, that looks a lot like
>>> >> >  -
>>> >> >
>>> >> >
>>> https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
>>> >> > ;)
>>> >> >
>>> >> > >
>>> >> > > If that's all what the injection plug-in is used for in ORM as
>>> well
>>> >> > > (and
>>> >> > you
>>> >> > > don't depend on that version info e.g. during testing in the IDE,
>>> >> > > where
>>> >> > > there is no JAR manifest yet which is the source of the version
>>> with
>>> >> > > that
>>> >> > > approach), you could do the same there.
>>> >> > >
>>> >> > > --Gunnar
>>> >> > >
>>> >> > > [1]
>>> >> > >
>>> >> >
>>> >> >
>>> https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
>>> >> > >
>>> >> > >
>>> >> > > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >> > >>
>>> >> > >> Some more progress by simply setting this environment variable:
>>> >> > >>
>>> >> > >>
>>> >> >
>>> >> >
>>> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
>>> >> > >> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
>>> >> > >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
>>> >> > >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
>>> >> > >> java.xml.bind"
>>> >> > >>
>>> >> > >> But it's getting tricky:
>>> >> > >>
>>> >> > >> Caused by: compile error: javassist.NotFoundException:
>>> >> > >> java.lang.String
>>> >> > >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
>>> >> > >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
>>> >> > >>    ... 76 more
>>> >> > >>
>>> >> > >> This seems to be caused by the following plugin, which I'm not
>>> >> > >> familiar
>>> >> > >> with:
>>> >> > >>  -
>>> >> > >>
>>> >> >
>>> >> >
>>> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
>>> >> > >> Is this something which we could disable/skip/remove for now, or
>>> >> > >> update to not require Javassist?
>>> >> > >>
>>> >> > >> Thanks,
>>> >> > >> sanne
>>> >> > >>
>>> >> > >> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org>
>>> >> > >> wrote:
>>> >> > >> > On 11 June 2016 at 18:47, Sanne Grinovero <sanne at hibernate.org
>>> >
>>> >> > wrote:
>>> >> > >> >> On 11 June 2016 at 18:25, Steve Ebersole <steve at hibernate.org
>>> >
>>> >> > wrote:
>>> >> > >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea
>>> about
>>> >> > that?
>>> >> > >> >>
>>> >> > >> >> Not sure, that's a new one :)
>>> >> > >> >> It could be related to
>>> >> > >> >> https://issues.gradle.org/browse/GRADLE-3287
>>> >> > ?
>>> >> > >> >>
>>> >> > >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at
>>> a
>>> >> > >> >> terminal at the moment, I could try later.
>>> >> > >> >
>>> >> > >> > I've upgraded to Gradle 2.13, the pull request is here:
>>> >> > >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
>>> >> > >> >
>>> >> > >> > It solved that specific issue, but it's not enough. I'm still
>>> >> > >> > trying
>>> >> > >> > to hack a workaround for the next step, but in the meantime
>>> that PR
>>> >> > >> > could be considered independently.
>>> >> > >> >
>>> >> > >> > I could use some pointers with Gradle and the custom plugins we
>>> >> > >> > use;
>>> >> > >> > essentially we need to pass some additional JVM flags,
>>> including to
>>> >> > >> > javac, like here:
>>> >> > >> >  -
>>> >> > >> >
>>> >> >
>>> >> >
>>> https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
>>> >> > >> >
>>> >> > >> > But the failure happens during:
>>> >> > >> >  Execution failed for task ':hibernate-core:xjc'
>>> >> > >> >
>>> >> > >> > and I'm not sure how to override the JVM flags for that plugin
>>> >> > >> > execution.
>>> >> > >> >
>>> >> > >> > Thanks,
>>> >> > >> > Sanne
>>> >> > >> >
>>> >> > >> >
>>> >> > >> >>
>>> >> > >> >>>
>>> >> > >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero
>>> >> > >> >>> <sanne at hibernate.org>
>>> >> > >> >>> wrote:
>>> >> > >> >>>>
>>> >> > >> >>>> Hi all,
>>> >> > >> >>>> please try to have a look at this page when you have a
>>> moment:
>>> >> > >> >>>>  - http://ci.hibernate.org/view/JDK9/
>>> >> > >> >>>>
>>> >> > >> >>>> Hibernate Search is working, and it shouldn't be too hard
>>> to get
>>> >> > the
>>> >> > >> >>>> others "green" as well.
>>> >> > >> >>>>
>>> >> > >> >>>> I've disabled some integration tests to get there, notably:
>>> >> > >> >>>>  - OSGi tests: Karaf is not ready for it.
>>> >> > >> >>>>  - Documentation build: Asciidoc will probably need an
>>> update.
>>> >> > >> >>>>  - WildFly integration tests: the WildFly team is aware,
>>> will
>>> >> > >> >>>> need
>>> >> > a
>>> >> > >> >>>> minor upgrade.
>>> >> > >> >>>>
>>> >> > >> >>>> I don't believe these issues are relevant, so I'm satisfied
>>> that
>>> >> > all
>>> >> > >> >>>> other tests working fine mean that the project will pretty
>>> much
>>> >> > work
>>> >> > >> >>>> out of the box for end users - at worst their container
>>> won't
>>> >> > >> >>>> work,
>>> >> > >> >>>> but that's not our responsibility to test for.
>>> >> > >> >>>>
>>> >> > >> >>>> Could you all contribute a bit to get all projects show
>>> "green"
>>> >> > >> >>>> on
>>> >> > >> >>>> this
>>> >> > >> >>>> page?
>>> >> > >> >>>>
>>> >> > >> >>>> Some "workarounds" you might want to apply:
>>> >> > >> >>>>  - the Logger interfaces won't compile because of a known
>>> issue,
>>> >> > this
>>> >> > >> >>>> can be worked around for now by having the compilation phase
>>> >> > >> >>>> also
>>> >> > >> >>>> explicitly depend on this artifact:
>>> >> > >> >>>>
>>> >> > >> >>>>
>>> >> > >> >>>>
>>> >> >
>>> >> >
>>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>>> >> > >> >>>>  - you'll have a ClassNotFoundException on JAXB usage
>>> unless you
>>> >> > set
>>> >> > >> >>>> this JVM flag:
>>> >> > >> >>>>
>>> >> > >> >>>>
>>> >> >
>>> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>>> >> > >> >>>> (This one is not a bug but will be required to be set by end
>>> >> > >> >>>> users
>>> >> > as
>>> >> > >> >>>> well - or we provide our own XML parser, that might be more
>>> user
>>> >> > >> >>>> friendly).
>>> >> > >> >>>>
>>> >> > >> >>>> As far as I know, other issues with the build tools have
>>> been
>>> >> > solved
>>> >> > >> >>>> already - including Gradle.
>>> >> > >> >>>>
>>> >> > >> >>>> Thanks,
>>> >> > >> >>>> Sanne
>>> >> > >> >>>> _______________________________________________
>>> >> > >> >>>> hibernate-dev mailing list
>>> >> > >> >>>> 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
>>> >> > >
>>> >> > >
>>> >> >
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From crancran at gmail.com  Sat Jun 18 13:50:50 2016
From: crancran at gmail.com (Chris Cranford)
Date: Sat, 18 Jun 2016 12:50:50 -0500
Subject: [hibernate-dev] HIbernate ORM CI builds
In-Reply-To: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
References: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
Message-ID: <61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>

+1

I think (1) and (2) on each push still makes sense with (3) being nightly.

Chris


On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> We have been having a lot of timeouts on the ORM CI builds.  Mainly this is
> due to ancillary tasks.  Currently the ORM jobs execute:
>
>     1. clean
>     2. test
>     3. check
>     4. :documentation:aggregateJavadocs
>     5. publish
>
> A huge chunk of the time is taken up in (3) which performs (a) checkstyle
> and (b) findbugs.  Also, I am not sure of the benefit of building
> aggregated javadocs for each and every CI build.  So I propose we break
> these up as follows:
>
>
>     1. A check job
>     2. A clean/test/publish job
>     3. (?) aggregated javadocs job (?)
>
> This would allow us to split the cost of the Job timeout across the jobs.
> In fact we might even consider making some of these into nightly job(s).
> Initially in setting up this server we decided to just have singular,
> all-encompassing jobs because moving to a new dedicated set of hardware
> (dedicated to Hibernate team) was supposed to free us from jobs fighting
> for resources.  But as our jobs have grown on the dedicated hardware we are
> seeing some of the same.  For certain we want a clean/test/publish job that
> is run on every push.  To me the others are more flexible in terms of
> scheduling.  We could have a separate check job that is run on each push,
> or it could be a nightly job.  We might even decide to leave off building
> aggregated javadocs as an automated job/task, or we might decide to make it
> a nightly job as well (maybe even with full documentation builds).
>
> WDYT?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From mihalcea.vlad at gmail.com  Sat Jun 18 13:55:48 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 18 Jun 2016 20:55:48 +0300
Subject: [hibernate-dev] HIbernate ORM CI builds
In-Reply-To: <61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
References: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
	<61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
Message-ID: <CA+gWKMBLmPDssLRLxqp9fFyFuA0qSZbvQn1AWi2UPHnw0wH5sg@mail.gmail.com>

+1 too.

On Sat, Jun 18, 2016 at 8:50 PM, Chris Cranford <crancran at gmail.com> wrote:

> +1
>
> I think (1) and (2) on each push still makes sense with (3) being nightly.
>
> Chris
>
>
> On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> > We have been having a lot of timeouts on the ORM CI builds.  Mainly this
> is
> > due to ancillary tasks.  Currently the ORM jobs execute:
> >
> >     1. clean
> >     2. test
> >     3. check
> >     4. :documentation:aggregateJavadocs
> >     5. publish
> >
> > A huge chunk of the time is taken up in (3) which performs (a) checkstyle
> > and (b) findbugs.  Also, I am not sure of the benefit of building
> > aggregated javadocs for each and every CI build.  So I propose we break
> > these up as follows:
> >
> >
> >     1. A check job
> >     2. A clean/test/publish job
> >     3. (?) aggregated javadocs job (?)
> >
> > This would allow us to split the cost of the Job timeout across the jobs.
> > In fact we might even consider making some of these into nightly job(s).
> > Initially in setting up this server we decided to just have singular,
> > all-encompassing jobs because moving to a new dedicated set of hardware
> > (dedicated to Hibernate team) was supposed to free us from jobs fighting
> > for resources.  But as our jobs have grown on the dedicated hardware we
> are
> > seeing some of the same.  For certain we want a clean/test/publish job
> that
> > is run on every push.  To me the others are more flexible in terms of
> > scheduling.  We could have a separate check job that is run on each push,
> > or it could be a nightly job.  We might even decide to leave off building
> > aggregated javadocs as an automated job/task, or we might decide to make
> it
> > a nightly job as well (maybe even with full documentation builds).
> >
> > WDYT?
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From sanne at hibernate.org  Sat Jun 18 13:58:13 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 18 Jun 2016 18:58:13 +0100
Subject: [hibernate-dev] HIbernate ORM CI builds
In-Reply-To: <61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
References: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
	<61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
Message-ID: <CAFm4XO3A-2xQe_kH6B7oAV6rbwrsqd+bU6zsO7ugZYZ43XBO3A@mail.gmail.com>

On 18 June 2016 at 18:50, Chris Cranford <crancran at gmail.com> wrote:
> +1
>
> I think (1) and (2) on each push still makes sense with (3) being nightly.

+1

 -- Sanne

>
> Chris
>
>
> On 06/18/2016 11:33 AM, Steve Ebersole wrote:
>> We have been having a lot of timeouts on the ORM CI builds.  Mainly this is
>> due to ancillary tasks.  Currently the ORM jobs execute:
>>
>>     1. clean
>>     2. test
>>     3. check
>>     4. :documentation:aggregateJavadocs
>>     5. publish
>>
>> A huge chunk of the time is taken up in (3) which performs (a) checkstyle
>> and (b) findbugs.  Also, I am not sure of the benefit of building
>> aggregated javadocs for each and every CI build.  So I propose we break
>> these up as follows:
>>
>>
>>     1. A check job
>>     2. A clean/test/publish job
>>     3. (?) aggregated javadocs job (?)
>>
>> This would allow us to split the cost of the Job timeout across the jobs.
>> In fact we might even consider making some of these into nightly job(s).
>> Initially in setting up this server we decided to just have singular,
>> all-encompassing jobs because moving to a new dedicated set of hardware
>> (dedicated to Hibernate team) was supposed to free us from jobs fighting
>> for resources.  But as our jobs have grown on the dedicated hardware we are
>> seeing some of the same.  For certain we want a clean/test/publish job that
>> is run on every push.  To me the others are more flexible in terms of
>> scheduling.  We could have a separate check job that is run on each push,
>> or it could be a nightly job.  We might even decide to leave off building
>> aggregated javadocs as an automated job/task, or we might decide to make it
>> a nightly job as well (maybe even with full documentation builds).
>>
>> WDYT?
>> _______________________________________________
>> hibernate-dev mailing list
>> 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

From steve at hibernate.org  Sat Jun 18 14:20:56 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 18 Jun 2016 18:20:56 +0000
Subject: [hibernate-dev] HIbernate ORM CI builds
In-Reply-To: <CAFm4XO3A-2xQe_kH6B7oAV6rbwrsqd+bU6zsO7ugZYZ43XBO3A@mail.gmail.com>
References: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
	<61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
	<CAFm4XO3A-2xQe_kH6B7oAV6rbwrsqd+bU6zsO7ugZYZ43XBO3A@mail.gmail.com>
Message-ID: <CAFdSV9u8kgGgBvWEw_Asj6Ogk9z62jAU8Rnv=7x2_2V270LKRw@mail.gmail.com>

http://ci.hibernate.org/job/hibernate-orm-master-h2-main/
http://ci.hibernate.org/job/hibernate-orm-master-h2-check/

Initial attempt

On Sat, Jun 18, 2016 at 12:58 PM Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 18 June 2016 at 18:50, Chris Cranford <crancran at gmail.com> wrote:
> > +1
> >
> > I think (1) and (2) on each push still makes sense with (3) being
> nightly.
>
> +1
>
>  -- Sanne
>
> >
> > Chris
> >
> >
> > On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> >> We have been having a lot of timeouts on the ORM CI builds.  Mainly
> this is
> >> due to ancillary tasks.  Currently the ORM jobs execute:
> >>
> >>     1. clean
> >>     2. test
> >>     3. check
> >>     4. :documentation:aggregateJavadocs
> >>     5. publish
> >>
> >> A huge chunk of the time is taken up in (3) which performs (a)
> checkstyle
> >> and (b) findbugs.  Also, I am not sure of the benefit of building
> >> aggregated javadocs for each and every CI build.  So I propose we break
> >> these up as follows:
> >>
> >>
> >>     1. A check job
> >>     2. A clean/test/publish job
> >>     3. (?) aggregated javadocs job (?)
> >>
> >> This would allow us to split the cost of the Job timeout across the
> jobs.
> >> In fact we might even consider making some of these into nightly job(s).
> >> Initially in setting up this server we decided to just have singular,
> >> all-encompassing jobs because moving to a new dedicated set of hardware
> >> (dedicated to Hibernate team) was supposed to free us from jobs fighting
> >> for resources.  But as our jobs have grown on the dedicated hardware we
> are
> >> seeing some of the same.  For certain we want a clean/test/publish job
> that
> >> is run on every push.  To me the others are more flexible in terms of
> >> scheduling.  We could have a separate check job that is run on each
> push,
> >> or it could be a nightly job.  We might even decide to leave off
> building
> >> aggregated javadocs as an automated job/task, or we might decide to
> make it
> >> a nightly job as well (maybe even with full documentation builds).
> >>
> >> WDYT?
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sun Jun 19 19:10:28 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 20 Jun 2016 00:10:28 +0100
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFdSV9sdn9BitwgvSoMyhMkyix=m2gore5QskuPm18j949obPQ@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
	<CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
	<CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
	<CAFm4XO0WAwrkR+vJMgxnuugnT+B09LVuHJAe54Oawi900pta8g@mail.gmail.com>
	<CAFdSV9sH5hBLmFoSZfm76htv43uzQqRJKVeEC_pCaiEqHPt1YQ@mail.gmail.com>
	<CAFdSV9snk7iMhS2fVaOqDknByD9nDt1G9r9WFF4UK8EnAhwGaw@mail.gmail.com>
	<CAFdSV9sdn9BitwgvSoMyhMkyix=m2gore5QskuPm18j949obPQ@mail.gmail.com>
Message-ID: <CAFm4XO27DaPeyw0xKJ4-dyR9L=pToTK6=tnVzpeo1RD+1OTBVA@mail.gmail.com>

Hi Steve,
on ci.hibernate.org either you are admin (with all powers) or you're a
no-one, having only some read permissions. So I guess you merely
forgot to login, or you wouldn't be able to change any other job
either.

Anyway, the JDK 9 build job is showing green!
 - http://ci.hibernate.org/view/JDK9/job/hibernate-orm-master-h2-JDK9/

I've re-enabled the email notifications: it will bother yourself,
Andrea, and Chris in case of regressions (on top of notifying whoever
broke it). Feel free to make any other change..

A build will be triggered after each successful build of the "master
job" (H2, JDK8, branch master) - only if that is successful, so you
shouldn't get a pointless notifications about a failure which fails on
JDK8 too. On the other hand, this means it will take a while to get
you a JDK9 regression notification as it will need to have completed
both the master build and the JDK9 build; I hope this is a good
tradeoff for now, so that you don't get too many emails.

Thanks,
Sanne



On 18 June 2016 at 17:37, Steve Ebersole <steve at hibernate.org> wrote:
> Sanne I do not have rights to edit your ORM JDK 9 job.  I wanted to look at
> the job config to make sure it is ok, but I cannot even see it.
>
> On Fri, Jun 17, 2016 at 7:22 PM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> For the most part we have gotten ORM buildable with Java 9.  Some "open
>> items":
>>
>> Javassist does not seem to support Java 9 much, if at all.  I had to
>> disable some tests in hibernate-core that test enhancement as well as tests
>> for hibernate-hikari since it uses Javassist extensively too.
>> hibernate-envers has a bunch of test failures that seem related to Javassist
>> as well.
>> The tests for hibernate-osgi simply hang.  Something in that test stack
>> does not like Java 9.
>>
>> Longer term we need to decide how we want to handle non standard modules
>> moving forward.  This mostly came up in regards to JAXB and XJC.  For the
>> moment I added a set of non-transitive dependencies for JAXB and XJC to
>> hibernate-core and hibernate-jpamodelgen.  Since the hibernate-core one is
>> non-transitive I then had to add a similar fragment to each and every module
>> that depends on hibernate-core tries to run tests using it.  This gets fugly
>> :)  For reference the fragment looks like:
>>
>> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> // Java 9 ftw!
>> if ( JavaVersion.current().isJava9Compatible() ) {
>>     // The JDK used to run Gradle is Java 9+, and we assume that that is
>> the same
>>     //    JDK for executing tasks
>>     compile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
>>     compile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
>>     compile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
>>     compile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
>>     compile( 'javax:javaee-api:7.0' )
>>
>>     testCompile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
>>     testCompile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
>>     testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
>>     testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
>>     testCompile( 'javax:javaee-api:7.0' )
>>
>>     testRuntime( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
>>     testRuntime( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
>>     testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
>>     testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
>>     testRuntime( 'javax:javaee-api:7.0' )
>> }
>> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>> I decided to do this non-transitively since users may (probably) would
>> want to use a better JAXB impl.  Not sure the best way to handle this.
>>
>> On Wed, Jun 15, 2016 at 3:14 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>> No worries, I understand.
>>>
>>> On Wed, Jun 15, 2016 at 3:13 PM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>>
>>>> On 15 June 2016 at 19:29, Steve Ebersole <steve at hibernate.org> wrote:
>>>> > WRT JAXB (XJC) I am completely lost.
>>>> >
>>>> > Sanne I tried your solution of specifying an addmod for jaxb to
>>>> > GRADLE_OPTS
>>>> > but get the same result (ExceptionInInitializerError) with and without
>>>> > that
>>>> > change.  So not sure how you got that to work.
>>>>
>>>> Steve, sorry if that wasn't clear: this didn't work for me either.
>>>> I used the GRADLE_OPTS to bypass other issues which I had before
>>>> reaching this point, but then I got stuck on the 'xjc' plugin, and
>>>> that's were I asked if we could bypass/skip/rewrite the plugin.
>>>>
>>>> >
>>>> > I did try the alternative we discussed of defining an explicit build
>>>> > dependency on JAXB (which again has no effect):
>>>> >
>>>> >
>>>> > xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
>>>> > xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
>>>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
>>>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'
>>>> >
>>>> >
>>>> > For some background, XJC is currently performed via Gradle's
>>>> > AntBuilder
>>>> > support using the jaxb2_commons Ant task
>>>> > (org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using Sun's
>>>> > com.sun.tools.xjc.XJCTask directly.  Neither make any difference.  The
>>>> > fundamental problem is that for Ant execution Gradle simply reuses its
>>>> > VM.
>>>> > So to get this applied (iiuc) the only real option is to configure the
>>>> > Gradle launch to include the addmod (which makes it more odd that
>>>> > GRADLE_OPTS did not work for me).
>>>> >
>>>> > The other option is to write a new Gradle XjcTask that executes the
>>>> > XJC tool
>>>> > directly.  That we can use Gradle to help us fork and pass the addmod
>>>> > option
>>>> > to the forked process.  I think :)
>>>> >
>>>> >
>>>> > On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling <gunnar at hibernate.org>
>>>> > wrote:
>>>> >>
>>>> >> Yep, we discussed that approach last year already:
>>>> >> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
>>>> >>
>>>> >> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>>> >>
>>>> >> > On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org>
>>>> >> > wrote:
>>>> >> > > Hey,
>>>> >> > >
>>>> >> > > I hit the same issue with the injection plug-in in HV.
>>>> >> > >
>>>> >> > > It was used for obtaining the version of HV at runtime. I worked
>>>> >> > > around
>>>> >> > it
>>>> >> > > by obtaining that from the package instead [1]:
>>>> >> > >
>>>> >> > >     return
>>>> >> > > SomeHvClass.class.getPackage().getImplementationVersion();
>>>> >> >
>>>> >> > Right, that looks a lot like
>>>> >> >  -
>>>> >> >
>>>> >> >
>>>> >> > https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
>>>> >> > ;)
>>>> >> >
>>>> >> > >
>>>> >> > > If that's all what the injection plug-in is used for in ORM as
>>>> >> > > well
>>>> >> > > (and
>>>> >> > you
>>>> >> > > don't depend on that version info e.g. during testing in the IDE,
>>>> >> > > where
>>>> >> > > there is no JAR manifest yet which is the source of the version
>>>> >> > > with
>>>> >> > > that
>>>> >> > > approach), you could do the same there.
>>>> >> > >
>>>> >> > > --Gunnar
>>>> >> > >
>>>> >> > > [1]
>>>> >> > >
>>>> >> >
>>>> >> >
>>>> >> > https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
>>>> >> > >
>>>> >> > >
>>>> >> > > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>>> >> > >>
>>>> >> > >> Some more progress by simply setting this environment variable:
>>>> >> > >>
>>>> >> > >>
>>>> >> >
>>>> >> >
>>>> >> > GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
>>>> >> > >>
>>>> >> > >> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
>>>> >> > >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
>>>> >> > >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
>>>> >> > >> java.xml.bind"
>>>> >> > >>
>>>> >> > >> But it's getting tricky:
>>>> >> > >>
>>>> >> > >> Caused by: compile error: javassist.NotFoundException:
>>>> >> > >> java.lang.String
>>>> >> > >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
>>>> >> > >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
>>>> >> > >>    ... 76 more
>>>> >> > >>
>>>> >> > >> This seems to be caused by the following plugin, which I'm not
>>>> >> > >> familiar
>>>> >> > >> with:
>>>> >> > >>  -
>>>> >> > >>
>>>> >> >
>>>> >> >
>>>> >> > org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
>>>> >> > >> Is this something which we could disable/skip/remove for now, or
>>>> >> > >> update to not require Javassist?
>>>> >> > >>
>>>> >> > >> Thanks,
>>>> >> > >> sanne
>>>> >> > >>
>>>> >> > >> On 12 June 2016 at 20:56, Sanne Grinovero <sanne at hibernate.org>
>>>> >> > >> wrote:
>>>> >> > >> > On 11 June 2016 at 18:47, Sanne Grinovero
>>>> >> > >> > <sanne at hibernate.org>
>>>> >> > wrote:
>>>> >> > >> >> On 11 June 2016 at 18:25, Steve Ebersole
>>>> >> > >> >> <steve at hibernate.org>
>>>> >> > wrote:
>>>> >> > >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea
>>>> >> > >> >>> about
>>>> >> > that?
>>>> >> > >> >>
>>>> >> > >> >> Not sure, that's a new one :)
>>>> >> > >> >> It could be related to
>>>> >> > >> >> https://issues.gradle.org/browse/GRADLE-3287
>>>> >> > ?
>>>> >> > >> >>
>>>> >> > >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not at
>>>> >> > >> >> a
>>>> >> > >> >> terminal at the moment, I could try later.
>>>> >> > >> >
>>>> >> > >> > I've upgraded to Gradle 2.13, the pull request is here:
>>>> >> > >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
>>>> >> > >> >
>>>> >> > >> > It solved that specific issue, but it's not enough. I'm still
>>>> >> > >> > trying
>>>> >> > >> > to hack a workaround for the next step, but in the meantime
>>>> >> > >> > that PR
>>>> >> > >> > could be considered independently.
>>>> >> > >> >
>>>> >> > >> > I could use some pointers with Gradle and the custom plugins
>>>> >> > >> > we
>>>> >> > >> > use;
>>>> >> > >> > essentially we need to pass some additional JVM flags,
>>>> >> > >> > including to
>>>> >> > >> > javac, like here:
>>>> >> > >> >  -
>>>> >> > >> >
>>>> >> >
>>>> >> >
>>>> >> > https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
>>>> >> > >> >
>>>> >> > >> > But the failure happens during:
>>>> >> > >> >  Execution failed for task ':hibernate-core:xjc'
>>>> >> > >> >
>>>> >> > >> > and I'm not sure how to override the JVM flags for that plugin
>>>> >> > >> > execution.
>>>> >> > >> >
>>>> >> > >> > Thanks,
>>>> >> > >> > Sanne
>>>> >> > >> >
>>>> >> > >> >
>>>> >> > >> >>
>>>> >> > >> >>>
>>>> >> > >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero
>>>> >> > >> >>> <sanne at hibernate.org>
>>>> >> > >> >>> wrote:
>>>> >> > >> >>>>
>>>> >> > >> >>>> Hi all,
>>>> >> > >> >>>> please try to have a look at this page when you have a
>>>> >> > >> >>>> moment:
>>>> >> > >> >>>>  - http://ci.hibernate.org/view/JDK9/
>>>> >> > >> >>>>
>>>> >> > >> >>>> Hibernate Search is working, and it shouldn't be too hard
>>>> >> > >> >>>> to get
>>>> >> > the
>>>> >> > >> >>>> others "green" as well.
>>>> >> > >> >>>>
>>>> >> > >> >>>> I've disabled some integration tests to get there, notably:
>>>> >> > >> >>>>  - OSGi tests: Karaf is not ready for it.
>>>> >> > >> >>>>  - Documentation build: Asciidoc will probably need an
>>>> >> > >> >>>> update.
>>>> >> > >> >>>>  - WildFly integration tests: the WildFly team is aware,
>>>> >> > >> >>>> will
>>>> >> > >> >>>> need
>>>> >> > a
>>>> >> > >> >>>> minor upgrade.
>>>> >> > >> >>>>
>>>> >> > >> >>>> I don't believe these issues are relevant, so I'm satisfied
>>>> >> > >> >>>> that
>>>> >> > all
>>>> >> > >> >>>> other tests working fine mean that the project will pretty
>>>> >> > >> >>>> much
>>>> >> > work
>>>> >> > >> >>>> out of the box for end users - at worst their container
>>>> >> > >> >>>> won't
>>>> >> > >> >>>> work,
>>>> >> > >> >>>> but that's not our responsibility to test for.
>>>> >> > >> >>>>
>>>> >> > >> >>>> Could you all contribute a bit to get all projects show
>>>> >> > >> >>>> "green"
>>>> >> > >> >>>> on
>>>> >> > >> >>>> this
>>>> >> > >> >>>> page?
>>>> >> > >> >>>>
>>>> >> > >> >>>> Some "workarounds" you might want to apply:
>>>> >> > >> >>>>  - the Logger interfaces won't compile because of a known
>>>> >> > >> >>>> issue,
>>>> >> > this
>>>> >> > >> >>>> can be worked around for now by having the compilation
>>>> >> > >> >>>> phase
>>>> >> > >> >>>> also
>>>> >> > >> >>>> explicitly depend on this artifact:
>>>> >> > >> >>>>
>>>> >> > >> >>>>
>>>> >> > >> >>>>
>>>> >> >
>>>> >> >
>>>> >> > https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
>>>> >> > >> >>>>  - you'll have a ClassNotFoundException on JAXB usage
>>>> >> > >> >>>> unless you
>>>> >> > set
>>>> >> > >> >>>> this JVM flag:
>>>> >> > >> >>>>
>>>> >> > >> >>>>
>>>> >> >
>>>> >> > https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
>>>> >> > >> >>>> (This one is not a bug but will be required to be set by
>>>> >> > >> >>>> end
>>>> >> > >> >>>> users
>>>> >> > as
>>>> >> > >> >>>> well - or we provide our own XML parser, that might be more
>>>> >> > >> >>>> user
>>>> >> > >> >>>> friendly).
>>>> >> > >> >>>>
>>>> >> > >> >>>> As far as I know, other issues with the build tools have
>>>> >> > >> >>>> been
>>>> >> > solved
>>>> >> > >> >>>> already - including Gradle.
>>>> >> > >> >>>>
>>>> >> > >> >>>> Thanks,
>>>> >> > >> >>>> Sanne
>>>> >> > >> >>>> _______________________________________________
>>>> >> > >> >>>> hibernate-dev mailing list
>>>> >> > >> >>>> 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
>>>> >> > >
>>>> >> > >
>>>> >> >
>>>> >> _______________________________________________
>>>> >> hibernate-dev mailing list
>>>> >> hibernate-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Sun Jun 19 23:05:19 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 20 Jun 2016 03:05:19 +0000
Subject: [hibernate-dev] Java 9: progress on compatibility
In-Reply-To: <CAFm4XO27DaPeyw0xKJ4-dyR9L=pToTK6=tnVzpeo1RD+1OTBVA@mail.gmail.com>
References: <CAFm4XO2WYhYV=H5PYDS1qOCe3bJ01LZRQOi7QRL=-vtUqPNZvw@mail.gmail.com>
	<CAFdSV9vw0TKwjt7geBhYw1r=Gsnep+ox=9Nnv5FhNFQk=Zu12w@mail.gmail.com>
	<CAFm4XO2Zm0zYqUah90OUZXw5SbKrGys1VS=FzffFCF_MjqUGdg@mail.gmail.com>
	<CAFm4XO0cbFcfV4gL_McRGuApJdokno-UFjnU71e8-9MSspWKnw@mail.gmail.com>
	<CAFm4XO0X71uGsSzJE4_6xvBj1bWTK8ut_z8uvC5HgphGr6UU2w@mail.gmail.com>
	<CADGJaX-=S3FiKHGEHFJ4jpgc6Ynuyqt-Pvnd1j6eHcOfBFU_Kg@mail.gmail.com>
	<CAFm4XO23LmEWbAMUqH3UMcdW=TKMyX9pTXoRzw3VvEgBCu=PNg@mail.gmail.com>
	<CADGJaX9rMnkuW4XPDevcaYCjCYC8azR9QhS==Y_x52UpH5eaWg@mail.gmail.com>
	<CAFdSV9tWwMt2EfrBmhGrJ5my5D+1hHq0Wa6jEEk0uuw3WAYW=w@mail.gmail.com>
	<CAFm4XO0WAwrkR+vJMgxnuugnT+B09LVuHJAe54Oawi900pta8g@mail.gmail.com>
	<CAFdSV9sH5hBLmFoSZfm76htv43uzQqRJKVeEC_pCaiEqHPt1YQ@mail.gmail.com>
	<CAFdSV9snk7iMhS2fVaOqDknByD9nDt1G9r9WFF4UK8EnAhwGaw@mail.gmail.com>
	<CAFdSV9sdn9BitwgvSoMyhMkyix=m2gore5QskuPm18j949obPQ@mail.gmail.com>
	<CAFm4XO27DaPeyw0xKJ4-dyR9L=pToTK6=tnVzpeo1RD+1OTBVA@mail.gmail.com>
Message-ID: <CAFdSV9tN+_2MmFSPRGEEE-YDsOmp6H7d42Xn7dji3w=O9xdq6Q@mail.gmail.com>

Sounds good to me.  Thanks!

On Sun, Jun 19, 2016 at 6:10 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Steve,
> on ci.hibernate.org either you are admin (with all powers) or you're a
> no-one, having only some read permissions. So I guess you merely
> forgot to login, or you wouldn't be able to change any other job
> either.
>
> Anyway, the JDK 9 build job is showing green!
>  - http://ci.hibernate.org/view/JDK9/job/hibernate-orm-master-h2-JDK9/
>
> I've re-enabled the email notifications: it will bother yourself,
> Andrea, and Chris in case of regressions (on top of notifying whoever
> broke it). Feel free to make any other change..
>
> A build will be triggered after each successful build of the "master
> job" (H2, JDK8, branch master) - only if that is successful, so you
> shouldn't get a pointless notifications about a failure which fails on
> JDK8 too. On the other hand, this means it will take a while to get
> you a JDK9 regression notification as it will need to have completed
> both the master build and the JDK9 build; I hope this is a good
> tradeoff for now, so that you don't get too many emails.
>
> Thanks,
> Sanne
>
>
>
> On 18 June 2016 at 17:37, Steve Ebersole <steve at hibernate.org> wrote:
> > Sanne I do not have rights to edit your ORM JDK 9 job.  I wanted to look
> at
> > the job config to make sure it is ok, but I cannot even see it.
> >
> > On Fri, Jun 17, 2016 at 7:22 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> For the most part we have gotten ORM buildable with Java 9.  Some "open
> >> items":
> >>
> >> Javassist does not seem to support Java 9 much, if at all.  I had to
> >> disable some tests in hibernate-core that test enhancement as well as
> tests
> >> for hibernate-hikari since it uses Javassist extensively too.
> >> hibernate-envers has a bunch of test failures that seem related to
> Javassist
> >> as well.
> >> The tests for hibernate-osgi simply hang.  Something in that test stack
> >> does not like Java 9.
> >>
> >> Longer term we need to decide how we want to handle non standard modules
> >> moving forward.  This mostly came up in regards to JAXB and XJC.  For
> the
> >> moment I added a set of non-transitive dependencies for JAXB and XJC to
> >> hibernate-core and hibernate-jpamodelgen.  Since the hibernate-core one
> is
> >> non-transitive I then had to add a similar fragment to each and every
> module
> >> that depends on hibernate-core tries to run tests using it.  This gets
> fugly
> >> :)  For reference the fragment looks like:
> >>
> >> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >> // Java 9 ftw!
> >> if ( JavaVersion.current().isJava9Compatible() ) {
> >>     // The JDK used to run Gradle is Java 9+, and we assume that that is
> >> the same
> >>     //    JDK for executing tasks
> >>     compile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
> >>     compile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
> >>     compile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
> >>     compile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
> >>     compile( 'javax:javaee-api:7.0' )
> >>
> >>     testCompile( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
> >>     testCompile( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
> >>     testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
> >>     testCompile( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
> >>     testCompile( 'javax:javaee-api:7.0' )
> >>
> >>     testRuntime( 'com.sun.xml.bind:jaxb-impl:2.2.11' )
> >>     testRuntime( 'org.glassfish.jaxb:jaxb-xjc:2.2.11' )
> >>     testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0' )
> >>     testRuntime( 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0' )
> >>     testRuntime( 'javax:javaee-api:7.0' )
> >> }
> >> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>
> >>
> >> I decided to do this non-transitively since users may (probably) would
> >> want to use a better JAXB impl.  Not sure the best way to handle this.
> >>
> >> On Wed, Jun 15, 2016 at 3:14 PM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>>
> >>> No worries, I understand.
> >>>
> >>> On Wed, Jun 15, 2016 at 3:13 PM Sanne Grinovero <sanne at hibernate.org>
> >>> wrote:
> >>>>
> >>>> On 15 June 2016 at 19:29, Steve Ebersole <steve at hibernate.org> wrote:
> >>>> > WRT JAXB (XJC) I am completely lost.
> >>>> >
> >>>> > Sanne I tried your solution of specifying an addmod for jaxb to
> >>>> > GRADLE_OPTS
> >>>> > but get the same result (ExceptionInInitializerError) with and
> without
> >>>> > that
> >>>> > change.  So not sure how you got that to work.
> >>>>
> >>>> Steve, sorry if that wasn't clear: this didn't work for me either.
> >>>> I used the GRADLE_OPTS to bypass other issues which I had before
> >>>> reaching this point, but then I got stuck on the 'xjc' plugin, and
> >>>> that's were I asked if we could bypass/skip/rewrite the plugin.
> >>>>
> >>>> >
> >>>> > I did try the alternative we discussed of defining an explicit build
> >>>> > dependency on JAXB (which again has no effect):
> >>>> >
> >>>> >
> >>>> > xjc 'org.glassfish.jaxb:jaxb-core:2.2.11'
> >>>> > xjc 'org.glassfish.jaxb:jaxb-xjc:2.2.11'
> >>>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics:0.11.0'
> >>>> > xjc 'org.jvnet.jaxb2_commons:jaxb2-basics-ant:0.11.0'
> >>>> >
> >>>> >
> >>>> > For some background, XJC is currently performed via Gradle's
> >>>> > AntBuilder
> >>>> > support using the jaxb2_commons Ant task
> >>>> > (org.jvnet.jaxb2_commons.xjc.XJC2Task). I also have tried using
> Sun's
> >>>> > com.sun.tools.xjc.XJCTask directly.  Neither make any difference.
> The
> >>>> > fundamental problem is that for Ant execution Gradle simply reuses
> its
> >>>> > VM.
> >>>> > So to get this applied (iiuc) the only real option is to configure
> the
> >>>> > Gradle launch to include the addmod (which makes it more odd that
> >>>> > GRADLE_OPTS did not work for me).
> >>>> >
> >>>> > The other option is to write a new Gradle XjcTask that executes the
> >>>> > XJC tool
> >>>> > directly.  That we can use Gradle to help us fork and pass the
> addmod
> >>>> > option
> >>>> > to the forked process.  I think :)
> >>>> >
> >>>> >
> >>>> > On Mon, Jun 13, 2016 at 3:00 AM Gunnar Morling <
> gunnar at hibernate.org>
> >>>> > wrote:
> >>>> >>
> >>>> >> Yep, we discussed that approach last year already:
> >>>> >>
> http://lists.jboss.org/pipermail/hibernate-dev/2015-March/012250.html
> >>>> >>
> >>>> >> 2016-06-13 9:49 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>>> >>
> >>>> >> > On 13 June 2016 at 07:34, Gunnar Morling <gunnar at hibernate.org>
> >>>> >> > wrote:
> >>>> >> > > Hey,
> >>>> >> > >
> >>>> >> > > I hit the same issue with the injection plug-in in HV.
> >>>> >> > >
> >>>> >> > > It was used for obtaining the version of HV at runtime. I
> worked
> >>>> >> > > around
> >>>> >> > it
> >>>> >> > > by obtaining that from the package instead [1]:
> >>>> >> > >
> >>>> >> > >     return
> >>>> >> > > SomeHvClass.class.getPackage().getImplementationVersion();
> >>>> >> >
> >>>> >> > Right, that looks a lot like
> >>>> >> >  -
> >>>> >> >
> >>>> >> >
> >>>> >> >
> https://github.com/hibernate/hibernate-search/commit/fde388e9fd822abf877e56ab4147ac95c9fffd51
> >>>> >> > ;)
> >>>> >> >
> >>>> >> > >
> >>>> >> > > If that's all what the injection plug-in is used for in ORM as
> >>>> >> > > well
> >>>> >> > > (and
> >>>> >> > you
> >>>> >> > > don't depend on that version info e.g. during testing in the
> IDE,
> >>>> >> > > where
> >>>> >> > > there is no JAR manifest yet which is the source of the version
> >>>> >> > > with
> >>>> >> > > that
> >>>> >> > > approach), you could do the same there.
> >>>> >> > >
> >>>> >> > > --Gunnar
> >>>> >> > >
> >>>> >> > > [1]
> >>>> >> > >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> https://github.com/hibernate/hibernate-validator/commit/8a0eb0bfbc7610ea6fc9962eef024a98c3f9468c#diff-963bab11ed76f80c4a804903ed66e03fR34
> >>>> >> > >
> >>>> >> > >
> >>>> >> > > 2016-06-12 22:18 GMT+02:00 Sanne Grinovero <
> sanne at hibernate.org>:
> >>>> >> > >>
> >>>> >> > >> Some more progress by simply setting this environment
> variable:
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> >
> >>>> >> >
> >>>> >> >
> GRADLE_OPTS="-XaddExports:java.security.sasl/com.sun.security.sasl.digest=ALL-UNNAMED
> >>>> >> > >>
> >>>> >> > >>
> -XaddExports:java.security.sasl/com.sun.security.sasl=ALL-UNNAMED
> >>>> >> > >> -XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
> >>>> >> > >> -XaddExports:jdk.unsupported/sun.reflect=ALL-UNNAMED -addmods
> >>>> >> > >> java.xml.bind"
> >>>> >> > >>
> >>>> >> > >> But it's getting tricky:
> >>>> >> > >>
> >>>> >> > >> Caused by: compile error: javassist.NotFoundException:
> >>>> >> > >> java.lang.String
> >>>> >> > >>    at javassist.compiler.Javac.compileBody(Javac.java:229)
> >>>> >> > >>    at javassist.CtBehavior.setBody(CtBehavior.java:438)
> >>>> >> > >>    ... 76 more
> >>>> >> > >>
> >>>> >> > >> This seems to be caused by the following plugin, which I'm not
> >>>> >> > >> familiar
> >>>> >> > >> with:
> >>>> >> > >>  -
> >>>> >> > >>
> >>>> >> >
> >>>> >> >
> >>>> >> >
> org.hibernate.build.gradle.inject.InjectionAction.execute(InjectionAction.java:62)
> >>>> >> > >> Is this something which we could disable/skip/remove for now,
> or
> >>>> >> > >> update to not require Javassist?
> >>>> >> > >>
> >>>> >> > >> Thanks,
> >>>> >> > >> sanne
> >>>> >> > >>
> >>>> >> > >> On 12 June 2016 at 20:56, Sanne Grinovero <
> sanne at hibernate.org>
> >>>> >> > >> wrote:
> >>>> >> > >> > On 11 June 2016 at 18:47, Sanne Grinovero
> >>>> >> > >> > <sanne at hibernate.org>
> >>>> >> > wrote:
> >>>> >> > >> >> On 11 June 2016 at 18:25, Steve Ebersole
> >>>> >> > >> >> <steve at hibernate.org>
> >>>> >> > wrote:
> >>>> >> > >> >>> The ORM failure seems to be a Gradle/JDK9 issue.  Any idea
> >>>> >> > >> >>> about
> >>>> >> > that?
> >>>> >> > >> >>
> >>>> >> > >> >> Not sure, that's a new one :)
> >>>> >> > >> >> It could be related to
> >>>> >> > >> >> https://issues.gradle.org/browse/GRADLE-3287
> >>>> >> > ?
> >>>> >> > >> >>
> >>>> >> > >> >> Might be worth trying to upgrade to Gradle 2.12 .. I'm not
> at
> >>>> >> > >> >> a
> >>>> >> > >> >> terminal at the moment, I could try later.
> >>>> >> > >> >
> >>>> >> > >> > I've upgraded to Gradle 2.13, the pull request is here:
> >>>> >> > >> >  - https://github.com/hibernate/hibernate-orm/pull/1417#
> >>>> >> > >> >
> >>>> >> > >> > It solved that specific issue, but it's not enough. I'm
> still
> >>>> >> > >> > trying
> >>>> >> > >> > to hack a workaround for the next step, but in the meantime
> >>>> >> > >> > that PR
> >>>> >> > >> > could be considered independently.
> >>>> >> > >> >
> >>>> >> > >> > I could use some pointers with Gradle and the custom plugins
> >>>> >> > >> > we
> >>>> >> > >> > use;
> >>>> >> > >> > essentially we need to pass some additional JVM flags,
> >>>> >> > >> > including to
> >>>> >> > >> > javac, like here:
> >>>> >> > >> >  -
> >>>> >> > >> >
> >>>> >> >
> >>>> >> >
> >>>> >> >
> https://github.com/hibernate/hibernate-orm/commit/5e6a8ea754e3c4c59925fe7f824092490efc008b
> >>>> >> > >> >
> >>>> >> > >> > But the failure happens during:
> >>>> >> > >> >  Execution failed for task ':hibernate-core:xjc'
> >>>> >> > >> >
> >>>> >> > >> > and I'm not sure how to override the JVM flags for that
> plugin
> >>>> >> > >> > execution.
> >>>> >> > >> >
> >>>> >> > >> > Thanks,
> >>>> >> > >> > Sanne
> >>>> >> > >> >
> >>>> >> > >> >
> >>>> >> > >> >>
> >>>> >> > >> >>>
> >>>> >> > >> >>> On Fri, Jun 10, 2016, 4:39 PM Sanne Grinovero
> >>>> >> > >> >>> <sanne at hibernate.org>
> >>>> >> > >> >>> wrote:
> >>>> >> > >> >>>>
> >>>> >> > >> >>>> Hi all,
> >>>> >> > >> >>>> please try to have a look at this page when you have a
> >>>> >> > >> >>>> moment:
> >>>> >> > >> >>>>  - http://ci.hibernate.org/view/JDK9/
> >>>> >> > >> >>>>
> >>>> >> > >> >>>> Hibernate Search is working, and it shouldn't be too hard
> >>>> >> > >> >>>> to get
> >>>> >> > the
> >>>> >> > >> >>>> others "green" as well.
> >>>> >> > >> >>>>
> >>>> >> > >> >>>> I've disabled some integration tests to get there,
> notably:
> >>>> >> > >> >>>>  - OSGi tests: Karaf is not ready for it.
> >>>> >> > >> >>>>  - Documentation build: Asciidoc will probably need an
> >>>> >> > >> >>>> update.
> >>>> >> > >> >>>>  - WildFly integration tests: the WildFly team is aware,
> >>>> >> > >> >>>> will
> >>>> >> > >> >>>> need
> >>>> >> > a
> >>>> >> > >> >>>> minor upgrade.
> >>>> >> > >> >>>>
> >>>> >> > >> >>>> I don't believe these issues are relevant, so I'm
> satisfied
> >>>> >> > >> >>>> that
> >>>> >> > all
> >>>> >> > >> >>>> other tests working fine mean that the project will
> pretty
> >>>> >> > >> >>>> much
> >>>> >> > work
> >>>> >> > >> >>>> out of the box for end users - at worst their container
> >>>> >> > >> >>>> won't
> >>>> >> > >> >>>> work,
> >>>> >> > >> >>>> but that's not our responsibility to test for.
> >>>> >> > >> >>>>
> >>>> >> > >> >>>> Could you all contribute a bit to get all projects show
> >>>> >> > >> >>>> "green"
> >>>> >> > >> >>>> on
> >>>> >> > >> >>>> this
> >>>> >> > >> >>>> page?
> >>>> >> > >> >>>>
> >>>> >> > >> >>>> Some "workarounds" you might want to apply:
> >>>> >> > >> >>>>  - the Logger interfaces won't compile because of a known
> >>>> >> > >> >>>> issue,
> >>>> >> > this
> >>>> >> > >> >>>> can be worked around for now by having the compilation
> >>>> >> > >> >>>> phase
> >>>> >> > >> >>>> also
> >>>> >> > >> >>>> explicitly depend on this artifact:
> >>>> >> > >> >>>>
> >>>> >> > >> >>>>
> >>>> >> > >> >>>>
> >>>> >> >
> >>>> >> >
> >>>> >> >
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L878-L883
> >>>> >> > >> >>>>  - you'll have a ClassNotFoundException on JAXB usage
> >>>> >> > >> >>>> unless you
> >>>> >> > set
> >>>> >> > >> >>>> this JVM flag:
> >>>> >> > >> >>>>
> >>>> >> > >> >>>>
> >>>> >> >
> >>>> >> >
> https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L1429
> >>>> >> > >> >>>> (This one is not a bug but will be required to be set by
> >>>> >> > >> >>>> end
> >>>> >> > >> >>>> users
> >>>> >> > as
> >>>> >> > >> >>>> well - or we provide our own XML parser, that might be
> more
> >>>> >> > >> >>>> user
> >>>> >> > >> >>>> friendly).
> >>>> >> > >> >>>>
> >>>> >> > >> >>>> As far as I know, other issues with the build tools have
> >>>> >> > >> >>>> been
> >>>> >> > solved
> >>>> >> > >> >>>> already - including Gradle.
> >>>> >> > >> >>>>
> >>>> >> > >> >>>> Thanks,
> >>>> >> > >> >>>> Sanne
> >>>> >> > >> >>>> _______________________________________________
> >>>> >> > >> >>>> hibernate-dev mailing list
> >>>> >> > >> >>>> 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
> >>>> >> > >
> >>>> >> > >
> >>>> >> >
> >>>> >> _______________________________________________
> >>>> >> hibernate-dev mailing list
> >>>> >> hibernate-dev at lists.jboss.org
> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Mon Jun 20 02:55:46 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Jun 2016 08:55:46 +0200
Subject: [hibernate-dev] [Question] Target runtime WildFly is unpacked
	after maven tests
In-Reply-To: <CACWxqgC5rJAdS=wzQs83dQL1cp+ivxXCVzraqYOmzepFhbhA1Q@mail.gmail.com>
References: <CACWxqgC5rJAdS=wzQs83dQL1cp+ivxXCVzraqYOmzepFhbhA1Q@mail.gmail.com>
Message-ID: <CADGJaX86cnLJqoBOzMN66iYoF8CtpyM+WySJMJRyD91asQTToQ@mail.gmail.com>

Hi Mincong,

Seems you got an answer on SO already. Very glad to see you are making good
progress!

Cheers,

--Gunnar


2016-06-18 17:05 GMT+02:00 Mincong Huang <mincong.h at gmail.com>:

> Hi everybody,
>
> I'm Mincong, your intern from Google Summer of Code. I'm working on
> a new implement of mass indexer for Hibernate Search but I get some
> difficulties to configure correctly the test cases. It seems that the tests
> try to run before the WF10 setup. I've post this question on Stack Overflow
> [1]. The question itself is really long, so please click the link to see
> it. Any
> tip will be helpful.
>
> Thank you and have a good weekend :)
>
> Mincong
>
> [1]:
> http://stackoverflow.com/questions/37898297/target-runtime-wildfly-is-unpacked-after-maven-tests
>

From mincong.h at gmail.com  Mon Jun 20 02:58:45 2016
From: mincong.h at gmail.com (Mincong Huang)
Date: Mon, 20 Jun 2016 08:58:45 +0200
Subject: [hibernate-dev] [Question] Target runtime WildFly is unpacked
	after maven tests
In-Reply-To: <CADGJaX86cnLJqoBOzMN66iYoF8CtpyM+WySJMJRyD91asQTToQ@mail.gmail.com>
References: <CACWxqgC5rJAdS=wzQs83dQL1cp+ivxXCVzraqYOmzepFhbhA1Q@mail.gmail.com>
	<CADGJaX86cnLJqoBOzMN66iYoF8CtpyM+WySJMJRyD91asQTToQ@mail.gmail.com>
Message-ID: <CACWxqgCAQeugo4-1OC2ABJjVnaPCOzndir7arSx4FbLTfHVNhA@mail.gmail.com>

Thanks, Gunnar :)

On Mon, Jun 20, 2016 at 8:55 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi Mincong,
>
> Seems you got an answer on SO already. Very glad to see you are making
> good progress!
>
> Cheers,
>
> --Gunnar
>
>
> 2016-06-18 17:05 GMT+02:00 Mincong Huang <mincong.h at gmail.com>:
>
>> Hi everybody,
>>
>> I'm Mincong, your intern from Google Summer of Code. I'm working on
>> a new implement of mass indexer for Hibernate Search but I get some
>> difficulties to configure correctly the test cases. It seems that the
>> tests
>> try to run before the WF10 setup. I've post this question on Stack
>> Overflow
>> [1]. The question itself is really long, so please click the link to see
>> it. Any
>> tip will be helpful.
>>
>> Thank you and have a good weekend :)
>>
>> Mincong
>>
>> [1]:
>> http://stackoverflow.com/questions/37898297/target-runtime-wildfly-is-unpacked-after-maven-tests
>>
>
>

From emmanuel at hibernate.org  Mon Jun 20 03:33:08 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 20 Jun 2016 09:33:08 +0200
Subject: [hibernate-dev] No Hibernate Search version compatible with
 Hibernate ORM 5.2.0.Final
In-Reply-To: <CAFm4XO2r_BXySW8z-XevWWKYyKwKSdgYPFx0PZ2AE0fRhwfLSA@mail.gmail.com>
References: <CAFm4XO2r_BXySW8z-XevWWKYyKwKSdgYPFx0PZ2AE0fRhwfLSA@mail.gmail.com>
Message-ID: <20160620073308.GB18153@hibernate.org>

Are the incompatibilities here for good on ORM, or could they be
reverted / softened in the 5.2 branch to allow for an easier path?



On Tue 2016-06-14 17:33, Sanne Grinovero wrote:
> There have been various complaints that people can't upgrade to the
> latest Hibernate ORM because they don't have a compatible version of
> Hibernate Search.
> 
> Rejected 3 issues on JIRA as duplicates of:
> https://hibernate.atlassian.net/browse/HSEARCH-2296
> 
> We never guaranteed compatibility beyond the micro-range, still we
> probably should do something about this as I hate rejecting issues.
> 
> Status reminder:
>  - we're not ready to release a "Final" version of Hibernate Search
> branch 5.6 because the Elasticsearch work isn't complete.
>  - the changes needed to be compatible with Hibernate ORM 5.2 are
> breaking, i.e. it won't work with Hibernate ORM 5.0 and 5.1 if I apply
> them.
>  - Hibernate Search 5.5 (the previous stable branch) works fine with
> both ORM 5.0.x and 5.1.x.
>  - Breaking compatibility with ORM 5.1 means to break compatibility
> with WildFly 10 (unless they also upgrade or we start shipping
> alternative ORM modules).
> 
> On top of this, Hibernate OGM was wishing to have an upgrade to ORM
> 5.1.x. I don't see how we can squeeze that in.
> 
> The only solution I see is that people will have to be patient and use
> ORM 5.0 / 5.1 for now.
> 
> Better ideas?
> 
> I have a branch of Search which is making progress towards ORM 5.2
> compatibility.. not fully complete but it's very clear already that we
> can't keep compatibility open for a wider range of ORM versions. Feel
> free to try ;)
> 
> Also related, the proposal here:
>  - https://hibernate.atlassian.net/browse/HHH-10793
> 
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From rvansa at redhat.com  Mon Jun 20 03:50:06 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 20 Jun 2016 09:50:06 +0200
Subject: [hibernate-dev] Is
 org.hibernate.cache.spi.OptimisticCacheSource#getVersionComparator
 obsolete?
In-Reply-To: <CAFdSV9uFFK+Uzc0fdzB3VOB+rkyMwXDw4BBKLT1C5wngv=LdRg@mail.gmail.com>
References: <CAFDzhiShHqL9fC6parpfcBRGSKtokqXpU8VoQWiKSiEhUdvAuw@mail.gmail.com>
	<CAFdSV9uFFK+Uzc0fdzB3VOB+rkyMwXDw4BBKLT1C5wngv=LdRg@mail.gmail.com>
Message-ID: <5767A02E.1060007@redhat.com>

On 06/18/2016 06:14 PM, Steve Ebersole wrote:
> TIMESTAMP is a deprecated synonym for the TSQL rownumber datatype, at least
> on SQL Server.  Not sure specifically about Sybase.  So I'll use "rownumber"
> here...
>
> As we discussed in HipChat yesterday OptimisticCacheSource was added a long
> time ago to facilitate leveraging JBossCache's MVCC support for versioned
> data.  The idea was to allow JBossCache to reuse a versioned entity's
> version as its MVCC version via the comparator.
>
> JBossCache is of course no more, now morphed into Infinispan.  To my
> knowledge, Infinispan does not have the same MVCC support if any.  Either
> way, hibernate-infinispan does not support MVCC in the Infinispan cache by
> leveraging the entity version.  Radim, Galder - is this something we want
> to consider?

Versions can remove the need to lock some entries. At this point the 
comparison is used only in the nonstrict read-write access strategy, and 
it does not use Infinispan MVCC (I can't recall exactly why, probably it 
was more convenient to have the version in entry value than in metadata, 
as there's really no OOTB support).

One reason this is not leveraged more is that it imposes limitation on 
the types of entries; though it can be transparent to the user, the 
effort is still reduced by the fact that it's only a portion of use cases.

>
> Depending on the version (and I forget the exact version this changed) the
> role played by OptimisticCacheSource is actually now handled by
> org.hibernate.cache.spi.CacheDataDescription.
> So that is one of the reasons you do not find any uses of
> OptimisticCacheSource#getVersionComparator.  Do a usage search for
> CacheDataDescription#getVersionComparator instead.
>
> Same question, different contract.

Never seen OptimisticCacheSource, CDD was there at hand. Infinispan does 
not need to keep that in API.

>
> Some of the cache providers do leverage this version comparator (via
> CacheDataDescription#getVersionComparator) for read-write locking.  So
> really the question is whether we want to allow the combination of:
>
>
>     1.  these cache providers with those access strategies using the version
>     comparator
>     2. versions based on TSQL rowversion datatype.
>
> Aside from a general dislike of versions based on TSQL rowversion datatype
> (for many reasons), there is no fundamental reason to not allow it as a
> comparator (provided we find the right comparison algorithm).  If you have
> found the secret incantation for writing a proper Java Comparator based on
> the TSQL rowversion datatype, then I think we should just implement that.

If DB has that info, it's fair that Cache can have that, too. I would 
keep the support, though it does not have to have 100% coverage on the 
possible datatypes (if there are 2% that are too complex to implement).

Radim

> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From sanne at hibernate.org  Mon Jun 20 06:47:06 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 20 Jun 2016 11:47:06 +0100
Subject: [hibernate-dev] No Hibernate Search version compatible with
 Hibernate ORM 5.2.0.Final
In-Reply-To: <20160620073308.GB18153@hibernate.org>
References: <CAFm4XO2r_BXySW8z-XevWWKYyKwKSdgYPFx0PZ2AE0fRhwfLSA@mail.gmail.com>
	<20160620073308.GB18153@hibernate.org>
Message-ID: <CAFm4XO0FojkFfyYN3C-V9Z_mcNxTh-zJNk1zPd6x5WPij9whAg@mail.gmail.com>

On 20 June 2016 at 08:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Are the incompatibilities here for good on ORM, or could they be
> reverted / softened in the 5.2 branch to allow for an easier path?

I'm working on a set of PRs for both ORM and Search which reduce the
list of incompatibilities,
but while the amount of issues is getting lower I strongly suspect
that I won't be able to get it down to zero.

Of course some more changes on ORM SPIs could be reverted but I don't
feel like that's something we could do in a micro..

-- Sanne

From gunnar at hibernate.org  Mon Jun 20 07:03:24 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 20 Jun 2016 13:03:24 +0200
Subject: [hibernate-dev] No Hibernate Search version compatible with
 Hibernate ORM 5.2.0.Final
In-Reply-To: <CAFm4XO0FojkFfyYN3C-V9Z_mcNxTh-zJNk1zPd6x5WPij9whAg@mail.gmail.com>
References: <CAFm4XO2r_BXySW8z-XevWWKYyKwKSdgYPFx0PZ2AE0fRhwfLSA@mail.gmail.com>
	<20160620073308.GB18153@hibernate.org>
	<CAFm4XO0FojkFfyYN3C-V9Z_mcNxTh-zJNk1zPd6x5WPij9whAg@mail.gmail.com>
Message-ID: <CADGJaX90DPyPDCksP-GNh7fGz4OzeC_32AfSxdSPWEVD=AhijQ@mail.gmail.com>

What changes are we talking here specifically? Have they been done
intentionally or by accident?

For the better or worse, ORM - so far - doesn't stick to SemVer rules, so I
don't think we should revert anything which has been changed on purpose.
Different story for accidental changes of course.

In HSEARCH we are using a tool named "japicmp" (
http://siom79.github.io/japicmp/) for creating a report with changed public
API/SPIs. Running this prior to a release - comparing to the last stable
version - helps to detect any unintentional changes and create a public
report / migration notes for intentionally changed things.


2016-06-20 12:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 20 June 2016 at 08:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > Are the incompatibilities here for good on ORM, or could they be
> > reverted / softened in the 5.2 branch to allow for an easier path?
>
> I'm working on a set of PRs for both ORM and Search which reduce the
> list of incompatibilities,
> but while the amount of issues is getting lower I strongly suspect
> that I won't be able to get it down to zero.
>
> Of course some more changes on ORM SPIs could be reverted but I don't
> feel like that's something we could do in a micro..
>
> -- Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Jun 20 09:33:13 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 20 Jun 2016 14:33:13 +0100
Subject: [hibernate-dev] No Hibernate Search version compatible with
 Hibernate ORM 5.2.0.Final
In-Reply-To: <CADGJaX90DPyPDCksP-GNh7fGz4OzeC_32AfSxdSPWEVD=AhijQ@mail.gmail.com>
References: <CAFm4XO2r_BXySW8z-XevWWKYyKwKSdgYPFx0PZ2AE0fRhwfLSA@mail.gmail.com>
	<20160620073308.GB18153@hibernate.org>
	<CAFm4XO0FojkFfyYN3C-V9Z_mcNxTh-zJNk1zPd6x5WPij9whAg@mail.gmail.com>
	<CADGJaX90DPyPDCksP-GNh7fGz4OzeC_32AfSxdSPWEVD=AhijQ@mail.gmail.com>
Message-ID: <CAFm4XO1WCNrqkdiAcr9V0csfLNZxY_QeRYMf4ptVgknnJw4WJQ@mail.gmail.com>

On 20 June 2016 at 12:03, Gunnar Morling <gunnar at hibernate.org> wrote:
> What changes are we talking here specifically? Have they been done
> intentionally or by accident?

The change with highest impact on Search is that the various Query API
interfaces have been moved.

The legacy contracts still exist in the original location, but are
deprecated and extend the new types; this might be all good for end
users - and necessary as some JPA and "native" APIs have been merged
-, but we actually extend these interfaces with the Fulltext versions,
and have custom implementations of each.. which implies we now have to
implement also the new methods of the new contracts.

It might be possible to introduce a base class in ORM for Search to
extend - like we did in the past for other components -  but even
doing so this same base class should also be backported to older ORM
versions which we want to support with the same Search build; this
means we could support newer bugfix releases of the older minor
branches, but the trick won't work with e.g. existing Wildfly unless
we get them to do a release with such a newly patched ORM.

BTW it's all non-trivial as other elements which need to be passed the
Query implementations - like Metadata related types - have also been
moved.

Then there are several smaller issues which could be easily solved,
but add up in complexity: eg some services have been moved in a
different SPI package, and Search used to lookup these services by
class type. We'd need to re-introduce the old service type as a
deprecated interface within the ORM sources, and patch ORM's
serviceregistry so that when asking X you actually get the newer
version Y of that same service (downcasted).

These minor things are doable but are a pointless exercise if the
bigger impact issues (the Query API) don't get addressed as well.

The doubt is that this is all not worth it: ideally I'd prefer to have
Hibernate Search stick on ORM 5.1 for a while longer, and upgrade to
ORM 5.2 when a WildFly 10.x release introduces ORM 5.2, or if we could
have those ORM 5.2 modules for any WildFly version.
At that point we'll require ORM 5.2, let's aim at not have people wait
too long for that - at least we'd be spending energy in forward-moving
progress rather than on maintenance which will be useless soon enough.

Thanks,
Sanne


>
> For the better or worse, ORM - so far - doesn't stick to SemVer rules, so I
> don't think we should revert anything which has been changed on purpose.
> Different story for accidental changes of course.
>
> In HSEARCH we are using a tool named "japicmp"
> (http://siom79.github.io/japicmp/) for creating a report with changed public
> API/SPIs. Running this prior to a release - comparing to the last stable
> version - helps to detect any unintentional changes and create a public
> report / migration notes for intentionally changed things.
>
>
> 2016-06-20 12:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> On 20 June 2016 at 08:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> > Are the incompatibilities here for good on ORM, or could they be
>> > reverted / softened in the 5.2 branch to allow for an easier path?
>>
>> I'm working on a set of PRs for both ORM and Search which reduce the
>> list of incompatibilities,
>> but while the amount of issues is getting lower I strongly suspect
>> that I won't be able to get it down to zero.
>>
>> Of course some more changes on ORM SPIs could be reverted but I don't
>> feel like that's something we could do in a micro..
>>
>> -- Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Mon Jun 20 09:47:45 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 20 Jun 2016 13:47:45 +0000
Subject: [hibernate-dev] No Hibernate Search version compatible with
 Hibernate ORM 5.2.0.Final
In-Reply-To: <CADGJaX90DPyPDCksP-GNh7fGz4OzeC_32AfSxdSPWEVD=AhijQ@mail.gmail.com>
References: <CAFm4XO2r_BXySW8z-XevWWKYyKwKSdgYPFx0PZ2AE0fRhwfLSA@mail.gmail.com>
	<20160620073308.GB18153@hibernate.org>
	<CAFm4XO0FojkFfyYN3C-V9Z_mcNxTh-zJNk1zPd6x5WPij9whAg@mail.gmail.com>
	<CADGJaX90DPyPDCksP-GNh7fGz4OzeC_32AfSxdSPWEVD=AhijQ@mail.gmail.com>
Message-ID: <CAFdSV9uXhusP532NjqrqUT-AHt_amQMeFzAvSjuKSqrp07KgGQ@mail.gmail.com>

We all discussed these changes in the dev list.  You could easily have been
proactive in these concerns.  And yes, I mentioned exactly these points
Sanne is bringing up on that original discussion.

Bottom line we all agreed that there were some breaking changes in 5.2 and
we all understood the motivations and we all agreed to do them anyway.

Thanks.


On Mon, Jun 20, 2016 at 6:03 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> What changes are we talking here specifically? Have they been done
> intentionally or by accident?
>
> For the better or worse, ORM - so far - doesn't stick to SemVer rules, so I
> don't think we should revert anything which has been changed on purpose.
> Different story for accidental changes of course.
>
> In HSEARCH we are using a tool named "japicmp" (
> http://siom79.github.io/japicmp/) for creating a report with changed
> public
> API/SPIs. Running this prior to a release - comparing to the last stable
> version - helps to detect any unintentional changes and create a public
> report / migration notes for intentionally changed things.
>
>
> 2016-06-20 12:47 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > On 20 June 2016 at 08:33, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> > > Are the incompatibilities here for good on ORM, or could they be
> > > reverted / softened in the 5.2 branch to allow for an easier path?
> >
> > I'm working on a set of PRs for both ORM and Search which reduce the
> > list of incompatibilities,
> > but while the amount of issues is getting lower I strongly suspect
> > that I won't be able to get it down to zero.
> >
> > Of course some more changes on ORM SPIs could be reverted but I don't
> > feel like that's something we could do in a micro..
> >
> > -- Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From guillaume.smet at gmail.com  Tue Jun 21 10:34:41 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 21 Jun 2016 16:34:41 +0200
Subject: [hibernate-dev] NoORM IRC meeting transcripts
Message-ID: <CALt0+o_NUKfufO1Vw6zUB0p8Q37xxqJQkst=hqcxd9cVtE6Y3g@mail.gmail.com>

Hi everyone,

Here are the transcripts of this week's NoORM IRC meeting.

16:32 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-21-13.05.html
16:32 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-21-13.05.txt
16:32 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-21-13.05.log.html

-- 
Guillaume

From steve at hibernate.org  Wed Jun 22 12:54:37 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Jun 2016 16:54:37 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
Message-ID: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>

I started a wiki discussing the proposal for the type system redesign.
Let's get discussions about it starter sooner rather than later.  Thanks!

https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign

From gbadner at redhat.com  Thu Jun 23 17:37:01 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 23 Jun 2016 14:37:01 -0700
Subject: [hibernate-dev] HHH-10888
Message-ID: <CAFDzhiTNOX4Bsi1i8pQLAfp=pNmM5_PGnm6Ax+kHP7ikrvQhRg@mail.gmail.com>

Currently, Hibernate's implementation of
javax.persistence.metamodel.PluralAttribute#isAssociation always returns
true. I haven't found anything in JSR 338 (yet) that refers to an element
collection as an association.

I don't see a good definition of "association", but the term is used with
respect to entities. I also see examples of @ElementCollection with
@AttributeOverride, but none with @AssociationOverride.

The change suggested in HHH-10888 is to have
PluralAttributeImpl#isAssociation return true only for one-to-many and
many-to-many. I believe this is correct, but it breaks a couple of tests
that specifically check if an element collection is an association.

I wanted to pass this by you in case I'm missing something here.

Please take a look at the pull request to see the fix and the required test
changes. [1]

Thanks,
Gail

https://github.com/hibernate/hibernate-orm/pull/1447

From gbadner at redhat.com  Fri Jun 24 02:11:04 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 23 Jun 2016 23:11:04 -0700
Subject: [hibernate-dev] HIbernate ORM CI builds
In-Reply-To: <CAFdSV9u8kgGgBvWEw_Asj6Ogk9z62jAU8Rnv=7x2_2V270LKRw@mail.gmail.com>
References: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
	<61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
	<CAFm4XO3A-2xQe_kH6B7oAV6rbwrsqd+bU6zsO7ugZYZ43XBO3A@mail.gmail.com>
	<CAFdSV9u8kgGgBvWEw_Asj6Ogk9z62jAU8Rnv=7x2_2V270LKRw@mail.gmail.com>
Message-ID: <CAFDzhiQGvneuSpgaN4XH3-BE1-bCXb3LWM+7MrwG00L-diWKuw@mail.gmail.com>

If check is so compute intensive, does it really have to be done on each
commit? When I've seen failures, it has been easy to figure out what is
wrong. Can the check job be done nightly, or on demand (e.g., before a
release)?

On Sat, Jun 18, 2016 at 11:20 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/
> http://ci.hibernate.org/job/hibernate-orm-master-h2-check/
>
> Initial attempt
>
> On Sat, Jun 18, 2016 at 12:58 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > On 18 June 2016 at 18:50, Chris Cranford <crancran at gmail.com> wrote:
> > > +1
> > >
> > > I think (1) and (2) on each push still makes sense with (3) being
> > nightly.
> >
> > +1
> >
> >  -- Sanne
> >
> > >
> > > Chris
> > >
> > >
> > > On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> > >> We have been having a lot of timeouts on the ORM CI builds.  Mainly
> > this is
> > >> due to ancillary tasks.  Currently the ORM jobs execute:
> > >>
> > >>     1. clean
> > >>     2. test
> > >>     3. check
> > >>     4. :documentation:aggregateJavadocs
> > >>     5. publish
> > >>
> > >> A huge chunk of the time is taken up in (3) which performs (a)
> > checkstyle
> > >> and (b) findbugs.  Also, I am not sure of the benefit of building
> > >> aggregated javadocs for each and every CI build.  So I propose we
> break
> > >> these up as follows:
> > >>
> > >>
> > >>     1. A check job
> > >>     2. A clean/test/publish job
> > >>     3. (?) aggregated javadocs job (?)
> > >>
> > >> This would allow us to split the cost of the Job timeout across the
> > jobs.
> > >> In fact we might even consider making some of these into nightly
> job(s).
> > >> Initially in setting up this server we decided to just have singular,
> > >> all-encompassing jobs because moving to a new dedicated set of
> hardware
> > >> (dedicated to Hibernate team) was supposed to free us from jobs
> fighting
> > >> for resources.  But as our jobs have grown on the dedicated hardware
> we
> > are
> > >> seeing some of the same.  For certain we want a clean/test/publish job
> > that
> > >> is run on every push.  To me the others are more flexible in terms of
> > >> scheduling.  We could have a separate check job that is run on each
> > push,
> > >> or it could be a nightly job.  We might even decide to leave off
> > building
> > >> aggregated javadocs as an automated job/task, or we might decide to
> > make it
> > >> a nightly job as well (maybe even with full documentation builds).
> > >>
> > >> WDYT?
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> 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
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From gunnar at hibernate.org  Fri Jun 24 04:14:13 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 24 Jun 2016 10:14:13 +0200
Subject: [hibernate-dev] [OGM] Doing a 5.0.1 release?
Message-ID: <CADGJaX-L1gGwxGMBOLpQ5aHsw9_9tH+GxTk7dXfJxq05tg=Phw@mail.gmail.com>

Hi,

I noticed there is a 5.0.1 version in JIRA for OGM, and a handful of issues
are assigned to it. Do we still plan to do such 5.0.1, or is everyone
focused on the first preview for 5.1 right now?

There is one interesting issue in 5.0.1 which alone I'd find worth
releasing: OGM-828 ("Need to list entities when using Hibernate OGM on
WildFly"). We also might consider to backport some of the recent bugfixes
and create a branch for 5.0 off master, prior to the first work meant for
5.1 (Neo4j Remote etc.).

I'd like that, not the least to have another release soon-ish (say next
week?), preventing another long phase without news from OGM. Thoughts?

Thanks,

--Gunnar

From sanne at hibernate.org  Fri Jun 24 05:57:29 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 24 Jun 2016 10:57:29 +0100
Subject: [hibernate-dev] [OGM] Doing a 5.0.1 release?
In-Reply-To: <CADGJaX-L1gGwxGMBOLpQ5aHsw9_9tH+GxTk7dXfJxq05tg=Phw@mail.gmail.com>
References: <CADGJaX-L1gGwxGMBOLpQ5aHsw9_9tH+GxTk7dXfJxq05tg=Phw@mail.gmail.com>
Message-ID: <CAFm4XO2Lq4O9TDMaXfjU2fm6oJkoE+M6FHz89q0+7V4+_4je9Q@mail.gmail.com>

+1 keep those releases coming!
and yes those fixes need to be made available better sooner than later.
On 24 Jun 2016 09:14, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> Hi,
>
> I noticed there is a 5.0.1 version in JIRA for OGM, and a handful of issues
> are assigned to it. Do we still plan to do such 5.0.1, or is everyone
> focused on the first preview for 5.1 right now?
>
> There is one interesting issue in 5.0.1 which alone I'd find worth
> releasing: OGM-828 ("Need to list entities when using Hibernate OGM on
> WildFly"). We also might consider to backport some of the recent bugfixes
> and create a branch for 5.0 off master, prior to the first work meant for
> 5.1 (Neo4j Remote etc.).
>
> I'd like that, not the least to have another release soon-ish (say next
> week?), preventing another long phase without news from OGM. Thoughts?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From daltodavide at gmail.com  Fri Jun 24 05:59:58 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 24 Jun 2016 10:59:58 +0100
Subject: [hibernate-dev] [OGM] Doing a 5.0.1 release?
In-Reply-To: <CAFm4XO2Lq4O9TDMaXfjU2fm6oJkoE+M6FHz89q0+7V4+_4je9Q@mail.gmail.com>
References: <CADGJaX-L1gGwxGMBOLpQ5aHsw9_9tH+GxTk7dXfJxq05tg=Phw@mail.gmail.com>
	<CAFm4XO2Lq4O9TDMaXfjU2fm6oJkoE+M6FHz89q0+7V4+_4je9Q@mail.gmail.com>
Message-ID: <CANoTJYOtCbZTzz=gasYZ56myAjeCBedR0ovgLou+CUm_FcsjgQ@mail.gmail.com>

Sounds good to me

Davide

On Fri, Jun 24, 2016 at 10:57 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
> +1 keep those releases coming!
> and yes those fixes need to be made available better sooner than later.
> On 24 Jun 2016 09:14, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>
>> Hi,
>>
>> I noticed there is a 5.0.1 version in JIRA for OGM, and a handful of issues
>> are assigned to it. Do we still plan to do such 5.0.1, or is everyone
>> focused on the first preview for 5.1 right now?
>>
>> There is one interesting issue in 5.0.1 which alone I'd find worth
>> releasing: OGM-828 ("Need to list entities when using Hibernate OGM on
>> WildFly"). We also might consider to backport some of the recent bugfixes
>> and create a branch for 5.0 off master, prior to the first work meant for
>> 5.1 (Neo4j Remote etc.).
>>
>> I'd like that, not the least to have another release soon-ish (say next
>> week?), preventing another long phase without news from OGM. Thoughts?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> 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

From gunnar at hibernate.org  Fri Jun 24 06:05:13 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 24 Jun 2016 12:05:13 +0200
Subject: [hibernate-dev] [OGM] Doing a 5.0.1 release?
In-Reply-To: <CANoTJYOtCbZTzz=gasYZ56myAjeCBedR0ovgLou+CUm_FcsjgQ@mail.gmail.com>
References: <CADGJaX-L1gGwxGMBOLpQ5aHsw9_9tH+GxTk7dXfJxq05tg=Phw@mail.gmail.com>
	<CAFm4XO2Lq4O9TDMaXfjU2fm6oJkoE+M6FHz89q0+7V4+_4je9Q@mail.gmail.com>
	<CANoTJYOtCbZTzz=gasYZ56myAjeCBedR0ovgLou+CUm_FcsjgQ@mail.gmail.com>
Message-ID: <CADGJaX9+1G7TEy_q-vEadBGptjuv-RfZuq7XX1zV55LkQns9TQ@mail.gmail.com>

Cool; Anyone volunteering for doing the release?

2016-06-24 11:59 GMT+02:00 Davide D'Alto <daltodavide at gmail.com>:

> Sounds good to me
>
> Davide
>
> On Fri, Jun 24, 2016 at 10:57 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> > +1 keep those releases coming!
> > and yes those fixes need to be made available better sooner than later.
> > On 24 Jun 2016 09:14, "Gunnar Morling" <gunnar at hibernate.org> wrote:
> >
> >> Hi,
> >>
> >> I noticed there is a 5.0.1 version in JIRA for OGM, and a handful of
> issues
> >> are assigned to it. Do we still plan to do such 5.0.1, or is everyone
> >> focused on the first preview for 5.1 right now?
> >>
> >> There is one interesting issue in 5.0.1 which alone I'd find worth
> >> releasing: OGM-828 ("Need to list entities when using Hibernate OGM on
> >> WildFly"). We also might consider to backport some of the recent
> bugfixes
> >> and create a branch for 5.0 off master, prior to the first work meant
> for
> >> 5.1 (Neo4j Remote etc.).
> >>
> >> I'd like that, not the least to have another release soon-ish (say next
> >> week?), preventing another long phase without news from OGM. Thoughts?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> 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
>

From steve at hibernate.org  Fri Jun 24 11:40:32 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Jun 2016 15:40:32 +0000
Subject: [hibernate-dev] HIbernate ORM CI builds
In-Reply-To: <CAFDzhiQGvneuSpgaN4XH3-BE1-bCXb3LWM+7MrwG00L-diWKuw@mail.gmail.com>
References: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
	<61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
	<CAFm4XO3A-2xQe_kH6B7oAV6rbwrsqd+bU6zsO7ugZYZ43XBO3A@mail.gmail.com>
	<CAFdSV9u8kgGgBvWEw_Asj6Ogk9z62jAU8Rnv=7x2_2V270LKRw@mail.gmail.com>
	<CAFDzhiQGvneuSpgaN4XH3-BE1-bCXb3LWM+7MrwG00L-diWKuw@mail.gmail.com>
Message-ID: <CAFdSV9v90s+7QeOMT_bjbY158Dvwe2CqPJdyOjorS2JjJdzQ=g@mail.gmail.com>

I definitely want it run regularly (i.e. not "just before a release").  I'd
be ok with it being nightly.  That's why I asked in the first place.
Everyone who responded +1'd to it being on-each-push.  I really don't
care.  I tend to agree it should be nightly, but I only get one vote :)

So the one bad thing about it not being per-push is that we may notify more
than just the person that pushed the breakage.

For now I went ahead and made it nightly (I think, see below) so that we
can see how that works.

To "make it nightly" I enabled 2 triggers:
1) after push
2) each night

Is that inclusive or exclusive?  Really what I'd like to say is "run it
nightly, but only if a change has been pushed" (no need to run `check`
twice against the same inputs).  So will those triggers do that?

On Fri, Jun 24, 2016 at 1:11 AM Gail Badner <gbadner at redhat.com> wrote:

> If check is so compute intensive, does it really have to be done on each
> commit? When I've seen failures, it has been easy to figure out what is
> wrong. Can the check job be done nightly, or on demand (e.g., before a
> release)?
>
> On Sat, Jun 18, 2016 at 11:20 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/
>> http://ci.hibernate.org/job/hibernate-orm-master-h2-check/
>>
>> Initial attempt
>>
>> On Sat, Jun 18, 2016 at 12:58 PM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>> > On 18 June 2016 at 18:50, Chris Cranford <crancran at gmail.com> wrote:
>> > > +1
>> > >
>> > > I think (1) and (2) on each push still makes sense with (3) being
>> > nightly.
>> >
>> > +1
>> >
>> >  -- Sanne
>> >
>> > >
>> > > Chris
>> > >
>> > >
>> > > On 06/18/2016 11:33 AM, Steve Ebersole wrote:
>> > >> We have been having a lot of timeouts on the ORM CI builds.  Mainly
>> > this is
>> > >> due to ancillary tasks.  Currently the ORM jobs execute:
>> > >>
>> > >>     1. clean
>> > >>     2. test
>> > >>     3. check
>> > >>     4. :documentation:aggregateJavadocs
>> > >>     5. publish
>> > >>
>> > >> A huge chunk of the time is taken up in (3) which performs (a)
>> > checkstyle
>> > >> and (b) findbugs.  Also, I am not sure of the benefit of building
>> > >> aggregated javadocs for each and every CI build.  So I propose we
>> break
>> > >> these up as follows:
>> > >>
>> > >>
>> > >>     1. A check job
>> > >>     2. A clean/test/publish job
>> > >>     3. (?) aggregated javadocs job (?)
>> > >>
>> > >> This would allow us to split the cost of the Job timeout across the
>> > jobs.
>> > >> In fact we might even consider making some of these into nightly
>> job(s).
>> > >> Initially in setting up this server we decided to just have singular,
>> > >> all-encompassing jobs because moving to a new dedicated set of
>> hardware
>> > >> (dedicated to Hibernate team) was supposed to free us from jobs
>> fighting
>> > >> for resources.  But as our jobs have grown on the dedicated hardware
>> we
>> > are
>> > >> seeing some of the same.  For certain we want a clean/test/publish
>> job
>> > that
>> > >> is run on every push.  To me the others are more flexible in terms of
>> > >> scheduling.  We could have a separate check job that is run on each
>> > push,
>> > >> or it could be a nightly job.  We might even decide to leave off
>> > building
>> > >> aggregated javadocs as an automated job/task, or we might decide to
>> > make it
>> > >> a nightly job as well (maybe even with full documentation builds).
>> > >>
>> > >> WDYT?
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> 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
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > 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
>>
>
>

From steve at hibernate.org  Fri Jun 24 11:58:30 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Jun 2016 15:58:30 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
Message-ID: <CAFdSV9sLBodHZ-1ybdwGwA3kG+Kw96hbqW7K6o9_iqbGQjTKtg@mail.gmail.com>

I worked on this some more today and wanted to pass along a few high-points
I started to see emerge...

The idea of "Type scoping" is very important and central.  The basic idea
is to have a single point for the creation and caching of Type instances.
Specifically this Scope would define just 2 methods and would be passed to
any Type that requested access to the Scope (however we decide that
"requested access" should look: annotation, interface, etc):

   1. It would give access to the org.hibernate.engine.spi.Mapping
   reference which is implemented for both boot-time
   (org.hibernate.boot.Metadata) and run-time (SessionFactory, though I'd like
   to move that to the SessionFactory's Metamodel delegate).
   2. It would give access to  SessionFactory, but an exception would be
   thrown if the #resolveFactory method is called before the SessionFactory
   is bound to the Scope.

(1) is the new pieces I am proposing.  (2) is what Scope does today.

The discussion about removing the Type method overloads around passing
Mapping and SessionFactory as arguments is something I'd like to hear
people's opinions about.

In a way I do think we ought to look at this as a chance to
GetTypeRight(tm).  Essentially there is a lot of change here not matter
what, so we ought to not be afraid to design in a clean-room for
Type-related code in 6.0.

On Wed, Jun 22, 2016 at 11:54 AM Steve Ebersole <steve at hibernate.org> wrote:

> I started a wiki discussing the proposal for the type system redesign.
> Let's get discussions about it starter sooner rather than later.  Thanks!
>
> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
>

From sanne at hibernate.org  Fri Jun 24 12:13:06 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 24 Jun 2016 17:13:06 +0100
Subject: [hibernate-dev] HIbernate ORM CI builds
In-Reply-To: <CAFdSV9v90s+7QeOMT_bjbY158Dvwe2CqPJdyOjorS2JjJdzQ=g@mail.gmail.com>
References: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
	<61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
	<CAFm4XO3A-2xQe_kH6B7oAV6rbwrsqd+bU6zsO7ugZYZ43XBO3A@mail.gmail.com>
	<CAFdSV9u8kgGgBvWEw_Asj6Ogk9z62jAU8Rnv=7x2_2V270LKRw@mail.gmail.com>
	<CAFDzhiQGvneuSpgaN4XH3-BE1-bCXb3LWM+7MrwG00L-diWKuw@mail.gmail.com>
	<CAFdSV9v90s+7QeOMT_bjbY158Dvwe2CqPJdyOjorS2JjJdzQ=g@mail.gmail.com>
Message-ID: <CAFm4XO1ropRf9djGgsm7EyLpONM69z8jsiqdbBWZNErM1g19+Q@mail.gmail.com>

On 24 June 2016 at 16:40, Steve Ebersole <steve at hibernate.org> wrote:
> I definitely want it run regularly (i.e. not "just before a release").  I'd
> be ok with it being nightly.  That's why I asked in the first place.
> Everyone who responded +1'd to it being on-each-push.  I really don't care.
> I tend to agree it should be nightly, but I only get one vote :)

For the record:
 a) you're the lead so it's nice that you ask for our opinions but
your "one vote" is deciding if you want it to.
 b) I replied "+1" on Chris's answer to you which was to do checks
only nightly, and believe Vlad also meant it that way. Sorry if this
wasn't clear.

>
> So the one bad thing about it not being per-push is that we may notify more
> than just the person that pushed the breakage.
>
> For now I went ahead and made it nightly (I think, see below) so that we can
> see how that works.
>
> To "make it nightly" I enabled 2 triggers:
> 1) after push
> 2) each night
>
> Is that inclusive or exclusive?  Really what I'd like to say is "run it
> nightly, but only if a change has been pushed" (no need to run `check` twice
> against the same inputs).  So will those triggers do that?

No, Jenkins will interpret that as a trigger on "either/or".
You need to use the option "Poll SCM", and set that to @midnight :
that means that once a night - approximately at midnight - the job
will fetch from git, and then trigger the build only if there's new
commits.

I applied this change for you on job 'hibernate-orm-master-h2-check'
.. I hope it's the right one?

Thanks,
Sanne

>
> On Fri, Jun 24, 2016 at 1:11 AM Gail Badner <gbadner at redhat.com> wrote:
>>
>> If check is so compute intensive, does it really have to be done on each
>> commit? When I've seen failures, it has been easy to figure out what is
>> wrong. Can the check job be done nightly, or on demand (e.g., before a
>> release)?
>>
>> On Sat, Jun 18, 2016 at 11:20 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2-check/
>>>
>>> Initial attempt
>>>
>>> On Sat, Jun 18, 2016 at 12:58 PM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>
>>> > On 18 June 2016 at 18:50, Chris Cranford <crancran at gmail.com> wrote:
>>> > > +1
>>> > >
>>> > > I think (1) and (2) on each push still makes sense with (3) being
>>> > nightly.
>>> >
>>> > +1
>>> >
>>> >  -- Sanne
>>> >
>>> > >
>>> > > Chris
>>> > >
>>> > >
>>> > > On 06/18/2016 11:33 AM, Steve Ebersole wrote:
>>> > >> We have been having a lot of timeouts on the ORM CI builds.  Mainly
>>> > this is
>>> > >> due to ancillary tasks.  Currently the ORM jobs execute:
>>> > >>
>>> > >>     1. clean
>>> > >>     2. test
>>> > >>     3. check
>>> > >>     4. :documentation:aggregateJavadocs
>>> > >>     5. publish
>>> > >>
>>> > >> A huge chunk of the time is taken up in (3) which performs (a)
>>> > checkstyle
>>> > >> and (b) findbugs.  Also, I am not sure of the benefit of building
>>> > >> aggregated javadocs for each and every CI build.  So I propose we
>>> > >> break
>>> > >> these up as follows:
>>> > >>
>>> > >>
>>> > >>     1. A check job
>>> > >>     2. A clean/test/publish job
>>> > >>     3. (?) aggregated javadocs job (?)
>>> > >>
>>> > >> This would allow us to split the cost of the Job timeout across the
>>> > jobs.
>>> > >> In fact we might even consider making some of these into nightly
>>> > >> job(s).
>>> > >> Initially in setting up this server we decided to just have
>>> > >> singular,
>>> > >> all-encompassing jobs because moving to a new dedicated set of
>>> > >> hardware
>>> > >> (dedicated to Hibernate team) was supposed to free us from jobs
>>> > >> fighting
>>> > >> for resources.  But as our jobs have grown on the dedicated hardware
>>> > >> we
>>> > are
>>> > >> seeing some of the same.  For certain we want a clean/test/publish
>>> > >> job
>>> > that
>>> > >> is run on every push.  To me the others are more flexible in terms
>>> > >> of
>>> > >> scheduling.  We could have a separate check job that is run on each
>>> > push,
>>> > >> or it could be a nightly job.  We might even decide to leave off
>>> > building
>>> > >> aggregated javadocs as an automated job/task, or we might decide to
>>> > make it
>>> > >> a nightly job as well (maybe even with full documentation builds).
>>> > >>
>>> > >> WDYT?
>>> > >> _______________________________________________
>>> > >> hibernate-dev mailing list
>>> > >> 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
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > 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
>>
>>
>

From steve at hibernate.org  Fri Jun 24 12:20:29 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Jun 2016 16:20:29 +0000
Subject: [hibernate-dev] HIbernate ORM CI builds
In-Reply-To: <CAFm4XO1ropRf9djGgsm7EyLpONM69z8jsiqdbBWZNErM1g19+Q@mail.gmail.com>
References: <CAFdSV9tN1gGxQVwkBwOMH8Adi-A4+YhB4Wv-4b7rYA8fU+hNoA@mail.gmail.com>
	<61c9b92a-7c84-1ad6-9076-8b71dcc4a9c8@gmail.com>
	<CAFm4XO3A-2xQe_kH6B7oAV6rbwrsqd+bU6zsO7ugZYZ43XBO3A@mail.gmail.com>
	<CAFdSV9u8kgGgBvWEw_Asj6Ogk9z62jAU8Rnv=7x2_2V270LKRw@mail.gmail.com>
	<CAFDzhiQGvneuSpgaN4XH3-BE1-bCXb3LWM+7MrwG00L-diWKuw@mail.gmail.com>
	<CAFdSV9v90s+7QeOMT_bjbY158Dvwe2CqPJdyOjorS2JjJdzQ=g@mail.gmail.com>
	<CAFm4XO1ropRf9djGgsm7EyLpONM69z8jsiqdbBWZNErM1g19+Q@mail.gmail.com>
Message-ID: <CAFdSV9vouCqsqAqyjp0nk8esg9aCcC2GBjfSVG8ju4Y5kL2V8A@mail.gmail.com>

That's it, thanks!

On Fri, Jun 24, 2016 at 11:13 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 24 June 2016 at 16:40, Steve Ebersole <steve at hibernate.org> wrote:
> > I definitely want it run regularly (i.e. not "just before a release").
> I'd
> > be ok with it being nightly.  That's why I asked in the first place.
> > Everyone who responded +1'd to it being on-each-push.  I really don't
> care.
> > I tend to agree it should be nightly, but I only get one vote :)
>
> For the record:
>  a) you're the lead so it's nice that you ask for our opinions but
> your "one vote" is deciding if you want it to.
>  b) I replied "+1" on Chris's answer to you which was to do checks
> only nightly, and believe Vlad also meant it that way. Sorry if this
> wasn't clear.
>
> >
> > So the one bad thing about it not being per-push is that we may notify
> more
> > than just the person that pushed the breakage.
> >
> > For now I went ahead and made it nightly (I think, see below) so that we
> can
> > see how that works.
> >
> > To "make it nightly" I enabled 2 triggers:
> > 1) after push
> > 2) each night
> >
> > Is that inclusive or exclusive?  Really what I'd like to say is "run it
> > nightly, but only if a change has been pushed" (no need to run `check`
> twice
> > against the same inputs).  So will those triggers do that?
>
> No, Jenkins will interpret that as a trigger on "either/or".
> You need to use the option "Poll SCM", and set that to @midnight :
> that means that once a night - approximately at midnight - the job
> will fetch from git, and then trigger the build only if there's new
> commits.
>
> I applied this change for you on job 'hibernate-orm-master-h2-check'
> .. I hope it's the right one?
>
> Thanks,
> Sanne
>
> >
> > On Fri, Jun 24, 2016 at 1:11 AM Gail Badner <gbadner at redhat.com> wrote:
> >>
> >> If check is so compute intensive, does it really have to be done on each
> >> commit? When I've seen failures, it has been easy to figure out what is
> >> wrong. Can the check job be done nightly, or on demand (e.g., before a
> >> release)?
> >>
> >> On Sat, Jun 18, 2016 at 11:20 AM, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>>
> >>> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/
> >>> http://ci.hibernate.org/job/hibernate-orm-master-h2-check/
> >>>
> >>> Initial attempt
> >>>
> >>> On Sat, Jun 18, 2016 at 12:58 PM Sanne Grinovero <sanne at hibernate.org>
> >>> wrote:
> >>>
> >>> > On 18 June 2016 at 18:50, Chris Cranford <crancran at gmail.com> wrote:
> >>> > > +1
> >>> > >
> >>> > > I think (1) and (2) on each push still makes sense with (3) being
> >>> > nightly.
> >>> >
> >>> > +1
> >>> >
> >>> >  -- Sanne
> >>> >
> >>> > >
> >>> > > Chris
> >>> > >
> >>> > >
> >>> > > On 06/18/2016 11:33 AM, Steve Ebersole wrote:
> >>> > >> We have been having a lot of timeouts on the ORM CI builds.
> Mainly
> >>> > this is
> >>> > >> due to ancillary tasks.  Currently the ORM jobs execute:
> >>> > >>
> >>> > >>     1. clean
> >>> > >>     2. test
> >>> > >>     3. check
> >>> > >>     4. :documentation:aggregateJavadocs
> >>> > >>     5. publish
> >>> > >>
> >>> > >> A huge chunk of the time is taken up in (3) which performs (a)
> >>> > checkstyle
> >>> > >> and (b) findbugs.  Also, I am not sure of the benefit of building
> >>> > >> aggregated javadocs for each and every CI build.  So I propose we
> >>> > >> break
> >>> > >> these up as follows:
> >>> > >>
> >>> > >>
> >>> > >>     1. A check job
> >>> > >>     2. A clean/test/publish job
> >>> > >>     3. (?) aggregated javadocs job (?)
> >>> > >>
> >>> > >> This would allow us to split the cost of the Job timeout across
> the
> >>> > jobs.
> >>> > >> In fact we might even consider making some of these into nightly
> >>> > >> job(s).
> >>> > >> Initially in setting up this server we decided to just have
> >>> > >> singular,
> >>> > >> all-encompassing jobs because moving to a new dedicated set of
> >>> > >> hardware
> >>> > >> (dedicated to Hibernate team) was supposed to free us from jobs
> >>> > >> fighting
> >>> > >> for resources.  But as our jobs have grown on the dedicated
> hardware
> >>> > >> we
> >>> > are
> >>> > >> seeing some of the same.  For certain we want a clean/test/publish
> >>> > >> job
> >>> > that
> >>> > >> is run on every push.  To me the others are more flexible in terms
> >>> > >> of
> >>> > >> scheduling.  We could have a separate check job that is run on
> each
> >>> > push,
> >>> > >> or it could be a nightly job.  We might even decide to leave off
> >>> > building
> >>> > >> aggregated javadocs as an automated job/task, or we might decide
> to
> >>> > make it
> >>> > >> a nightly job as well (maybe even with full documentation builds).
> >>> > >>
> >>> > >> WDYT?
> >>> > >> _______________________________________________
> >>> > >> hibernate-dev mailing list
> >>> > >> 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
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > 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
> >>
> >>
> >
>

From gunnar at hibernate.org  Fri Jun 24 18:18:42 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 25 Jun 2016 00:18:42 +0200
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
Message-ID: <CADGJaX8zk4OQYgy32G26deo90VLsne+fKMiH6daUH2q+CV1ktA@mail.gmail.com>

Steve,

I still need to look at the wiki page and will give more detailed feedback
on some parts of it.

One general thing coming to mind though is how support for OGM could be
improved. On first thought I'd say the "Java side" of Type might stay as
is, but the "SQL side" (or "datastore side") and read/write logic
interacting with result sets etc. would have to look differently in the
case of OGM.

If this part of the story could be made pluggable somehow, than a custom
factory of sorts in OGM could plug in its dedicated implementation of the
"datastore side". Not sure how it'd look in practice, the implementations
would be rather different (we don't work with ResultSet at all in OGM), so
I suppose it might require casting to the expected subtype when working
with Type in ORM or OGM.

Currently, we completely override the Type hierarchy from ORM with a
corresponding GridType hierarchy in OGM, but it might be possible to re-use
many more code by just customizing the "datastore side". Plus, it'd be a
tad more efficient for OGM, as we can skip the translation from Type to
GridType.

I might provide some more details once having studied the current proposal
in more depth, just wanted to get out these thoughts to you.

--Gunnar




2016-06-22 18:54 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> I started a wiki discussing the proposal for the type system redesign.
> Let's get discussions about it starter sooner rather than later.  Thanks!
>
> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jun 24 19:24:22 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Jun 2016 23:24:22 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CADGJaX8zk4OQYgy32G26deo90VLsne+fKMiH6daUH2q+CV1ktA@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<CADGJaX8zk4OQYgy32G26deo90VLsne+fKMiH6daUH2q+CV1ktA@mail.gmail.com>
Message-ID: <CAFdSV9t1fdpsBf3q-myi5rJJkWZ+RcDOhR95PFefhuUUnUUkOw@mail.gmail.com>

This is all part of the to-be-decided read/write part of the new Type
contract.  I propose, as discussed in the wiki, that we have Type return
ValueExtractor and ValueBinder for read/write.  So assuming that is there...

One possible answer to your story is that OGM as a SQM interpreter and
Metamodel (persisters, etc) implementor would influence the Type and
therefore the ValueExtractor and ValueBinder.  We'd just need to define the
right generic API to allow that to happen without ORM, e.g., having to jump
through a bunch of hoops to get to JDBC objects.

On Fri, Jun 24, 2016 at 5:18 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Steve,
>
> I still need to look at the wiki page and will give more detailed feedback
> on some parts of it.
>
> One general thing coming to mind though is how support for OGM could be
> improved. On first thought I'd say the "Java side" of Type might stay as
> is, but the "SQL side" (or "datastore side") and read/write logic
> interacting with result sets etc. would have to look differently in the
> case of OGM.
>
> If this part of the story could be made pluggable somehow, than a custom
> factory of sorts in OGM could plug in its dedicated implementation of the
> "datastore side". Not sure how it'd look in practice, the implementations
> would be rather different (we don't work with ResultSet at all in OGM), so
> I suppose it might require casting to the expected subtype when working
> with Type in ORM or OGM.
>
> Currently, we completely override the Type hierarchy from ORM with a
> corresponding GridType hierarchy in OGM, but it might be possible to re-use
> many more code by just customizing the "datastore side". Plus, it'd be a
> tad more efficient for OGM, as we can skip the translation from Type to
> GridType.
>
> I might provide some more details once having studied the current proposal
> in more depth, just wanted to get out these thoughts to you.
>
> --Gunnar
>
>
>
>
> 2016-06-22 18:54 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> I started a wiki discussing the proposal for the type system redesign.
>> Let's get discussions about it starter sooner rather than later.  Thanks!
>>
>> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Sat Jun 25 05:53:22 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 25 Jun 2016 11:53:22 +0200
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
Message-ID: <CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>

Scott, all,

As discussed I've started to work on a module ZIP which can be used to add
Hibernate ORM 5.1 to an existing WildFly 10.0 instance (which comes with
ORM 5.0). As module slot I'm using "5.1".

Now I assumed that it'd be enough to set this property in persistence.xml:

     jboss.as.jpa.providerModule=org.hibernate:5.1

Indeed I'm seeing that my new module is added as a dependency to the
deployment, but the default ORM ("org.hibernate:main") is still being
added, too. As a result I'm getting an exception due to incompatible
Integrator classes (the 5.0 ORM tries to load the 5.1 integrator for Envers
which is failing due to the incompatible class hierarchies).

Do you have any idea why this is happening? I see that the module
org.jboss.as.ejb3 has a dependency to module org.hibernate (no slot, i.e.
"main"). May this be the cause? If so, what would I have to do to enable
only my 5.1 module and not the default 5.0 one for a given deployment? Or
any other idea?

Thanks,

--Gunnar





2016-06-08 17:16 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 8 June 2016 at 16:08, Gunnar Morling <gunnar at hibernate.org> wrote:
> > It'd not only be a library, but an image containing WF with the latest
> > Hibernate ORM. But as said, the module ZIP is more versatile and is what
> I'd
> > do.
>
> +1 for the priority on ZIP files.
>
> I had not understood that you meant to re-distribute a customized WF
> image so I was quite confused :)
>
> >
> > 2016-06-08 16:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 8 June 2016 at 08:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >> >
> >> >> Too bad we can't just publish a Docker image.
> >> >>
> >> >
> >> > We could do that, but I think we should have a solution for non-Docker
> >> > users, too.
> >>
> >> What's the point to package a library in a Docker image?
> >>
> >> >
> >> >>
> >> >> Is this something we'd publish somewhere (Nexus/Artifactory)?
> >> >>
> >> >
> >> > Yes, we'd publish it in Nexus and also BinTray/SourceForge.
> >> >
> >> > People would download it, unzip it into the "modules" directory of
> their
> >> > WF
> >> > instance and could start using the new ORM version (provided the
> larger
> >> > scheme of integration hasn't changed, so the JipiJapa bits in WF
> >> > continue
> >> > to work as is).
> >> >
> >> >
> >> >>   I know nothing about building a WF module ZIP.  But if you are
> >> >> willing
> >> >> to do the work and it helps OGM etc, of course we would incorporate
> it.
> >> >>
> >> >
> >> > Ok, cool. I'll take a look then.
> >> >
> >> > On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar at hibernate.org>
> >> > wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> As discussed by some of us during the No ORM meeting in May, it'd be
> >> >>> great
> >> >>> if there was a module ZIP allowing people to easily upgrade
> Hibernate
> >> >>> ORM
> >> >>> in the WildFly version they are using.
> >> >>>
> >> >>> Just the other day there was a blog post published [1] describing
> how
> >> >>> to
> >> >>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on
> >> >>> the
> >> >>> existing module.xml files. We could do better than that, leaving the
> >> >>> original version intact and providing a new one with a specific slot
> >> >>> ("5.2") in the ZIP.
> >> >>>
> >> >>> That'd also be helpful for other projects such as Hibernate OGM
> which
> >> >>> already provide a module ZIP for WF but currently need to package
> ORM,
> >> >>> too,
> >> >>> in case they need features from a later ORM version.
> >> >>>
> >> >>> If we all agree that's a good thing to have, I can help with making
> it
> >> >>> happen.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> --Gunnar
> >> >>>
> >> >>> [1]
> >> >>>
> >> >>>
> >> >>>
> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
> >> >>> _______________________________________________
> >> >>> hibernate-dev mailing list
> >> >>> 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
> >
> >
>

From gunnar at hibernate.org  Sat Jun 25 08:15:36 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Sat, 25 Jun 2016 14:15:36 +0200
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
	<CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
Message-ID: <CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>

Ok, so this was caused by the module dependency
from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to
create a 5.1-specific adapter module, too, and require that to be
configured by users via jboss.as.jpa.adapterModule.

2016-06-25 11:53 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> Scott, all,
>
> As discussed I've started to work on a module ZIP which can be used to add
> Hibernate ORM 5.1 to an existing WildFly 10.0 instance (which comes with
> ORM 5.0). As module slot I'm using "5.1".
>
> Now I assumed that it'd be enough to set this property in persistence.xml:
>
>      jboss.as.jpa.providerModule=org.hibernate:5.1
>
> Indeed I'm seeing that my new module is added as a dependency to the
> deployment, but the default ORM ("org.hibernate:main") is still being
> added, too. As a result I'm getting an exception due to incompatible
> Integrator classes (the 5.0 ORM tries to load the 5.1 integrator for Envers
> which is failing due to the incompatible class hierarchies).
>
> Do you have any idea why this is happening? I see that the module
> org.jboss.as.ejb3 has a dependency to module org.hibernate (no slot, i.e.
> "main"). May this be the cause? If so, what would I have to do to enable
> only my 5.1 module and not the default 5.0 one for a given deployment? Or
> any other idea?
>
> Thanks,
>
> --Gunnar
>
>
>
>
>
> 2016-06-08 17:16 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> On 8 June 2016 at 16:08, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > It'd not only be a library, but an image containing WF with the latest
>> > Hibernate ORM. But as said, the module ZIP is more versatile and is
>> what I'd
>> > do.
>>
>> +1 for the priority on ZIP files.
>>
>> I had not understood that you meant to re-distribute a customized WF
>> image so I was quite confused :)
>>
>> >
>> > 2016-06-08 16:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >> On 8 June 2016 at 08:11, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> > 2016-06-07 15:51 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> >> >
>> >> >> Too bad we can't just publish a Docker image.
>> >> >>
>> >> >
>> >> > We could do that, but I think we should have a solution for
>> non-Docker
>> >> > users, too.
>> >>
>> >> What's the point to package a library in a Docker image?
>> >>
>> >> >
>> >> >>
>> >> >> Is this something we'd publish somewhere (Nexus/Artifactory)?
>> >> >>
>> >> >
>> >> > Yes, we'd publish it in Nexus and also BinTray/SourceForge.
>> >> >
>> >> > People would download it, unzip it into the "modules" directory of
>> their
>> >> > WF
>> >> > instance and could start using the new ORM version (provided the
>> larger
>> >> > scheme of integration hasn't changed, so the JipiJapa bits in WF
>> >> > continue
>> >> > to work as is).
>> >> >
>> >> >
>> >> >>   I know nothing about building a WF module ZIP.  But if you are
>> >> >> willing
>> >> >> to do the work and it helps OGM etc, of course we would incorporate
>> it.
>> >> >>
>> >> >
>> >> > Ok, cool. I'll take a look then.
>> >> >
>> >> > On Tue, Jun 7, 2016 at 8:19 AM Gunnar Morling <gunnar at hibernate.org>
>> >> > wrote:
>> >> >>
>> >> >>> Hi,
>> >> >>>
>> >> >>> As discussed by some of us during the No ORM meeting in May, it'd
>> be
>> >> >>> great
>> >> >>> if there was a module ZIP allowing people to easily upgrade
>> Hibernate
>> >> >>> ORM
>> >> >>> in the WildFly version they are using.
>> >> >>>
>> >> >>> Just the other day there was a blog post published [1] describing
>> how
>> >> >>> to
>> >> >>> use Hibernate ORM 5.2 in WF 10, essentially via Search & Replace on
>> >> >>> the
>> >> >>> existing module.xml files. We could do better than that, leaving
>> the
>> >> >>> original version intact and providing a new one with a specific
>> slot
>> >> >>> ("5.2") in the ZIP.
>> >> >>>
>> >> >>> That'd also be helpful for other projects such as Hibernate OGM
>> which
>> >> >>> already provide a module ZIP for WF but currently need to package
>> ORM,
>> >> >>> too,
>> >> >>> in case they need features from a later ORM version.
>> >> >>>
>> >> >>> If we all agree that's a good thing to have, I can help with
>> making it
>> >> >>> happen.
>> >> >>>
>> >> >>> Thanks,
>> >> >>>
>> >> >>> --Gunnar
>> >> >>>
>> >> >>> [1]
>> >> >>>
>> >> >>>
>> >> >>>
>> http://avolpe.github.io/docker/2016/06/05/docker-wildfly-hibernate-5.2.html
>> >> >>> _______________________________________________
>> >> >>> hibernate-dev mailing list
>> >> >>> 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
>> >
>> >
>>
>
>

From sanne at hibernate.org  Sat Jun 25 17:12:28 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 25 Jun 2016 22:12:28 +0100
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
	<CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
	<CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>
Message-ID: <CAFm4XO3Cqp-C4gJqaB6vxHC6P=TCpoJVDh9iPhttCO4ULv8BZQ@mail.gmail.com>

On 25 June 2016 at 13:15, Gunnar Morling <gunnar at hibernate.org> wrote:
> Ok, so this was caused by the module dependency
> from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to
> create a 5.1-specific adapter module, too, and require that to be
> configured by users via jboss.as.jpa.adapterModule.

If you include the adaptor module with the ORM modules, it should be
auto-discovered.

See how OGM does it.

I'm not sure I understood why you were being exposed to the
jipijapa-hibernate5 module though?
This shouldn't activate automatically when you change the
providerModule setting.

--Sanne

From mihalcea.vlad at gmail.com  Mon Jun 27 07:35:07 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 27 Jun 2016 14:35:07 +0300
Subject: [hibernate-dev] ActionQueue order question
Message-ID: <CA+gWKMDYVBL-Gt18YGKd5GJqt=fBsr6aY=pqoE03sBTGF-EtwQ@mail.gmail.com>

Hi,

Does anyone know why the "orphan-removal" is the first action to be
executed while "delete" is the last one?
Shouldn't the "delete"action queue operation be executed after
"orphan-removal" before insert or update?

Thanks,
Vlad

From mihalcea.vlad at gmail.com  Mon Jun 27 07:41:01 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 27 Jun 2016 14:41:01 +0300
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the core
	ones
Message-ID: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>

Hi,

Since hibenrate-spatial has been merged into Hibernate code base, shouldn't
we merge the Dialects as well.
For instance, we have MySQL56InnoDBSpatialDialect which can simply be
merged into a MySQL56InnoDBDialect.
This way, MySQL57InnoDBDialect can take advantage of spatial queries as
well.

The only drawback is that we need to add the geolatte-geom lib to
hibernate-orm.

Let me know what you think.

Vlad

From sanne at hibernate.org  Mon Jun 27 07:42:08 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 27 Jun 2016 12:42:08 +0100
Subject: [hibernate-dev] JDK 9 b124 now running on ci.hibernate.org
Message-ID: <CAFm4XO1uZUtnLEayaE2zxu9e_g3MUcu_gUmsYXSZpXwj7wchbA@mail.gmail.com>

I've updated the OpenJDK preview of JDK 9 to build 9-ea+124 on our CI servers.

I expect it all to work like before, but in case you receive a failure
report be aware that it might relate to the JVM upgrade.

For a general overview of our Java 9 compatibility status see here as usual:
 - http://ci.hibernate.org/view/JDK9/

[The OGM failure isn't a JDK regression but is my mistake; should be
fixed soon: OGM-1107]

Thanks,
Sanne

From sanne at hibernate.org  Mon Jun 27 07:49:36 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 27 Jun 2016 12:49:36 +0100
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
Message-ID: <CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>

Nice idea!

since the modules were merged already, don't we already require geolatte-geom ?
I guess some code might be intentionally designed to fail gracefully
about this library being there or not, but we'd need to make sure that
can be tested for it to be maintainable.

My preference would be to have:
 - All Dialects automatically provide the spatial extensions if the
needed dependencies are in place: we could automatically alias them
based on this?
 - a good error message naming the missing dependencies explicitly
when someone attempts to use such a Spatial extensions, but the
feature was not enabled by our automatic logic.
 - be able to test for these.

In practice I believe this means we should still have it as an
independent source module, compile and test it as an independent
module, and only bundle within the ORM main jar as final distribution
step.

If that's too much work, I'd rather make the geolatte-geom a mandatory
dependency than to have cryptic runtime failures.

On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> Since hibenrate-spatial has been merged into Hibernate code base, shouldn't
> we merge the Dialects as well.
> For instance, we have MySQL56InnoDBSpatialDialect which can simply be
> merged into a MySQL56InnoDBDialect.
> This way, MySQL57InnoDBDialect can take advantage of spatial queries as
> well.
>
> The only drawback is that we need to add the geolatte-geom lib to
> hibernate-orm.
>
> Let me know what you think.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From guillaume.smet at gmail.com  Mon Jun 27 08:43:25 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 27 Jun 2016 14:43:25 +0200
Subject: [hibernate-dev] Redis and TTL
Message-ID: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>

Hi,

So, I'm currently working on reducing the number of calls issued to Redis
in OGM as part of OGM-1064.

At the moment, we execute a call to Redis to get the TTL already configured
on an object before saving it. If the TTL is not explicitly configured with
@TTL, we set this TTL again after having stored this entity (see
RedisJsonDialect#storeEntity). Same for associations stored in a different
document.

In fact, this call returns the time remaining before expiration, not the
TTL previously configured,  so I find this behavior quite weird. Basically,
we store information which will expire sooner than expected. I can't really
get a use case for this and I don't think we should have an additional call
every time we store an object for a so obscure thing. Do we really expect
people to mess with TTLs of objects stored by OGM without relying on OGM
@TTL management?

IMHO, we should get rid of this call and only deal with TTL when it's
configured via the @TTL annotation.

Thoughts?

-- 
Guillaume

From smarlow at redhat.com  Mon Jun 27 09:39:31 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jun 2016 09:39:31 -0400
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CAFm4XO3Cqp-C4gJqaB6vxHC6P=TCpoJVDh9iPhttCO4ULv8BZQ@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
	<CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
	<CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>
	<CAFm4XO3Cqp-C4gJqaB6vxHC6P=TCpoJVDh9iPhttCO4ULv8BZQ@mail.gmail.com>
Message-ID: <a0c89470-0427-c5e3-076a-5c075781cf21@redhat.com>



On 06/25/2016 05:12 PM, Sanne Grinovero wrote:
> On 25 June 2016 at 13:15, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Ok, so this was caused by the module dependency
>> from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to
>> create a 5.1-specific adapter module, too, and require that to be
>> configured by users via jboss.as.jpa.adapterModule.

What happens if we copy the contents of the 
org.hibernate.jipijapa-hibernate5 module, to 
org.hibernate.jipijapa-hibernate5-1.  Change 
org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and change ORM 
5.1 to depend on org.hibernate.jipijapa-hibernate5-1.

>
> If you include the adaptor module with the ORM modules, it should be
> auto-discovered.

The ORM 5.0 module.xml has the following so that service loading can do 
the discovery:

"
<module name="org.hibernate.jipijapa-hibernate5" services="import"/>
"

>
> See how OGM does it.
>
> I'm not sure I understood why you were being exposed to the
> jipijapa-hibernate5 module though?

I'm guessing but most likely by copying the above module reference to 
"org.hibernate.jipijapa-hibernate5" into the ORM 5.1 module.xml.

> This shouldn't activate automatically when you change the
> providerModule setting.
>
> --Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mpaluch at paluch.biz  Mon Jun 27 09:47:20 2016
From: mpaluch at paluch.biz (Mark Paluch)
Date: Mon, 27 Jun 2016 15:47:20 +0200
Subject: [hibernate-dev] Redis and TTL
In-Reply-To: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
References: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
Message-ID: <8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>


Hi Guillaume, 

TTL preservation behavior originates from Redis? behavior and is to preserve interoperability: 

> http://redis.io/commands/set <http://redis.io/commands/set>
> Set key to hold the string value. [...] Any previous time to live associated with the key is discarded on successful SET operation.


Keys written with SET loose their TTL value and the entry is persisted without any further TTL. Reading and re-applying TTL is to preserve the expiry.
The general idea behind is to either apply the remaining TTL from the key, because TTL is not configured in the entity model or to set the configured TTL from the entity model.
I see it from an integration-perspective in which Hibernate OGM and other tools share Redis data and so you?re opting-in for features but things are not broken.

Best regards, Mark


> Am 27.06.2016 um 14:43 schrieb Guillaume Smet <guillaume.smet at gmail.com>:
> 
> Hi,
> 
> So, I'm currently working on reducing the number of calls issued to Redis
> in OGM as part of OGM-1064.
> 
> At the moment, we execute a call to Redis to get the TTL already configured
> on an object before saving it. If the TTL is not explicitly configured with
> @TTL, we set this TTL again after having stored this entity (see
> RedisJsonDialect#storeEntity). Same for associations stored in a different
> document.
> 
> In fact, this call returns the time remaining before expiration, not the
> TTL previously configured,  so I find this behavior quite weird. Basically,
> we store information which will expire sooner than expected. I can't really
> get a use case for this and I don't think we should have an additional call
> every time we store an object for a so obscure thing. Do we really expect
> people to mess with TTLs of objects stored by OGM without relying on OGM
> @TTL management?
> 
> IMHO, we should get rid of this call and only deal with TTL when it's
> configured via the @TTL annotation.
> 
> Thoughts?
> 
> -- 
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Mon Jun 27 09:52:49 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 27 Jun 2016 14:52:49 +0100
Subject: [hibernate-dev] Redis and TTL
In-Reply-To: <8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
References: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
	<8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
Message-ID: <CAFm4XO02p0hJ8zL4QHWLqEW9auNjz1hN65eWvQODWtM12fO5Og@mail.gmail.com>

Hi Mark,

you wouldn't expect the timeout to be "reset" to some default value
when your code writes to an entity?

If you could explain the use case, that might help us to understand this.

Thanks,
Sanne

On 27 June 2016 at 14:47, Mark Paluch <mpaluch at paluch.biz> wrote:
>
> Hi Guillaume,
>
> TTL preservation behavior originates from Redis? behavior and is to preserve interoperability:
>
>> http://redis.io/commands/set <http://redis.io/commands/set>
>> Set key to hold the string value. [...] Any previous time to live associated with the key is discarded on successful SET operation.
>
>
> Keys written with SET loose their TTL value and the entry is persisted without any further TTL. Reading and re-applying TTL is to preserve the expiry.
> The general idea behind is to either apply the remaining TTL from the key, because TTL is not configured in the entity model or to set the configured TTL from the entity model.
> I see it from an integration-perspective in which Hibernate OGM and other tools share Redis data and so you?re opting-in for features but things are not broken.
>
> Best regards, Mark
>
>
>> Am 27.06.2016 um 14:43 schrieb Guillaume Smet <guillaume.smet at gmail.com>:
>>
>> Hi,
>>
>> So, I'm currently working on reducing the number of calls issued to Redis
>> in OGM as part of OGM-1064.
>>
>> At the moment, we execute a call to Redis to get the TTL already configured
>> on an object before saving it. If the TTL is not explicitly configured with
>> @TTL, we set this TTL again after having stored this entity (see
>> RedisJsonDialect#storeEntity). Same for associations stored in a different
>> document.
>>
>> In fact, this call returns the time remaining before expiration, not the
>> TTL previously configured,  so I find this behavior quite weird. Basically,
>> we store information which will expire sooner than expected. I can't really
>> get a use case for this and I don't think we should have an additional call
>> every time we store an object for a so obscure thing. Do we really expect
>> people to mess with TTLs of objects stored by OGM without relying on OGM
>> @TTL management?
>>
>> IMHO, we should get rid of this call and only deal with TTL when it's
>> configured via the @TTL annotation.
>>
>> Thoughts?
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> 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


From steve at hibernate.org  Mon Jun 27 09:53:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 27 Jun 2016 13:53:47 +0000
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
Message-ID: <CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>

They have not been "merged" in the same way we merged
hibernate-entitymanager into hibernate-core.    So at the moment using
hibernate-core e.g. does not require geolatte to be present.  geolatte is
only required if using hibernate-spatial (isolated transitive dep).

Karel, what are your thoughts on this?  I am not a fan of making geolatte
optional/provided, but if we all deem that folding hibernate-spatial into
hibernate-core (ala hibernate-entitymanager) as Vlad suggests is desirable
then I will accept that

On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Nice idea!
>
> since the modules were merged already, don't we already require
> geolatte-geom ?
> I guess some code might be intentionally designed to fail gracefully
> about this library being there or not, but we'd need to make sure that
> can be tested for it to be maintainable.
>
> My preference would be to have:
>  - All Dialects automatically provide the spatial extensions if the
> needed dependencies are in place: we could automatically alias them
> based on this?
>  - a good error message naming the missing dependencies explicitly
> when someone attempts to use such a Spatial extensions, but the
> feature was not enabled by our automatic logic.
>  - be able to test for these.
>
> In practice I believe this means we should still have it as an
> independent source module, compile and test it as an independent
> module, and only bundle within the ORM main jar as final distribution
> step.
>
> If that's too much work, I'd rather make the geolatte-geom a mandatory
> dependency than to have cryptic runtime failures.
>
> On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> > Hi,
> >
> > Since hibenrate-spatial has been merged into Hibernate code base,
> shouldn't
> > we merge the Dialects as well.
> > For instance, we have MySQL56InnoDBSpatialDialect which can simply be
> > merged into a MySQL56InnoDBDialect.
> > This way, MySQL57InnoDBDialect can take advantage of spatial queries as
> > well.
> >
> > The only drawback is that we need to add the geolatte-geom lib to
> > hibernate-orm.
> >
> > Let me know what you think.
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From gunnar at hibernate.org  Mon Jun 27 10:00:25 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 27 Jun 2016 16:00:25 +0200
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <a0c89470-0427-c5e3-076a-5c075781cf21@redhat.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
	<CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
	<CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>
	<CAFm4XO3Cqp-C4gJqaB6vxHC6P=TCpoJVDh9iPhttCO4ULv8BZQ@mail.gmail.com>
	<a0c89470-0427-c5e3-076a-5c075781cf21@redhat.com>
Message-ID: <CADGJaX-VafLO76CgL1rRuzdKYzt27+NAD5qkFp1rBaLXOz4wWg@mail.gmail.com>

Hey,

I've sent PR https://github.com/hibernate/hibernate-orm/pull/1455 earlier
today for this.

> What happens if we copy the contents of the org.hibernate.jipijapa-hibernate5
module, to org.hibernate.jipijapa-hibernate5-1.
> Change org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and
change ORM 5.1 to depend on org.hibernate.jipijapa-hibernate5-1.

Yes, that's what I ended up doing. At first I wasn't aware of that circular
dependency between the two modules, thus missing to update one of the
references to the 5.1 slot and hence pulling in the WF-provided ORM.

> I'm guessing but most likely by copying the above module reference to
"org.hibernate.jipijapa-hibernate5" into the ORM 5.1 module.xml.

Exactly.

Alternatively, I just could add the JipiJapa adapter JAR to my ORM 5.1
module, itself. But I decided to stick to the original WF structure as
close as possible.

That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks a
bit scary. My simple test passes, not sure whether that may be a problem in
other cases, though?

--Gunnar




2016-06-27 15:39 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

>
>
> On 06/25/2016 05:12 PM, Sanne Grinovero wrote:
> > On 25 June 2016 at 13:15, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> Ok, so this was caused by the module dependency
> >> from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to
> >> create a 5.1-specific adapter module, too, and require that to be
> >> configured by users via jboss.as.jpa.adapterModule.
>
> What happens if we copy the contents of the
> org.hibernate.jipijapa-hibernate5 module, to
> org.hibernate.jipijapa-hibernate5-1.  Change
> org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and change ORM
> 5.1 to depend on org.hibernate.jipijapa-hibernate5-1.
>
> >
> > If you include the adaptor module with the ORM modules, it should be
> > auto-discovered.
>
> The ORM 5.0 module.xml has the following so that service loading can do
> the discovery:
>
> "
> <module name="org.hibernate.jipijapa-hibernate5" services="import"/>
> "
>
> >
> > See how OGM does it.
> >
> > I'm not sure I understood why you were being exposed to the
> > jipijapa-hibernate5 module though?
>
> I'm guessing but most likely by copying the above module reference to
> "org.hibernate.jipijapa-hibernate5" into the ORM 5.1 module.xml.
>
> > This shouldn't activate automatically when you change the
> > providerModule setting.
> >
> > --Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From guillaume.smet at gmail.com  Mon Jun 27 10:21:28 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Mon, 27 Jun 2016 16:21:28 +0200
Subject: [hibernate-dev] Redis and TTL
In-Reply-To: <8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
References: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
	<8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
Message-ID: <CALt0+o9ZEokfvOSSH3z12niEMDk7j2BnPsihDoyWJ8uxu8c5Dg@mail.gmail.com>

Hi Mark!

Thanks for commenting on this, I was hoping for it.

While I can see the use case for sharing Redis data between 2 tools, I must
admit that I find it a bit weird to set the TTL on one tool and store the
entity on another one. It looks to me that if OGM stores the data, it has
to manage also the expiration.

Otherwise you store data from OGM which might expire in a few seconds if
you're not lucky!

Don't you agree?

-- 
Guillaume

On Mon, Jun 27, 2016 at 3:47 PM, Mark Paluch <mpaluch at paluch.biz> wrote:

>
> Hi Guillaume,
>
> TTL preservation behavior originates from Redis? behavior and is to
> preserve interoperability:
>
> http://redis.io/commands/set
>
> Set key to hold the string value. [...] Any previous time to live
> associated with the key is discarded on successful SET operation.
>
>
> Keys written with SET loose their TTL value and the entry is persisted
> without any further TTL. Reading and re-applying TTL is to preserve the
> expiry.
> The general idea behind is to either apply the remaining TTL from the key,
> because TTL is not configured in the entity model or to set the configured
> TTL from the entity model.
> I see it from an integration-perspective in which Hibernate OGM and other
> tools share Redis data and so you?re opting-in for features but things are
> not broken.
>
> Best regards, Mark
>
>
> Am 27.06.2016 um 14:43 schrieb Guillaume Smet <guillaume.smet at gmail.com>:
>
> Hi,
>
> So, I'm currently working on reducing the number of calls issued to Redis
> in OGM as part of OGM-1064.
>
> At the moment, we execute a call to Redis to get the TTL already configured
> on an object before saving it. If the TTL is not explicitly configured with
> @TTL, we set this TTL again after having stored this entity (see
> RedisJsonDialect#storeEntity). Same for associations stored in a different
> document.
>
> In fact, this call returns the time remaining before expiration, not the
> TTL previously configured,  so I find this behavior quite weird. Basically,
> we store information which will expire sooner than expected. I can't really
> get a use case for this and I don't think we should have an additional call
> every time we store an object for a so obscure thing. Do we really expect
> people to mess with TTLs of objects stored by OGM without relying on OGM
> @TTL management?
>
> IMHO, we should get rid of this call and only deal with TTL when it's
> configured via the @TTL annotation.
>
> Thoughts?
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>

From mpaluch at paluch.biz  Mon Jun 27 10:39:16 2016
From: mpaluch at paluch.biz (Mark Paluch)
Date: Mon, 27 Jun 2016 16:39:16 +0200
Subject: [hibernate-dev] Redis and TTL
In-Reply-To: <CAFm4XO02p0hJ8zL4QHWLqEW9auNjz1hN65eWvQODWtM12fO5Og@mail.gmail.com>
References: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
	<8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
	<CAFm4XO02p0hJ8zL4QHWLqEW9auNjz1hN65eWvQODWtM12fO5Og@mail.gmail.com>
Message-ID: <1159174E-246B-4793-BC7D-D16C86F98019@paluch.biz>

Hi Sanne, 

not sure I follow.

The use case is: Two applications (clients) share one Redis instance. The first (non-OGM) client writes some data and sets an expiry (TTL). The second (OGM) client updates the data stored inside of Redis and preserves the remaining TTL. Note that the first (non-OGM) client wrote an expiry and expects the key to disappear sooner or later.

The TTL is not configured in OGM for this use-case because the TTL might be determined somehow dynamic by the first client.

Greetings, Mark

> Am 27.06.2016 um 15:52 schrieb Sanne Grinovero <sanne at hibernate.org>:
> 
> Hi Mark,
> 
> you wouldn't expect the timeout to be "reset" to some default value
> when your code writes to an entity?
> 
> If you could explain the use case, that might help us to understand this.
> 
> Thanks,
> Sanne
> 
> On 27 June 2016 at 14:47, Mark Paluch <mpaluch at paluch.biz> wrote:
>> 
>> Hi Guillaume,
>> 
>> TTL preservation behavior originates from Redis? behavior and is to preserve interoperability:
>> 
>>> http://redis.io/commands/set <http://redis.io/commands/set>
>>> Set key to hold the string value. [...] Any previous time to live associated with the key is discarded on successful SET operation.
>> 
>> 
>> Keys written with SET loose their TTL value and the entry is persisted without any further TTL. Reading and re-applying TTL is to preserve the expiry.
>> The general idea behind is to either apply the remaining TTL from the key, because TTL is not configured in the entity model or to set the configured TTL from the entity model.
>> I see it from an integration-perspective in which Hibernate OGM and other tools share Redis data and so you?re opting-in for features but things are not broken.
>> 
>> Best regards, Mark
>> 
>> 
>>> Am 27.06.2016 um 14:43 schrieb Guillaume Smet <guillaume.smet at gmail.com>:
>>> 
>>> Hi,
>>> 
>>> So, I'm currently working on reducing the number of calls issued to Redis
>>> in OGM as part of OGM-1064.
>>> 
>>> At the moment, we execute a call to Redis to get the TTL already configured
>>> on an object before saving it. If the TTL is not explicitly configured with
>>> @TTL, we set this TTL again after having stored this entity (see
>>> RedisJsonDialect#storeEntity). Same for associations stored in a different
>>> document.
>>> 
>>> In fact, this call returns the time remaining before expiration, not the
>>> TTL previously configured,  so I find this behavior quite weird. Basically,
>>> we store information which will expire sooner than expected. I can't really
>>> get a use case for this and I don't think we should have an additional call
>>> every time we store an object for a so obscure thing. Do we really expect
>>> people to mess with TTLs of objects stored by OGM without relying on OGM
>>> @TTL management?
>>> 
>>> IMHO, we should get rid of this call and only deal with TTL when it's
>>> configured via the @TTL annotation.
>>> 
>>> Thoughts?
>>> 
>>> --
>>> Guillaume
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> 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



From mpaluch at paluch.biz  Mon Jun 27 10:56:11 2016
From: mpaluch at paluch.biz (Mark Paluch)
Date: Mon, 27 Jun 2016 16:56:11 +0200
Subject: [hibernate-dev] Redis and TTL
In-Reply-To: <CALt0+o9ZEokfvOSSH3z12niEMDk7j2BnPsihDoyWJ8uxu8c5Dg@mail.gmail.com>
References: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
	<8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
	<CALt0+o9ZEokfvOSSH3z12niEMDk7j2BnPsihDoyWJ8uxu8c5Dg@mail.gmail.com>
Message-ID: <AEFBFEAE-9EF3-474A-921F-C17FAEEF11EF@paluch.biz>

There are many views on this problem. Let me borrow an example from Hibernate ORM:

Databases were be shared amongst multiple applications and clients (I?m aware that this pattern is discouraged for many reasons) on several of my earlier projects. A lot of these projects used Hibernate ORM to access the data. There was one master application that had the authority over several tables. Other clients than the master applications were able to perform modifications to data and they configured just a minimal subset of entities and columns, sometimes even different from the configuration of the master application.

That was required to ensure interoperability between applications and the database. I fully understand the weirdness of these scenarios, especially because in some cases there was no one who really knew how it worked in total. The openness in Hibernate allowed us to use Hibernate and still do our work because Hibernated did not break things. It went out of our way where we needed and served us where required. 

That?s also my way of thinking here. I?d be rather surprised if someone accesses data and because the framework takes ownership over particular aspects of data I?m no longer able to integrate with other clients by operating on the same data store.

I?ve the feeling that there might be the same number of good arguments for both strategies: Preserving the TTL or applying the configured TTL. 

Let?s diverge into TTL in MongoDB: TTL in MongoDB is handled by an index (expireAfterSeconds) and documents. The actual expiry is set within a document.

So maybe we could address the TTL issue in a different way that is more user-friendly and provide properties within an entity annotated with @TTL. I?m not familiar enough with the ORM and OGM core to estimate the complexity of such an feature. With @TTL properties we could give the user the control over the TTL. Then we just need to decide what to do if there?s no @TTL property inside an entity and we?re back at the question what to do in the default case.


> Am 27.06.2016 um 16:21 schrieb Guillaume Smet <guillaume.smet at gmail.com>:
> 
> Hi Mark!
> 
> Thanks for commenting on this, I was hoping for it.

:-)

> 
> While I can see the use case for sharing Redis data between 2 tools, I must admit that I find it a bit weird to set the TTL on one tool and store the entity on another one. It looks to me that if OGM stores the data, it has to manage also the expiration.
> 
> Otherwise you store data from OGM which might expire in a few seconds if you're not lucky!
> 
> Don't you agree?

That?s the nature of NoSQL data stores I guess. 


> 
> -- 
> Guillaume
> 
> On Mon, Jun 27, 2016 at 3:47 PM, Mark Paluch <mpaluch at paluch.biz <mailto:mpaluch at paluch.biz>> wrote:
> 
> Hi Guillaume, 
> 
> TTL preservation behavior originates from Redis? behavior and is to preserve interoperability: 
> 
>> http://redis.io/commands/set <http://redis.io/commands/set>
>> Set key to hold the string value. [...] Any previous time to live associated with the key is discarded on successful SET operation.
> 
> 
> Keys written with SET loose their TTL value and the entry is persisted without any further TTL. Reading and re-applying TTL is to preserve the expiry.
> The general idea behind is to either apply the remaining TTL from the key, because TTL is not configured in the entity model or to set the configured TTL from the entity model.
> I see it from an integration-perspective in which Hibernate OGM and other tools share Redis data and so you?re opting-in for features but things are not broken.
> 
> Best regards, Mark
> 
> 
>> Am 27.06.2016 um 14:43 schrieb Guillaume Smet <guillaume.smet at gmail.com <mailto:guillaume.smet at gmail.com>>:
>> 
>> Hi,
>> 
>> So, I'm currently working on reducing the number of calls issued to Redis
>> in OGM as part of OGM-1064.
>> 
>> At the moment, we execute a call to Redis to get the TTL already configured
>> on an object before saving it. If the TTL is not explicitly configured with
>> @TTL, we set this TTL again after having stored this entity (see
>> RedisJsonDialect#storeEntity). Same for associations stored in a different
>> document.
>> 
>> In fact, this call returns the time remaining before expiration, not the
>> TTL previously configured,  so I find this behavior quite weird. Basically,
>> we store information which will expire sooner than expected. I can't really
>> get a use case for this and I don't think we should have an additional call
>> every time we store an object for a so obscure thing. Do we really expect
>> people to mess with TTLs of objects stored by OGM without relying on OGM
>> @TTL management?
>> 
>> IMHO, we should get rid of this call and only deal with TTL when it's
>> configured via the @TTL annotation.
>> 
>> Thoughts?
>> 
>> -- 
>> Guillaume
>> _______________________________________________
>> 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 <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> 
> 


From sanne at hibernate.org  Mon Jun 27 11:05:37 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 27 Jun 2016 16:05:37 +0100
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CADGJaX-VafLO76CgL1rRuzdKYzt27+NAD5qkFp1rBaLXOz4wWg@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
	<CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
	<CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>
	<CAFm4XO3Cqp-C4gJqaB6vxHC6P=TCpoJVDh9iPhttCO4ULv8BZQ@mail.gmail.com>
	<a0c89470-0427-c5e3-076a-5c075781cf21@redhat.com>
	<CADGJaX-VafLO76CgL1rRuzdKYzt27+NAD5qkFp1rBaLXOz4wWg@mail.gmail.com>
Message-ID: <CAFm4XO1mDacSSweQb1s52R8pK-2fiuf-pOsHO88SRiB+uK8Yvw@mail.gmail.com>

On 27 June 2016 at 15:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hey,
>
> I've sent PR https://github.com/hibernate/hibernate-orm/pull/1455 earlier
> today for this.
>
>> What happens if we copy the contents of the
>> org.hibernate.jipijapa-hibernate5 module, to
>> org.hibernate.jipijapa-hibernate5-1.
>> Change org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and
>> change ORM 5.1 to depend on org.hibernate.jipijapa-hibernate5-1.
>
> Yes, that's what I ended up doing. At first I wasn't aware of that circular
> dependency between the two modules, thus missing to update one of the
> references to the 5.1 slot and hence pulling in the WF-provided ORM.
>
>> I'm guessing but most likely by copying the above module reference to
>> "org.hibernate.jipijapa-hibernate5" into the ORM 5.1 module.xml.
>
> Exactly.
>
> Alternatively, I just could add the JipiJapa adapter JAR to my ORM 5.1
> module, itself. But I decided to stick to the original WF structure as close
> as possible.

+1 the ORM module is exposed to user code, while we don't want to
expose these classes.

> That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks a
> bit scary. My simple test passes, not sure whether that may be a problem in
> other cases, though?

Great catch! Sound very dangerous indeed, at least for our plans.
Could you raise it on the wildfly-dev mailing list to be cleaned up?

--Sanne


>
> --Gunnar
>
>
>
>
> 2016-06-27 15:39 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>
>>
>>
>> On 06/25/2016 05:12 PM, Sanne Grinovero wrote:
>> > On 25 June 2016 at 13:15, Gunnar Morling <gunnar at hibernate.org> wrote:
>> >> Ok, so this was caused by the module dependency
>> >> from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need
>> >> to
>> >> create a 5.1-specific adapter module, too, and require that to be
>> >> configured by users via jboss.as.jpa.adapterModule.
>>
>> What happens if we copy the contents of the
>> org.hibernate.jipijapa-hibernate5 module, to
>> org.hibernate.jipijapa-hibernate5-1.  Change
>> org.hibernate.jipijapa-hibernate5-1, to depend on ORM 5.1 and change ORM
>> 5.1 to depend on org.hibernate.jipijapa-hibernate5-1.
>>
>> >
>> > If you include the adaptor module with the ORM modules, it should be
>> > auto-discovered.
>>
>> The ORM 5.0 module.xml has the following so that service loading can do
>> the discovery:
>>
>> "
>> <module name="org.hibernate.jipijapa-hibernate5" services="import"/>
>> "
>>
>> >
>> > See how OGM does it.
>> >
>> > I'm not sure I understood why you were being exposed to the
>> > jipijapa-hibernate5 module though?
>>
>> I'm guessing but most likely by copying the above module reference to
>> "org.hibernate.jipijapa-hibernate5" into the ORM 5.1 module.xml.
>>
>> > This shouldn't activate automatically when you change the
>> > providerModule setting.
>> >
>> > --Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > 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
>
>

From smarlow at redhat.com  Mon Jun 27 11:23:59 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jun 2016 11:23:59 -0400
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CADGJaX-VafLO76CgL1rRuzdKYzt27+NAD5qkFp1rBaLXOz4wWg@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
	<CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
	<CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>
	<CAFm4XO3Cqp-C4gJqaB6vxHC6P=TCpoJVDh9iPhttCO4ULv8BZQ@mail.gmail.com>
	<a0c89470-0427-c5e3-076a-5c075781cf21@redhat.com>
	<CADGJaX-VafLO76CgL1rRuzdKYzt27+NAD5qkFp1rBaLXOz4wWg@mail.gmail.com>
Message-ID: <8c182986-7dc0-6291-e202-1ef8916bd902@redhat.com>

>
> That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks
> a bit scary. My simple test passes, not sure whether that may be a
> problem in other cases, though?
>

Sorry, I missed this part of your email.  EJB3 timers are using 
Hibernate [1].

Scott

[1] 
https://github.com/wildfly/wildfly/commit/01924ed3a38e0a4d8ef7fa54a59f12ab68932875

From sanne at hibernate.org  Mon Jun 27 11:44:24 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 27 Jun 2016 16:44:24 +0100
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <8c182986-7dc0-6291-e202-1ef8916bd902@redhat.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
	<CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
	<CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>
	<CAFm4XO3Cqp-C4gJqaB6vxHC6P=TCpoJVDh9iPhttCO4ULv8BZQ@mail.gmail.com>
	<a0c89470-0427-c5e3-076a-5c075781cf21@redhat.com>
	<CADGJaX-VafLO76CgL1rRuzdKYzt27+NAD5qkFp1rBaLXOz4wWg@mail.gmail.com>
	<8c182986-7dc0-6291-e202-1ef8916bd902@redhat.com>
Message-ID: <CAFm4XO17DPi=u-JRZk2nkRa7ZmPDw_N_e8d_xGsSHDN1R9pPqQ@mail.gmail.com>

On 27 June 2016 at 16:23, Scott Marlow <smarlow at redhat.com> wrote:
>>
>> That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks
>> a bit scary. My simple test passes, not sure whether that may be a
>> problem in other cases, though?
>>
>
> Sorry, I missed this part of your email.  EJB3 timers are using Hibernate

Thanks Scott, that sounds reassuring. May we assume that this is not
exported in any way to user's classpath?

Also, I see no instance of a "import org.hibernate" string in those
sources. Am I understanding correctly that the dependency is there
just to have a JPA implementation,
and while it happens to be tested with Hibernate, the dependency is
actually flexible?

Thanks,
Sanne


>
> Scott
>
> [1]
> https://github.com/wildfly/wildfly/commit/01924ed3a38e0a4d8ef7fa54a59f12ab68932875

From smarlow at redhat.com  Mon Jun 27 12:03:15 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 27 Jun 2016 12:03:15 -0400
Subject: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in
	WildFly
In-Reply-To: <CAFm4XO17DPi=u-JRZk2nkRa7ZmPDw_N_e8d_xGsSHDN1R9pPqQ@mail.gmail.com>
References: <CADGJaX_4o9uS6VuXbeH9WP-TrvvA4jM5daTZ392+VJOjHrJjog@mail.gmail.com>
	<CAFdSV9uN=JOFTjtWwMv3aMt9GTQpgvk4r+3KTGcmasQY693F5g@mail.gmail.com>
	<CADGJaX9aZ92pmFz5_TQzTN7SFRJd62fH3NBiDrcsQ+C3=LGUPQ@mail.gmail.com>
	<CAFm4XO1W8+qeT6uE+ELEiV-t2k6rKW0E1qn72SieV_+tNtTjAA@mail.gmail.com>
	<CADGJaX-nR_+1Q2_MwqNMUNSkSi0o25QVQyqtFXLUGqDJo8wRPA@mail.gmail.com>
	<CAFm4XO3GUkP_PdyCEwB0on4WyDg_nQ+M3BQcjHhG+Y1vsfnCVw@mail.gmail.com>
	<CADGJaX-9ZVEQ+mJxz3Dq=7OoLddU1DddA=tDup-m5b-Q1UjCUw@mail.gmail.com>
	<CADGJaX_yio0AUPxOxrZLh1DJjiy839W9quVdyfEgYN6NRJTE=w@mail.gmail.com>
	<CAFm4XO3Cqp-C4gJqaB6vxHC6P=TCpoJVDh9iPhttCO4ULv8BZQ@mail.gmail.com>
	<a0c89470-0427-c5e3-076a-5c075781cf21@redhat.com>
	<CADGJaX-VafLO76CgL1rRuzdKYzt27+NAD5qkFp1rBaLXOz4wWg@mail.gmail.com>
	<8c182986-7dc0-6291-e202-1ef8916bd902@redhat.com>
	<CAFm4XO17DPi=u-JRZk2nkRa7ZmPDw_N_e8d_xGsSHDN1R9pPqQ@mail.gmail.com>
Message-ID: <f804eee9-6e79-f262-d4b8-0f17b7203d85@redhat.com>



On 06/27/2016 11:44 AM, Sanne Grinovero wrote:
> On 27 June 2016 at 16:23, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>> That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks
>>> a bit scary. My simple test passes, not sure whether that may be a
>>> problem in other cases, though?
>>>
>>
>> Sorry, I missed this part of your email.  EJB3 timers are using Hibernate
>
> Thanks Scott, that sounds reassuring. May we assume that this is not
> exported in any way to user's classpath?

Doesn't appear to be exported to the clients classpath.

>
> Also, I see no instance of a "import org.hibernate" string in those
> sources. Am I understanding correctly that the dependency is there
> just to have a JPA implementation,
> and while it happens to be tested with Hibernate, the dependency is
> actually flexible?

org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence 
[1] appears to be purely JPA based.  DDL/DML appears to be in [2].

Scott

[1] 
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/timerservice/persistence/database/DatabaseTimerPersistence.java

[2] 
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/timers/timer-sql.properties

From gunnar at hibernate.org  Tue Jun 28 06:55:16 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 28 Jun 2016 12:55:16 +0200
Subject: [hibernate-dev] Redis and TTL
In-Reply-To: <1159174E-246B-4793-BC7D-D16C86F98019@paluch.biz>
References: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
	<8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
	<CAFm4XO02p0hJ8zL4QHWLqEW9auNjz1hN65eWvQODWtM12fO5Og@mail.gmail.com>
	<1159174E-246B-4793-BC7D-D16C86F98019@paluch.biz>
Message-ID: <CADGJaX-QqvVPGfYsfm2X_6LPSdwW4JRabnQ7RqTj77HYe4QM+Q@mail.gmail.com>

Hi,

> [...] The TTL is not configured in OGM for this use-case because the TTL
might be determined somehow dynamic by the first client.

Yes, but this kind of issue is the crux when integrating different
applications through the database. If you can't avoid it, you at least
should use the same configurations within all the applications. Just as
e.g. column names, all applications syncing on one DB must be using the
same ones.

> So maybe we could address the TTL issue in a different way that is more
user-friendly and provide properties within an entity annotated with @TTL

That sounds interesting, could you describe in some more details how such
feature would be used? I could imagine some kind of "state-based" TTL
calculation, leaving it to the entity to return the TTL to use from some
annotated property. Is that what you had in mind?

Or maybe we could have some strategy of sort which determines
the behaviour for OGM writes:

    @Entity
    @TTL(value = 7, unit = TimeUnit.DAYS, strategy = REFRESH)
    public class Zoo { ... }

TtlStrategy.REFRESH would update the value to the given one for each write.
Another value such as KEEP would maintain the existing one to implement the
alternative behaviour. RERESH would be the default. On the downside, to
support no TTL being given via OGM at all and being able to work with KEEP,
we'd have to make value and unit optional. Maybe a separate annotation then?

--Gunnar


2016-06-27 16:39 GMT+02:00 Mark Paluch <mpaluch at paluch.biz>:

> Hi Sanne,
>
> not sure I follow.
>
> The use case is: Two applications (clients) share one Redis instance. The
> first (non-OGM) client writes some data and sets an expiry (TTL). The
> second (OGM) client updates the data stored inside of Redis and preserves
> the remaining TTL. Note that the first (non-OGM) client wrote an expiry and
> expects the key to disappear sooner or later.
>
> The TTL is not configured in OGM for this use-case because the TTL might
> be determined somehow dynamic by the first client.
>
> Greetings, Mark
>
> > Am 27.06.2016 um 15:52 schrieb Sanne Grinovero <sanne at hibernate.org>:
> >
> > Hi Mark,
> >
> > you wouldn't expect the timeout to be "reset" to some default value
> > when your code writes to an entity?
> >
> > If you could explain the use case, that might help us to understand this.
> >
> > Thanks,
> > Sanne
> >
> > On 27 June 2016 at 14:47, Mark Paluch <mpaluch at paluch.biz> wrote:
> >>
> >> Hi Guillaume,
> >>
> >> TTL preservation behavior originates from Redis? behavior and is to
> preserve interoperability:
> >>
> >>> http://redis.io/commands/set <http://redis.io/commands/set>
> >>> Set key to hold the string value. [...] Any previous time to live
> associated with the key is discarded on successful SET operation.
> >>
> >>
> >> Keys written with SET loose their TTL value and the entry is persisted
> without any further TTL. Reading and re-applying TTL is to preserve the
> expiry.
> >> The general idea behind is to either apply the remaining TTL from the
> key, because TTL is not configured in the entity model or to set the
> configured TTL from the entity model.
> >> I see it from an integration-perspective in which Hibernate OGM and
> other tools share Redis data and so you?re opting-in for features but
> things are not broken.
> >>
> >> Best regards, Mark
> >>
> >>
> >>> Am 27.06.2016 um 14:43 schrieb Guillaume Smet <
> guillaume.smet at gmail.com>:
> >>>
> >>> Hi,
> >>>
> >>> So, I'm currently working on reducing the number of calls issued to
> Redis
> >>> in OGM as part of OGM-1064.
> >>>
> >>> At the moment, we execute a call to Redis to get the TTL already
> configured
> >>> on an object before saving it. If the TTL is not explicitly configured
> with
> >>> @TTL, we set this TTL again after having stored this entity (see
> >>> RedisJsonDialect#storeEntity). Same for associations stored in a
> different
> >>> document.
> >>>
> >>> In fact, this call returns the time remaining before expiration, not
> the
> >>> TTL previously configured,  so I find this behavior quite weird.
> Basically,
> >>> we store information which will expire sooner than expected. I can't
> really
> >>> get a use case for this and I don't think we should have an additional
> call
> >>> every time we store an object for a so obscure thing. Do we really
> expect
> >>> people to mess with TTLs of objects stored by OGM without relying on
> OGM
> >>> @TTL management?
> >>>
> >>> IMHO, we should get rid of this call and only deal with TTL when it's
> >>> configured via the @TTL annotation.
> >>>
> >>> Thoughts?
> >>>
> >>> --
> >>> Guillaume
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> 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
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mpaluch at paluch.biz  Tue Jun 28 08:23:33 2016
From: mpaluch at paluch.biz (Mark Paluch)
Date: Tue, 28 Jun 2016 14:23:33 +0200
Subject: [hibernate-dev] Redis and TTL
In-Reply-To: <CADGJaX-QqvVPGfYsfm2X_6LPSdwW4JRabnQ7RqTj77HYe4QM+Q@mail.gmail.com>
References: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
	<8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
	<CAFm4XO02p0hJ8zL4QHWLqEW9auNjz1hN65eWvQODWtM12fO5Og@mail.gmail.com>
	<1159174E-246B-4793-BC7D-D16C86F98019@paluch.biz>
	<CADGJaX-QqvVPGfYsfm2X_6LPSdwW4JRabnQ7RqTj77HYe4QM+Q@mail.gmail.com>
Message-ID: <6E37AFE6-106E-4BEF-96EA-E1CC8FC8758E@paluch.biz>

Hi Gunnar, 
see my responses in-line.

Best regards, Mark


> Am 28.06.2016 um 12:55 schrieb Gunnar Morling <gunnar at hibernate.org>:
> 
> Hi,
> 
> > [...] The TTL is not configured in OGM for this use-case because the TTL might be determined somehow dynamic by the first client.
> 
> Yes, but this kind of issue is the crux when integrating different applications through the database. If you can't avoid it, you at least should use the same configurations within all the applications. Just as e.g. column names, all applications syncing on one DB must be using the same ones.
> 
> > So maybe we could address the TTL issue in a different way that is more user-friendly and provide properties within an entity annotated with @TTL
> 
> That sounds interesting, could you describe in some more details how such feature would be used? I could imagine some kind of "state-based" TTL calculation, leaving it to the entity to return the TTL to use from some annotated property. Is that what you had in mind?

Yeah, I added some code below.

public class Zoo {

 @TTL // not sure about value and defaults here, so omitting that right now
 long ttl;
}

public updateZoo(){
  Zoo zoo = ?;
  
  if(zoo.hasZebra()) {
     zoo.setTtl(zoo.getTtl() + 100);
  }
}

public class Horse {

  @TTL // not sure about value and defaults here, so omitting that right now
  public long getTtl() {
    if(this.closed) {
       return 100;
    }
    return -1;
  }
}

> 
> Or maybe we could have some strategy of sort which determines the behaviour for OGM writes:
> 
>     @Entity
>     @TTL(value = 7, unit = TimeUnit.DAYS, strategy = REFRESH)
>     public class Zoo { ... }
> 
> TtlStrategy.REFRESH would update the value to the given one for each write. Another value such as KEEP would maintain the existing one to implement the alternative behaviour. RERESH would be the default. On the downside, to support no TTL being given via OGM at all and being able to work with KEEP, we'd have to make value and unit optional. Maybe a separate annotation then?
> 

Something like that would work nicely. Let?s split that into two annotations as @TTL should require the TTL and some TTL strategy annotation could specify the strategy. Seeing the code I even thing that KEEP could have a nice side-effect with @TTL defined as one could just load and edit an entity without renewing the TTL.


> --Gunnar
> 
> 
> 2016-06-27 16:39 GMT+02:00 Mark Paluch <mpaluch at paluch.biz <mailto:mpaluch at paluch.biz>>:
> Hi Sanne,
> 
> not sure I follow.
> 
> The use case is: Two applications (clients) share one Redis instance. The first (non-OGM) client writes some data and sets an expiry (TTL). The second (OGM) client updates the data stored inside of Redis and preserves the remaining TTL. Note that the first (non-OGM) client wrote an expiry and expects the key to disappear sooner or later.
> 
> The TTL is not configured in OGM for this use-case because the TTL might be determined somehow dynamic by the first client.
> 
> Greetings, Mark
> 
> > Am 27.06.2016 um 15:52 schrieb Sanne Grinovero <sanne at hibernate.org <mailto:sanne at hibernate.org>>:
> >
> > Hi Mark,
> >
> > you wouldn't expect the timeout to be "reset" to some default value
> > when your code writes to an entity?
> >
> > If you could explain the use case, that might help us to understand this.
> >
> > Thanks,
> > Sanne
> >
> > On 27 June 2016 at 14:47, Mark Paluch <mpaluch at paluch.biz <mailto:mpaluch at paluch.biz>> wrote:
> >>
> >> Hi Guillaume,
> >>
> >> TTL preservation behavior originates from Redis? behavior and is to preserve interoperability:
> >>
> >>> http://redis.io/commands/set <http://redis.io/commands/set> <http://redis.io/commands/set <http://redis.io/commands/set>>
> >>> Set key to hold the string value. [...] Any previous time to live associated with the key is discarded on successful SET operation.
> >>
> >>
> >> Keys written with SET loose their TTL value and the entry is persisted without any further TTL. Reading and re-applying TTL is to preserve the expiry.
> >> The general idea behind is to either apply the remaining TTL from the key, because TTL is not configured in the entity model or to set the configured TTL from the entity model.
> >> I see it from an integration-perspective in which Hibernate OGM and other tools share Redis data and so you?re opting-in for features but things are not broken.
> >>
> >> Best regards, Mark
> >>
> >>
> >>> Am 27.06.2016 um 14:43 schrieb Guillaume Smet <guillaume.smet at gmail.com <mailto:guillaume.smet at gmail.com>>:
> >>>
> >>> Hi,
> >>>
> >>> So, I'm currently working on reducing the number of calls issued to Redis
> >>> in OGM as part of OGM-1064.
> >>>
> >>> At the moment, we execute a call to Redis to get the TTL already configured
> >>> on an object before saving it. If the TTL is not explicitly configured with
> >>> @TTL, we set this TTL again after having stored this entity (see
> >>> RedisJsonDialect#storeEntity). Same for associations stored in a different
> >>> document.
> >>>
> >>> In fact, this call returns the time remaining before expiration, not the
> >>> TTL previously configured,  so I find this behavior quite weird. Basically,
> >>> we store information which will expire sooner than expected. I can't really
> >>> get a use case for this and I don't think we should have an additional call
> >>> every time we store an object for a so obscure thing. Do we really expect
> >>> people to mess with TTLs of objects stored by OGM without relying on OGM
> >>> @TTL management?
> >>>
> >>> IMHO, we should get rid of this call and only deal with TTL when it's
> >>> configured via the @TTL annotation.
> >>>
> >>> Thoughts?
> >>>
> >>> --
> >>> Guillaume
> >>> _______________________________________________
> >>> 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 <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> >>
> >> _______________________________________________
> >> 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 <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
> 
> 
> _______________________________________________
> 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 <https://lists.jboss.org/mailman/listinfo/hibernate-dev>


From guillaume.smet at gmail.com  Tue Jun 28 09:04:39 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 28 Jun 2016 15:04:39 +0200
Subject: [hibernate-dev] Redis and TTL
In-Reply-To: <6E37AFE6-106E-4BEF-96EA-E1CC8FC8758E@paluch.biz>
References: <CALt0+o_nO_rjCAjLyyRVqVRv7PEZ9mao5dSnrbJh8nQ3K48e0A@mail.gmail.com>
	<8A14F531-49B1-4032-8569-532E1ED57913@paluch.biz>
	<CAFm4XO02p0hJ8zL4QHWLqEW9auNjz1hN65eWvQODWtM12fO5Og@mail.gmail.com>
	<1159174E-246B-4793-BC7D-D16C86F98019@paluch.biz>
	<CADGJaX-QqvVPGfYsfm2X_6LPSdwW4JRabnQ7RqTj77HYe4QM+Q@mail.gmail.com>
	<6E37AFE6-106E-4BEF-96EA-E1CC8FC8758E@paluch.biz>
Message-ID: <CALt0+o8ssiyJrnumf==hK9Nt-_4Rwh2RezPnQboCLwZwtfyFVQ@mail.gmail.com>

I might be dumb but I can't figure out a use case where you would want an
external app to set a TTL and OGM to manipulate the same objects while
keeping the TTL originally set. It really looks weird to me.

Anyway, if it's really a use case, I think Gunnar's proposal does fit and
will allow to remove these useless pttl calls.

As for the dynamic TTL based on a property/method, let's keep it for
another day.

Mark, do you wish to make a proposal on the REFRESH/KEEP thing or should I
take it from there?

Btw, as far as I'm concerned, I would use @TTL because even if you want to
use the KEEP option, you probably would want to set a TTL if the entity
doesn't exist yet? What I would do is: if there is already a TTL for this
object, keep it, if not use the TTL defined in @TTL. But as I didn't
understand the original use case, I wouldn't bet on it :).

-- 
Guillaume

From karel at geovise.com  Tue Jun 28 09:22:59 2016
From: karel at geovise.com (Karel Maesen)
Date: Tue, 28 Jun 2016 15:22:59 +0200
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
	<CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
Message-ID: <CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>

It makes sense for some Dialects such as those for MySQL and MS SQL Server.
Less so for Postgresql and Oracle Spatial because here the spatial
capabilities need to be installed and configured separately (and even have
versioning separate from the main database engine).

I would favour an approach, close to what Sanne is suggesting, where the
spatial capability (Incl. Types) is injected into the Dialect during
Dialect construction based on some explicit configuration. In that way the
relation between Dialect and the spatial capability mirrors the relation
between database engine and spatial capability (if any).

Regards,

Karel

PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
able to resume the exchange before July 20.

On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org> wrote:

> They have not been "merged" in the same way we merged
> hibernate-entitymanager into hibernate-core.    So at the moment using
> hibernate-core e.g. does not require geolatte to be present.  geolatte is
> only required if using hibernate-spatial (isolated transitive dep).
>
> Karel, what are your thoughts on this?  I am not a fan of making geolatte
> optional/provided, but if we all deem that folding hibernate-spatial into
> hibernate-core (ala hibernate-entitymanager) as Vlad suggests is desirable
> then I will accept that
>
> On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > Nice idea!
> >
> > since the modules were merged already, don't we already require
> > geolatte-geom ?
> > I guess some code might be intentionally designed to fail gracefully
> > about this library being there or not, but we'd need to make sure that
> > can be tested for it to be maintainable.
> >
> > My preference would be to have:
> >  - All Dialects automatically provide the spatial extensions if the
> > needed dependencies are in place: we could automatically alias them
> > based on this?
> >  - a good error message naming the missing dependencies explicitly
> > when someone attempts to use such a Spatial extensions, but the
> > feature was not enabled by our automatic logic.
> >  - be able to test for these.
> >
> > In practice I believe this means we should still have it as an
> > independent source module, compile and test it as an independent
> > module, and only bundle within the ORM main jar as final distribution
> > step.
> >
> > If that's too much work, I'd rather make the geolatte-geom a mandatory
> > dependency than to have cryptic runtime failures.
> >
> > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> > > Hi,
> > >
> > > Since hibenrate-spatial has been merged into Hibernate code base,
> > shouldn't
> > > we merge the Dialects as well.
> > > For instance, we have MySQL56InnoDBSpatialDialect which can simply be
> > > merged into a MySQL56InnoDBDialect.
> > > This way, MySQL57InnoDBDialect can take advantage of spatial queries as
> > > well.
> > >
> > > The only drawback is that we need to add the geolatte-geom lib to
> > > hibernate-orm.
> > >
> > > Let me know what you think.
> > >
> > > Vlad
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jun 28 09:24:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Jun 2016 13:24:38 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9t1fdpsBf3q-myi5rJJkWZ+RcDOhR95PFefhuUUnUUkOw@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<CADGJaX8zk4OQYgy32G26deo90VLsne+fKMiH6daUH2q+CV1ktA@mail.gmail.com>
	<CAFdSV9t1fdpsBf3q-myi5rJJkWZ+RcDOhR95PFefhuUUnUUkOw@mail.gmail.com>
Message-ID: <CAFdSV9v0nQ22QLq-34BkfWD_+UHj1yuSEtonk9U4WM6v_5+G=A@mail.gmail.com>

Ok, I need to move forward on this and I have gotten enough affirmative
feedback to ahead.

On Fri, Jun 24, 2016 at 6:24 PM Steve Ebersole <steve at hibernate.org> wrote:

> This is all part of the to-be-decided read/write part of the new Type
> contract.  I propose, as discussed in the wiki, that we have Type return
> ValueExtractor and ValueBinder for read/write.  So assuming that is there...
>
> One possible answer to your story is that OGM as a SQM interpreter and
> Metamodel (persisters, etc) implementor would influence the Type and
> therefore the ValueExtractor and ValueBinder.  We'd just need to define the
> right generic API to allow that to happen without ORM, e.g., having to jump
> through a bunch of hoops to get to JDBC objects.
>
> On Fri, Jun 24, 2016 at 5:18 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Steve,
>>
>> I still need to look at the wiki page and will give more detailed
>> feedback on some parts of it.
>>
>> One general thing coming to mind though is how support for OGM could be
>> improved. On first thought I'd say the "Java side" of Type might stay as
>> is, but the "SQL side" (or "datastore side") and read/write logic
>> interacting with result sets etc. would have to look differently in the
>> case of OGM.
>>
>> If this part of the story could be made pluggable somehow, than a custom
>> factory of sorts in OGM could plug in its dedicated implementation of the
>> "datastore side". Not sure how it'd look in practice, the implementations
>> would be rather different (we don't work with ResultSet at all in OGM), so
>> I suppose it might require casting to the expected subtype when working
>> with Type in ORM or OGM.
>>
>> Currently, we completely override the Type hierarchy from ORM with a
>> corresponding GridType hierarchy in OGM, but it might be possible to re-use
>> many more code by just customizing the "datastore side". Plus, it'd be a
>> tad more efficient for OGM, as we can skip the translation from Type to
>> GridType.
>>
>> I might provide some more details once having studied the current
>> proposal in more depth, just wanted to get out these thoughts to you.
>>
>> --Gunnar
>>
>>
>>
>>
>> 2016-06-22 18:54 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> I started a wiki discussing the proposal for the type system redesign.
>>> Let's get discussions about it starter sooner rather than later.  Thanks!
>>>
>>> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From gunnar at hibernate.org  Tue Jun 28 09:33:08 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 28 Jun 2016 15:33:08 +0200
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
	<CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
	<CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>
Message-ID: <CADGJaX-TMYaLMdQQAoxrHXdVGiaaib+15S71v8Jx3__2_msRfQ@mail.gmail.com>

One thing to keep in mind is that the module system of Java 9 ("Jigsaw")
doesn't support a notion of optional module dependences.

So if this is meant to remain an "optional feature" (i.e. Geo-specific
libraries are not required at runtime when not using the spatial stuff), it
should remain a separate artifact - this is, should we plan to make
Hibernate ORM JARs Jigsaw modules at some point.

--Gunnar


2016-06-28 15:22 GMT+02:00 Karel Maesen <karel at geovise.com>:

> It makes sense for some Dialects such as those for MySQL and MS SQL Server.
> Less so for Postgresql and Oracle Spatial because here the spatial
> capabilities need to be installed and configured separately (and even have
> versioning separate from the main database engine).
>
> I would favour an approach, close to what Sanne is suggesting, where the
> spatial capability (Incl. Types) is injected into the Dialect during
> Dialect construction based on some explicit configuration. In that way the
> relation between Dialect and the spatial capability mirrors the relation
> between database engine and spatial capability (if any).
>
> Regards,
>
> Karel
>
> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
> able to resume the exchange before July 20.
>
> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > They have not been "merged" in the same way we merged
> > hibernate-entitymanager into hibernate-core.    So at the moment using
> > hibernate-core e.g. does not require geolatte to be present.  geolatte is
> > only required if using hibernate-spatial (isolated transitive dep).
> >
> > Karel, what are your thoughts on this?  I am not a fan of making geolatte
> > optional/provided, but if we all deem that folding hibernate-spatial into
> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
> desirable
> > then I will accept that
> >
> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >
> > > Nice idea!
> > >
> > > since the modules were merged already, don't we already require
> > > geolatte-geom ?
> > > I guess some code might be intentionally designed to fail gracefully
> > > about this library being there or not, but we'd need to make sure that
> > > can be tested for it to be maintainable.
> > >
> > > My preference would be to have:
> > >  - All Dialects automatically provide the spatial extensions if the
> > > needed dependencies are in place: we could automatically alias them
> > > based on this?
> > >  - a good error message naming the missing dependencies explicitly
> > > when someone attempts to use such a Spatial extensions, but the
> > > feature was not enabled by our automatic logic.
> > >  - be able to test for these.
> > >
> > > In practice I believe this means we should still have it as an
> > > independent source module, compile and test it as an independent
> > > module, and only bundle within the ORM main jar as final distribution
> > > step.
> > >
> > > If that's too much work, I'd rather make the geolatte-geom a mandatory
> > > dependency than to have cryptic runtime failures.
> > >
> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > > > Hi,
> > > >
> > > > Since hibenrate-spatial has been merged into Hibernate code base,
> > > shouldn't
> > > > we merge the Dialects as well.
> > > > For instance, we have MySQL56InnoDBSpatialDialect which can simply be
> > > > merged into a MySQL56InnoDBDialect.
> > > > This way, MySQL57InnoDBDialect can take advantage of spatial queries
> as
> > > > well.
> > > >
> > > > The only drawback is that we need to add the geolatte-geom lib to
> > > > hibernate-orm.
> > > >
> > > > Let me know what you think.
> > > >
> > > > Vlad
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > 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
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > 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
>

From steve at hibernate.org  Tue Jun 28 09:40:00 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Jun 2016 13:40:00 +0000
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CADGJaX-TMYaLMdQQAoxrHXdVGiaaib+15S71v8Jx3__2_msRfQ@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
	<CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
	<CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>
	<CADGJaX-TMYaLMdQQAoxrHXdVGiaaib+15S71v8Jx3__2_msRfQ@mail.gmail.com>
Message-ID: <CAFdSV9t7yY7_GcD29DU8-kKGwHXE+uYoXsLw0+Yo2jQBdRWcAQ@mail.gmail.com>

I agree.  I think keeping these separate makes the most sense.

@Karel, we already have that capability wrt Types (see
Dialect#contributeTypes).  What else would get injected?

On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> One thing to keep in mind is that the module system of Java 9 ("Jigsaw")
> doesn't support a notion of optional module dependences.
>
> So if this is meant to remain an "optional feature" (i.e. Geo-specific
> libraries are not required at runtime when not using the spatial stuff), it
> should remain a separate artifact - this is, should we plan to make
> Hibernate ORM JARs Jigsaw modules at some point.
>
> --Gunnar
>
>
> 2016-06-28 15:22 GMT+02:00 Karel Maesen <karel at geovise.com>:
>
>> It makes sense for some Dialects such as those for MySQL and MS SQL
>> Server.
>> Less so for Postgresql and Oracle Spatial because here the spatial
>> capabilities need to be installed and configured separately (and even have
>> versioning separate from the main database engine).
>>
>> I would favour an approach, close to what Sanne is suggesting, where the
>> spatial capability (Incl. Types) is injected into the Dialect during
>> Dialect construction based on some explicit configuration. In that way the
>> relation between Dialect and the spatial capability mirrors the relation
>> between database engine and spatial capability (if any).
>>
>> Regards,
>>
>> Karel
>>
>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
>> able to resume the exchange before July 20.
>>
>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > They have not been "merged" in the same way we merged
>> > hibernate-entitymanager into hibernate-core.    So at the moment using
>> > hibernate-core e.g. does not require geolatte to be present.  geolatte
>> is
>> > only required if using hibernate-spatial (isolated transitive dep).
>> >
>> > Karel, what are your thoughts on this?  I am not a fan of making
>> geolatte
>> > optional/provided, but if we all deem that folding hibernate-spatial
>> into
>> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
>> desirable
>> > then I will accept that
>> >
>> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> >
>> > > Nice idea!
>> > >
>> > > since the modules were merged already, don't we already require
>> > > geolatte-geom ?
>> > > I guess some code might be intentionally designed to fail gracefully
>> > > about this library being there or not, but we'd need to make sure that
>> > > can be tested for it to be maintainable.
>> > >
>> > > My preference would be to have:
>> > >  - All Dialects automatically provide the spatial extensions if the
>> > > needed dependencies are in place: we could automatically alias them
>> > > based on this?
>> > >  - a good error message naming the missing dependencies explicitly
>> > > when someone attempts to use such a Spatial extensions, but the
>> > > feature was not enabled by our automatic logic.
>> > >  - be able to test for these.
>> > >
>> > > In practice I believe this means we should still have it as an
>> > > independent source module, compile and test it as an independent
>> > > module, and only bundle within the ORM main jar as final distribution
>> > > step.
>> > >
>> > > If that's too much work, I'd rather make the geolatte-geom a mandatory
>> > > dependency than to have cryptic runtime failures.
>> > >
>> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>> > > > Hi,
>> > > >
>> > > > Since hibenrate-spatial has been merged into Hibernate code base,
>> > > shouldn't
>> > > > we merge the Dialects as well.
>> > > > For instance, we have MySQL56InnoDBSpatialDialect which can simply
>> be
>> > > > merged into a MySQL56InnoDBDialect.
>> > > > This way, MySQL57InnoDBDialect can take advantage of spatial
>> queries as
>> > > > well.
>> > > >
>> > > > The only drawback is that we need to add the geolatte-geom lib to
>> > > > hibernate-orm.
>> > > >
>> > > > Let me know what you think.
>> > > >
>> > > > Vlad
>> > > > _______________________________________________
>> > > > hibernate-dev mailing list
>> > > > 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
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > 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
>>
>
>

From karel at geovise.com  Tue Jun 28 10:18:02 2016
From: karel at geovise.com (Karel Maesen)
Date: Tue, 28 Jun 2016 16:18:02 +0200
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CAFdSV9t7yY7_GcD29DU8-kKGwHXE+uYoXsLw0+Yo2jQBdRWcAQ@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
	<CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
	<CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>
	<CADGJaX-TMYaLMdQQAoxrHXdVGiaaib+15S71v8Jx3__2_msRfQ@mail.gmail.com>
	<CAFdSV9t7yY7_GcD29DU8-kKGwHXE+uYoXsLw0+Yo2jQBdRWcAQ@mail.gmail.com>
Message-ID: <CADEPDB=kcZWzEGe473jKQBsKDM0U5_xSuZC04E0g1juWM9P=mg@mail.gmail.com>

@Steve, besides Types a number of spatial Functions are registered for use
in queries.

The Dialect#contributetypes method is currently already used by
Hibernate-spatial to inject to correct Types (with the correct
SqlTypeDescriptors) for the SpatialDialect.

On Tue, Jun 28, 2016 at 3:40 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I agree.  I think keeping these separate makes the most sense.
>
> @Karel, we already have that capability wrt Types (see
> Dialect#contributeTypes).  What else would get injected?
>
> On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> One thing to keep in mind is that the module system of Java 9 ("Jigsaw")
>> doesn't support a notion of optional module dependences.
>>
>> So if this is meant to remain an "optional feature" (i.e. Geo-specific
>> libraries are not required at runtime when not using the spatial stuff), it
>> should remain a separate artifact - this is, should we plan to make
>> Hibernate ORM JARs Jigsaw modules at some point.
>>
>> --Gunnar
>>
>>
>> 2016-06-28 15:22 GMT+02:00 Karel Maesen <karel at geovise.com>:
>>
>>> It makes sense for some Dialects such as those for MySQL and MS SQL
>>> Server.
>>> Less so for Postgresql and Oracle Spatial because here the spatial
>>> capabilities need to be installed and configured separately (and even
>>> have
>>> versioning separate from the main database engine).
>>>
>>> I would favour an approach, close to what Sanne is suggesting, where the
>>> spatial capability (Incl. Types) is injected into the Dialect during
>>> Dialect construction based on some explicit configuration. In that way
>>> the
>>> relation between Dialect and the spatial capability mirrors the relation
>>> between database engine and spatial capability (if any).
>>>
>>> Regards,
>>>
>>> Karel
>>>
>>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
>>> able to resume the exchange before July 20.
>>>
>>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>> > They have not been "merged" in the same way we merged
>>> > hibernate-entitymanager into hibernate-core.    So at the moment using
>>> > hibernate-core e.g. does not require geolatte to be present.  geolatte
>>> is
>>> > only required if using hibernate-spatial (isolated transitive dep).
>>> >
>>> > Karel, what are your thoughts on this?  I am not a fan of making
>>> geolatte
>>> > optional/provided, but if we all deem that folding hibernate-spatial
>>> into
>>> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
>>> desirable
>>> > then I will accept that
>>> >
>>> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>> >
>>> > > Nice idea!
>>> > >
>>> > > since the modules were merged already, don't we already require
>>> > > geolatte-geom ?
>>> > > I guess some code might be intentionally designed to fail gracefully
>>> > > about this library being there or not, but we'd need to make sure
>>> that
>>> > > can be tested for it to be maintainable.
>>> > >
>>> > > My preference would be to have:
>>> > >  - All Dialects automatically provide the spatial extensions if the
>>> > > needed dependencies are in place: we could automatically alias them
>>> > > based on this?
>>> > >  - a good error message naming the missing dependencies explicitly
>>> > > when someone attempts to use such a Spatial extensions, but the
>>> > > feature was not enabled by our automatic logic.
>>> > >  - be able to test for these.
>>> > >
>>> > > In practice I believe this means we should still have it as an
>>> > > independent source module, compile and test it as an independent
>>> > > module, and only bundle within the ORM main jar as final distribution
>>> > > step.
>>> > >
>>> > > If that's too much work, I'd rather make the geolatte-geom a
>>> mandatory
>>> > > dependency than to have cryptic runtime failures.
>>> > >
>>> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>> > > > Hi,
>>> > > >
>>> > > > Since hibenrate-spatial has been merged into Hibernate code base,
>>> > > shouldn't
>>> > > > we merge the Dialects as well.
>>> > > > For instance, we have MySQL56InnoDBSpatialDialect which can simply
>>> be
>>> > > > merged into a MySQL56InnoDBDialect.
>>> > > > This way, MySQL57InnoDBDialect can take advantage of spatial
>>> queries as
>>> > > > well.
>>> > > >
>>> > > > The only drawback is that we need to add the geolatte-geom lib to
>>> > > > hibernate-orm.
>>> > > >
>>> > > > Let me know what you think.
>>> > > >
>>> > > > Vlad
>>> > > > _______________________________________________
>>> > > > hibernate-dev mailing list
>>> > > > 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
>>> > >
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > 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
>>>
>>
>>

From gunnar at hibernate.org  Tue Jun 28 10:37:09 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 28 Jun 2016 16:37:09 +0200
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CAFdSV9v0nQ22QLq-34BkfWD_+UHj1yuSEtonk9U4WM6v_5+G=A@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<CADGJaX8zk4OQYgy32G26deo90VLsne+fKMiH6daUH2q+CV1ktA@mail.gmail.com>
	<CAFdSV9t1fdpsBf3q-myi5rJJkWZ+RcDOhR95PFefhuUUnUUkOw@mail.gmail.com>
	<CAFdSV9v0nQ22QLq-34BkfWD_+UHj1yuSEtonk9U4WM6v_5+G=A@mail.gmail.com>
Message-ID: <CADGJaX-Ctf8xDRFm1yQSO=FUNC8E4PmAK2qE7RcK1Scj4WD-xg@mail.gmail.com>

Hi Steve,

Yes, assuming ValueExtractor/ValueBinder are going to be sufficiently
generified (i.e. no usage of java.sql.* types such as ResultSet,
PreparedStatement etc. in the method signatures), it might fly for OGM, too.

No idea though how feasible that'd be. Once you have some sort of PoC, we
should try it out very quickly with OGM (i.e. implement the new contracts
for a handful of types) so to see whether that's the right path or not.
Having one generic facade for SQL and OGM's needs would be great. But it
might be asking too much, I am really not sure.

Some more thoughts on the wiki (great write-up btw., that's much
appreciated):

* Type#sqlTypes() would be an issue for OGM
* BasicType#getSqlTypeDescriptor(), too; Or would you expect us to provide
a NoSqlBasicTypeDescriptor contract here? I.e. is BasicType meant as a
generic contract across SQL/NoSQL backends or just specific for SQL?
* I like the proposal of not passing in Mapping to getColumnMapping() et al.

--Gunnar



2016-06-28 15:24 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Ok, I need to move forward on this and I have gotten enough affirmative
> feedback to ahead.
>
> On Fri, Jun 24, 2016 at 6:24 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> This is all part of the to-be-decided read/write part of the new Type
>> contract.  I propose, as discussed in the wiki, that we have Type return
>> ValueExtractor and ValueBinder for read/write.  So assuming that is there...
>>
>> One possible answer to your story is that OGM as a SQM interpreter and
>> Metamodel (persisters, etc) implementor would influence the Type and
>> therefore the ValueExtractor and ValueBinder.  We'd just need to define the
>> right generic API to allow that to happen without ORM, e.g., having to jump
>> through a bunch of hoops to get to JDBC objects.
>>
>> On Fri, Jun 24, 2016 at 5:18 PM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> Steve,
>>>
>>> I still need to look at the wiki page and will give more detailed
>>> feedback on some parts of it.
>>>
>>> One general thing coming to mind though is how support for OGM could be
>>> improved. On first thought I'd say the "Java side" of Type might stay as
>>> is, but the "SQL side" (or "datastore side") and read/write logic
>>> interacting with result sets etc. would have to look differently in the
>>> case of OGM.
>>>
>>> If this part of the story could be made pluggable somehow, than a custom
>>> factory of sorts in OGM could plug in its dedicated implementation of the
>>> "datastore side". Not sure how it'd look in practice, the implementations
>>> would be rather different (we don't work with ResultSet at all in OGM), so
>>> I suppose it might require casting to the expected subtype when working
>>> with Type in ORM or OGM.
>>>
>>> Currently, we completely override the Type hierarchy from ORM with a
>>> corresponding GridType hierarchy in OGM, but it might be possible to re-use
>>> many more code by just customizing the "datastore side". Plus, it'd be a
>>> tad more efficient for OGM, as we can skip the translation from Type to
>>> GridType.
>>>
>>> I might provide some more details once having studied the current
>>> proposal in more depth, just wanted to get out these thoughts to you.
>>>
>>> --Gunnar
>>>
>>>
>>>
>>>
>>> 2016-06-22 18:54 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> I started a wiki discussing the proposal for the type system redesign.
>>>> Let's get discussions about it starter sooner rather than later.
>>>> Thanks!
>>>>
>>>> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>

From steve at hibernate.org  Tue Jun 28 11:19:15 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Jun 2016 15:19:15 +0000
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CADEPDB=kcZWzEGe473jKQBsKDM0U5_xSuZC04E0g1juWM9P=mg@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
	<CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
	<CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>
	<CADGJaX-TMYaLMdQQAoxrHXdVGiaaib+15S71v8Jx3__2_msRfQ@mail.gmail.com>
	<CAFdSV9t7yY7_GcD29DU8-kKGwHXE+uYoXsLw0+Yo2jQBdRWcAQ@mail.gmail.com>
	<CADEPDB=kcZWzEGe473jKQBsKDM0U5_xSuZC04E0g1juWM9P=mg@mail.gmail.com>
Message-ID: <CAFdSV9tn3Jbk0J4wg0LZ52EQ5zkqmFWHnTKYGbJOw01Y8L5gug@mail.gmail.com>

Thanks for the clarification.

However, all told I am not sure what you are suggesting.  Are you
suggesting that we somehow make Dialect itself expandable/mutable and
hibernate-spatial hook into that to expand mutate the ORM Dialect?

If it is just augmenting Types and SQLFunctions we already have
capabilities for this that I'd rather leverage:

   - For Types, hibernate-spatial would just provide a TypeContributor and
   based on the ORM Dialect it could contribute the needed Types.
   - We do not currently have a clean way to "contribute SQLFunctions" from
   an integration.  But if we are making changes anyway, I'd rather do this -
   adding a SqlFunctionContributor

If spatial dialects are really *only* used to contribute Types and
SQLFunctions,
the above options would remove the need for having spatial dialects at all
and still allow hibernate-spatial to contribute its things.

WDYT?


On Tue, Jun 28, 2016 at 9:18 AM Karel Maesen <karel at geovise.com> wrote:

> @Steve, besides Types a number of spatial Functions are registered for use
> in queries.
>
> The Dialect#contributetypes method is currently already used by
> Hibernate-spatial to inject to correct Types (with the correct
> SqlTypeDescriptors) for the SpatialDialect.
>
> On Tue, Jun 28, 2016 at 3:40 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I agree.  I think keeping these separate makes the most sense.
>>
>> @Karel, we already have that capability wrt Types (see
>> Dialect#contributeTypes).  What else would get injected?
>>
>> On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> One thing to keep in mind is that the module system of Java 9 ("Jigsaw")
>>> doesn't support a notion of optional module dependences.
>>>
>>> So if this is meant to remain an "optional feature" (i.e. Geo-specific
>>> libraries are not required at runtime when not using the spatial stuff), it
>>> should remain a separate artifact - this is, should we plan to make
>>> Hibernate ORM JARs Jigsaw modules at some point.
>>>
>>> --Gunnar
>>>
>>>
>>> 2016-06-28 15:22 GMT+02:00 Karel Maesen <karel at geovise.com>:
>>>
>>>> It makes sense for some Dialects such as those for MySQL and MS SQL
>>>> Server.
>>>> Less so for Postgresql and Oracle Spatial because here the spatial
>>>> capabilities need to be installed and configured separately (and even
>>>> have
>>>> versioning separate from the main database engine).
>>>>
>>>> I would favour an approach, close to what Sanne is suggesting, where the
>>>> spatial capability (Incl. Types) is injected into the Dialect during
>>>> Dialect construction based on some explicit configuration. In that way
>>>> the
>>>> relation between Dialect and the spatial capability mirrors the relation
>>>> between database engine and spatial capability (if any).
>>>>
>>>> Regards,
>>>>
>>>> Karel
>>>>
>>>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
>>>> able to resume the exchange before July 20.
>>>>
>>>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>> > They have not been "merged" in the same way we merged
>>>> > hibernate-entitymanager into hibernate-core.    So at the moment using
>>>> > hibernate-core e.g. does not require geolatte to be present.
>>>> geolatte is
>>>> > only required if using hibernate-spatial (isolated transitive dep).
>>>> >
>>>> > Karel, what are your thoughts on this?  I am not a fan of making
>>>> geolatte
>>>> > optional/provided, but if we all deem that folding hibernate-spatial
>>>> into
>>>> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
>>>> desirable
>>>> > then I will accept that
>>>> >
>>>> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org>
>>>> wrote:
>>>> >
>>>> > > Nice idea!
>>>> > >
>>>> > > since the modules were merged already, don't we already require
>>>> > > geolatte-geom ?
>>>> > > I guess some code might be intentionally designed to fail gracefully
>>>> > > about this library being there or not, but we'd need to make sure
>>>> that
>>>> > > can be tested for it to be maintainable.
>>>> > >
>>>> > > My preference would be to have:
>>>> > >  - All Dialects automatically provide the spatial extensions if the
>>>> > > needed dependencies are in place: we could automatically alias them
>>>> > > based on this?
>>>> > >  - a good error message naming the missing dependencies explicitly
>>>> > > when someone attempts to use such a Spatial extensions, but the
>>>> > > feature was not enabled by our automatic logic.
>>>> > >  - be able to test for these.
>>>> > >
>>>> > > In practice I believe this means we should still have it as an
>>>> > > independent source module, compile and test it as an independent
>>>> > > module, and only bundle within the ORM main jar as final
>>>> distribution
>>>> > > step.
>>>> > >
>>>> > > If that's too much work, I'd rather make the geolatte-geom a
>>>> mandatory
>>>> > > dependency than to have cryptic runtime failures.
>>>> > >
>>>> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>> wrote:
>>>> > > > Hi,
>>>> > > >
>>>> > > > Since hibenrate-spatial has been merged into Hibernate code base,
>>>> > > shouldn't
>>>> > > > we merge the Dialects as well.
>>>> > > > For instance, we have MySQL56InnoDBSpatialDialect which can
>>>> simply be
>>>> > > > merged into a MySQL56InnoDBDialect.
>>>> > > > This way, MySQL57InnoDBDialect can take advantage of spatial
>>>> queries as
>>>> > > > well.
>>>> > > >
>>>> > > > The only drawback is that we need to add the geolatte-geom lib to
>>>> > > > hibernate-orm.
>>>> > > >
>>>> > > > Let me know what you think.
>>>> > > >
>>>> > > > Vlad
>>>> > > > _______________________________________________
>>>> > > > hibernate-dev mailing list
>>>> > > > 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
>>>> > >
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > 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
>>>>
>>>
>>>
>

From steve at hibernate.org  Tue Jun 28 11:38:15 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Jun 2016 15:38:15 +0000
Subject: [hibernate-dev] 6.0 - Type redesign
In-Reply-To: <CADGJaX-Ctf8xDRFm1yQSO=FUNC8E4PmAK2qE7RcK1Scj4WD-xg@mail.gmail.com>
References: <CAFdSV9sSM7cCCd0TTYi-oxNgQxrym-rgxOK_VeA+Q-BzaN06fA@mail.gmail.com>
	<CADGJaX8zk4OQYgy32G26deo90VLsne+fKMiH6daUH2q+CV1ktA@mail.gmail.com>
	<CAFdSV9t1fdpsBf3q-myi5rJJkWZ+RcDOhR95PFefhuUUnUUkOw@mail.gmail.com>
	<CAFdSV9v0nQ22QLq-34BkfWD_+UHj1yuSEtonk9U4WM6v_5+G=A@mail.gmail.com>
	<CADGJaX-Ctf8xDRFm1yQSO=FUNC8E4PmAK2qE7RcK1Scj4WD-xg@mail.gmail.com>
Message-ID: <CAFdSV9tTcKY7dS0mXH5uaAqTLwN4KjEsjatPEkPP_dY8aGnB9g@mail.gmail.com>

Abstraction from JDBC is not my primary concern atm tbh.  I think
ValueExtractor/ValueBinder
*could* be made to work in a way that is datastore agnostic (not JDBC
dependent).

Like I said, I am not a fan of `int[] Type#sqlTypes`.  I think that ought
to be `SqlTypeDescriptor[] Type#getSqlTypeDescriptors`

Aside from SqlTypeDescriptor#getSqlType, SqlTypeDescriptor is not meant to
be SQL/JDBC-specific.  And even #getSqlType is really just meant as a
"key", a way to easily identify a particular SqlTypeDescriptor.



On Tue, Jun 28, 2016 at 9:37 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Steve,
>
> Yes, assuming ValueExtractor/ValueBinder are going to be sufficiently
> generified (i.e. no usage of java.sql.* types such as ResultSet,
> PreparedStatement etc. in the method signatures), it might fly for OGM, too.
>
> No idea though how feasible that'd be. Once you have some sort of PoC, we
> should try it out very quickly with OGM (i.e. implement the new contracts
> for a handful of types) so to see whether that's the right path or not.
> Having one generic facade for SQL and OGM's needs would be great. But it
> might be asking too much, I am really not sure.
>
> Some more thoughts on the wiki (great write-up btw., that's much
> appreciated):
>
> * Type#sqlTypes() would be an issue for OGM
> * BasicType#getSqlTypeDescriptor(), too; Or would you expect us to provide
> a NoSqlBasicTypeDescriptor contract here? I.e. is BasicType meant as a
> generic contract across SQL/NoSQL backends or just specific for SQL?
> * I like the proposal of not passing in Mapping to getColumnMapping() et
> al.
>
> --Gunnar
>
>
>
> 2016-06-28 15:24 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Ok, I need to move forward on this and I have gotten enough affirmative
>> feedback to ahead.
>>
>> On Fri, Jun 24, 2016 at 6:24 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> This is all part of the to-be-decided read/write part of the new Type
>>> contract.  I propose, as discussed in the wiki, that we have Type return
>>> ValueExtractor and ValueBinder for read/write.  So assuming that is there...
>>>
>>> One possible answer to your story is that OGM as a SQM interpreter and
>>> Metamodel (persisters, etc) implementor would influence the Type and
>>> therefore the ValueExtractor and ValueBinder.  We'd just need to define the
>>> right generic API to allow that to happen without ORM, e.g., having to jump
>>> through a bunch of hoops to get to JDBC objects.
>>>
>>> On Fri, Jun 24, 2016 at 5:18 PM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> Steve,
>>>>
>>>> I still need to look at the wiki page and will give more detailed
>>>> feedback on some parts of it.
>>>>
>>>> One general thing coming to mind though is how support for OGM could be
>>>> improved. On first thought I'd say the "Java side" of Type might stay as
>>>> is, but the "SQL side" (or "datastore side") and read/write logic
>>>> interacting with result sets etc. would have to look differently in the
>>>> case of OGM.
>>>>
>>>> If this part of the story could be made pluggable somehow, than a
>>>> custom factory of sorts in OGM could plug in its dedicated implementation
>>>> of the "datastore side". Not sure how it'd look in practice, the
>>>> implementations would be rather different (we don't work with ResultSet at
>>>> all in OGM), so I suppose it might require casting to the expected subtype
>>>> when working with Type in ORM or OGM.
>>>>
>>>> Currently, we completely override the Type hierarchy from ORM with a
>>>> corresponding GridType hierarchy in OGM, but it might be possible to re-use
>>>> many more code by just customizing the "datastore side". Plus, it'd be a
>>>> tad more efficient for OGM, as we can skip the translation from Type to
>>>> GridType.
>>>>
>>>> I might provide some more details once having studied the current
>>>> proposal in more depth, just wanted to get out these thoughts to you.
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>>>
>>>> 2016-06-22 18:54 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> I started a wiki discussing the proposal for the type system redesign.
>>>>> Let's get discussions about it starter sooner rather than later.
>>>>> Thanks!
>>>>>
>>>>> https://github.com/hibernate/hibernate-orm/wiki/6.0---Type-redesign
>>>>>
>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>

From karel at geovise.com  Tue Jun 28 12:02:51 2016
From: karel at geovise.com (Karel Maesen)
Date: Tue, 28 Jun 2016 18:02:51 +0200
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CAFdSV9tn3Jbk0J4wg0LZ52EQ5zkqmFWHnTKYGbJOw01Y8L5gug@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
	<CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
	<CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>
	<CADGJaX-TMYaLMdQQAoxrHXdVGiaaib+15S71v8Jx3__2_msRfQ@mail.gmail.com>
	<CAFdSV9t7yY7_GcD29DU8-kKGwHXE+uYoXsLw0+Yo2jQBdRWcAQ@mail.gmail.com>
	<CADEPDB=kcZWzEGe473jKQBsKDM0U5_xSuZC04E0g1juWM9P=mg@mail.gmail.com>
	<CAFdSV9tn3Jbk0J4wg0LZ52EQ5zkqmFWHnTKYGbJOw01Y8L5gug@mail.gmail.com>
Message-ID: <CADEPDBmRJP8MZRa3Vrf5HQ26e7nCzp_wWEv5SgXOvcYMNFoSOg@mail.gmail.com>

Yes, a SqlFunctionContributor would solve the problem of registering
spatial functions. Then the only thing left are the methods defined in the
SpatialDialect interface. These are helper methods for use in Criterion
implementations (to generate the correct SQL syntax). I think these methods
can be refactored to a separate Service (SpatialQuerySupportService). In
that case, yes we can remove the spatial dialects altogether.

When I'm back from holiday, I will attempt refactoring the methods in
SpatialDialect to a Service. If you then provide a SqlFunctionContributor
we can start with the work of removing spatial dialects.


On Tue, Jun 28, 2016 at 5:19 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Thanks for the clarification.
>
> However, all told I am not sure what you are suggesting.  Are you
> suggesting that we somehow make Dialect itself expandable/mutable and
> hibernate-spatial hook into that to expand mutate the ORM Dialect?
>
> If it is just augmenting Types and SQLFunctions we already have
> capabilities for this that I'd rather leverage:
>
>    - For Types, hibernate-spatial would just provide a TypeContributor
>    and based on the ORM Dialect it could contribute the needed Types.
>    - We do not currently have a clean way to "contribute SQLFunctions"
>    from an integration.  But if we are making changes anyway, I'd rather do
>    this - adding a SqlFunctionContributor
>
> If spatial dialects are really *only* used to contribute Types and SQLFunctions,
> the above options would remove the need for having spatial dialects at all
> and still allow hibernate-spatial to contribute its things.
>
> WDYT?
>
>
> On Tue, Jun 28, 2016 at 9:18 AM Karel Maesen <karel at geovise.com> wrote:
>
>> @Steve, besides Types a number of spatial Functions are registered for
>> use in queries.
>>
>> The Dialect#contributetypes method is currently already used by
>> Hibernate-spatial to inject to correct Types (with the correct
>> SqlTypeDescriptors) for the SpatialDialect.
>>
>> On Tue, Jun 28, 2016 at 3:40 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> I agree.  I think keeping these separate makes the most sense.
>>>
>>> @Karel, we already have that capability wrt Types (see
>>> Dialect#contributeTypes).  What else would get injected?
>>>
>>> On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> One thing to keep in mind is that the module system of Java 9
>>>> ("Jigsaw") doesn't support a notion of optional module dependences.
>>>>
>>>> So if this is meant to remain an "optional feature" (i.e. Geo-specific
>>>> libraries are not required at runtime when not using the spatial stuff), it
>>>> should remain a separate artifact - this is, should we plan to make
>>>> Hibernate ORM JARs Jigsaw modules at some point.
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>> 2016-06-28 15:22 GMT+02:00 Karel Maesen <karel at geovise.com>:
>>>>
>>>>> It makes sense for some Dialects such as those for MySQL and MS SQL
>>>>> Server.
>>>>> Less so for Postgresql and Oracle Spatial because here the spatial
>>>>> capabilities need to be installed and configured separately (and even
>>>>> have
>>>>> versioning separate from the main database engine).
>>>>>
>>>>> I would favour an approach, close to what Sanne is suggesting, where
>>>>> the
>>>>> spatial capability (Incl. Types) is injected into the Dialect during
>>>>> Dialect construction based on some explicit configuration. In that way
>>>>> the
>>>>> relation between Dialect and the spatial capability mirrors the
>>>>> relation
>>>>> between database engine and spatial capability (if any).
>>>>>
>>>>> Regards,
>>>>>
>>>>> Karel
>>>>>
>>>>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
>>>>> able to resume the exchange before July 20.
>>>>>
>>>>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>> > They have not been "merged" in the same way we merged
>>>>> > hibernate-entitymanager into hibernate-core.    So at the moment
>>>>> using
>>>>> > hibernate-core e.g. does not require geolatte to be present.
>>>>> geolatte is
>>>>> > only required if using hibernate-spatial (isolated transitive dep).
>>>>> >
>>>>> > Karel, what are your thoughts on this?  I am not a fan of making
>>>>> geolatte
>>>>> > optional/provided, but if we all deem that folding hibernate-spatial
>>>>> into
>>>>> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
>>>>> desirable
>>>>> > then I will accept that
>>>>> >
>>>>> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org>
>>>>> wrote:
>>>>> >
>>>>> > > Nice idea!
>>>>> > >
>>>>> > > since the modules were merged already, don't we already require
>>>>> > > geolatte-geom ?
>>>>> > > I guess some code might be intentionally designed to fail
>>>>> gracefully
>>>>> > > about this library being there or not, but we'd need to make sure
>>>>> that
>>>>> > > can be tested for it to be maintainable.
>>>>> > >
>>>>> > > My preference would be to have:
>>>>> > >  - All Dialects automatically provide the spatial extensions if the
>>>>> > > needed dependencies are in place: we could automatically alias them
>>>>> > > based on this?
>>>>> > >  - a good error message naming the missing dependencies explicitly
>>>>> > > when someone attempts to use such a Spatial extensions, but the
>>>>> > > feature was not enabled by our automatic logic.
>>>>> > >  - be able to test for these.
>>>>> > >
>>>>> > > In practice I believe this means we should still have it as an
>>>>> > > independent source module, compile and test it as an independent
>>>>> > > module, and only bundle within the ORM main jar as final
>>>>> distribution
>>>>> > > step.
>>>>> > >
>>>>> > > If that's too much work, I'd rather make the geolatte-geom a
>>>>> mandatory
>>>>> > > dependency than to have cryptic runtime failures.
>>>>> > >
>>>>> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>>> wrote:
>>>>> > > > Hi,
>>>>> > > >
>>>>> > > > Since hibenrate-spatial has been merged into Hibernate code base,
>>>>> > > shouldn't
>>>>> > > > we merge the Dialects as well.
>>>>> > > > For instance, we have MySQL56InnoDBSpatialDialect which can
>>>>> simply be
>>>>> > > > merged into a MySQL56InnoDBDialect.
>>>>> > > > This way, MySQL57InnoDBDialect can take advantage of spatial
>>>>> queries as
>>>>> > > > well.
>>>>> > > >
>>>>> > > > The only drawback is that we need to add the geolatte-geom lib to
>>>>> > > > hibernate-orm.
>>>>> > > >
>>>>> > > > Let me know what you think.
>>>>> > > >
>>>>> > > > Vlad
>>>>> > > > _______________________________________________
>>>>> > > > hibernate-dev mailing list
>>>>> > > > 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
>>>>> > >
>>>>> > _______________________________________________
>>>>> > hibernate-dev mailing list
>>>>> > 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
>>>>>
>>>>
>>>>
>>

From steve at hibernate.org  Tue Jun 28 13:43:15 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Jun 2016 17:43:15 +0000
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CADEPDBmRJP8MZRa3Vrf5HQ26e7nCzp_wWEv5SgXOvcYMNFoSOg@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
	<CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
	<CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>
	<CADGJaX-TMYaLMdQQAoxrHXdVGiaaib+15S71v8Jx3__2_msRfQ@mail.gmail.com>
	<CAFdSV9t7yY7_GcD29DU8-kKGwHXE+uYoXsLw0+Yo2jQBdRWcAQ@mail.gmail.com>
	<CADEPDB=kcZWzEGe473jKQBsKDM0U5_xSuZC04E0g1juWM9P=mg@mail.gmail.com>
	<CAFdSV9tn3Jbk0J4wg0LZ52EQ5zkqmFWHnTKYGbJOw01Y8L5gug@mail.gmail.com>
	<CADEPDBmRJP8MZRa3Vrf5HQ26e7nCzp_wWEv5SgXOvcYMNFoSOg@mail.gmail.com>
Message-ID: <CAFdSV9tbDozhF=U_kgUpbLBT2m+XsWy1KW1wKw_PutsaJdc18w@mail.gmail.com>

I just created HHH-10901 for that.

So we'd still have the question of merging hibernate-spatial into
hibernate-core.  Personally I am against that for the dependencies.

On Tue, Jun 28, 2016, 11:02 AM Karel Maesen <karel at geovise.com> wrote:

> Yes, a SqlFunctionContributor would solve the problem of registering
> spatial functions. Then the only thing left are the methods defined in the
> SpatialDialect interface. These are helper methods for use in Criterion
> implementations (to generate the correct SQL syntax). I think these methods
> can be refactored to a separate Service (SpatialQuerySupportService). In
> that case, yes we can remove the spatial dialects altogether.
>
> When I'm back from holiday, I will attempt refactoring the methods in
> SpatialDialect to a Service. If you then provide a SqlFunctionContributor
> we can start with the work of removing spatial dialects.
>
>
> On Tue, Jun 28, 2016 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Thanks for the clarification.
>>
>> However, all told I am not sure what you are suggesting.  Are you
>> suggesting that we somehow make Dialect itself expandable/mutable and
>> hibernate-spatial hook into that to expand mutate the ORM Dialect?
>>
>> If it is just augmenting Types and SQLFunctions we already have
>> capabilities for this that I'd rather leverage:
>>
>>    - For Types, hibernate-spatial would just provide a TypeContributor
>>    and based on the ORM Dialect it could contribute the needed Types.
>>    - We do not currently have a clean way to "contribute SQLFunctions"
>>    from an integration.  But if we are making changes anyway, I'd rather do
>>    this - adding a SqlFunctionContributor
>>
>> If spatial dialects are really *only* used to contribute Types and SQLFunctions,
>> the above options would remove the need for having spatial dialects at all
>> and still allow hibernate-spatial to contribute its things.
>>
>> WDYT?
>>
>>
>> On Tue, Jun 28, 2016 at 9:18 AM Karel Maesen <karel at geovise.com> wrote:
>>
>>> @Steve, besides Types a number of spatial Functions are registered for
>>> use in queries.
>>>
>>> The Dialect#contributetypes method is currently already used by
>>> Hibernate-spatial to inject to correct Types (with the correct
>>> SqlTypeDescriptors) for the SpatialDialect.
>>>
>>> On Tue, Jun 28, 2016 at 3:40 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> I agree.  I think keeping these separate makes the most sense.
>>>>
>>>> @Karel, we already have that capability wrt Types (see
>>>> Dialect#contributeTypes).  What else would get injected?
>>>>
>>>> On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling <gunnar at hibernate.org>
>>>> wrote:
>>>>
>>>>> One thing to keep in mind is that the module system of Java 9
>>>>> ("Jigsaw") doesn't support a notion of optional module dependences.
>>>>>
>>>>> So if this is meant to remain an "optional feature" (i.e. Geo-specific
>>>>> libraries are not required at runtime when not using the spatial stuff), it
>>>>> should remain a separate artifact - this is, should we plan to make
>>>>> Hibernate ORM JARs Jigsaw modules at some point.
>>>>>
>>>>> --Gunnar
>>>>>
>>>>>
>>>>> 2016-06-28 15:22 GMT+02:00 Karel Maesen <karel at geovise.com>:
>>>>>
>>>>>> It makes sense for some Dialects such as those for MySQL and MS SQL
>>>>>> Server.
>>>>>> Less so for Postgresql and Oracle Spatial because here the spatial
>>>>>> capabilities need to be installed and configured separately (and even
>>>>>> have
>>>>>> versioning separate from the main database engine).
>>>>>>
>>>>>> I would favour an approach, close to what Sanne is suggesting, where
>>>>>> the
>>>>>> spatial capability (Incl. Types) is injected into the Dialect during
>>>>>> Dialect construction based on some explicit configuration. In that
>>>>>> way the
>>>>>> relation between Dialect and the spatial capability mirrors the
>>>>>> relation
>>>>>> between database engine and spatial capability (if any).
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Karel
>>>>>>
>>>>>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't
>>>>>> be
>>>>>> able to resume the exchange before July 20.
>>>>>>
>>>>>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>> > They have not been "merged" in the same way we merged
>>>>>> > hibernate-entitymanager into hibernate-core.    So at the moment
>>>>>> using
>>>>>> > hibernate-core e.g. does not require geolatte to be present.
>>>>>> geolatte is
>>>>>> > only required if using hibernate-spatial (isolated transitive dep).
>>>>>> >
>>>>>> > Karel, what are your thoughts on this?  I am not a fan of making
>>>>>> geolatte
>>>>>> > optional/provided, but if we all deem that folding
>>>>>> hibernate-spatial into
>>>>>> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
>>>>>> desirable
>>>>>> > then I will accept that
>>>>>> >
>>>>>> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org>
>>>>>> wrote:
>>>>>> >
>>>>>> > > Nice idea!
>>>>>> > >
>>>>>> > > since the modules were merged already, don't we already require
>>>>>> > > geolatte-geom ?
>>>>>> > > I guess some code might be intentionally designed to fail
>>>>>> gracefully
>>>>>> > > about this library being there or not, but we'd need to make sure
>>>>>> that
>>>>>> > > can be tested for it to be maintainable.
>>>>>> > >
>>>>>> > > My preference would be to have:
>>>>>> > >  - All Dialects automatically provide the spatial extensions if
>>>>>> the
>>>>>> > > needed dependencies are in place: we could automatically alias
>>>>>> them
>>>>>> > > based on this?
>>>>>> > >  - a good error message naming the missing dependencies explicitly
>>>>>> > > when someone attempts to use such a Spatial extensions, but the
>>>>>> > > feature was not enabled by our automatic logic.
>>>>>> > >  - be able to test for these.
>>>>>> > >
>>>>>> > > In practice I believe this means we should still have it as an
>>>>>> > > independent source module, compile and test it as an independent
>>>>>> > > module, and only bundle within the ORM main jar as final
>>>>>> distribution
>>>>>> > > step.
>>>>>> > >
>>>>>> > > If that's too much work, I'd rather make the geolatte-geom a
>>>>>> mandatory
>>>>>> > > dependency than to have cryptic runtime failures.
>>>>>> > >
>>>>>> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>>>> wrote:
>>>>>> > > > Hi,
>>>>>> > > >
>>>>>> > > > Since hibenrate-spatial has been merged into Hibernate code
>>>>>> base,
>>>>>> > > shouldn't
>>>>>> > > > we merge the Dialects as well.
>>>>>> > > > For instance, we have MySQL56InnoDBSpatialDialect which can
>>>>>> simply be
>>>>>> > > > merged into a MySQL56InnoDBDialect.
>>>>>> > > > This way, MySQL57InnoDBDialect can take advantage of spatial
>>>>>> queries as
>>>>>> > > > well.
>>>>>> > > >
>>>>>> > > > The only drawback is that we need to add the geolatte-geom lib
>>>>>> to
>>>>>> > > > hibernate-orm.
>>>>>> > > >
>>>>>> > > > Let me know what you think.
>>>>>> > > >
>>>>>> > > > Vlad
>>>>>> > > > _______________________________________________
>>>>>> > > > hibernate-dev mailing list
>>>>>> > > > 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
>>>>>> > >
>>>>>> > _______________________________________________
>>>>>> > hibernate-dev mailing list
>>>>>> > 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
>>>>>>
>>>>>
>>>>>
>>>
>

From sanne at hibernate.org  Tue Jun 28 16:07:23 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 28 Jun 2016 21:07:23 +0100
Subject: [hibernate-dev] Merging hibernate spatial Dialects with the
	core ones
In-Reply-To: <CAFdSV9tbDozhF=U_kgUpbLBT2m+XsWy1KW1wKw_PutsaJdc18w@mail.gmail.com>
References: <CA+gWKMBdGTUDYQ_1HcWk=LBT16AKwm_if0CNd4v6YPGQOA7BYg@mail.gmail.com>
	<CAFm4XO3L85ebPebzJy59Xpt_bn6DzVugS5vSZmhsWfNz4TUmvg@mail.gmail.com>
	<CAFdSV9tGHwhgL9WA1izH+Mx-NRLMBhBWCDSh33yf2cdF9LYSfw@mail.gmail.com>
	<CADEPDBkg9F8GDXPyB6QZzS1NKk+M-QO+6xxPrrjp+t_cXHFG7Q@mail.gmail.com>
	<CADGJaX-TMYaLMdQQAoxrHXdVGiaaib+15S71v8Jx3__2_msRfQ@mail.gmail.com>
	<CAFdSV9t7yY7_GcD29DU8-kKGwHXE+uYoXsLw0+Yo2jQBdRWcAQ@mail.gmail.com>
	<CADEPDB=kcZWzEGe473jKQBsKDM0U5_xSuZC04E0g1juWM9P=mg@mail.gmail.com>
	<CAFdSV9tn3Jbk0J4wg0LZ52EQ5zkqmFWHnTKYGbJOw01Y8L5gug@mail.gmail.com>
	<CADEPDBmRJP8MZRa3Vrf5HQ26e7nCzp_wWEv5SgXOvcYMNFoSOg@mail.gmail.com>
	<CAFdSV9tbDozhF=U_kgUpbLBT2m+XsWy1KW1wKw_PutsaJdc18w@mail.gmail.com>
Message-ID: <CAFm4XO1DMwxNahiCppHCzTK1UZtjkP1BYUfGGU5H-5F0caX0BQ@mail.gmail.com>

On 28 June 2016 at 18:43, Steve Ebersole <steve at hibernate.org> wrote:
> I just created HHH-10901 for that.
>
> So we'd still have the question of merging hibernate-spatial into
> hibernate-core.  Personally I am against that for the dependencies.

+1
I agree, my previous comment was mislead as I thought it was merged
already, I didn't mean to suggest merging it.
Better keep them separated.


>
> On Tue, Jun 28, 2016, 11:02 AM Karel Maesen <karel at geovise.com> wrote:
>
>> Yes, a SqlFunctionContributor would solve the problem of registering
>> spatial functions. Then the only thing left are the methods defined in the
>> SpatialDialect interface. These are helper methods for use in Criterion
>> implementations (to generate the correct SQL syntax). I think these methods
>> can be refactored to a separate Service (SpatialQuerySupportService). In
>> that case, yes we can remove the spatial dialects altogether.
>>
>> When I'm back from holiday, I will attempt refactoring the methods in
>> SpatialDialect to a Service. If you then provide a SqlFunctionContributor
>> we can start with the work of removing spatial dialects.
>>
>>
>> On Tue, Jun 28, 2016 at 5:19 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Thanks for the clarification.
>>>
>>> However, all told I am not sure what you are suggesting.  Are you
>>> suggesting that we somehow make Dialect itself expandable/mutable and
>>> hibernate-spatial hook into that to expand mutate the ORM Dialect?
>>>
>>> If it is just augmenting Types and SQLFunctions we already have
>>> capabilities for this that I'd rather leverage:
>>>
>>>    - For Types, hibernate-spatial would just provide a TypeContributor
>>>    and based on the ORM Dialect it could contribute the needed Types.
>>>    - We do not currently have a clean way to "contribute SQLFunctions"
>>>    from an integration.  But if we are making changes anyway, I'd rather do
>>>    this - adding a SqlFunctionContributor
>>>
>>> If spatial dialects are really *only* used to contribute Types and SQLFunctions,
>>> the above options would remove the need for having spatial dialects at all
>>> and still allow hibernate-spatial to contribute its things.
>>>
>>> WDYT?
>>>
>>>
>>> On Tue, Jun 28, 2016 at 9:18 AM Karel Maesen <karel at geovise.com> wrote:
>>>
>>>> @Steve, besides Types a number of spatial Functions are registered for
>>>> use in queries.
>>>>
>>>> The Dialect#contributetypes method is currently already used by
>>>> Hibernate-spatial to inject to correct Types (with the correct
>>>> SqlTypeDescriptors) for the SpatialDialect.
>>>>
>>>> On Tue, Jun 28, 2016 at 3:40 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> I agree.  I think keeping these separate makes the most sense.
>>>>>
>>>>> @Karel, we already have that capability wrt Types (see
>>>>> Dialect#contributeTypes).  What else would get injected?
>>>>>
>>>>> On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling <gunnar at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> One thing to keep in mind is that the module system of Java 9
>>>>>> ("Jigsaw") doesn't support a notion of optional module dependences.
>>>>>>
>>>>>> So if this is meant to remain an "optional feature" (i.e. Geo-specific
>>>>>> libraries are not required at runtime when not using the spatial stuff), it
>>>>>> should remain a separate artifact - this is, should we plan to make
>>>>>> Hibernate ORM JARs Jigsaw modules at some point.
>>>>>>
>>>>>> --Gunnar
>>>>>>
>>>>>>
>>>>>> 2016-06-28 15:22 GMT+02:00 Karel Maesen <karel at geovise.com>:
>>>>>>
>>>>>>> It makes sense for some Dialects such as those for MySQL and MS SQL
>>>>>>> Server.
>>>>>>> Less so for Postgresql and Oracle Spatial because here the spatial
>>>>>>> capabilities need to be installed and configured separately (and even
>>>>>>> have
>>>>>>> versioning separate from the main database engine).
>>>>>>>
>>>>>>> I would favour an approach, close to what Sanne is suggesting, where
>>>>>>> the
>>>>>>> spatial capability (Incl. Types) is injected into the Dialect during
>>>>>>> Dialect construction based on some explicit configuration. In that
>>>>>>> way the
>>>>>>> relation between Dialect and the spatial capability mirrors the
>>>>>>> relation
>>>>>>> between database engine and spatial capability (if any).
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Karel
>>>>>>>
>>>>>>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't
>>>>>>> be
>>>>>>> able to resume the exchange before July 20.
>>>>>>>
>>>>>>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <steve at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > They have not been "merged" in the same way we merged
>>>>>>> > hibernate-entitymanager into hibernate-core.    So at the moment
>>>>>>> using
>>>>>>> > hibernate-core e.g. does not require geolatte to be present.
>>>>>>> geolatte is
>>>>>>> > only required if using hibernate-spatial (isolated transitive dep).
>>>>>>> >
>>>>>>> > Karel, what are your thoughts on this?  I am not a fan of making
>>>>>>> geolatte
>>>>>>> > optional/provided, but if we all deem that folding
>>>>>>> hibernate-spatial into
>>>>>>> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
>>>>>>> desirable
>>>>>>> > then I will accept that
>>>>>>> >
>>>>>>> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sanne at hibernate.org>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > > Nice idea!
>>>>>>> > >
>>>>>>> > > since the modules were merged already, don't we already require
>>>>>>> > > geolatte-geom ?
>>>>>>> > > I guess some code might be intentionally designed to fail
>>>>>>> gracefully
>>>>>>> > > about this library being there or not, but we'd need to make sure
>>>>>>> that
>>>>>>> > > can be tested for it to be maintainable.
>>>>>>> > >
>>>>>>> > > My preference would be to have:
>>>>>>> > >  - All Dialects automatically provide the spatial extensions if
>>>>>>> the
>>>>>>> > > needed dependencies are in place: we could automatically alias
>>>>>>> them
>>>>>>> > > based on this?
>>>>>>> > >  - a good error message naming the missing dependencies explicitly
>>>>>>> > > when someone attempts to use such a Spatial extensions, but the
>>>>>>> > > feature was not enabled by our automatic logic.
>>>>>>> > >  - be able to test for these.
>>>>>>> > >
>>>>>>> > > In practice I believe this means we should still have it as an
>>>>>>> > > independent source module, compile and test it as an independent
>>>>>>> > > module, and only bundle within the ORM main jar as final
>>>>>>> distribution
>>>>>>> > > step.
>>>>>>> > >
>>>>>>> > > If that's too much work, I'd rather make the geolatte-geom a
>>>>>>> mandatory
>>>>>>> > > dependency than to have cryptic runtime failures.
>>>>>>> > >
>>>>>>> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>>>>>> wrote:
>>>>>>> > > > Hi,
>>>>>>> > > >
>>>>>>> > > > Since hibenrate-spatial has been merged into Hibernate code
>>>>>>> base,
>>>>>>> > > shouldn't
>>>>>>> > > > we merge the Dialects as well.
>>>>>>> > > > For instance, we have MySQL56InnoDBSpatialDialect which can
>>>>>>> simply be
>>>>>>> > > > merged into a MySQL56InnoDBDialect.
>>>>>>> > > > This way, MySQL57InnoDBDialect can take advantage of spatial
>>>>>>> queries as
>>>>>>> > > > well.
>>>>>>> > > >
>>>>>>> > > > The only drawback is that we need to add the geolatte-geom lib
>>>>>>> to
>>>>>>> > > > hibernate-orm.
>>>>>>> > > >
>>>>>>> > > > Let me know what you think.
>>>>>>> > > >
>>>>>>> > > > Vlad
>>>>>>> > > > _______________________________________________
>>>>>>> > > > hibernate-dev mailing list
>>>>>>> > > > 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
>>>>>>> > >
>>>>>>> > _______________________________________________
>>>>>>> > hibernate-dev mailing list
>>>>>>> > 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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Wed Jun 29 04:14:26 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 29 Jun 2016 11:14:26 +0300
Subject: [hibernate-dev] Hibenrate-orm migration guides in one landing page
Message-ID: <CA+gWKMBjuN+5tRRHcZs=ZThySDez+tGQ3Digw8X+YLuiB7XXuA@mail.gmail.com>

Hi,

I've seen questions on our forum and SO related to migration from 3.x to
5.x,
and users are complaining that it's difficult to follow the migration
guides since they are scattered among hibernate.org and GitHub.

Emmanuel pointed out that in Hibernate Search we have a single migration
page:

http://hibernate.org/search/documentation/migrate/

I find this a very good idea, and I think we should follow the same trend.

So, I think we should have a new migration folder path under
hibernate-orm/documentation:

http://hibernate.org/orm/documentation/migrate/

The migration guides can still be written in Asciidoctor, as on GitHub, and
during release, we copy this folder to hibernate.org.

As for the hibernate.org landing page, we'll have to add a new link only
when we deploy a new version, which, even if we can't automate it, we can
do it after the release.

Let me know what you think?

Vlad

From emmanuel at hibernate.org  Wed Jun 29 09:48:51 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 29 Jun 2016 15:48:51 +0200
Subject: [hibernate-dev] Hibenrate-orm migration guides in one landing
	page
In-Reply-To: <CA+gWKMBjuN+5tRRHcZs=ZThySDez+tGQ3Digw8X+YLuiB7XXuA@mail.gmail.com>
References: <CA+gWKMBjuN+5tRRHcZs=ZThySDez+tGQ3Digw8X+YLuiB7XXuA@mail.gmail.com>
Message-ID: <F535B822-E5BE-4473-983E-87BBA83BE7F5@hibernate.org>

+1

> On 29 Jun 2016, at 10:14, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> 
> Hi,
> 
> I've seen questions on our forum and SO related to migration from 3.x to
> 5.x,
> and users are complaining that it's difficult to follow the migration
> guides since they are scattered among hibernate.org and GitHub.
> 
> Emmanuel pointed out that in Hibernate Search we have a single migration
> page:
> 
> http://hibernate.org/search/documentation/migrate/
> 
> I find this a very good idea, and I think we should follow the same trend.
> 
> So, I think we should have a new migration folder path under
> hibernate-orm/documentation:
> 
> http://hibernate.org/orm/documentation/migrate/
> 
> The migration guides can still be written in Asciidoctor, as on GitHub, and
> during release, we copy this folder to hibernate.org.
> 
> As for the hibernate.org landing page, we'll have to add a new link only
> when we deploy a new version, which, even if we can't automate it, we can
> do it after the release.
> 
> Let me know what you think?
> 
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From guillaume.smet at gmail.com  Wed Jun 29 09:50:18 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 29 Jun 2016 15:50:18 +0200
Subject: [hibernate-dev] Released: Hibernate Search 5.5.4.Final
Message-ID: <CALt0+o-9RgssK6qmwvPFdQb5EGK_Kt+Na-OT-EhTxTYjP5kXDQ@mail.gmail.com>

Hello everyone,

A maintenance release of our latest stable branch, version 5.5.4.Final
of Hibernate Search is now available, and is the suggested stable
version for everyone to use.

More details about the improvements can be found on our blog:
 - http://in.relation.to/2016/06/29/Polishing-Polishing-And-More-Polishing-Hibernate-Search-5-5-4-Final/

Have a nice day!

-- 
Guillaume

From steve at hibernate.org  Wed Jun 29 10:12:28 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Jun 2016 14:12:28 +0000
Subject: [hibernate-dev] Hibenrate-orm migration guides in one landing
	page
In-Reply-To: <CA+gWKMBjuN+5tRRHcZs=ZThySDez+tGQ3Digw8X+YLuiB7XXuA@mail.gmail.com>
References: <CA+gWKMBjuN+5tRRHcZs=ZThySDez+tGQ3Digw8X+YLuiB7XXuA@mail.gmail.com>
Message-ID: <CAFdSV9toLXg-Z822y--GFgLx1zrFkQw=4=_9qGj8M_QW+5NAZg@mail.gmail.com>

That is the intent of
https://github.com/hibernate/hibernate-orm/wiki/Migration-Guides.  We just
have to collect the other legacy guide links together there.

On Wed, Jun 29, 2016 at 3:14 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I've seen questions on our forum and SO related to migration from 3.x to
> 5.x,
> and users are complaining that it's difficult to follow the migration
> guides since they are scattered among hibernate.org and GitHub.
>
> Emmanuel pointed out that in Hibernate Search we have a single migration
> page:
>
> http://hibernate.org/search/documentation/migrate/
>
> I find this a very good idea, and I think we should follow the same trend.
>
> So, I think we should have a new migration folder path under
> hibernate-orm/documentation:
>
> http://hibernate.org/orm/documentation/migrate/
>
> The migration guides can still be written in Asciidoctor, as on GitHub, and
> during release, we copy this folder to hibernate.org.
>
> As for the hibernate.org landing page, we'll have to add a new link only
> when we deploy a new version, which, even if we can't automate it, we can
> do it after the release.
>
> Let me know what you think?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu Jun 30 01:07:29 2016
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 29 Jun 2016 22:07:29 -0700
Subject: [hibernate-dev] EnhancementContext and HHH-10801
Message-ID: <CAFDzhiSuvM7z7dinKUso3+XX3iBX+ZwtOzhGffzjY7KCbj7iaw@mail.gmail.com>

The fix for HHH-10801 added a method,
isMappedSuperclassClass(CtClass), to
org.hibernate.bytecode.enhance.spi.EnhancementContext.
[1]

Would an application implement EnhancementContext? I don't see anything
that would break, but I'd like to confirm before backporting HHH-10801 to
5.0 and 5.1.

Thanks,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/cdc69a475bb9f37a61e571950072eaf777086cae/hibernate-core/src/main/java/org/hibernate/bytecode/enhance/spi/EnhancementContext.java#L55

From gunnar at hibernate.org  Thu Jun 30 07:01:52 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 30 Jun 2016 13:01:52 +0200
Subject: [hibernate-dev] Non-final dependencies in hibernate-core.gradle
Message-ID: <CADGJaX-fYOLncM_GUoRBL6HPr4L8WCZYbsTqucHBohntkWqvYw@mail.gmail.com>

Hi,

I noticed that a preview release of CDI is specified as dependency for the
ORM core module: "javax.enterprise:cdi-api:1.1-PFD [1].

Is there a reason for using this specific one, or can we change it to the
Final (version "1.1")? Similarly for Weld
("org.jboss.weld:weld-core:2.0.0.Beta6") and EJB API
("org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:1.0.0.Alpha2").

I can send a patch to change it, just wanted to be sure it's nothing
intentional.

Thanks,

--Gunnar

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/hibernate-core.gradle#L68

From steve at hibernate.org  Thu Jun 30 09:02:03 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 30 Jun 2016 13:02:03 +0000
Subject: [hibernate-dev] Non-final dependencies in hibernate-core.gradle
In-Reply-To: <CADGJaX-fYOLncM_GUoRBL6HPr4L8WCZYbsTqucHBohntkWqvYw@mail.gmail.com>
References: <CADGJaX-fYOLncM_GUoRBL6HPr4L8WCZYbsTqucHBohntkWqvYw@mail.gmail.com>
Message-ID: <CAFdSV9tzZGDp_1s_zwpdbzH2b-UniP6YtwDZkPtWzmNscmrhNQ@mail.gmail.com>

That was just the latest when we updated those for JPA 2.1

On Thu, Jun 30, 2016 at 6:02 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> I noticed that a preview release of CDI is specified as dependency for the
> ORM core module: "javax.enterprise:cdi-api:1.1-PFD [1].
>
> Is there a reason for using this specific one, or can we change it to the
> Final (version "1.1")? Similarly for Weld
> ("org.jboss.weld:weld-core:2.0.0.Beta6") and EJB API
> ("org.jboss.spec.javax.ejb:jboss-ejb-api_3.2_spec:1.0.0.Alpha2").
>
> I can send a patch to change it, just wanted to be sure it's nothing
> intentional.
>
> Thanks,
>
> --Gunnar
>
> [1]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/hibernate-core.gradle#L68
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From andrea at hibernate.org  Thu Jun 30 12:14:07 2016
From: andrea at hibernate.org (andrea boriero)
Date: Thu, 30 Jun 2016 18:14:07 +0200
Subject: [hibernate-dev] Starting 5.2.1 release
Message-ID: <CAL00eST_vmUadGr3GvSGe-BZZ2og1=vhz94KAx=FkygzGY==7g@mail.gmail.com>

per $subject

From andrea at hibernate.org  Thu Jun 30 20:03:33 2016
From: andrea at hibernate.org (andrea boriero)
Date: Fri, 1 Jul 2016 02:03:33 +0200
Subject: [hibernate-dev] ORM 5.2.1.Final has been released
Message-ID: <CAL00eSTg2X4gbY9Dpep+iOkpuXSgaUjBTtMuvW7o=1UJj+abtg@mail.gmail.com>

Release is done, I'll announce tomorrow.