[hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deployment

[Scott Marlow]

Hello,

How would Hibernate ORM react to its persistence provider class instance 
being used with multiple application deployments?  Is there any "per 
application" state in the ORM persistence provider class instance?

A few different implementations of 
javax.persistence.spi.PersistenceProviderResolver.getPersistenceProviders() 
are not caching the returned PersistenceProvider class instances. [1] 
raised the issue with the WildFly 
PersistenceProviderResolver.getPersistenceProviders() not caching the 
provider class instances for reuse.

Same question for OGM, is there any "per application state" in the OGM 
persistence provider class?

Scott

[1] 
http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html 
is the thread which raised this as a performance issue.

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

Re: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deploy

[Scott Marlow]

Never mind, we will look at caching the PersistenceProvider class 
instance at the application deployment level (in WildFly).

On 09/12/2014 04:02 PM, Scott Marlow wrote:
> Hello,
>
> How would Hibernate ORM react to its persistence provider class instance
> being used with multiple application deployments?  Is there any "per
> application" state in the ORM persistence provider class instance?
>
> A few different implementations of
> javax.persistence.spi.PersistenceProviderResolver.getPersistenceProviders()
> are not caching the returned PersistenceProvider class instances. [1]
> raised the issue with the WildFly
> PersistenceProviderResolver.getPersistenceProviders() not caching the
> provider class instances for reuse.
>
> Same question for OGM, is there any "per application state" in the OGM
> persistence provider class?
>
> Scott
>
> [1]
> http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002984.html
> is the thread which raised this as a performance issue.
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

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

Re: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deploy

[Scott Marlow]

What triggers Hibernate Validator to call 
PersistenceProviderResolver.getPersistenceProviders()?  Does this happen 
during the call to 
PersistenceProvider.createContainerEntityManagerFactory() or later after 
application deployment completes?

I'm looking at changing 
PersistenceProviderResolver.getPersistenceProviders() to cache the 
results on a per deployment basis but need to know when the first call 
will be made, so I don't break deployment of persistence providers in 
the deployed application.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] DuplicateMappingException in ORM 4.3.6.Final

[Scott Marlow]

I'm working on an application server bug fix that I need some advice 
with, as Hibernate ORM 4.3.6.Final is throwing a 
"o.h.DuplicateMappingException: Duplicate query mapping 
EventManager.MyEvents" after I fixed a jar-file reference bug in WildFly 
(when I try to deploy a test case).

Prior to my jar-file bug fix, the jar-file URL was incorrectly pointing 
at the wrong location (zero files were returned when file url was 
accessed).  As a result, entities were loaded only once from the ear/lib 
jar.  Now, with my bug fix (getJarFileUrls now returns a valid URL for 
jar-file) , WildFly is getting the DuplicateMappingException because the 
entity is loaded twice (even though *exclude-unlisted-classes* is in the 
persistence unit).

I would like to resolve the DME before back porting the "jar-file" 
(WildFly) bug fix.  I didn't see this behaviour in my ORM 4.2.x testing 
(with EAP).

By the way, the getPersistenceUnitRootUrl is the test.ear.

test.ear contents:

lib
   test-entities.jar
META-INF
   application.xml
   MANIFEST.MF
   persistence.xml
test-ejb.jar

persistence.xml contents:

   
   lib/test-entities.jar
   
   

test-entities.jar contents:

META-INF
Event.hbm.xml

EventManager entity class
Event entity class

Event.hbm.xml contents:

   
   
 
 SELECT * FROM EVENT e where e.manager = ?
   

Thanks,
Scott

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

Re: [hibernate-dev] DuplicateMappingException in ORM 4.3.6.Final

[Scott Marlow]

If the cause is allowing the application to deploy with the persistence unit 
root being the entire EAR, I am interested in feedback on what to do.  e.g. 
throw a deployment exception or log a warning.  Logging a warning is probably 
best, if this is indeed the cause.  It might be harsh to fail the deployment, 
when it might work (if no jar-files are specified).
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Feedback on the idea of PersistenceProviderResolver.getPersistenceProviders() caching the same org.hibernate.ejb.HibernatePersistence class instance for multiple application deploy

[Scott Marlow]

On 09/17/2014 05:28 AM, Emmanuel Bernard wrote:
> BTW there can be multiple persistence units deployed per application so
> if you are trying to tie your cache to the lifecycle of
> createContainerEntityManagerFactory, you might be making a mistake.

When applications include a persistence provider(s), we associate the 
provider with the application classloader (saved in 
PersistenceProviderResolver level cache).  This is not tied to the 
persistence unit.  The call to 
PersistenceProvider.createContainerEntityManagerFactory() can happen 
before the PersistenceProviderResolver cache is updated with the 
deployed provider.

So, it is important to understand when Hibernate Validator first calls 
Persistence.getProviders(), so that we know to set the cache earlier. 
This looked hard to do a few years ago (chicken + egg problem with when 
application classloaders are known in WildFly from what I remember).

>
> On Wed 2014-09-17 11:22, Emmanuel Bernard wrote:
>> PersistenceProvider implementations are not app specific.
>>
>> Hibernate Validator uses
>>
>> Persistence.getPersistenceUtil()
>>
>> This in turn is a static reference object that in its method calls
>> Persistence.getProviders() *each time* to resolve operations like
>> isLoaded(entity).
>>
>> So to answer your question, I think it's after.
>>
>> On Fri 2014-09-12 17:02, Scott Marlow wrote:
>>> What triggers Hibernate Validator to call
>>> PersistenceProviderResolver.getPersistenceProviders()?  Does this happen
>>> during the call to
>>> PersistenceProvider.createContainerEntityManagerFactory() or later after
>>> application deployment completes?
>>>
>>> I'm looking at changing
>>> PersistenceProviderResolver.getPersistenceProviders() to cache the
>>> results on a per deployment basis but need to know when the first call
>>> will be made, so I don't break deployment of persistence providers in
>>> the deployed application.
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] IRC

[Scott Marlow]

I don't see how it could be related but a few weeks ago freenode 
recommended that everyone change their passwords.

On 10/13/2014 02:48 PM, Steve Ebersole wrote:
> just a heads up that I have not been able to connect to freenode for quite
> a few weeks now.  Still no idea what is up there.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

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

Re: [hibernate-dev] Session factory name & clustering

[Scott Marlow]

On 11/10/2014 07:40 AM, Steve Ebersole wrote:
> It would depend on what is inside the CacheKey, which is the key object
> Hibernate passes to the second-level cache.  Usually this situation
> comes up with the identifier Type(s), especially in the case of
> composite identifiers.  Some of the Type implementations hold reference
> to the SessionFactory.  Serializing those properly depends on being able
> to resolve the proper SessionFactory reference on deser, which can
> happen based on UUID (same JVM) or name (across JVMs).
>
> On Mon, Nov 10, 2014 at 4:17 AM, Galder Zamarreño  > wrote:
>
> Hi all,
>
> Re:
> 
> http://stackoverflow.com/questions/26110918/infinispan-marshalling-error-for-hibernate-entity-with-composite-primary-key

This user found the "hibernate.session_factory_name" + 
"hibernate.session_factory_name_is_jndi" settings and HHH-6822.

> Re: https://github.com/hibernate/hibernate-orm/pull/820
>
> Seems like the issue is resolved by making sure Session Factories
> have the same name.
>
> Is this something new? I’ve never had the need to set it in order to
> get Hibernate 2LC clustered tests working. None of my unit tests set
> the session factory name. One of my most recent demos uses JPA, and
> never had to set hibernate.session_factory_name property.
>
> Or is this due to the peculiarity of the Entity the user has? I’ve
> run some tests locally and SessionFactoryImpl.readResolve() does not
> seem to get called.

If the local test serializes the SF UUID and then deserializes from the 
same JVM, the test should pass (as long as the same Hibernate 
classloader is used).  If you are involving multiple JVMs, the SF UUIDs 
are local to each JVM, so you should see failures when deserializing on 
a different JVM (as the SF UUID lookup will fail).

>
> @Paul/@Scott, have you seen anything similar before?

For EE container deployments, we set the 
"hibernate.session_factory_name" if the application doesn't.  We set it 
to an application scoped unique name (deployment archive name (including 
sub-deployment reference) and the persistence unit name).

>
> Cheers,
> --
> Galder Zamarreño
> gal...@redhat.com 
> twitter.com/galderz 
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

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

[hibernate-dev] did hibernate.org crash?

[Scott Marlow]

Trying to open http://hibernate.org/dtd/hibernate-configuration-3.0.dtd, 
gives a:

"
Site temporarily disabled

This page has been temporarily disabled due to a misconfigured custom 
domain.

Are you the site owner? Follow the instructions for setting up a custom 
domain with GitHub pages to update your site's DNS records to point to 
the proper IP address.

You can find more information in our GitHub Pages legacy IP deprecation 
blog post. If you have any questions, please contact support.
"

The above causes a WildFly test failure http://pastebin.com/fm8VMCcb 
(from org.hibernate.service.internal.JaxbProcessor.unmarshal).

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

Re: [hibernate-dev] did hibernate.org crash?

[Scott Marlow]

Related question, should we instead be using the 
org/hibernate/hibernate-configuration-3.0.dtd in 
hibernate-core-4.3.7.Final.jar (instead of accessing the hibernate.org 
website)?

On 11/18/2014 07:48 PM, Scott Marlow wrote:
> Trying to open http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
> gives a:
>
> "
> Site temporarily disabled
>
> This page has been temporarily disabled due to a misconfigured custom
> domain.
>
> Are you the site owner? Follow the instructions for setting up a custom
> domain with GitHub pages to update your site's DNS records to point to
> the proper IP address.
>
> You can find more information in our GitHub Pages legacy IP deprecation
> blog post. If you have any questions, please contact support.
> "
>
> The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
> (from org.hibernate.service.internal.JaxbProcessor.unmarshal).
>
> Scott
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

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

Re: [hibernate-dev] did hibernate.org crash?

[Scott Marlow]

On 11/19/2014 08:53 AM, Sanne Grinovero wrote:
> On 19 November 2014 01:13, Scott Marlow  wrote:
>> Related question, should we instead be using the
>> org/hibernate/hibernate-configuration-3.0.dtd in
>> hibernate-core-4.3.7.Final.jar (instead of accessing the hibernate.org
>> website)?
>
> I'd agree that it's generally not a good idea to rely on external web
> services in your tests. Although in this case it's turned out useful
> as we got your notification about the problem :)

I'm not exactly sure what I need to change in the tests to use the local 
org/hibernate/hibernate-configuration-3.0.dtd (ORM jar) copy of the DTD. 
  I tried a few different options but the only thing that helped was 
removing the DTD reference.

For example, what should 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/cfgfile/CfgFileTestCase.java#L54
 
be changed to?

I tried changing the "PUBLIC" to "SYSTEM" but that didn't seem to make a 
difference (also tried adding a classpath reference which some forum 
posts talked about doing).

>
> Sanne
>
>>
>> On 11/18/2014 07:48 PM, Scott Marlow wrote:
>>> Trying to open http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
>>> gives a:
>>>
>>> "
>>> Site temporarily disabled
>>>
>>> This page has been temporarily disabled due to a misconfigured custom
>>> domain.
>>>
>>> Are you the site owner? Follow the instructions for setting up a custom
>>> domain with GitHub pages to update your site's DNS records to point to
>>> the proper IP address.
>>>
>>> You can find more information in our GitHub Pages legacy IP deprecation
>>> blog post. If you have any questions, please contact support.
>>> "
>>>
>>> The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
>>> (from org.hibernate.service.internal.JaxbProcessor.unmarshal).
>>>
>>> Scott
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] did hibernate.org crash?

[Scott Marlow]

On 11/19/2014 11:26 AM, Steve Ebersole wrote:
> ORM has had local resolution of these DTDs forever.  Something is amiss
> in your set up.  I just ran ORM tests and the DTDs are being resolved
> locally properly.

Thanks for checking.

>
> Can you make sure control is getting through our registered
> EntityResolver?  Ultimately, this should be resolved
> by org.hibernate.internal.util.xml.DTDEntityResolver

I'll give this a try.

>
> On Wed, Nov 19, 2014 at 10:04 AM, Gunnar Morling  <mailto:gun...@hibernate.org>> wrote:
>
> 2014-11-19 16:48 GMT+01:00 Scott Marlow  <mailto:smar...@redhat.com>>:
>
> > On 11/19/2014 08:53 AM, Sanne Grinovero wrote:
> > > On 19 November 2014 01:13, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
> > >> Related question, should we instead be using the
> > >> org/hibernate/hibernate-configuration-3.0.dtd in
> > >> hibernate-core-4.3.7.Final.jar (instead of accessing 
> thehibernate.org <http://hibernate.org>
> > >> website)?
> > >
> > > I'd agree that it's generally not a good idea to rely on external web
> > > services in your tests. Although in this case it's turned out useful
> > > as we got your notification about the problem :)
> >
> > I'm not exactly sure what I need to change in the tests to use the local
> > org/hibernate/hibernate-configuration-3.0.dtd (ORM jar) copy of the DTD.
> >   I tried a few different options but the only thing that helped was
> > removing the DTD reference.
> >
> > For example, what should
> >
> 
> >https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/cfgfile/CfgFileTestCase.java#L54
> > be changed to?
> >
> > I tried changing the "PUBLIC" to "SYSTEM" but that didn't seem to make a
> > difference (also tried adding a classpath reference which some forum
> > posts talked about doing).
> >
>
> I don't think that's something which can (or should) be controlled
> within
> the test.
>
> Rather the code processing the XML file in ORM should make sure to
> use the
> local version of the DTD. That's how it's done in Validator:
>
>
> 
> https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/xml/ValidationXmlParser.java
>
> Not sure how helpful it is though, as this is for XSDs and we're
> using JAXB
> to do the parsing, so it may be a bit different to do in ORM.
>
> --Gunnar
>
>
>  > >
>  > > Sanne
>  > >
>  > >>
>  > >> On 11/18/2014 07:48 PM, Scott Marlow wrote:
>  > >>> Trying to open
>  > http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
>  > >>> gives a:
>  > >>>
>  > >>> "
>  > >>> Site temporarily disabled
>  > >>>
>  > >>> This page has been temporarily disabled due to a
> misconfigured custom
>  > >>> domain.
>  > >>>
>  > >>> Are you the site owner? Follow the instructions for setting
> up a custom
>  > >>> domain with GitHub pages to update your site's DNS records to
> point to
>  > >>> the proper IP address.
>  > >>>
>  > >>> You can find more information in our GitHub Pages legacy IP
> deprecation
>  > >>> blog post. If you have any questions, please contact support.
>  > >>> "
>  > >>>
>  > >>> The above causes a WildFly test failure
> http://pastebin.com/fm8VMCcb
>  > >>> (from org.hibernate.service.internal.JaxbProcessor.unmarshal).
>  > >>>
>  > >>> Scott
>  > >>> ___
>  > >>> hibernate-dev mailing list
>  > >>> hibernate-dev@lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
>  > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  > >>>
>  > >>
>  > >> ___
>  > >> hibernate-dev mailing list
>  > >> hibernate-dev@lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
>  > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  >
>  > ___
>  > hibernate-dev mailing list
>  > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>  > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

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

Re: [hibernate-dev] did hibernate.org crash?

[Scott Marlow]

http://pastebin.com/Baz7FRyf is an initial call stack into 
org.hibernate.service.internal.JaxbProcessor.  I'm debugging on the 
Hibernate 4.3 branch and don't hit any break points in 
org.hibernate.cfg.Configuration#entityResolver.  Perhaps I ended up in 
the wrong class, not sure.  I also set break points in 
org.hibernate.internal.util.xml.DTDEntityResolver (don't see 
org.hibernate.internal.util.__xml.DTDEntityResolver).

The first exception that I see is http://pastebin.com/CYd0aNzE

On 11/19/2014 11:46 AM, Steve Ebersole wrote:
> I should have been more complete :)
>
> You can either set a breakpoint or crank up logging on that class.
> Breakpoint debugging is probably better as you could see the whole call
> stack.  These resolvers use a lot of delegation.  You could also look
> at org.hibernate.cfg.Configuration#entityResolver to verify which
> specific resolver is being used.
>
> On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>
> ORM has had local resolution of these DTDs forever.  Something
> is amiss
> in your set up.  I just ran ORM tests and the DTDs are being
> resolved
> locally properly.
>
>
> Thanks for checking.
>
>
> Can you make sure control is getting through our registered
> EntityResolver?  Ultimately, this should be resolved
> by org.hibernate.internal.util.__xml.DTDEntityResolver
>
>
> I'll give this a try.
>
>

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

Re: [hibernate-dev] did hibernate.org crash?

[Scott Marlow]

On 11/19/2014 02:43 PM, Steve Ebersole wrote:
> Ah, there is a difference in how core and hem are loading these.  This
> is likely a bug, could you open a Jira?

I created HHH-9511 for this.

>
> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> http://pastebin.com/Baz7FRyf is an initial call stack into
> org.hibernate.service.__internal.JaxbProcessor.  I'm debugging on
> the Hibernate 4.3 branch and don't hit any break points in
> org.hibernate.cfg.__Configuration#entityResolver.  Perhaps I ended
> up in the wrong class, not sure.  I also set break points in
> org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
> org.hibernate.internal.util.xml.DTDEntityResolver).
>
> The first exception that I see is http://pastebin.com/CYd0aNzE
>
> On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>
> I should have been more complete :)
>
> You can either set a breakpoint or crank up logging on that class.
> Breakpoint debugging is probably better as you could see the
> whole call
> stack.  These resolvers use a lot of delegation.  You could also
> look
> at org.hibernate.cfg.__Configuration#entityResolver to verify which
> specific resolver is being used.
>
> On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
> mailto:smar...@redhat.com>
> <mailto:smar...@redhat.com <mailto:smar...@redhat.com>>> wrote:
>
>  On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>
>  ORM has had local resolution of these DTDs forever.
> Something
>  is amiss
>  in your set up.  I just ran ORM tests and the DTDs are
> being
>  resolved
>  locally properly.
>
>
>  Thanks for checking.
>
>
>  Can you make sure control is getting through our registered
>  EntityResolver?  Ultimately, this should be resolved
>  by org.hibernate.internal.util.xml.DTDEntityResolver
>
>
>  I'll give this a try.
>
>
>
>

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

Re: [hibernate-dev] Slot name for modules of Hibernate OGM

[Scott Marlow]

Not a big deal to change the WildFly default which is in code, since we 
don't have a suitable configuration file for the setting.

We should update 
org.jboss.as.jpa.config.Configuration.PROVIDER_MODULE_HIBERNATE_OGM, 
which currently is set to "org.hibernate:ogm".  WildFly 8.x is already 
final, so WildFly 9.0 would be the place to make this minor change.

On 01/08/2015 05:21 PM, Sanne Grinovero wrote:
> I just noticed that the main module for Hibernate OGM has slot="ogm",
> while the various dialect extension modules use the "main" slot.
>
> My understanding is that "main" should be reserved for the version
> included in a specific application server version, so we'd better
> avoid it to make it possible to eventually include OGM in WildFly and
> still be able to differentiate versions.
>
> The "ogm" slot also doesn't make it possible to use multiple versions,
> which is ok now that there's a single release but won't be
> sustainable.
>
> Could we use the same label for all modules in a specific release, and
> encode version in it too?
> I propose using "ogm-{Major.Minor.Micro}".

I hate seeing the micro version, but if that can be ignored by users, as 
you suggest, by using the "ogm-{Major.Minor}" instead, not a big deal to 
me.  The hate comes from my past experience with dynamic link modules 
that changed module names like the wind (some database companies did 
this in the past).

Having said that, do what you want but it could be a pita for other 
static modules that need to depend on OGM.

>
> Using the ".Micro" postfix might seem overzealous as micro versions
> are supposed to be drop-in compatible but I'd rather be safe and be
> able to be explicit; we could in addition provide an alias like we do
> with Hibernate Search and Infinispan; this seems to be working quite
> well so far.
> Such an alias deploys a module which defines for say "ogm-4.1" should
> look for "ogm-4.1.1": then applications can generally refer to
> "ogm-4.1" and let the alias resolve it, or be more explicit if they
> like so.

The alias is static, so nothing is looked for.  I don't think anyone 
thinks otherwise but wanted to be clear, that no search is performed. 
By no search, I mean we do not look for a set of possible "ogm-4.1.*" 
matches, instead the "ogm-4.1" alias is hard coded to reference a 
specific "ogm-4.1.minor".

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

Re: [hibernate-dev] Fwd: Hibernate ORM modules published as major.minor and an alias for main

[Scott Marlow]

The change I mentioned for WFLY-4021, is merged in for WildFly 9.0.

On 01/15/2015 07:42 AM, Sanne Grinovero wrote:
> Hi Scott,
> I'm not sure I completely understood your email, but from the example
> it looks like you're having the alias relation in the opposite
> direction.

The WFLY-4021 change allows an application to depend on a specific 
major.minor version of Hibernate ORM:



>
> We would need to have the actual jars into a module which has the
> precise identifier, to match exactly the jars it contains.
> Then we'd add an alias to specify that the "main" slot is the specific 
> version.

When we talked at the f2f, I said that we would do major.minor, I think 
that is the summary notes from the discussion.

If we were to reverse the definitions, so that org.hibernate:main is an 
alias for a specific version of ORM (whether its using major.minor or 
major.minor.micro, it makes no difference to me) and that offers the 
advantages that your thinking of.

Something to keep in mind, in this multiple ORM version world, is that 
the static javax.persistence api is not aware of modules currently.  By 
the fact that WildFly always loads org.hibernate:main first, 
org.hibernate:main is always first in the list returned by 
PersistenceProviderResolver.getPersistenceProviders().  In the module 
aware (container) deployment code in WildFly, we do check if the 
persistence unit specifies a jboss.as.jpa.providerModule property and 
use that to load the persistence provider from the specified module.


>
> For example:
>
> ## Actual Module
> 
>  
>  
>  <
>  
> ...
> 
>
> ## The alias
>   name="org.hibernate" slot="main"
>  target-name="org.hibernate" target-slot="4.3.8.Final" />
>
> By using this structure you can allow most applications to simply
> depend on "org.hibernate" at slot "main". This is useful for the
> majority of users, who know they want to depend on Hibernate and are
> not too fuzzy about the version they use, or simply want the
> "recommended" version, which is essentially what you decide is by
> pulling upgrades into WildFly.
>
> But some of our frameworks who might need to depend on a specific
> version of ORM would have the option to explicitly depend on
> "org.hibernate" slot "4.3.8.Final", which is what we occasionally
> need.
> Also this would make it possible for the ORM project to release
> "update packs", say a version 4.3.9.Final is released soon: users
> would be able to drop this into their application server using slot
> "4.3.9.Final" without risking to break other applications.
>
> We could also be a bit more fine-grained: are you still keeping
> Hibernate 3 around in WildFly 9?

My plan was to remove the Hibernate 3 integration code.  I started doing 
that about a year ago or so, on a WildFly branch that (almost) works 
against Hibernate master from back then.  That branch is very dusty now.

Is there going to be a stable ORM 5.0 branch soon?  At some point, we 
can resume integrating Jipijapa with ORM 5.0 and integrating that with 
WildFly (not sure if that will be WildFly 9 or 10).


> If yes, you might want to have a structure like this one:
>
> ## Actual Module
> 
>  
>  
>  
> ...
> 
>
> ## The 4.x alias
>   name="org.hibernate" slot="4.x"
>  target-name="org.hibernate" target-slot="4.3.8.Final" />
>
> ## The main alias
>   name="org.hibernate" slot="main"
>      target-name="org.hibernate" target-slot="4.x" />
>
> One could also think of introducing a 4.3.x level.. possibilities are
> endless but the priority for us would be to be able to call out a
> specific version.
>
> Thanks,
> Sanne
>
>
>
> On 14 January 2015 at 17:12, Emmanuel Bernard  wrote:
>> FYI
>>
>>> Begin forwarded message:
>>>
>>> Date: 14 Jan 2015 17:30:59 CET
>>> From: Scott Marlow 
>>> To: Emmanuel Bernard 
>>> Subject: Re: Hibernate ORM modules published as major.minor and an alias 
>>> for main
>>>
>>> Hi Emmanuel,
>>>
>>> On 01/14/2015 11:06 AM, Emmanuel Bernard wrote:
>>>> Hi Scott,
>>>>
>>>> In the f2f we discussed the idea of having ORM being published as 
>>>> major.minor and have an alias form main to the default WildFly targeted 
>>>> version.
>>>> Is that in and for which WildFly version?
>>>
>>> I created https://issues.jboss.org/browse/WFLY-4021 and 
>&

Re: [hibernate-dev] Hibernate ORM modules published as major.minor and an alias for main

[Scott Marlow]

On 01/15/2015 09:49 AM, Emmanuel Bernard wrote:
>
>> On 15 Jan 2015, at 14:56, Scott Marlow > <mailto:smar...@redhat.com>> wrote:
>>
>> When we talked at the f2f, I said that we would do major.minor, I think
>> that is the summary notes from the discussion.
>>
>> If we were to reverse the definitions, so that org.hibernate:main is an
>> alias for a specific version of ORM (whether its using major.minor or
>> major.minor.micro, it makes no difference to me) and that offers the
>> advantages that your thinking of.
>
> I think what Sanne propose is what he and I had in mind when we
> discussed at the f2f. I think it makes a bit more sense.

I think that this is some sort of minimal/maximal regular expressing 
matching thing.

When we discussed this at the f2f meeting, I was thinking of the minimal 
way to do what you wanted and thought we were in sync.  Now, I 
understand the additional part of what you wanted (more of a maximal 
match).   :)

I think the simple change, is to invert the modules, like suggested. 
Such that org.hibernate:main is an alias that points to a real module.

The part that I am unsure about is including the micro version in the 
module path, which means that every release of WildFly that includes an 
upgraded Hibernate, will likely have the jars in a different path (could 
be a pain for any configuration settings that point to the Hibernate jars).

The actual module path would also move around a lot in git, which is 
annoying but I have no real complaints about that.

One question is how will the different actual "4.3.micro" modules be 
created?  Would external tools automate that or the user manually create 
them (copy all of the Hibernate jars in, setup a module.xml and 
reference needed dependencies)?

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

Re: [hibernate-dev] did hibernate.org crash?

[Scott Marlow]

Hibernate.org is down (seeing WildFly testsuite failures).

On 11/19/2014 03:33 PM, Scott Marlow wrote:
> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>> Ah, there is a difference in how core and hem are loading these.  This
>> is likely a bug, could you open a Jira?
>
> I created HHH-9511 for this.
>
>>
>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow > <mailto:smar...@redhat.com>> wrote:
>>
>>  http://pastebin.com/Baz7FRyf is an initial call stack into
>>  org.hibernate.service.__internal.JaxbProcessor.  I'm debugging on
>>  the Hibernate 4.3 branch and don't hit any break points in
>>  org.hibernate.cfg.__Configuration#entityResolver.  Perhaps I ended
>>  up in the wrong class, not sure.  I also set break points in
>>  org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>>  org.hibernate.internal.util.xml.DTDEntityResolver).
>>
>>  The first exception that I see is http://pastebin.com/CYd0aNzE
>>
>>  On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>
>>  I should have been more complete :)
>>
>>  You can either set a breakpoint or crank up logging on that class.
>>  Breakpoint debugging is probably better as you could see the
>>  whole call
>>  stack.  These resolvers use a lot of delegation.  You could also
>>  look
>>  at org.hibernate.cfg.__Configuration#entityResolver to verify which
>>  specific resolver is being used.
>>
>>  On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>>  mailto:smar...@redhat.com>
>>  <mailto:smar...@redhat.com <mailto:smar...@redhat.com>>> wrote:
>>
>>   On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>
>>   ORM has had local resolution of these DTDs forever.
>>  Something
>>   is amiss
>>   in your set up.  I just ran ORM tests and the DTDs are
>>  being
>>   resolved
>>   locally properly.
>>
>>
>>   Thanks for checking.
>>
>>
>>   Can you make sure control is getting through our registered
>>   EntityResolver?  Ultimately, this should be resolved
>>   by org.hibernate.internal.util.xml.DTDEntityResolver
>>
>>
>>   I'll give this a try.
>>
>>
>>
>>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] did hibernate.org crash?

[Scott Marlow]

HHH-9511 shows the call stack (should answer where/why).

On 02/03/2015 03:22 PM, Steve Ebersole wrote:
> Great question!  Scott?
>
> On Tue, Feb 3, 2015 at 2:19 PM, Carlo de Wolf  <mailto:cdew...@redhat.com>> wrote:
>
> Why and where do we have such a dependency?
>
> Carlo
>
>
>     On 02/03/2015 08:44 PM, Scott Marlow wrote:
>
> Hibernate.org is down (seeing WildFly testsuite failures).
>
> On 11/19/2014 03:33 PM, Scott Marlow wrote:
>
> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>
> Ah, there is a difference in how core and hem are
> loading these.  This
> is likely a bug, could you open a Jira?
>
> I created HHH-9511 for this.
>
> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow
> mailto:smar...@redhat.com>
> <mailto:smar...@redhat.com <mailto:smar...@redhat.com>>>
> wrote:
>
> http://pastebin.com/Baz7FRyf is an initial call stack into
>
> org.hibernate.service.internal.JaxbProcessor.  I'm
> debugging on
>the Hibernate 4.3 branch and don't hit any break
> points in
>
> org.hibernate.cfg.Configuration#entityResolver.
> Perhaps I ended
>up in the wrong class, not sure.  I also set
> break points in
>
> org.hibernate.internal.util.xml.DTDEntityResolver
> (don't see
>
> org.hibernate.internal.util.__xml.DTDEntityResolver).
>
>The first exception that I see is
> http://pastebin.com/CYd0aNzE
>
>On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>
>I should have been more complete :)
>
>You can either set a breakpoint or crank up
> logging on that class.
>Breakpoint debugging is probably better as
> you could see the
>whole call
>stack.  These resolvers use a lot of
> delegation.  You could also
>look
>at
>     org.hibernate.cfg.Configuration#entityResolver to
> verify which
>specific resolver is being used.
>
>On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
> <mailto:smar...@redhat.com> <mailto:smar...@redhat.com
> <mailto:smar...@redhat.com>>
><mailto:smar...@redhat.com
> <mailto:smar...@redhat.com> <mailto:smar...@redhat.com
> <mailto:smar...@redhat.com>>>> wrote:
>
> On 11/19/2014 11:26 AM, Steve Ebersole
> wrote:
>
> ORM has had local resolution of
> these DTDs forever.
>Something
> is amiss
> in your set up.  I just ran ORM
> tests and the DTDs are
>being
> resolved
> locally properly.
>
>
> Thanks for checking.
>
>
> Can you make sure control is getting
> through our registered
> EntityResolver?  Ultimately, this
> should be resolved
> by
> org.hibernate.internal.util.__xml.DTDEntityResolver
>
>
> I'll give this a try.
>
>
>
>
> _
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> <mailto:hibernate-dev@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@lists.jboss.org <mailto:hibernate-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

With a proposed TM level listener, we will have an SPI for notification 
of when application threads associated with a JTA transaction, become 
disassociated with the transaction (tm.commit/rollback/suspend time). 
Having this knowledge in a synchronization callback, can determine 
whether the persistence context should be cleared directly from the 
Synchronization.afterCompletion(int) call or should be deferred until 
the transaction is disassociated from the JTA transaction.

This idea is based on a TM level listener approach that Tom Jenkinson 
[1] suggested.  Mike Musgrove has a "proof of concept" implementation of 
the suggested changes [2].  I did some testing with [3] to see if the 
improvement helps with clearing entities that might still be in the 
persistence context after a background tx timeout.

I'm wondering if in the Hibernate ORM 
Synchronization.afterCompletion(int status) implementation, in case of 
tx rollback, if we could defer the clearing of the Hibernate session to 
be handled by the JtaPlatform.  This could be setup at 
EntityManager.joinTransaction() time (if a new property like 
"hibernate.transaction.defer_clear_session" is true).  Perhaps via a 
JtaPlatform.joinTransaction(EntityManager) registration call?

Thoughts?

Scott

[1] https://developer.jboss.org/thread/252572?start=45&tstart=0

[2] 
https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociationListener/src/main/java/org/jboss/tm/

[3] 
https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_noejb_wildfly9_march5_2015
 

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

Re: [hibernate-dev] JTA synchronizations on WildFly

[Scott Marlow]

Hi Gunnar,

Yes, this behaviour is expected since you registered an non-interposed 
synchronization.  For what purpose are you registering the transaction 
synchronization?  I would like to be aware of the synchronizations that 
we register in WildFly.

The non-interposed sync beforeCompletion callback are invoked first, 
then the interposed sync beforeCompletion calls, then the interposed 
afterCompletion(int status) calls and finally, the non-interposed 
afterCompletion(int status) calls.

The Synchronizations that are registered via the 
javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
 
[2] are interposed.

Synchronizations that are registered via the 
javax.transaction.Transaction.registerSynchronization(Synchronization) 
[3] are non-interposed.

In WildFly, the transaction manager uses the registration order within 
the interposed/non-interposed group.  Before completion syncs (within 
their respective group), are run in registration order.  After 
completion syncs (within their respective group), are run in reverse 
registration order.

I believe that your workaround, mentioned below, of using 
JtaPlatform#registerSynchronization() on WildFly, is registering your 
synchronization as interposed via the TransactionSynchronizationRegistry 
[2]. There might be a way to register a sync callback at the Hibernate 
session level (which would also run as interposed sync on WildFly).

Not sure if you saw my email yesterday to Hibernate-dev ml.  You should 
be aware that the afterCompletion(int status) callback, may be called 
from a non-application thread when the WildFly tm reaper handles tx 
timeout (this can happen while the application thread is still invoking 
calls on the Hibernate session).  Because the Hibernate session is not 
thread safe, we need to ensure that the Hibernate session 
afterCompletion(int status) callback does not mutate the Hibernate 
session (e.g. calling session.clear() what status == rolled back).

Scott

[2] 
http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html#registerInterposedSynchronization%28javax.transaction.Synchronization%29

[3] 
http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#registerSynchronization%28javax.transaction.Synchronization%29

On 03/10/2015 09:03 AM, Gunnar Morling wrote:
> Hi,
>
> I'm trying to perform a specific action upon transaction rollback.
>
> Assuming this could be done using a custom
> javax.transaction.Synchronization, I tried to register a synchronization as
> follows:
>
>  TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>  transaction.registerSynchronization( new MySync() );
>
> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
> never is. I debugged this a bit on WildFly and observed the following:
>
> * Hibernate ORM registers RegisteredSynchronization with JTA.
> RegisteredSynchronization manages (indirectly, through
> TransactionCoordinator, SynchronizationRegistry etc.) those
> synchronizations added through o.h.t.Transaction.registerSynchronization()
> * WildFly (specifically, TransactionUtil [1]) registers its own
> SessionSynchronization
> for closing the entity manager/session
>
> Now that second synchronization is called first, closing the session. Upon
> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
> afterComplection() is called on RegisteredSynchronization afterwards, any
> previously registered delegate synchronizations are gone already and thus
> do not get invoked.
>
> I believe I found a workaround for my case by registering my
> synchronization through JtaPlatform#registerSynchronization() (which
> registers it with the actual JTA transaction).
>
> My questions are:
>
> * Is this behaviour expected?
> * Is the work-around of doing the registration via JtaPlatform viable or
> are there any drawbacks which I'm not aware of?
>
> Thanks,
>
> --Gunnar
>
> [1]
> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Scott Marlow]

On 03/10/2015 10:12 AM, Emmanuel Bernard wrote:
> So Gunnar, your workaround is fine today but will pose problems in the future 
> if we decide that onRollback for ErrorHandler needs access to the session 
> somehow to be able to compensate and undo the already executed operations:
> - a closed session will do us no good
> - there is a harder problem that Scott mentions below related to tx reaping 
> in a different thread
>
> Let’s try and find a solution for the first problem.
>
> @Scott, I think what happens is the following:
>
> - Hibernate registers a Sync when the EM is created (for the flush() 
> callbacks and a few other things)
> - Synchronization attached to the Hibernate Transaction objects are 
> piggybacking on that initial Sync attachement
> - Wildfly attach a “close session” Sync once it has the instance of 
> EntityManager
> - according to your rules, the close session afterTransaction Sync is called 
> before the one Hibernate put
> - that explains why Gunnar finds an already closed Tx.
>
> But since Gunnar attaches its Sync when the Hibernate TransactionCoordinator 
> creates the Hibernate transaction, which is when the EM is created, I can’t 
> explain why the workaround works.

Because Gunnar initially registered the Sync, via [3] 
javax.transaction.Transaction.registerSynchronization(Sync), which might 
be correct in some non-WildFly environments where perhaps all Syncs are 
registered via [3] (as non-interposed syncs).  When Gunnar, switched to 
the Hibernate JtaPlatform mechanism for registering the Sync, we then 
switched to an interposed Sync.  I suspect that the JtaPlatform sync 
registration is a good way to register the OGM, however, I have been 
told that the *best* way is to register only one sync (to avoid ordering 
issues).

If OGM could register to share the existing Hibernate EM sync, we would 
have more control over when the OGM sync is invoked and in which thread 
(application versus background tm reaping thread).

Regarding the proposed "new proposal for tx timeout handling using 
transaction DISASSOCIATING event notification" discussion and how that 
could impact OGM.  We will continue to run the interposed/non-interposed 
sync callbacks in whatever thread the TM, calls them from (e.g. 
beforeCompletion may or may not be called from app thread, 
afterCompletion will be called from either app thread, background 
reaping thread or background communications thread).  The reason is that 
certain resources need to be cleaned up immediately from the 
Sync.afterCompletion(int status) call.  Certain other resources (like 
clearing managed entities from persistence context after a rollback), 
need to be handled from either the application thread or a background 
thread after the application thread is disassociated from the JTA 
transaction.

IMO, the OGM ErrorHandling/Compensation API probably needs to be aware 
of the same concurrency requirements to avoid presenting the executed 
operations list, while the application thread is still executing new 
operations (because it perhaps doesn't yet know that the tx rolled back).

It would be good to know if OGM will also need the concurrency 
protection, so that any new Hibernate 5.0 SPI can be used by OGM (e.g. 
currently the only need is to run the Hibernate Session.clear when we 
know that the application thread is not actively using the Session).

>
> Emmanuel
>
>> On 10 Mar 2015, at 14:39, Scott Marlow  wrote:
>>
>> Hi Gunnar,
>>
>> Yes, this behaviour is expected since you registered an non-interposed
>> synchronization.  For what purpose are you registering the transaction
>> synchronization?  I would like to be aware of the synchronizations that
>> we register in WildFly.
>>
>> The non-interposed sync beforeCompletion callback are invoked first,
>> then the interposed sync beforeCompletion calls, then the interposed
>> afterCompletion(int status) calls and finally, the non-interposed
>> afterCompletion(int status) calls.
>>
>> The Synchronizations that are registered via the
>> javax.transaction.TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
>> [2] are interposed.
>>
>> Synchronizations that are registered via the
>> javax.transaction.Transaction.registerSynchronization(Synchronization)
>> [3] are non-interposed.
>>
>> In WildFly, the transaction manager uses the registration order within
>> the interposed/non-interposed group.  Before completion syncs (within
>> their respective group), are run in registration order.  After
>> completion syncs (within their respective group), are run in reverse
>> registration order.
>>
>> I believe that your workaround, mentioned below, of using
>> JtaPlatform#registerSynchroni

Re: [hibernate-dev] JTA synchronizations on WildFly

[Scott Marlow]

I just saw the below email response after I sent the last one.  Sorry 
about that, will respond here also.  :)

On 03/10/2015 09:14 AM, Emmanuel Bernard wrote:
> Ah synchronization ordering, it never gets old :) Steve might remember better 
> but I don’t think we ever managed to convice the tx team to offer guaranteed 
> ordering.

We started discussing synchronization ordering as well (within the 
interposed group) and there is a WildFly specific code change being 
worked on to always run the JCA sync last (so IronJacamar can delist a 
resource that would of otherwise been leaked).

>
> Your workaround seems fine (if there is a JtaPlaform) but when we add more 
> logic to your onRollback calls, we might want to offer access tot he Session 
> to try compensating for example. In which case, we would be in trouble with 
> the closed session. I don’t have a good idea.

Hmm, for the new SPI that deals with registering "concurrency safe" 
OnRollback calls, I wonder if we should have an ordering priority, so 
that the session clear/OGM operations list presentation, can always run 
before the JPA container closes the session.  In a discussion about 
changing the TM level Sync ordering for an unknown set of Syncs, we 
talked about specifying an ordering priority for registered Syncs, that 
idea will probably be useful for ordering the OnRollback calls if we 
enable that.

>
> I am a bit surprised WildFly closes the session but that might be per spec 
> that the container manages these calls.

Yes, only for a transaction scoped entity manager, do we have to close 
the session after the transaction ends.  We don't do this for 
application managed (application needs to call EM.close()).  For 
extended persistence contexts, we close the session, after the last 
referencing stateful bean is destroyed (tracking is done in the JPA 
container).

Scott

>
>> On 10 Mar 2015, at 14:03, Gunnar Morling  wrote:
>>
>> Hi,
>>
>> I'm trying to perform a specific action upon transaction rollback.
>>
>> Assuming this could be done using a custom
>> javax.transaction.Synchronization, I tried to register a synchronization as
>> follows:
>>
>> TransactionImplementor transaction = ...; // e.g. a CMTTransaction
>> transaction.registerSynchronization( new MySync() );
>>
>> And indeed beforeCompletion() is invoked as expected. But afterCompletion()
>> never is. I debugged this a bit on WildFly and observed the following:
>>
>> * Hibernate ORM registers RegisteredSynchronization with JTA.
>> RegisteredSynchronization manages (indirectly, through
>> TransactionCoordinator, SynchronizationRegistry etc.) those
>> synchronizations added through o.h.t.Transaction.registerSynchronization()
>> * WildFly (specifically, TransactionUtil [1]) registers its own
>> SessionSynchronization
>> for closing the entity manager/session
>>
>> Now that second synchronization is called first, closing the session. Upon
>> SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
>> afterComplection() is called on RegisteredSynchronization afterwards, any
>> previously registered delegate synchronizations are gone already and thus
>> do not get invoked.
>>
>> I believe I found a workaround for my case by registering my
>> synchronization through JtaPlatform#registerSynchronization() (which
>> registers it with the actual JTA transaction).
>>
>> My questions are:
>>
>> * Is this behaviour expected?
>> * Is the work-around of doing the registration via JtaPlatform viable or
>> are there any drawbacks which I'm not aware of?
>>
>> Thanks,
>>
>> --Gunnar
>>
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jboss/as/jpa/transaction/TransactionUtil.java
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

On 03/10/2015 11:44 AM, Steve Ebersole wrote:
> Scott, I am not following.  Pardon me if I am being dense :)
>
> Today, in our afterCompletion hooks we have code that, in the case of
> rollback, tries to make a determination of whether the rollback is due
> to a timeout or a "normal" rollback.  If we deem a timeout occurred,
> then we delay the afterCompletion processing.

Currently, in our afterCompletion hooks, the determining code isn't 
aware of the current/last application thread id.  I think that we are 
only tracking the first thread id that is used with the Hibernate 
session but not the last thread id.

>
> So how, specifically, would this be different in what you propose?

The new approach will not use thread id, instead in our afterCompletion 
call, we will have the TM level knowledge, of whether the application 
thread has called tx rollback/suspend/commit yet.  If the application 
thread has called tx rollback/suspend/commit already, the 
afterCompletion call can safely clear managed entities from the session 
without violating concurrency concerns.  If the application has not yet 
called tx rollback/suspend/commit yet, we need to defer the clearing of 
the Hibernate session, until the TM listener calls us back, to let us 
know that the application has called tx rollback/suspend/commit, at 
which time we can safely clear the Hibernate session without violating 
(Hibernate session) concurrency concerns.

>
> Are you saying that with this listener approach, that the listener would
> be notified of disassociation prior to the afterCompletion callback on
> our RegisteredSynchronization?  But in the timeout case, the
> disassociation would happen later?

Yes.  It is also possible that in the timeout case, that the 
disassociation will come first (e.g. if there is a race between the app 
committing the transaction and the reaper thread timing out) but more 
likely that the disassociation comes later for the timeout case.

FYI, the TM level SPI changes [4][5] are still open for review.

Scott

[4] https://github.com/jbosstm/jboss-transaction-spi/pull/5
[5] https://github.com/jbosstm/narayana/pull/810

>
> On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> With a proposed TM level listener, we will have an SPI for notification
> of when application threads associated with a JTA transaction, become
> disassociated with the transaction (tm.commit/rollback/suspend time).
> Having this knowledge in a synchronization callback, can determine
> whether the persistence context should be cleared directly from the
> Synchronization.afterCompletion(int) call or should be deferred until
> the transaction is disassociated from the JTA transaction.
>
> This idea is based on a TM level listener approach that Tom Jenkinson
> [1] suggested.  Mike Musgrove has a "proof of concept" implementation of
> the suggested changes [2].  I did some testing with [3] to see if the
> improvement helps with clearing entities that might still be in the
> persistence context after a background tx timeout.
>
> I'm wondering if in the Hibernate ORM
> Synchronization.afterCompletion(int status) implementation, in case of
> tx rollback, if we could defer the clearing of the Hibernate session to
> be handled by the JtaPlatform.  This could be setup at
> EntityManager.joinTransaction() time (if a new property like
> "hibernate.transaction.defer_clear_session" is true).  Perhaps via a
> JtaPlatform.joinTransaction(EntityManager) registration call?
>
> Thoughts?
>
> Scott
>
> [1] https://developer.jboss.org/thread/252572?start=45&tstart=0
>
> [2]
> 
> https://github.com/mmusgrov/jboss-transaction-spi/blob/threadDisassociationListener/src/main/java/org/jboss/tm/
>
> [3]
> 
> https://github.com/scottmarlow/wildfly/tree/transactiontimeout_clientut_noejb_wildfly9_march5_2015
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

On 03/10/2015 12:30 PM, Steve Ebersole wrote:
> You confused me more :)
>
> One the one had you say that we will use this fact of whether the
> transaction has been disassociated to indicate whether the transaction
> is completing normally (disassociated == true) or timed-out
> (disassociated == false).  But at the same time you are saying that it
> is quite possible that we could still receive the
> afterCompletion callback in the timed-out case and have (disassociated
> == true) due to race conditions.

When we have both disassociated == true and afterCompletion has been 
called, then it is safe to clear the Hibernate session.  The order that 
these conditions are detected, does not matter.

>
> So what is this buying us?
>
>
> On Tue, Mar 10, 2015 at 11:09 AM, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
>
>
> On 03/10/2015 11:44 AM, Steve Ebersole wrote:
>
> Scott, I am not following.  Pardon me if I am being dense :)
>
> Today, in our afterCompletion hooks we have code that, in the
> case of
> rollback, tries to make a determination of whether the rollback
> is due
> to a timeout or a "normal" rollback.  If we deem a timeout occurred,
> then we delay the afterCompletion processing.
>
>
> Currently, in our afterCompletion hooks, the determining code isn't
> aware of the current/last application thread id.  I think that we
> are only tracking the first thread id that is used with the
> Hibernate session but not the last thread id.
>
>
> So how, specifically, would this be different in what you propose?
>
>
> The new approach will not use thread id, instead in our
> afterCompletion call, we will have the TM level knowledge, of
> whether the application thread has called tx rollback/suspend/commit
> yet.  If the application thread has called tx
> rollback/suspend/commit already, the afterCompletion call can safely
> clear managed entities from the session without violating
> concurrency concerns.  If the application has not yet called tx
> rollback/suspend/commit yet, we need to defer the clearing of the
> Hibernate session, until the TM listener calls us back, to let us
> know that the application has called tx rollback/suspend/commit, at
> which time we can safely clear the Hibernate session without
> violating (Hibernate session) concurrency concerns.
>
>
> Are you saying that with this listener approach, that the
> listener would
> be notified of disassociation prior to the afterCompletion
> callback on
> our RegisteredSynchronization?  But in the timeout case, the
> disassociation would happen later?
>
>
> Yes.  It is also possible that in the timeout case, that the
> disassociation will come first (e.g. if there is a race between the
> app committing the transaction and the reaper thread timing out) but
> more likely that the disassociation comes later for the timeout case.
>
> FYI, the TM level SPI changes [4][5] are still open for review.
>
> Scott
>
> [4] https://github.com/jbosstm/__jboss-transaction-spi/pull/5
> <https://github.com/jbosstm/jboss-transaction-spi/pull/5>
> [5] https://github.com/jbosstm/__narayana/pull/810
> <https://github.com/jbosstm/narayana/pull/810>
>
>
> On Mon, Mar 9, 2015 at 1:19 PM, Scott Marlow  <mailto:smar...@redhat.com>
> <mailto:smar...@redhat.com <mailto:smar...@redhat.com>>> wrote:
>
>  With a proposed TM level listener, we will have an SPI for
> notification
>  of when application threads associated with a JTA
> transaction, become
>  disassociated with the transaction
> (tm.commit/rollback/suspend time).
>  Having this knowledge in a synchronization callback, can
> determine
>  whether the persistence context should be cleared directly
> from the
>  Synchronization.__afterCompletion(int) call or should be
> deferred until
>  the transaction is disassociated from the JTA transaction.
>
>  This idea is based on a TM level listener approach that Tom
> Jenkinson
>  [1] suggested.  Mike Musgrove has a "proof of concept"
> implementation of
>  the suggested changes [2].  I did some testing with [3] to
> see if the
>  improvement helps with clearing entities that might still
> be in the
>  persistence context after a background tx tim

Re: [hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

>
> So what is this buying us?
>

The current Hibernate ORM thread id checking, does not properly handle 
the case when the application thread changes between calls to the 
Hibernate session.  The new approach does handle the application thread 
changing between session invocations and also covers a few other cases 
as well (like clearing the persistence context after the application may 
of added another entity after the background thread rolled back the 
transaction).
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JTA synchronizations on WildFly

[Scott Marlow]

Not exactly sure but this might be the way that Jipijapa registers the 
JtaPlatform.  Originally, Jipijapa used the service approach but 
reverted that due to a memory leak (I think in envers?).

This was mentioned a while back via [3].  I think we talked about 
switching Jipijapa back to using a 
META-INF/services/org.hibernate.engine.transaction.jta.platform.spi.JtaPlatformProvider
 
but I never bothered since the current non-service approach works 
(except for your use case :).

Scott

[3] http://lists.jboss.org/pipermail/hibernate-dev/2013-July/010140.html

On 03/10/2015 01:14 PM, Gunnar Morling wrote:
> For some reason I'm seeing though JBossStandAloneJtaPlatform being used
> when debugging an OGM integration test on WildFly.
>
> WF's JtaPlatform seems not to be picked up. Tried to debug a but,
> apparently it never comes to the point where JipiJapa would inject the
> JBossAppServerJtaPlatform as platform. I could imagine it's due to OGM
> being used as persistence provider, so maybe the right implicit module
> dependencies don't get added? Scott?
>
> It's all a bit guess work on my side, I don't know that WF/JipiJapa code
> very well.
>
>
>
> 2015-03-10 16:50 GMT+01:00 Steve Ebersole  <mailto:st...@hibernate.org>>:
>
> Gunnar, WildFly uses its own JtaPlatform...
>
> On Tue, Mar 10, 2015 at 10:44 AM, Gunnar Morling
> mailto:gun...@hibernate.org>> wrote:
>
> Hi,
>
> > I believe that your workaround, mentioned below, of using
> JtaPlatform#registerSynchronization() on WildFly, is registering
> your
> synchronization as interposed via the
> TransactionSynchronizationRegistry
> [2].
>
> That seems not to be the case. If you check out
> AbstractJtaPlatform and
> TransactionManagerBasedSynchronizationStrategy in ORM,
> registerSynchronization() adds the Sync as non-interposed via
> TransactionManager.getTransaction().registerSynchronization().
>
> But the ordering is indeed what makes me wonder. As
> SessionSynchronization
> is interposed, the non-interposed beforeCompletion() hooks are
> run, but the
> non-interposed afterCompletion() hooks managed via
> RegisteredSynchronization are never run, as the session has been
> closed and
> thus the list of syncs to be invoked through
> RegisteredSynchronization has
> been cleared at this point. At least this behaviour was
> surprising to me.
>
> My work-around works because my non-interposed sync is added through
> JtaPlatform to the actual (Arjuna) Transaction instance directly
> (rather
> than indirectly via RegisteredSynchronization) and thus gets invoked
> properly.
>
> 2015-03-10 14:39 GMT+01:00 Scott Marlow  <mailto:smar...@redhat.com>>:
>
>  > Hi Gunnar,
>  >
>  > Yes, this behaviour is expected since you registered an
> non-interposed
>  > synchronization.  For what purpose are you registering the
> transaction
>  > synchronization?  I would like to be aware of the
> synchronizations that we
>  > register in WildFly.
>  >
>  > The non-interposed sync beforeCompletion callback are invoked
> first, then
>  > the interposed sync beforeCompletion calls, then the interposed
>  > afterCompletion(int status) calls and finally, the non-interposed
>  > afterCompletion(int status) calls.
>  >
>  > The Synchronizations that are registered via the
> javax.transaction.
>  >
> 
> TransactionSynchronizationRegistry.registerInterposedSynchronization(Synchronization)
>  > [2] are interposed.
>  >
>  > Synchronizations that are registered via the
> javax.transaction.Transaction.
>  > registerSynchronization(Synchronization) [3] are non-interposed.
>  >
>  > In WildFly, the transaction manager uses the registration
> order within the
>  > interposed/non-interposed group.  Before completion syncs
> (within their
>  > respective group), are run in registration order.  After
> completion syncs
>  > (within their respective group), are run in reverse
> registration order.
>  >
>  > I believe that your workaround, mentioned below, of using
> JtaPlatform#registerSynchronization()
>  > on WildFly, is registering you

[hibernate-dev] Question about Jandex composite indexes passed into via "hibernate.jandex_index" and whether ORM keeps a strong reference to Jandex indexes after deployment...

[Scott Marlow]

Steve,

Wildfly-dev [1] brings up a change expected for WildFly 10, to not 
reference the Jandex indexes after deployment completes.  I'm curious if 
our current/planned ORM 5.0 jandex using code, keeps a reference to the 
passed in "hibernate.jandex_index"?

How how hard would it be for ORM, to only reference the composite Jandex 
index during application deployment time?  Deployment time ends when 
PersistenceProvider.createContainerEntityManagerFactory() returns.

Scott

[1] http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Question about Jandex composite indexes passed into via "hibernate.jandex_index" and whether ORM keeps a strong reference to Jandex indexes after deployment...

[Scott Marlow]

On 03/18/2015 01:05 PM, Steve Ebersole wrote:
> Well I should also clarify that currently we are not using Jandex.  That
> was all work done as part of the mapping/metamodel redesign which we
> decided to push to 6.0.

I assume you mean the master (5.0) code base doesn't use Jandex but it 
looks like [2] in 4.3, is building/using the Jandex index.

How big of a change would it be to use Jandex (via 
"hibernate.jandex_index") in ORM 4.3/5.0 mapping?  Would be nice to have 
a comparison of how long it takes to deploy a large application with and 
without Jandex.

Scott

[2] 
https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java

>
> On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole  <mailto:st...@hibernate.org>> wrote:
>
> I don't *think* we do, but it sounds like something we definitely
> need to make sure we aren't doing.
>
> On Mar 17, 2015 8:41 AM, "Scott Marlow"  <mailto:smar...@redhat.com>> wrote:
>
> Steve,
>
> Wildfly-dev [1] brings up a change expected for WildFly 10, to not
> reference the Jandex indexes after deployment completes.  I'm
> curious if
> our current/planned ORM 5.0 jandex using code, keeps a reference
> to the
> passed in "hibernate.jandex_index"?
>
> How how hard would it be for ORM, to only reference the
> composite Jandex
> index during application deployment time?  Deployment time ends when
> PersistenceProvider.createContainerEntityManagerFactory() returns.
>
> Scott
>
> [1]
> http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Question about Jandex composite indexes passed into via "hibernate.jandex_index" and whether ORM keeps a strong reference to Jandex indexes after deployment...

[Scott Marlow]

On 03/18/2015 01:53 PM, Steve Ebersole wrote:
> Out of curiosity though, since you want more and more and more things
> pushed to "second phase bootstrapping", I am curious how this new
> expectation plays in with that.  Specifically, us "using" Jandex will
> certainly include us accessing classes, unless Jason has added the
> expanded capabilities he and I have discussed to Jandex wrt accessing
> Class members outside of the annotations they may or may not have.

If we use the application classloader during the "first phase 
bootstrapping", entity class enhancement will not work (application 
classes will be loaded before they can be rewritten).  Classloading 
during the "first phase bootstrapping" with 
javax.persistence.spi.PersistenceUnitInfo.getNewTempClassLoader() would 
still work with entity class enhancement.

>
> On Wed, Mar 18, 2015 at 12:49 PM, Steve Ebersole  <mailto:st...@hibernate.org>> wrote:
>
> Massive.
>
> On Wed, Mar 18, 2015 at 12:44 PM, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> On 03/18/2015 01:05 PM, Steve Ebersole wrote:
>
> Well I should also clarify that currently we are not using
> Jandex.  That
> was all work done as part of the mapping/metamodel redesign
> which we
> decided to push to 6.0.
>
>
> I assume you mean the master (5.0) code base doesn't use Jandex
> but it looks like [2] in 4.3, is building/using the Jandex index.
>
> How big of a change would it be to use Jandex (via
> "hibernate.jandex_index") in ORM 4.3/5.0 mapping?  Would be nice
> to have a comparison of how long it takes to deploy a large
> application with and without Jandex.
>
> Scott
>
> [2]
> 
> https://github.com/hibernate/__hibernate-orm/blob/4.3/__hibernate-entitymanager/src/__main/java/org/hibernate/jpa/__boot/internal/__EntityManagerFactoryBuilderImp__l.java
> 
> <https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java>
>
>
> On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole
> mailto:st...@hibernate.org>
> <mailto:st...@hibernate.org <mailto:st...@hibernate.org>>>
>     wrote:
>
>  I don't *think* we do, but it sounds like something we
> definitely
>  need to make sure we aren't doing.
>
>  On Mar 17, 2015 8:41 AM, "Scott Marlow"
> mailto:smar...@redhat.com>
>  <mailto:smar...@redhat.com
> <mailto:smar...@redhat.com>>> wrote:
>
>  Steve,
>
>  Wildfly-dev [1] brings up a change expected for
> WildFly 10, to not
>  reference the Jandex indexes after deployment
> completes.  I'm
>  curious if
>  our current/planned ORM 5.0 jandex using code,
> keeps a reference
>  to the
>  passed in "hibernate.jandex_index"?
>
>  How how hard would it be for ORM, to only reference the
>  composite Jandex
>  index during application deployment time?
> Deployment time ends when
>
> PersistenceProvider.__createContainerEntityManagerFa__ctory() 
> returns.
>
>  Scott
>
>  [1]
> 
> http://lists.jboss.org/__pipermail/wildfly-dev/2015-__March/003679.html
> 
> <http://lists.jboss.org/pipermail/wildfly-dev/2015-March/003679.html>
>  _
>  hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
> <mailto:hibernate-dev@lists.__jboss.org
> <mailto:hibernate-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Question about Jandex composite indexes passed into via "hibernate.jandex_index" and whether ORM keeps a strong reference to Jandex indexes after deployment...

[Scott Marlow]

On 03/18/2015 02:56 PM, Scott Marlow wrote:
>
> On 03/18/2015 01:53 PM, Steve Ebersole wrote:
>> Out of curiosity though, since you want more and more and more things
>> pushed to "second phase bootstrapping", I am curious how this new
>> expectation plays in with that.  Specifically, us "using" Jandex will
>> certainly include us accessing classes, unless Jason has added the
>> expanded capabilities he and I have discussed to Jandex wrt accessing
>> Class members outside of the annotations they may or may not have.
>
> If we use the application classloader during the "first phase
> bootstrapping", entity class enhancement will not work (application
> classes will be loaded before they can be rewritten).  Classloading
> during the "first phase bootstrapping" with
> javax.persistence.spi.PersistenceUnitInfo.getNewTempClassLoader() would
> still work with entity class enhancement.

Jipijapa for ORM 4.1 is currently using the 
PersistenceUnitInfo.getNewTempClassLoader() [3] and that works well. 
Jason asked why we dropped using Jandex in our integration with ORM 4.3. 
  The 4.3 integration in Jipijapa is more elegant/better except it might 
not be as fast as using Jandex with 
org.hibernate.boot.archive.scan.spi.Scanner.

Should we look at switching Jipijapa back to 
org.hibernate.boot.archive.scan.spi.Scanner (so we can use Jandex) and 
remove Jandex from 4.3.x?

In the Jipijapa integration for ORM 5.0, should we use 
org.hibernate.boot.archive.scan.spi.Scanner so that we are using jandex?

[3] 
https://github.com/jipijapa/jipijapa/blob/master/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/HibernateAnnotationScanner.java#L167

>
>>
>> On Wed, Mar 18, 2015 at 12:49 PM, Steve Ebersole > <mailto:st...@hibernate.org>> wrote:
>>
>>  Massive.
>>
>>  On Wed, Mar 18, 2015 at 12:44 PM, Scott Marlow >  <mailto:smar...@redhat.com>> wrote:
>>
>>  On 03/18/2015 01:05 PM, Steve Ebersole wrote:
>>
>>  Well I should also clarify that currently we are not using
>>  Jandex.  That
>>  was all work done as part of the mapping/metamodel redesign
>>  which we
>>  decided to push to 6.0.
>>
>>
>>  I assume you mean the master (5.0) code base doesn't use Jandex
>>  but it looks like [2] in 4.3, is building/using the Jandex index.
>>
>>  How big of a change would it be to use Jandex (via
>>  "hibernate.jandex_index") in ORM 4.3/5.0 mapping?  Would be nice
>>  to have a comparison of how long it takes to deploy a large
>>  application with and without Jandex.
>>
>>  Scott
>>
>>  [2]
>>  
>> https://github.com/hibernate/__hibernate-orm/blob/4.3/__hibernate-entitymanager/src/__main/java/org/hibernate/jpa/__boot/internal/__EntityManagerFactoryBuilderImp__l.java
>>  
>> <https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java>
>>
>>
>>  On Wed, Mar 18, 2015 at 10:22 AM, Steve Ebersole
>>      mailto:st...@hibernate.org>
>>  <mailto:st...@hibernate.org <mailto:st...@hibernate.org>>>
>>  wrote:
>>
>>   I don't *think* we do, but it sounds like something we
>>  definitely
>>   need to make sure we aren't doing.
>>
>>   On Mar 17, 2015 8:41 AM, "Scott Marlow"
>>  mailto:smar...@redhat.com>
>>   <mailto:smar...@redhat.com
>>  <mailto:smar...@redhat.com>>> wrote:
>>
>>   Steve,
>>
>>   Wildfly-dev [1] brings up a change expected for
>>  WildFly 10, to not
>>   reference the Jandex indexes after deployment
>>  completes.  I'm
>>   curious if
>>   our current/planned ORM 5.0 jandex using code,
>>  keeps a reference
>>   to the
>>   passed in "hibernate.jandex_index"?
>>
>>   How how hard would it be for ORM, to only reference the
>>   composite Jandex
>>   index during application deployment time?
>>  Deployment time ends when
>>
>>  PersistenceProvider.__createCont

Re: [hibernate-dev] Hibernate 4.3.9.Final and 4.2.19.Final Released

[Scott Marlow]

Congratulations on the new releases!

On 04/16/2015 02:20 AM, Gail Badner wrote:
> For details, see: 
> http://in.relation.to/Bloggers/HibernateORM439Final4218FinalAnd4219FinalReleased
>
> Gail Badner
> Red Hat, Hibernate ORM
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [wildfly-dev] WildFly 9.0.0.CR1 is released!

[Scott Marlow]

> What is "end of deployment"?  Is that the end of phase-2 in our 2-phase
> JPA bootstrap design?  If so, that should be fine.

Yes, the end of phase-2 in our 2-phase JPA bootstrap design should occur 
before (WildFly) deployment is complete.

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

Re: [hibernate-dev] Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final

[Scott Marlow]

Do we need to have a Hibernate ORM continuous integration test setup to 
run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or 
is ORM/Infinispan already tested as part of the Infinispan CI testing?

On 05/11/2015 04:31 AM, Galder Zamarreño wrote:
> Hi Gail,
>
> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works 
> fine with both Infinispan 7.x and 6.x:
> https://github.com/hibernate/hibernate-orm/pull/948
>
> Cheers,
>
>> On 11 May 2015, at 09:48, Galder Zamarreño  wrote:
>>
>> Hi Gail,
>>
>> Thanks for looking into this.
>>
>> For the scope of WF, the XML part is irrelevant since WF does its own 
>> configuration parsing, and hence there's no need to make any such changes in 
>> ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x standalone, 
>> then yes, they need to adjust XML configuration.
>>
>> The evict/clear issues that 7.2 brought up, and the incorrect element count 
>> can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We 
>> just need to apply the changes in a way that work regardless of whether 6.0 
>> or 7.2 is used.
>>
>> I'll work on that today.
>>
>> Cheers,
>>
>>> On 11 May 2015, at 07:49, Gail Badner  wrote:
>>>
>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
>>>
>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 
>>> 7.1.0.Final:
>>>
>>> 1) 
>>> https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
>>> 2) 
>>> https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
>>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared 
>>> duplicate 1b7e112994413559484e6873f019c5e2c557506b).
>>>
>>> 1) updated infinispan-configs.xml to use
>>> http://www.w3.org/2001/XMLSchema-instance";
>>>xmlns="urn:infinispan:config:7.0"
>>>xsi:schemaLocation="urn:infinispan:config:7.0 
>>> http://www.infinispan.org/schemas/infinispan-config-7.0.xsd";>
>>>
>>> After 1) was cherry-picked, I was able to build and run tests successfully 
>>> using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) 
>>> using Infinispan 6.0.0.Final, there were lots of test failures due to 
>>> problems configuring the cache:
>>>Caused by: org.hibernate.cache.CacheException
>>>Caused by: org.infinispan.commons.CacheConfigurationException
>>>Caused by: javax.xml.stream.XMLStreamException
>>>
>>> I've attached the output from test 
>>> org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
>>>
>>> Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 
>>> branch? Could an application have its own dependence on Infinispan 
>>> 6.0.0.Final?
>>>
>>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 
>>> 7.2.1.Final: 
>>> https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87.
>>>  After rebuilding,
>>> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase 
>>> fails. I've attached the output for that test as well.
>>>
>>> Galder, HHH-9781 is still open. Is there more work to do on this? Am I 
>>> missing some other commit that would fix the TimestampsRegionImplTestCase 
>>> failure?
>>>
>>> This commit (for HHH-9781) includes a change to use 
>>> org.infinispan.commons.util.CloseableIterator, which does not appear to be 
>>> in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
>>>
>>> Next I cherry-picked the commit for HHH-9776: 
>>> https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5.
>>>  TimestampsRegionImplTestCase still fails; there are no other failures.
>>>
>>> Galder, HHH-9776 is still open. Is there more work to be done on that issue?
>>>
>>> I've pushed this work to my fork for others to see: 
>>> https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
>>>
>>> I've postponed creating a pull request and running the TCK until we resolve 
>>> backward-compatibility requirements and the unit test failure. It's OK with 
>>> me if someone wants to go ahead and run the TCK with what I have so far.
>>>
>>> Regards,
>>> Gail
>>> 
>>
>>
>> --
>> Galder Zamarreño
>> gal...@redhat.com
>>
>>
>>
>>
>
>
> --
> Galder Zamarreño
> gal...@redhat.com
>
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Need to list entities when using Hibernate OGM on WildFly

[Scott Marlow]

I remember seeing this before but don't remember why.  Years ago, I 
blogged [1] about using OGM on JBoss AS (before the rename to WildFly). 
  I didn't name the entity classes in the blog (or git [2]), so not sure 
if that was because OGM worked better back then or I just got lucky with 
my simple test case.

By the way, we are talking about moving Jipijapa back into the WildFly 
code base, to get more eyeballs on it.  Currently its just me reviewing 
my own code changes, but on WildFly we usually get a peer code review as 
part of pull request processing.  I wanted to mention this, as we talked 
in the past about possibly adding JPA integration code for OGM (if there 
is ever a need).  Obviously, if the Jipijapa code is moving to WildFly, 
we would want to do any integration there.  This is still being discussed.

Scott

[1] 
http://in.relation.to/Bloggers/UsingADifferentPersistenceProviderWithAS701#H-ExperimentalUseOfOGMOnAS701

[2] 
https://github.com/scottmarlow/wildfly/commit/9282f0f6bd20007b834f3390c08a0978bf578d2c

On 05/13/2015 08:28 AM, Gunnar Morling wrote:
> Hi,
>
> When using Hibernate OGM on WildFly, one needs to list the entity classes
> in persistence.xml, otherwise and "Unknown entity" exception will be raised.
>
> Does anyone have a rough idea what may be causing this or where to get
> started to analyse this issue?
>
> Thanks,
>
> --Gunnar
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Another pull request for supporting Infinispan 7.2.1 in 4.3

[Scott Marlow]

On 05/13/2015 02:48 PM, Gail Badner wrote:
> As suggested by Sanne and Galder, I'll open a new Jira for the commit in my 
> pull request and amend the comment to reflect the new Jira.
>
> I'll see if I can get "forced version" in Gradle working in the next couple 
> of hours. If not, I don't want to hold up releasing 4.3.10.Final for this. I 
> can try to get those details worked out later.
>
> I think that about wraps up what is needed for Hibernate 4.3 to support and 
> test with Infinispan 7.2.1.Final.  Unless I hear otherwise, I plan to release 
> 4.3.10.Final later today, tomorrow at the latest.

Awesome, thanks for all of the help Gail in syncing Hibernate up to 
Infinispan 7.2.1!  Thanks to Sanne, Galder & Steve as well.  Very much 
appreciated!

I'm not sure of what will be in Infinispan 8.0 but that could need more 
hibernate-infinispan changes as well.  I think that Infinispan 8.0 might 
find its way into WildFly 10.

>
> Regards,
> Gail
>
> - Original Message -
>> From: "Steve Ebersole" 
>> To: "Gail Badner" 
>> Cc: "Sanne Grinovero" , "Scott Marlow" 
>> , "Galder Zamarreño"
>> , "Hibernate Dev" 
>> Sent: Wednesday, May 13, 2015 9:57:24 AM
>> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
>>
>> Not sure what limitations you mean.  All I said was that if you wanted to
>> allow testing with both you would need to make this conditional and expose
>> a property to control which to use.
>>
>> On Wed, May 13, 2015 at 11:29 AM, Gail Badner  wrote:
>>
>>> Adding hibernate-dev.
>>>
>>> No, I did not have a chance to read up on what you suggested. I sounded
>>> like it had some limitations that would not work, but maybe I
>>> misunderstood. I'll look into it today.
>>>
>>> The last couple of days have been very long. Sorry for the oversights.
>>>
>>> - Original Message -
>>>> From: "Steve Ebersole" 
>>>> To: "Gail Badner" 
>>>> Cc: "Sanne Grinovero" , "Scott Marlow" <
>>> smar...@redhat.com>, "Galder Zamarreño"
>>>> 
>>>> Sent: Wednesday, May 13, 2015 5:33:24 AM
>>>> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
>>>>
>>>> On May 13, 2015 7:32 AM, "Steve Ebersole"  wrote:
>>>>>
>>>>> 1) This really should be a hibernate-core discussion
>>>>
>>>> I meant to say hibernate-dev...
>>>>
>>>>> 2) I already suggested using forced version in Gradle and gave you a
>>> link
>>>> on how that works.  Did you read it?  Did you try it?
>>>>>
>>>>> On May 13, 2015 2:04 AM, "Gail Badner"  wrote:
>>>>>>
>>>>>> Sanne, Scott, and I discussed how Hibernate should deal with
>>> supporting
>>>> Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it would
>>>> be sufficient to:
>>>>>> - specify the Infinispan 7.2 configuration by using
>>>> hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to switch if
>>>> parsing failed);
>>>>>> - run tests manually with Infinispan 7.2 for WildFly integration
>>> testing.
>>>>>>
>>>>>> I created another pull request:
>>>> https://github.com/hibernate/hibernate-orm/pull/953
>>>>>>
>>>>>> My pull request incorporated some of Galder's changes from
>>>> https://github.com/hibernate/hibernate-orm/pull/951.
>>>>>>
>>>>>> The main differences:
>>>>>> - Hibernate will consider the 7.2 configuration as test code
>>>>>> - the 7.2 configuration can be specified using
>>>>
>>> -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
>>>>>>
>>>>>> Currently, the only way to run hibernate-infinispan tests is to change
>>>> infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice to be
>>>> able to specify infinispanVersion as a environment variable, defaulting
>>> to
>>>> 6.0.0.Final to avoid having to manually update libraries.gradle.
>>>>>>
>>>>>> Another consideration is that manually updating libraries.gradle
>>> forces
>>>> a re-build using Infinispan 7.2.1 as a dependency.
>>>>>>
>>>>>> Since WildFly will use a hiberanate-infinispan jar build against
>>>> Infinispan 6.0.0.Final (won't it???), I think it would be best if we
>>> could
>>>> run unit tests without rebuilding with Infinispan 7.2.1, but using it as
>>> a
>>>> run time dependency. I haven't been able to figure out how to do that
>>>> though.
>>>>>>
>>>>>> Anyone have an idea how to do that, even manually?
>>>>>>
>>>>>> Thoughts on all this?
>>>>>>
>>>>>> Thanks,
>>>>>> Gail
>>>>
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1

[Scott Marlow]

On 05/15/2015 01:41 AM, Gail Badner wrote:
> Following Steve's suggestion using resolutionStrategy, I was able to build 
> the hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit 
> tests with 7.2.1.Final.
>
> I'm sure there's a more elegant way to do this, so I've created a new jira 
> (HHH-9802) and a pull request with the change I made: 
> https://github.com/hibernate/hibernate-orm/pull/955 .
>
> There were actually some unit test failures in 
> InfinispanRegionFactoryTestCase using 7.2.1.Final due to 
> java.lang.NoSuchMethodError.
>
> It happens in assertions like:
>
>   assertEquals(5000, cacheCfg.eviction().maxEntries());
>
> The problem is that 
> org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() returns 
> int in 6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is 
> in the unit tests. I can probably workaround this in the unit test, but I was 
> wondering if this could cause a problem if an application used this method 
> directly.
>
> Galder, do you know if this is a concern?
>
> I have instructions in the pull request for reproducing these failures.
>
> I commented out the failing assertions locally to verify that nothing else 
> causes the test to fail.
>
> I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is 
> defined as an int. That gets initialized based on a value set for on 
> hibernate.cache.infinispan..eviction.max_entries. The only place I 
> see TypeOverrides.getEvictionMaxEntries() used is in 
> InfinispanRegionFactoryTestCase. Does this actually get used anywhere? Does 
> the value find its way into a EvictionConfiguration.maxEntries field? If so, 
> should be a long (instead of an int) in master?
>
> I had a quick chat with Scott Marlow when I realized this was a potential 
> problem and we agreed that it shouldn't block releasing Hibernate ORM 
> 4.3.10.Final. I have gone ahead and released 4.3.10.Final.

As far as I can tell, applications that compile against Infinispan 6.x, 
will be expecting cacheCfg.eviction().maxEntries() to always be an int 
(as Gail states).  Those applications will be broken when they try to 
drop in Infinispan 7.x.  I don't think this is a Hibernate bug but think 
we need input from infinispan-dev.  I'll try cross posting on that 
mailing list.

>
> I will check in on things Friday morning, but I have to leave by 10:30am and 
> will be off the rest of the day. I can pick this up on Monday if need be.
>
> Regards,
> Gail
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

I ran part of the WildFly basic integration tests against the 
https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch, 
which includes the following Hibernate versions:

ORM 5.0.0.CR1
HCA 4.0.5.Final
HS 5.2.0.Final

I am seeing the below errors.

1. The Hibernate Search test 
(org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase) 
is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L

2. In the 
org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
 
we are seeing a "java.lang.ClassNotFoundException: 
org.infinispan.commons.util.CloseableIteratorSet from [Module 
"org.hibernate.infinispan:main"http://pastie.org/10213943

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

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

Also am using Infinispan 7.2.1.Final but noticed that Infinispan 
7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master 
to upgrade Infinispan.

On 05/29/2015 12:50 PM, Scott Marlow wrote:
> I ran part of the WildFly basic integration tests against the
> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
> which includes the following Hibernate versions:
>
> ORM 5.0.0.CR1
> HCA 4.0.5.Final
> HS 5.2.0.Final
>
> I am seeing the below errors.
>
> 1. The Hibernate Search test
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L
>
> 2. In the
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> we are seeing a "java.lang.ClassNotFoundException:
> org.infinispan.commons.util.CloseableIteratorSet from [Module
> "org.hibernate.infinispan:main"http://pastie.org/10213943
>
> Scott
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 05/29/2015 01:05 PM, Sanne Grinovero wrote:
> Thanks Scott!
>
> 1. this error is expected: HS 5.2 is not compatible with ORM 5.
> We'll need a compatible WildFly version to release a compatible
> version, or alternatively know how to get the tests to run w/o the
> jipijapa patch as I was trying ;-)

In the interest of getting ORM 5 into WildFly 10 before HS is upgraded, 
we could disable 
org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase and 
create a blocking jira for WF10 assigned to you, so you can either 
enable the HibernateSearchJPATestCase test or remove Search from WildFly 
10 as you mention below (as a possible option).  Please let me know how 
you want me to proceed.

>
> A backup plan is we stop producing Hibernate Search modules for
> WildFly as part of our release, and split it up as a secondary task
> like Hardy suggested today on IRC.

>
> 2. this is not expected, especially as I think the Infinispan version
> already in WF is aligned with the one in ORM5?
> Steve, do you remember about classloader strategy changes between
> latest ORM 4.3 and 5.0.0.CR1?
>
> Sanne
>
>
> On 29 May 2015 at 17:50, Scott Marlow  wrote:
>> I ran part of the WildFly basic integration tests against the
>> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
>> which includes the following Hibernate versions:
>>
>> ORM 5.0.0.CR1
>> HCA 4.0.5.Final
>> HS 5.2.0.Final
>>
>> I am seeing the below errors.
>>
>> 1. The Hibernate Search test
>> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
>> is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L
>>
>> 2. In the
>> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
>> we are seeing a "java.lang.ClassNotFoundException:
>> org.infinispan.commons.util.CloseableIteratorSet from [Module
>> "org.hibernate.infinispan:main"http://pastie.org/10213943
>>
>> Scott
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 05/29/2015 02:03 PM, Steve Ebersole wrote:
> Scott, first please use a SNAPSHOT build as you'll need it for the HCANN
> fix I did, or you could just pull in the newest HCANN (5.0.0.Final)

Will do.

>
> As for the ClassNotFoundException, I really do not get this one.  So,
> essentially:
>
> 1) hibernate-infinispan is able to access infinispan-core classes
> 2) hibernate-infinispan makes use of
> this org/infinispan/commons/util/CloseableIteratorSet class as returned
> from classes contained in infinispan-core.  I am not sure which jar
> holds org/infinispan/commons/util/CloseableIteratorSet.  Anyone?

infinispan-commons-7.2.1.Final.jar contains 
org.infinispan.commons.util.CloseableIteratorSet


> 3) hibernate-infinispan is not able to access
> org/infinispan/commons/util/CloseableIteratorSet
>
> On Fri, May 29, 2015 at 11:57 AM, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> Also am using Infinispan 7.2.1.Final but noticed that Infinispan
> 7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master
> to upgrade Infinispan.
>
> On 05/29/2015 12:50 PM, Scott Marlow wrote:
>  > I ran part of the WildFly basic integration tests against the
>  > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5
> branch,
>  > which includes the following Hibernate versions:
>  >
>  > ORM 5.0.0.CR1
>  > HCA 4.0.5.Final
>  > HS 5.2.0.Final
>  >
>  > I am seeing the below errors.
>  >
>  > 1. The Hibernate Search test
>  >
> 
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
>  > is failing with an AbstractServiceMethodError
> http://pastebin.com/CzEgVp0L
>  >
>  > 2. In the
>  >
> 
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
>  > we are seeing a "java.lang.ClassNotFoundException:
>  > org.infinispan.commons.util.CloseableIteratorSet from [Module
>  > "org.hibernate.infinispan:main"http://pastie.org/10213943
>  >
>  > Scott
>  > ___
>  > hibernate-dev mailing list
>  > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>  > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

>
> On 05/29/2015 02:03 PM, Steve Ebersole wrote:
>> Scott, first please use a SNAPSHOT build as you'll need it for the HCANN
>> fix I did, or you could just pull in the newest HCANN (5.0.0.Final)

Should I use a pushed SNAPSHOT?

I can build ORM master via "gradlew clean install", however, "gradlew 
PublishToMavenLocal" fails on 
"hibernate-osgi:publishMavenJavaPublicationToMavenLocal" with details:

"
What went wrong:
Execution failed for task 
':hibernate-osgi:publishMavenJavaPublicationToMavenLocal'.
 > Failed to publish publication 'mavenJava' to repository 'MavenLocal'
> Invalid publication 'mavenJava': artifact file does not exist: 
'/mnt/ssd/work/hibernate5/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.1-SNAPSHOT-karaf.xml'
"

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

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 05/29/2015 02:39 PM, Steve Ebersole wrote:
> So:
> 1) hibernate-infinispan seems to be able to see infinispan-core (which
> is what defines as a dependency)
> 2) hibernate-infinispan seems to not be able to see infinispan-commons
> (which I would have to assume infinispan-core defines as a dependency)

Your right, this is a WF module/classpath issue, as hibernate-infinispan 
does not have access to org.infinispan.commons.  Not exactly sure why 
this wasn't a problem before ORM 5.x.

Adding org.infinispan.commons to the hibernate-infinispan classpath 
fixes the 
org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase failure.

Next we just have to find the WildFly bug that is causing Sanne problems 
with his Hibernate Search testing, that prevents HS from doing external 
WF testing.

>
> This sure seems like a problem in the WF module/classpath set up...
>
>
> On Fri, May 29, 2015 at 1:21 PM Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
>
>
> On 05/29/2015 02:03 PM, Steve Ebersole wrote:
>  > Scott, first please use a SNAPSHOT build as you'll need it for
> the HCANN
>  > fix I did, or you could just pull in the newest HCANN (5.0.0.Final)
>
> Will do.
>
>  >
>  > As for the ClassNotFoundException, I really do not get this one.  So,
>  > essentially:
>  >
>  > 1) hibernate-infinispan is able to access infinispan-core classes
>  > 2) hibernate-infinispan makes use of
>  > this org/infinispan/commons/util/CloseableIteratorSet class as
> returned
>  > from classes contained in infinispan-core.  I am not sure which jar
>  > holds org/infinispan/commons/util/CloseableIteratorSet.  Anyone?
>
> infinispan-commons-7.2.1.Final.jar contains
> org.infinispan.commons.util.CloseableIteratorSet
>
>
>  > 3) hibernate-infinispan is not able to access
>  > org/infinispan/commons/util/CloseableIteratorSet
>  >
>  > On Fri, May 29, 2015 at 11:57 AM, Scott Marlow
> mailto:smar...@redhat.com>
>  > <mailto:smar...@redhat.com <mailto:smar...@redhat.com>>> wrote:
>  >
>  > Also am using Infinispan 7.2.1.Final but noticed that Infinispan
>  > 7.2.2.Final is now in WildFly 10, so I'll sync my branch with
> WF master
>  > to upgrade Infinispan.
>  >
>  > On 05/29/2015 12:50 PM, Scott Marlow wrote:
>  >  > I ran part of the WildFly basic integration tests against the
>  >  >
> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5
>  > branch,
>  >  > which includes the following Hibernate versions:
>  >  >
>  >  > ORM 5.0.0.CR1
>  >  > HCA 4.0.5.Final
>  >  > HS 5.2.0.Final
>  >  >
>  >  > I am seeing the below errors.
>  >  >
>  >  > 1. The Hibernate Search test
>  >  >
>  >
>   
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
>  >  > is failing with an AbstractServiceMethodError
>  > http://pastebin.com/CzEgVp0L
>  >  >
>  >  > 2. In the
>  >  >
>  >
>   
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
>  >  > we are seeing a "java.lang.ClassNotFoundException:
>  >  > org.infinispan.commons.util.CloseableIteratorSet from [Module
>  >  > "org.hibernate.infinispan:main"http://pastie.org/10213943
>  >  >
>  >  > Scott
>  >  > ___
>  >  > hibernate-dev mailing list
>  >  > hibernate-dev@lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
> <mailto:hibernate-dev@lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>>
>  >  > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  >  >
>  > ___
>  > hibernate-dev mailing list
>  > hibernate-dev@lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
> <mailto:hibernate-dev@lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>>
>  > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  >
>  >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 06/17/2015 06:44 AM, Sanne Grinovero wrote:
> Hi Scott,
> can we expect to see both Hibernate ORM 5 and this latest Hibernate
> Search version 5.4.0.Alpha1 soon in WildFly 10?

I hope so.  https://github.com/wildfly/wildfly/pull/7509 is passing the 
testsuite and I made the suggested code changes.  I asked for an ETA on 
the PR.

>
> thanks,
> Sanne
>
> On 4 June 2015 at 23:47, Sanne Grinovero  wrote:
>> On 29 May 2015 at 18:27, Scott Marlow  wrote:
>>>
>>>
>>> On 05/29/2015 01:05 PM, Sanne Grinovero wrote:
>>>>
>>>> Thanks Scott!
>>>>
>>>> 1. this error is expected: HS 5.2 is not compatible with ORM 5.
>>>> We'll need a compatible WildFly version to release a compatible
>>>> version, or alternatively know how to get the tests to run w/o the
>>>> jipijapa patch as I was trying ;-)
>>>
>>>
>>> In the interest of getting ORM 5 into WildFly 10 before HS is upgraded, we
>>> could disable
>>> org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase
>>> and create a blocking jira for WF10 assigned to you, so you can either
>>> enable the HibernateSearchJPATestCase test or remove Search from WildFly 10
>>> as you mention below (as a possible option).  Please let me know how you
>>> want me to proceed.
>>
>> That won't be necessary, as a compatible release is now available:
>> update Hibernate Search to version 5.4.0.Alpha1 when you upgrade Hibernate 
>> ORM.
>>
>> (don't upgrade HS w/o ORM to 5: it's required for this version of
>> Hibernate Search)
>>
>> Thanks!
>>
>> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 06/17/2015 08:57 AM, Sanne Grinovero wrote:
> On 17 June 2015 at 13:44, Scott Marlow  wrote:
>>
>>
>> On 06/17/2015 06:44 AM, Sanne Grinovero wrote:
>>>
>>> Hi Scott,
>>> can we expect to see both Hibernate ORM 5 and this latest Hibernate
>>> Search version 5.4.0.Alpha1 soon in WildFly 10?
>>
>>
>> I hope so.  https://github.com/wildfly/wildfly/pull/7509 is passing the
>> testsuite and I made the suggested code changes.  I asked for an ETA on the
>> PR.
>
> The actual update will be done in another PR after that is merged
> right? I didn't see the update in that one.

Correct, I kept the ORM 5 upgrade as a separate change.

> Maybe it's worth to include both changes in one pull request?

Problem is that could delay getting the above pull request merged in, 
which is something that I'd like to see happen first.

>
>>
>>
>>>
>>> thanks,
>>> Sanne
>>>
>>> On 4 June 2015 at 23:47, Sanne Grinovero  wrote:
>>>>
>>>> On 29 May 2015 at 18:27, Scott Marlow  wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 05/29/2015 01:05 PM, Sanne Grinovero wrote:
>>>>>>
>>>>>>
>>>>>> Thanks Scott!
>>>>>>
>>>>>> 1. this error is expected: HS 5.2 is not compatible with ORM 5.
>>>>>> We'll need a compatible WildFly version to release a compatible
>>>>>> version, or alternatively know how to get the tests to run w/o the
>>>>>> jipijapa patch as I was trying ;-)
>>>>>
>>>>>
>>>>>
>>>>> In the interest of getting ORM 5 into WildFly 10 before HS is upgraded,
>>>>> we
>>>>> could disable
>>>>>
>>>>> org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase
>>>>> and create a blocking jira for WF10 assigned to you, so you can either
>>>>> enable the HibernateSearchJPATestCase test or remove Search from WildFly
>>>>> 10
>>>>> as you mention below (as a possible option).  Please let me know how you
>>>>> want me to proceed.
>>>>
>>>>
>>>> That won't be necessary, as a compatible release is now available:
>>>> update Hibernate Search to version 5.4.0.Alpha1 when you upgrade
>>>> Hibernate ORM.
>>>>
>>>> (don't upgrade HS w/o ORM to 5: it's required for this version of
>>>> Hibernate Search)
>>>>
>>>> Thanks!
>>>>
>>>> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

Sanne,

The [1] pull request to bring Jipijapa source into WildFly master is merged.

I pushed a copy of the (work in progress) ORM 5 changes to github [2].

Is there a WildFly pull request for the changes to upgrade to Hibernate 
Search 5.4.0.Alpha1?  I didn't see one but I might of missed it.

Scott

[1] https://github.com/wildfly/wildfly/pull/7509

[2] https://github.com/scottmarlow/wildfly/tree/hibernate5_june18
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 06/18/2015 11:59 AM, Sanne Grinovero wrote:
> On 18 June 2015 at 15:55, Scott Marlow  wrote:
>> Sanne,
>>
>> The [1] pull request to bring Jipijapa source into WildFly master is merged.
>>
>> I pushed a copy of the (work in progress) ORM 5 changes to github [2].
>>
>> Is there a WildFly pull request for the changes to upgrade to Hibernate
>> Search 5.4.0.Alpha1?  I didn't see one but I might of missed it.
>
> No there isn't, as Hibernate Search 5.4.0.Alpha1 *requires* Hibernate
> ORM 5.0.0.CR1.

What needs to change on WildFly for the Hibernate Search upgrade?  I 
started with just changing the WildFly (top level) pom.xml to reference 
HS 5.4.0.Alpha1.  Do you expect that the latest ORM master branch will 
work with HS 5.4.0.Alpha1 or is ORM 5.0.0.CR1 better?

Locally, I am building the latest ORM master (built from source) and 
using Hibernate Search 5.4.0.Alpha1.  When running the WildFly 
testsuite, I see a few different errors.  One of them is from the 
HibernateSearchJPATestCase.testFullTextQuery test. 
http://pastebin.com/Q5xLrkpT shows the WildFly server.log contents from 
the Hibernate Search test.

>
> The two should be updated in synch this time, in future there will be
> more flexibility.
>
>>
>> Scott
>>
>> [1] https://github.com/wildfly/wildfly/pull/7509
>>
>> [2] https://github.com/scottmarlow/wildfly/tree/hibernate5_june18
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 06/18/2015 01:41 PM, Steve Ebersole wrote:
> That should still be ok.  If it does not work, that would be a bug.

A few other WildFly (JPA) tests also get the same error.

>
> On Thu, Jun 18, 2015 at 11:38 AM Sanne Grinovero  <mailto:sa...@hibernate.org>> wrote:
>
> On 18 June 2015 at 17:17, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>  >
>  >
>  > On 06/18/2015 11:59 AM, Sanne Grinovero wrote:
>      >>
>  >> On 18 June 2015 at 15:55, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>  >>>
>  >>> Sanne,
>  >>>
>  >>> The [1] pull request to bring Jipijapa source into WildFly
> master is
>  >>> merged.
>  >>>
>  >>> I pushed a copy of the (work in progress) ORM 5 changes to
> github [2].
>  >>>
>  >>> Is there a WildFly pull request for the changes to upgrade to
> Hibernate
>  >>> Search 5.4.0.Alpha1?  I didn't see one but I might of missed it.
>  >>
>  >>
>  >> No there isn't, as Hibernate Search 5.4.0.Alpha1 *requires*
> Hibernate
>  >> ORM 5.0.0.CR1.
>  >
>  >
>  > What needs to change on WildFly for the Hibernate Search upgrade?
>
>
> Nothing else changes. Just change the Hibernate Search version when
> you change the Hibernate ORM version.
>
>  > I started
>  > with just changing the WildFly (top level) pom.xml to reference HS
>  > 5.4.0.Alpha1.
>
> +1
>
>  >  Do you expect that the latest ORM master branch will work
>  > with HS 5.4.0.Alpha1 or is ORM 5.0.0.CR1 better?
>
> I didn't test the latest ORM master branch, but it will work with
> ORM 5.0.0.CR1.
>
>  > Locally, I am building the latest ORM master (built from source)
> and using
>  > Hibernate Search 5.4.0.Alpha1.  When running the WildFly
> testsuite, I see a
>  > few different errors.  One of them is from the
>  > HibernateSearchJPATestCase.testFullTextQuery test.
>  > http://pastebin.com/Q5xLrkpT shows the WildFly server.log
> contents from the
>  > Hibernate Search test.
>
> That looks like related to an Hibernate ORM change, not Search.
> The entity used for that test doesn't declare the fields as "public";
> that used to be ok in previous versions.
> You could workaround it by changing the test to use either public
> fields or traditional getters/setters?
> But we should check with Steve if that change was intentional? For
> now, better to workaround it in the test so we don't get stuck.
>
> Thanks!
> Sanne
>
>  >
>  >
>  >>
>  >> The two should be updated in synch this time, in future there
> will be
>  >> more flexibility.
>  >>
>  >>>
>  >>> Scott
>  >>>
>  >>> [1] https://github.com/wildfly/wildfly/pull/7509
>  >>>
>  >>> [2] https://github.com/scottmarlow/wildfly/tree/hibernate5_june18
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

I tried deploying a simple 2lc enabled test app and got a CNFE on 
Infinispan classes being referenced from the application classloader.

http://pastebin.com/PREzm6bn shows the exception.  I'm guessing this is 
a classloader issue in ORM 5 to be worked out.

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

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

To be a little more specific, WildFly is now respecting the Hibernate 
Search desire for Infinispan classes to *not* be available to Hibernate 
core/entitymanager.  This is important so that Hibernate Search can have 
the flexibility to use a different version of Infinispan than WildFly is 
using with hibernate-infinispan.  This seemed to work with Hibernate ORM 
4.3.x.

On 06/18/2015 04:28 PM, Scott Marlow wrote:
> I tried deploying a simple 2lc enabled test app and got a CNFE on
> Infinispan classes being referenced from the application classloader.
>
> http://pastebin.com/PREzm6bn shows the exception.  I'm guessing this is
> a classloader issue in ORM 5 to be worked out.
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

I'll see if I can capture a more complete exception call stack for the CNFE.

On 06/19/2015 09:32 AM, Steve Ebersole wrote:
> If Infinispan is not available to core/hem than I am not sure how ORM
> not being able to find Infinispan classes is a problem with class
> loading in ORM.  Seems to me this is simply a problem in the ClassLoader
> made available to ORM.
>
> On Fri, Jun 19, 2015 at 7:46 AM Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> To be a little more specific, WildFly is now respecting the Hibernate
> Search desire for Infinispan classes to *not* be available to Hibernate
> core/entitymanager.  This is important so that Hibernate Search can have
> the flexibility to use a different version of Infinispan than WildFly is
> using with hibernate-infinispan.  This seemed to work with Hibernate ORM
>     4.3.x.
>
> On 06/18/2015 04:28 PM, Scott Marlow wrote:
>  > I tried deploying a simple 2lc enabled test app and got a CNFE on
>  > Infinispan classes being referenced from the application classloader.
>  >
>  > http://pastebin.com/PREzm6bn shows the exception.  I'm guessing
> this is
>  > a classloader issue in ORM 5 to be worked out.
>  >
>  > ___
>  > hibernate-dev mailing list
>  > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>  > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

Complete exception call stack is here http://pastebin.com/564BNWSF

On 06/19/2015 09:43 AM, Scott Marlow wrote:
> I'll see if I can capture a more complete exception call stack for the CNFE.
>
> On 06/19/2015 09:32 AM, Steve Ebersole wrote:
>> If Infinispan is not available to core/hem than I am not sure how ORM
>> not being able to find Infinispan classes is a problem with class
>> loading in ORM.  Seems to me this is simply a problem in the ClassLoader
>> made available to ORM.
>>
>> On Fri, Jun 19, 2015 at 7:46 AM Scott Marlow > <mailto:smar...@redhat.com>> wrote:
>>
>>  To be a little more specific, WildFly is now respecting the Hibernate
>>  Search desire for Infinispan classes to *not* be available to Hibernate
>>  core/entitymanager.  This is important so that Hibernate Search can have
>>  the flexibility to use a different version of Infinispan than WildFly is
>>  using with hibernate-infinispan.  This seemed to work with Hibernate ORM
>>  4.3.x.
>>
>>  On 06/18/2015 04:28 PM, Scott Marlow wrote:
>>   > I tried deploying a simple 2lc enabled test app and got a CNFE on
>>   > Infinispan classes being referenced from the application classloader.
>>   >
>>   > http://pastebin.com/PREzm6bn shows the exception.  I'm guessing
>>  this is
>>   > a classloader issue in ORM 5 to be worked out.
>>   >
>>   > ___
>>   > hibernate-dev mailing list
>>   > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>>   > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>   >
>>  ___
>>  hibernate-dev mailing list
>>  hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>>  https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

I'm not exactly sure how infinispan-commons finds the infinispan-core 
classloader with ORM 4.3, but clearly that is not working now with ORM 5.0.

In WildFly, the infinispan-commons classloader doesn't have access to 
the infinispan-core classloader.

This seems somewhat related to the CNFE on 
org.infinispan.commons.util.CloseableIteratorSet in hibernate-infinispan 
that we talked about on IRC a few weeks ago 
(http://pastebin.com/atGrC124).  We worked around that by adding the 
infinispan-commons classloader to the hibernate-infinispan classloader 
(in WildFly 10).


On 06/19/2015 09:50 AM, Scott Marlow wrote:
> Complete exception call stack is here http://pastebin.com/564BNWSF
>
> On 06/19/2015 09:43 AM, Scott Marlow wrote:
>> I'll see if I can capture a more complete exception call stack for the CNFE.
>>
>> On 06/19/2015 09:32 AM, Steve Ebersole wrote:
>>> If Infinispan is not available to core/hem than I am not sure how ORM
>>> not being able to find Infinispan classes is a problem with class
>>> loading in ORM.  Seems to me this is simply a problem in the ClassLoader
>>> made available to ORM.
>>>
>>> On Fri, Jun 19, 2015 at 7:46 AM Scott Marlow >> <mailto:smar...@redhat.com>> wrote:
>>>
>>>   To be a little more specific, WildFly is now respecting the Hibernate
>>>   Search desire for Infinispan classes to *not* be available to 
>>> Hibernate
>>>   core/entitymanager.  This is important so that Hibernate Search can 
>>> have
>>>   the flexibility to use a different version of Infinispan than WildFly 
>>> is
>>>   using with hibernate-infinispan.  This seemed to work with Hibernate 
>>> ORM
>>>   4.3.x.
>>>
>>>   On 06/18/2015 04:28 PM, Scott Marlow wrote:
>>>> I tried deploying a simple 2lc enabled test app and got a CNFE on
>>>> Infinispan classes being referenced from the application 
>>> classloader.
>>>>
>>>> http://pastebin.com/PREzm6bn shows the exception.  I'm guessing
>>>   this is
>>>> a classloader issue in ORM 5 to be worked out.
>>>>
>>>> ___
>>>> hibernate-dev mailing list
>>>> hibernate-dev@lists.jboss.org 
>>> <mailto:hibernate-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>   ___
>>>   hibernate-dev mailing list
>>>   hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>>>   https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

The ISE message is:
"
Can not set java.lang.Long field 
org.jboss.as.test.integration.hibernate.search.Book.id to 
org.jboss.as.test.integration.hibernate.search.Book
", which does sound like a bug.


On 06/18/2015 01:41 PM, Steve Ebersole wrote:
> That should still be ok.  If it does not work, that would be a bug.
>
> On Thu, Jun 18, 2015 at 11:38 AM Sanne Grinovero  <mailto:sa...@hibernate.org>> wrote:
>
>     On 18 June 2015 at 17:17, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>  >
>  >
>  > On 06/18/2015 11:59 AM, Sanne Grinovero wrote:
>  >>
>  >> On 18 June 2015 at 15:55, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>  >>>
>  >>> Sanne,
>  >>>
>  >>> The [1] pull request to bring Jipijapa source into WildFly
> master is
>  >>> merged.
>  >>>
>  >>> I pushed a copy of the (work in progress) ORM 5 changes to
> github [2].
>  >>>
>  >>> Is there a WildFly pull request for the changes to upgrade to
> Hibernate
>  >>> Search 5.4.0.Alpha1?  I didn't see one but I might of missed it.
>  >>
>  >>
>  >> No there isn't, as Hibernate Search 5.4.0.Alpha1 *requires*
> Hibernate
>  >> ORM 5.0.0.CR1.
>  >
>  >
>  > What needs to change on WildFly for the Hibernate Search upgrade?
>
>
> Nothing else changes. Just change the Hibernate Search version when
> you change the Hibernate ORM version.
>
>  > I started
>  > with just changing the WildFly (top level) pom.xml to reference HS
>  > 5.4.0.Alpha1.
>
> +1
>
>  >  Do you expect that the latest ORM master branch will work
>  > with HS 5.4.0.Alpha1 or is ORM 5.0.0.CR1 better?
>
> I didn't test the latest ORM master branch, but it will work with
> ORM 5.0.0.CR1.
>
>  > Locally, I am building the latest ORM master (built from source)
> and using
>  > Hibernate Search 5.4.0.Alpha1.  When running the WildFly
> testsuite, I see a
>  > few different errors.  One of them is from the
>  > HibernateSearchJPATestCase.testFullTextQuery test.
>  > http://pastebin.com/Q5xLrkpT shows the WildFly server.log
> contents from the
>  > Hibernate Search test.
>
> That looks like related to an Hibernate ORM change, not Search.
> The entity used for that test doesn't declare the fields as "public";
> that used to be ok in previous versions.
> You could workaround it by changing the test to use either public
> fields or traditional getters/setters?
> But we should check with Steve if that change was intentional? For
> now, better to workaround it in the test so we don't get stuck.
>
> Thanks!
> Sanne
>
>  >
>  >
>  >>
>  >> The two should be updated in synch this time, in future there
> will be
>  >> more flexibility.
>  >>
>  >>>
>  >>> Scott
>  >>>
>  >>> [1] https://github.com/wildfly/wildfly/pull/7509
>  >>>
>  >>> [2] https://github.com/scottmarlow/wildfly/tree/hibernate5_june18
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 06/26/2015 12:12 PM, Sanne Grinovero wrote:
> On 26 June 2015 at 15:02, Scott Marlow  wrote:
>> The ISE message is:
>> "
>> Can not set java.lang.Long field
>> org.jboss.as.test.integration.hibernate.search.Book.id to
>> org.jboss.as.test.integration.hibernate.search.Book
>> ", which does sound like a bug.
>
> Hi Scott, could you just make those fields in the test "public", so we
> can get an ORM5 version of WildFly to play with? We've lots more work
> to do which is blocked by that.
>
> I've opened HHH-9887 to track this, but I'd treat it as a minor
> regression which shouldn't slow us down with integration in WildFly;
> not least it would be much more convenient for us to reproduce this if
> we upgrade WildFly first.

Which ORM class should be debugged to find the cause?  The same error 
occurs whether the 'id' field is public or not (see my comment on 
HHH-9887).

The same failure occurs for WildFly tests: HibernateSearchJPATestCase, 
JPABeanValidationTestCase, DataSourceDefinitionJPATestCase, 
JPA2LCTestCase, WebJPATestCase.

>
> Thanks,
> Sanne
>
>
>>
>> On 06/18/2015 01:41 PM, Steve Ebersole wrote:
>>>
>>> That should still be ok.  If it does not work, that would be a bug.
>>>
>>> On Thu, Jun 18, 2015 at 11:38 AM Sanne Grinovero >> <mailto:sa...@hibernate.org>> wrote:
>>>
>>>  On 18 June 2015 at 17:17, Scott Marlow >>  <mailto:smar...@redhat.com>> wrote:
>>>   >
>>>   >
>>>   > On 06/18/2015 11:59 AM, Sanne Grinovero wrote:
>>>   >>
>>>   >> On 18 June 2015 at 15:55, Scott Marlow >>  <mailto:smar...@redhat.com>> wrote:
>>>   >>>
>>>   >>> Sanne,
>>>   >>>
>>>   >>> The [1] pull request to bring Jipijapa source into WildFly
>>>  master is
>>>   >>> merged.
>>>   >>>
>>>   >>> I pushed a copy of the (work in progress) ORM 5 changes to
>>>  github [2].
>>>   >>>
>>>   >>> Is there a WildFly pull request for the changes to upgrade to
>>>  Hibernate
>>>   >>> Search 5.4.0.Alpha1?  I didn't see one but I might of missed it.
>>>   >>
>>>   >>
>>>   >> No there isn't, as Hibernate Search 5.4.0.Alpha1 *requires*
>>>  Hibernate
>>>   >> ORM 5.0.0.CR1.
>>>   >
>>>   >
>>>   > What needs to change on WildFly for the Hibernate Search upgrade?
>>>
>>>
>>>  Nothing else changes. Just change the Hibernate Search version when
>>>  you change the Hibernate ORM version.
>>>
>>>   > I started
>>>   > with just changing the WildFly (top level) pom.xml to reference HS
>>>   > 5.4.0.Alpha1.
>>>
>>>  +1
>>>
>>>   >  Do you expect that the latest ORM master branch will work
>>>   > with HS 5.4.0.Alpha1 or is ORM 5.0.0.CR1 better?
>>>
>>>  I didn't test the latest ORM master branch, but it will work with
>>>  ORM 5.0.0.CR1.
>>>
>>>   > Locally, I am building the latest ORM master (built from source)
>>>  and using
>>>   > Hibernate Search 5.4.0.Alpha1.  When running the WildFly
>>>  testsuite, I see a
>>>   > few different errors.  One of them is from the
>>>   > HibernateSearchJPATestCase.testFullTextQuery test.
>>>   > http://pastebin.com/Q5xLrkpT shows the WildFly server.log
>>>  contents from the
>>>   > Hibernate Search test.
>>>
>>>  That looks like related to an Hibernate ORM change, not Search.
>>>  The entity used for that test doesn't declare the fields as "public";
>>>  that used to be ok in previous versions.
>>>  You could workaround it by changing the test to use either public
>>>  fields or traditional getters/setters?
>>>  But we should check with Steve if that change was intentional? For
>>>  now, better to workaround it in the test so we don't get stuck.
>>>
>>>  Thanks!
>>>  Sanne
>>>
>>>   >
>>>   >
>>>   >>
>>>   >> The two should be updated in synch this time, in future there
>>>  will be
>>>   >> more flexibility.
>>>   >>
>>>   >>>
>>>   >>> Scott
>>>   >>>
>>>   >>> [1] https://github.com/wildfly/wildfly/pull/7509
>>>   >>>
>>>   >>> [2] https://github.com/scottmarlow/wildfly/tree/hibernate5_june18
>>>  ___
>>>  hibernate-dev mailing list
>>>  hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>>>  https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

[Scott Marlow]

On 06/29/2015 10:06 AM, Steve Ebersole wrote:
> org.hibernate.property.access.spi.GetterFieldImpl
>
> Its possible something is amiss
> in org.hibernate.property.access.internal.PropertyAccessStrategyFieldImpl,
> but considering GetterFieldImpl is chosen (properly) and that is where
> things break down that is where I would look.

The PropertyAccessFieldImpl ctor is passed with the 'containerJavaType' 
parameter set to class 
org.jboss.as.test.integration.hibernate.search.Book that is defined by 
the javax.persistence.spi.PersistenceUnitInfo.getNewTempClassLoader().

I wonder if 
org.hibernate.boot.internal.ClassLoaderAccessImpl.classForName(String 
name), should use the PersistenceUnitInfo.getClassLoader() instead of 
getNewTempClassLoader(), once we are in the second bootstrap phase 
(which we are when ClassLoaderAccessImpl.classForName(String) is called 
in this particular WildFly test case).

 From a WildFly classloading perspective, once we call 
EntityManagerFactoryBuilderImpl.build(), all application class 
enhancing/rewriting should be complete, so we should prefer the 
PersistenceUnitInfo.getClassLoader() once we reach the second bootstrap 
phase.

>
> I find it strange though that this works in our test suite.  Maybe some
> strange class loader issue?
>
> On Mon, Jun 29, 2015 at 8:18 AM Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> On 06/26/2015 12:12 PM, Sanne Grinovero wrote:
>  > On 26 June 2015 at 15:02, Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>  >> The ISE message is:
>  >> "
>  >> Can not set java.lang.Long field
>  >> org.jboss.as.test.integration.hibernate.search.Book.id
> <http://org.jboss.as.test.integration.hibernate.search.Book.id> to
>  >> org.jboss.as.test.integration.hibernate.search.Book
>  >> ", which does sound like a bug.
>  >
>  > Hi Scott, could you just make those fields in the test "public",
> so we
>  > can get an ORM5 version of WildFly to play with? We've lots more work
>  > to do which is blocked by that.
>  >
>  > I've opened HHH-9887 to track this, but I'd treat it as a minor
>  > regression which shouldn't slow us down with integration in WildFly;
>  > not least it would be much more convenient for us to reproduce
> this if
>  > we upgrade WildFly first.
>
> Which ORM class should be debugged to find the cause?  The same error
> occurs whether the 'id' field is public or not (see my comment on
> HHH-9887).
>
> The same failure occurs for WildFly tests: HibernateSearchJPATestCase,
> JPABeanValidationTestCase, DataSourceDefinitionJPATestCase,
> JPA2LCTestCase, WebJPATestCase.
>
>  >
>  > Thanks,
>  > Sanne
>  >
>  >
>  >>
>  >> On 06/18/2015 01:41 PM, Steve Ebersole wrote:
>  >>>
>  >>> That should still be ok.  If it does not work, that would be a bug.
>  >>>
>  >>> On Thu, Jun 18, 2015 at 11:38 AM Sanne Grinovero
> mailto:sa...@hibernate.org>
>  >>> <mailto:sa...@hibernate.org <mailto:sa...@hibernate.org>>> wrote:
>  >>>
>  >>>  On 18 June 2015 at 17:17, Scott Marlow  <mailto:smar...@redhat.com>
>  >>>  <mailto:smar...@redhat.com <mailto:smar...@redhat.com>>>
> wrote:
>  >>>   >
>  >>>   >
>  >>>   > On 06/18/2015 11:59 AM, Sanne Grinovero wrote:
>  >>>   >>
>  >>>   >> On 18 June 2015 at 15:55, Scott Marlow
> mailto:smar...@redhat.com>
>  >>>  <mailto:smar...@redhat.com <mailto:smar...@redhat.com>>>
> wrote:
>  >>>   >>>
>  >>>   >>> Sanne,
>  >>>   >>>
>  >>>   >>> The [1] pull request to bring Jipijapa source into
> WildFly
>  >>>  master is
>  >>>   >>> merged.
>  >>>   >>>
>  >>>   >>> I pushed a copy of the (work in progress) ORM 5
> changes to
>  >>>  github [2].
>  >>>   >>>
>  >>>   >>> Is there a WildFly pull request for the changes to
> upgrade to
>  >>>  Hibernate
>  >>>   >>> Search 5.4.0.Alpha1?  I didn't see one but I might of
> m

Re: [hibernate-dev] Building snapshots of Hibernate ORM / master

[Scott Marlow]

> I was hoping I could ignore the osgi module and take what it built to
> experiment with Scott's branch, but while on HHH-9887 he mentions
> being down to two failures, I'm having still dozens of failures so I
> suspect I'll need some advice on the build.
>
> Scott, could you share which exact commit id did you use to test
> Hibernate ORM on your branch "hibernate5_july2", and how I can build
> it like yours ?

To build ORM, I use:

./gradlew clean install generateKarafFeatures publishToMavenLocal

I last built against ORM master commit id 
9b5bb9751cdd15eaf1049d2b51f6f4a61b878ed8

Then I built WildFly via:

cd wildfly
/build.sh clean install -DskipTests=true

To recreate the WildFly test failures:
cd wildfly/testsuite/integration/basic
mvn clean install -Dtest=*JPA*


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

[hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

Hardy,

It seems that the ValidatorFactoryBean#createConstraintValidatorFactory 
is getting called too late for some reason. 
http://pastebin.com/WrdD91Hr shows the call stack for 
ValidatorFactoryBean#create(CreationalContext ctx) 
which calls createConstraintValidatorFactory, which seems too late 
(CdiValidatorFactoryService is shutting down).

To recreate the WildFly ORM 5 issue on WildFly (if you want to see it 
yourself), steps are:

1.  Build latest ORM master branch (./gradlew clean publishToMavenLocal).

2.  Build https://github.com/scottmarlow/wildfly/tree/hibernate5_july2 
branch (./build.sh clean install -DskipTests=true).

3. change into wildfly/testsuite/integration/basic folder and run "mvn 
clean install -Dtest=*BeanValidationCdiIntegrationTestCase*
"

To run WildFly with the debugger, cd into 
wildfly/dist/target/wildfly-10.0.0.Alpha5-SNAPSHOT/bin and edit the 
standalone.conf file.  Uncomment the "remote socket debugger" line #57 
to look something like the following:

JAVA_OPTS="$JAVA_OPTS 
-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y"

Then start WildFly, via ./standalone.sh and open port 8787 with your 
debugger.

Then run the test (step #3 above) and your debugger breakpoint should be 
hit.

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

Re: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

On 07/08/2015 07:15 AM, Sanne Grinovero wrote:
> On 8 July 2015 at 11:42, Hardy Ferentschik  wrote:
>> On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>>> Hardy,
>>>
>>> It seems that the ValidatorFactoryBean#createConstraintValidatorFactory is
>>> getting called too late for some reason. http://pastebin.com/WrdD91Hr shows
>>> the call stack for
>>> ValidatorFactoryBean#create(CreationalContext ctx) which
>>> calls createConstraintValidatorFactory, which seems too late
>>> (CdiValidatorFactoryService is shutting down).
>>
>> Did you not change some of the integration code in order to upgrade to ORM 5
>> within Wildfly? It is not just a version upgrade, right?
>>
>> The reason I am asking is that afaik we jump through quite some hoops 
>> regarding
>> the Bean Validation integration to ensure that the JNDI bound 
>> Validator(Factory)
>> is CDI enabled and identical to the one which can be retrieved via CDI. This
>> is the whole LazyValidatorFactory stuff. I am not so familiar with this code,
>> but I am wondering whether your changes for the ORM 5 integration interfere 
>> with
>> the Bean Valiadtion bootstrapping. What needed to change for the ORM 5 
>> integration?
>> I know that you and Sanne discussed the ability to bootstrap the 
>> PersistenceProvider
>> using the API as defined by JPA. Did you go in this direction?

The ORM integration code does not interact with the Bean Validation 
bootstrapping.  That is done the same (by the JPA 
container/deployer/subsystem) for any persistence provider that we 
integrate with.

>>
>>> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
>>> yourself), steps are:
>>
>> Ok, I'll take a look at your branch.
>>
>> Is this test failure the last hurdle to integrate ORM5 into Wildfly 10?

Yes.

>
> I have the same question, I'm confused as yesterday I heard we were
> down to zero failures.

There were certain tests that I was not running locally.  I found that 
the following command runs all of the WildFly tests that I really wanted 
to run:

./integration-tests.sh -Dts.basic -Dmaven.test.failure.ignore=true 
-DfailIfNoTests=false

I also ran the WildFly clustering tests which replicate an extended 
persistence context.  No failures with those.

> Did something else change, or are tests being run in incremental
> iterations? Just wondering how confident we are about not seeing more
> issues being reported tomorrow.

I am planning on running the EE TCK tests with ORM 5 CR2 after it is 
merged.  There may be EE TCK test failures with ORM 5 that will need to 
be addressed this summer (before end of August).

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

Re: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

On 07/08/2015 08:16 AM, Hardy Ferentschik wrote:
> On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>> To recreate the WildFly ORM 5 issue on WildFly (if you want to see it
>> yourself), steps are:
>
> For the record, I see the same test failures locally. I have not looked any
> further regarding their cause.
>
> @Scott, on a high level what are the changes which were required to integrate 
> ORM 5.
> Anything which you in your opinion interfere with the Bean Validation 
> integration?

The same test works with the WildFly master branch, which is using ORM 
4.3.x.  The Bean Validation integration code is unchanged in my WildFly 
branch, as is the Bean Validator.  The only thing different, is the ORM 
5 integration code and the ORM 5 persistence provider.

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

Re: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

Here are a few different call stacks:

1.  http://pastebin.com/ZiZL5vEh shows the call stack when running 
against the WildFly master branch (with ORM 4.3.x) and the @Inject works 
(the test 
org.jboss.as.test.integration.jpa.beanvalidation.cdi.CustomMinValidator.setMinimumValueProvider()
 
method is being called in the call stack).

2.  http://pastebin.com/ApYVvUHL shows the NPE that I get on the 
https://github.com/scottmarlow/wildfly/tree/hibernate5_july2 branch to 
run the BeanValidationCdiIntegrationTestCase.  The NPE occurs because 
the 
org.jboss.as.test.integration.jpa.beanvalidation.cdi.CustomMinValidator.setMinimumValueProvider()
 
is not called.

On 07/08/2015 08:33 AM, Gunnar Morling wrote:
> Scott, could you update the Gist with the complete stack trace you got?
> It seems to only contains parts of it.

I captured the call stack http://pastebin.com/WrdD91Hr right before 
stepping into the call to private method 
org.hibernate.validator.internal.cdi.ValidatorFactoryBean#createConstraintValidatorFactory()
 
which is called from 
ValidatorFactoryBean.create(CreationalContext ctx).

>
> 2015-07-08 14:32 GMT+02:00 Scott Marlow  <mailto:smar...@redhat.com>>:
>
>
>
> On 07/08/2015 08:16 AM, Hardy Ferentschik wrote:
>  > On Tue, Jul 07, 2015 at 04:50:36PM -0400, Scott Marlow wrote:
>  >> To recreate the WildFly ORM 5 issue on WildFly (if you want to
> see it
>  >> yourself), steps are:
>  >
>  > For the record, I see the same test failures locally. I have not
> looked any
>  > further regarding their cause.
>  >
>  > @Scott, on a high level what are the changes which were required
> to integrate ORM 5.
>  > Anything which you in your opinion interfere with the Bean
> Validation integration?
>
> The same test works with the WildFly master branch, which is using ORM
> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
> branch, as is the Bean Validator.  The only thing different, is the ORM
> 5 integration code and the ORM 5 persistence provider.
>
>  >
>  > --Hardy
>  >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
> Hi,
>
>> The same test works with the WildFly master branch, which is using ORM
>> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
>> branch, as is the Bean Validator.  The only thing different, is the ORM 5
>> integration code and the ORM 5 persistence provider.
>
> Just fishing here, but "integration code and the ORM 5 persistence provider" 
> might
> indicate a problem in the persistence bootstrapping.
> Have a look at 
> org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
> Basically ORM expects to retrieve the ValidatorFactory to use for the life 
> cycle based
> validation from the properties passed via the Persistence bootstrap. The 
> property name
> is javax.persistence.validation.factory. If there is no instance passed ORM 
> will bootstrap
> a default factory using  Validation.buildDefaultValidatorFactory(). The 
> latter would
> of course not be CDI enabled. This would explain why validation occurs, but 
> not CDI injection.
> I would for sure put a breakpoint in there as well (and some trace/debug log 
> would be probably
> nice to have as well to easily tell whether a factory is passed or a default 
> one is generated.

Good suggestion, the validation factory does get passed in during the 
second bootstrap phase.  If we looked for it during the first JPA 
bootstrap phase, we would not see it in Hibernate ORM 5.  We should 
check that.

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

Re: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
> Hi,
>
>> The same test works with the WildFly master branch, which is using ORM
>> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
>> branch, as is the Bean Validator.  The only thing different, is the ORM 5
>> integration code and the ORM 5 persistence provider.
>
> Just fishing here, but "integration code and the ORM 5 persistence provider" 
> might
> indicate a problem in the persistence bootstrapping.
> Have a look at 
> org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
> Basically ORM expects to retrieve the ValidatorFactory to use for the life 
> cycle based
> validation from the properties passed via the Persistence bootstrap. The 
> property name
> is javax.persistence.validation.factory. If there is no instance passed ORM 
> will bootstrap
> a default factory using  Validation.buildDefaultValidatorFactory(). The 
> latter would
> of course not be CDI enabled. This would explain why validation occurs, but 
> not CDI injection.
> I would for sure put a breakpoint in there as well (and some trace/debug log 
> would be probably
> nice to have as well to easily tell whether a factory is passed or a default 
> one is generated.

http://pastebin.com/4X0h1VPA is the call stack in.  We are in the second 
bootstrap phase, which is good.  The validator factory is passed into 
the integration properties but we are only checking the persistence unit 
properties in ORM 5.  Since we are not looking in the integration 
properties for the "javax.persistence.validation.factory", we are not 
seeing it.  So your are right on the money, great suggestion.

I'll check next why the 
EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is 
also ignored.



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

Re: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl#populate(SessionFactoryBuilder
 
sfBuilder, StandardServiceRegistry ssr) does pass the correct VF to 
sfBuilder.applyValidatorFactory (using the ValidatorFactory passed to 
the EntityManagerFactoryBuilderImpl.withValidatorFactory).  However,  a 
bit later when we reach 
org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory, 
we aren't using the SessionFactoryBuilder or 
EntityManagerFactoryBuilderImpl to obtain the VF.  Instead, we are 
looking in the persistence unit properties.  This sounds wrong to me.

On 07/08/2015 09:11 AM, Scott Marlow wrote:
>
>
> On 07/08/2015 09:02 AM, Hardy Ferentschik wrote:
>> Hi,
>>
>>> The same test works with the WildFly master branch, which is using ORM
>>> 4.3.x.  The Bean Validation integration code is unchanged in my WildFly
>>> branch, as is the Bean Validator.  The only thing different, is the ORM 5
>>> integration code and the ORM 5 persistence provider.
>>
>> Just fishing here, but "integration code and the ORM 5 persistence provider" 
>> might
>> indicate a problem in the persistence bootstrapping.
>> Have a look at 
>> org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
>> Basically ORM expects to retrieve the ValidatorFactory to use for the life 
>> cycle based
>> validation from the properties passed via the Persistence bootstrap. The 
>> property name
>> is javax.persistence.validation.factory. If there is no instance passed ORM 
>> will bootstrap
>> a default factory using  Validation.buildDefaultValidatorFactory(). The 
>> latter would
>> of course not be CDI enabled. This would explain why validation occurs, but 
>> not CDI injection.
>> I would for sure put a breakpoint in there as well (and some trace/debug log 
>> would be probably
>> nice to have as well to easily tell whether a factory is passed or a default 
>> one is generated.
>
> Good suggestion, the validation factory does get passed in during the
> second bootstrap phase.  If we looked for it during the first JPA
> bootstrap phase, we would not see it in Hibernate ORM 5.  We should
> check that.
>
>>
>> --Hardy
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

On 07/08/2015 09:32 AM, Hardy Ferentschik wrote:
> On Wed, Jul 08, 2015 at 09:11:55AM -0400, Scott Marlow wrote:
>>> Just fishing here, but "integration code and the ORM 5 persistence 
>>> provider" might
>>> indicate a problem in the persistence bootstrapping.
>>> Have a look at 
>>> org.hibernate.cfg.beanvalidation.TypeSafeActivator#getValidatorFactory.
>>> Basically ORM expects to retrieve the ValidatorFactory to use for the life 
>>> cycle based
>>> validation from the properties passed via the Persistence bootstrap. The 
>>> property name
>>> is javax.persistence.validation.factory. If there is no instance passed ORM 
>>> will bootstrap
>>> a default factory using  Validation.buildDefaultValidatorFactory(). The 
>>> latter would
>>> of course not be CDI enabled. This would explain why validation occurs, but 
>>> not CDI injection.
>>> I would for sure put a breakpoint in there as well (and some trace/debug 
>>> log would be probably
>>> nice to have as well to easily tell whether a factory is passed or a 
>>> default one is generated.
>>
>> Good suggestion, the validation factory does get passed in during the second
>> bootstrap phase.  If we looked for it during the first JPA bootstrap phase,
>> we would not see it in Hibernate ORM 5.  We should check that
>
> +1
>
> I am also confused about your debugging instructions. You are suggesting to 
> use the Wildfly instance
> under dist/target. When I do that and have this instance running when while 
> executing
> 'mvn install -Dtest=*BeanValidationCdiIntegrationTestCase*' the tests 
> actually pass. Apparently
> in this case Arquillian is configured to run against the running Wildfly 
> instance.
> If I, however, run the tests without having a running Wildfly instance the 
> tests keep failing. Seems
> to me that a different Wildfly instance is used. I guess I don't fully 
> understand the test setup
> in the widlfly repo and this integration tests in particular, but obviously I 
> want to debug the
> right thing.

I don't know why that is happening.  It sounds like we have enough 
information from your previous suggestion though and my last email. 
I'll follow up with you on IRC next. :)

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

Re: [hibernate-dev] WildFly BeanValidationCdiIntegrationTestCase test failure with ORM 5

[Scott Marlow]

Steve,

I created HHH-9905 for this, which I was able to workaround with a quick 
hack (set the missing "javax.persistence.validation.factory" property in 
the ConfigurationService).  I was able to pass the WildFly test with the 
workaround.

Steve, is that the right fix?  I assigned the jira to you.  Can we fix 
this for the CR2 build?  If we use the hack workaround, it will probably 
be coded a little different (the hack worked in the debugger but there 
is probably a more elegant way to code it).

Scott

On 07/08/2015 09:53 AM, Hardy Ferentschik wrote:
> Hi,
>
>> http://pastebin.com/4X0h1VPA is the call stack in.  We are in the second
>> bootstrap phase, which is good.  The validator factory is passed into the
>> integration properties but we are only checking the persistence unit
>> properties in ORM 5.  Since we are not looking in the integration properties
>> for the "javax.persistence.validation.factory", we are not seeing it.  So
>> your are right on the money, great suggestion.
>
> I am not sure how this all maps to the different phases and properties types, 
> but
> the JPA specs says in 3.6.2 Providing the ValidatorFactory -
>
> "In Java EE environments, a ValidatorFactory instance is made available by 
> the Java EE container.
> The container is responsible for passing this validator factory to the 
> persistence provider via the
> map that is passed as an argument to the createContainerEntityManagerFactory 
> call. The
> map key used by the container must be the standard property name 
> javax.persistence.validation.
> factory"
>
> I am not sure where the properties of this map end up during the current 
> bootstrapping process,
> but where ever that is, that's where we have to look in TypeSafeActivator 
> (and potentially ask us
> the question whether it is the right place).
>
>> I'll check next why the
>> EntityManagerFactoryBuilder.withValidatorFactory(ValidatorFactory) is also
>> ignored.
>
> Sure. Seems we have a solid lead now.
>
> --Hardy
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] WildFly error running org.jboss.as.test.integration.jpa.hibernate.classfiletransformertest.ClassFileTransformerTestCase (sets hibernate.ejb.use_class_enhancer to true)

[Scott Marlow]

We are getting a "Failed to define class 
org.jboss.as.test.integration.jpa.hibernate.SFSBHibernateSessionFactory" 
error when running the WildFly tests on the CI machine.  I don't see 
this error locally which is why we didn't see this before.

[1] shows the WildFly console at the time of error.

The class that cannot be defined is 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
 
[2]

I suspect that this is some type of race condition that we are hitting 
with deployment of three persistence units [3] concurrently from three 
threads.  The persistence units have "hibernate.ejb.use_class_enhancer" 
set to true.  This might have something to do with the same appliation 
class being enhanced concurrently from three threads.

The test case [4] is verifying that enhanced application classes can be 
used.

I'm not exactly sure why the SFSBHibernateSessionFactory class is being 
enhanced.  I thought we only enhanced the entity classes 
(SFSBHibernateSessionFactory references the Employee entity class but is 
not an entity class).

Scott

[1] https://gist.github.com/scottmarlow/c56cfe07f2ea514354aa

[2] 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java

[3] 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/persistence.xml

[4] 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly error running org.jboss.as.test.integration.jpa.hibernate.classfiletransformertest.ClassFileTransformerTestCase (sets hibernate.ejb.use_class_enhancer to true)

[Scott Marlow]

I noticed that CI test failure is only occurring on Windows.  I wonder 
if 
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/bytecode/enhance/spi/Enhancer.java#L114
 
is misbehaving on Windows.

On 07/08/2015 04:00 PM, Scott Marlow wrote:
> We are getting a "Failed to define class
> org.jboss.as.test.integration.jpa.hibernate.SFSBHibernateSessionFactory"
> error when running the WildFly tests on the CI machine.  I don't see
> this error locally which is why we didn't see this before.
>
> [1] shows the WildFly console at the time of error.
>
> The class that cannot be defined is
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
> [2]
>
> I suspect that this is some type of race condition that we are hitting
> with deployment of three persistence units [3] concurrently from three
> threads.  The persistence units have "hibernate.ejb.use_class_enhancer"
> set to true.  This might have something to do with the same appliation
> class being enhanced concurrently from three threads.
>
> The test case [4] is verifying that enhanced application classes can be
> used.
>
> I'm not exactly sure why the SFSBHibernateSessionFactory class is being
> enhanced.  I thought we only enhanced the entity classes
> (SFSBHibernateSessionFactory references the Employee entity class but is
> not an entity class).
>
> Scott
>
> [1] https://gist.github.com/scottmarlow/c56cfe07f2ea514354aa
>
> [2]
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
>
> [3]
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/persistence.xml
>
> [4]
> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly error running org.jboss.as.test.integration.jpa.hibernate.classfiletransformertest.ClassFileTransformerTestCase (sets hibernate.ejb.use_class_enhancer to true)

[Scott Marlow]

On 07/08/2015 07:00 PM, Scott Marlow wrote:
> I noticed that CI test failure is only occurring on Windows.  I wonder
> if
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/bytecode/enhance/spi/Enhancer.java#L114
> is misbehaving on Windows.

We might need to use '/' instead of File.separatorChar.

See javadoc for Class#getResourceAsStream:
"
public InputStream getResourceAsStream(String name)

 Finds a resource with a given name. The rules for searching 
resources associated with a given class are implemented by the defining 
class loader of the class. This method delegates to this object's class 
loader. If this object was loaded by the bootstrap class loader, the 
method delegates to ClassLoader.getSystemResourceAsStream(java.lang.String).

 Before delegation, an absolute resource name is constructed from 
the given resource name using this algorithm:

 If the name begins with a '/' ('\u002f'), then the absolute 
name of the resource is the portion of the name following the '/'.
 Otherwise, the absolute name is of the following form:

modified_package_name/name


 Where the modified_package_name is the package name of this 
object with '/' substituted for '.' ('\u002e').
"

>
> On 07/08/2015 04:00 PM, Scott Marlow wrote:
>> We are getting a "Failed to define class
>> org.jboss.as.test.integration.jpa.hibernate.SFSBHibernateSessionFactory"
>> error when running the WildFly tests on the CI machine.  I don't see
>> this error locally which is why we didn't see this before.
>>
>> [1] shows the WildFly console at the time of error.
>>
>> The class that cannot be defined is
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
>> [2]
>>
>> I suspect that this is some type of race condition that we are hitting
>> with deployment of three persistence units [3] concurrently from three
>> threads.  The persistence units have "hibernate.ejb.use_class_enhancer"
>> set to true.  This might have something to do with the same appliation
>> class being enhanced concurrently from three threads.
>>
>> The test case [4] is verifying that enhanced application classes can be
>> used.
>>
>> I'm not exactly sure why the SFSBHibernateSessionFactory class is being
>> enhanced.  I thought we only enhanced the entity classes
>> (SFSBHibernateSessionFactory references the Employee entity class but is
>> not an entity class).
>>
>> Scott
>>
>> [1] https://gist.github.com/scottmarlow/c56cfe07f2ea514354aa
>>
>> [2]
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/SFSBHibernateSessionFactory.java
>>
>> [3]
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/persistence.xml
>>
>> [4]
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/hibernate/classfiletransformertest/ClassFileTransformerTestCase.java
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Strange issues with -snapshot dependencies

[Scott Marlow]

> I'm starting to wonder if actually sometimes Maven runs my integration
> tests using a previous SNAPSHOT build, which would be missing both the
> logs and the fix, and in those cases it could either fail or not (as
> it wasn't always reproduced).
>
> Anyone else ever seen such an issue?
>

I worry about this problem happening but haven't experienced it.  If 
your building the SNAPSHOT build locally that you want to use, would it 
make sense to give it a unique name that wouldn't be found in the remote 
maven repository?  Something like:

hibernateTargetVersion = '5.0.1-SANNE-SNAPSHOT'

That might be a pita but at least you would have more confidence that 
its right.

Another approach would be to disassemble (jad or procyon-decompiler) one 
of the SNAPSHOT jar classes to see if your code changes are in it.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Should hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl be the default for Hibernate 5?

[Scott Marlow]

Or should WildFly perhaps use 
hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl
 
as the default?

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

Re: [hibernate-dev] Next 5.0 release

[Scott Marlow]

On 07/24/2015 08:05 AM, Steve Ebersole wrote:
> I am feeling like so many changes to SPIs have piled up on master since CR2
> that another CR is warranted.  Everyone ok with doing a CR3?

Yes, CR3 sounds good.  I ran the EE TCK last night with the 5.0.1 ORM 
snapshot and we are passing the JPA tests.  As we discussed yesterday, 
we will do the same testing again tonight (with the latest snapshot).

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

Re: [hibernate-dev] started release

[Scott Marlow]

I missed a WildFly second level query cache failure yesterday in my 
testing http://pastebin.com/kg3YhxxL

Test steps:

  - creates an entity

  - queries for the entity

  - verify that the query cache hit count is zero.

  - query again for the entity

  - verify that the query cache hit count is one (this fails as the 
query cache hit count is still zero)

The failing test code is at 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255

And is called from 
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229

This hurts my WF10 upgrade to ORM 5.0.0.CR3 
https://github.com/wildfly/wildfly/pull/7842

On 07/29/2015 11:37 AM, Steve Ebersole wrote:
> The release is done minus announcing and SF upload.  Also I decided to not
> upload the docs yet since they are still incomplete and i still have work
> to do there prior to Final.
>
>
> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole  wrote:
>
>> per $subject
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] started release

[Scott Marlow]

Hi Sanne,

Good idea. I'm not sure exactly what about the test is failing.  ORM 
currently doesn't have all of the same components as WildFly, so tests 
don't always translate (e.g. ORM doesn't have a EJB container).  We need 
to understand the cause and then maybe we can talk about an ORM test.

Scott

On 07/29/2015 04:47 PM, Sanne Grinovero wrote:
> Hi Scott,
> do you think you could merge those tests in Hibernate ORM?
>
> Thanks,
> Sanne
>
> On 29 July 2015 at 20:02, Scott Marlow  wrote:
>> I missed a WildFly second level query cache failure yesterday in my
>> testing http://pastebin.com/kg3YhxxL
>>
>> Test steps:
>>
>>- creates an entity
>>
>>- queries for the entity
>>
>>- verify that the query cache hit count is zero.
>>
>>- query again for the entity
>>
>>- verify that the query cache hit count is one (this fails as the
>> query cache hit count is still zero)
>>
>> The failing test code is at
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255
>>
>> And is called from
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229
>>
>> This hurts my WF10 upgrade to ORM 5.0.0.CR3
>> https://github.com/wildfly/wildfly/pull/7842
>>
>> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>>> The release is done minus announcing and SF upload.  Also I decided to not
>>> upload the docs yet since they are still incomplete and i still have work
>>> to do there prior to Final.
>>>
>>>
>>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole  wrote:
>>>
>>>> per $subject
>>>>
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] started release

[Scott Marlow]

On 07/30/2015 02:34 AM, Radim Vansa wrote:
> I think that the failure is caused by HHH-7898 fix. The put is executed
> only after the current transaction is finished (as synchronization),
> until then the query is cached only for the current session and
> therefore not reflected in statistics.

Aren't the statistics at the SF level?

>
> Radim
>
> On 07/29/2015 09:02 PM, Scott Marlow wrote:
>> I missed a WildFly second level query cache failure yesterday in my
>> testing http://pastebin.com/kg3YhxxL
>>
>> Test steps:
>>
>> - creates an entity
>>
>> - queries for the entity
>>
>> - verify that the query cache hit count is zero.
>>
>> - query again for the entity
>>
>> - verify that the query cache hit count is one (this fails as the
>> query cache hit count is still zero)
>>
>> The failing test code is at
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255
>>
>> And is called from
>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229
>>
>> This hurts my WF10 upgrade to ORM 5.0.0.CR3
>> https://github.com/wildfly/wildfly/pull/7842
>>
>> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>>> The release is done minus announcing and SF upload.  Also I decided to not
>>> upload the docs yet since they are still incomplete and i still have work
>>> to do there prior to Final.
>>>
>>>
>>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole  wrote:
>>>
>>>> per $subject
>>>>
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] started release

[Scott Marlow]

On 07/30/2015 09:36 AM, Radim Vansa wrote:
> On 07/30/2015 03:27 PM, Scott Marlow wrote:
>>
>>
>> On 07/30/2015 02:34 AM, Radim Vansa wrote:
>>> I think that the failure is caused by HHH-7898 fix. The put is executed
>>> only after the current transaction is finished (as synchronization),
>>> until then the query is cached only for the current session and
>>> therefore not reflected in statistics.
>>
>> Aren't the statistics at the SF level?
>
> Hmm, you're right. Could you send me a trace log for this test to check
> what's happening, rather than guess?

Easily done.  I'll enable TRACE logging for org.hibernate + 
org.infinispan unless you want a little less?

I'll also include org.jboss.as.jpa TRACE logging so we have logging of 
each EntityManager invocation.  May as well include JTA trace also, so 
we know when the TX starts/ends.


>
> Radim
>
>>
>>>
>>> Radim
>>>
>>> On 07/29/2015 09:02 PM, Scott Marlow wrote:
>>>> I missed a WildFly second level query cache failure yesterday in my
>>>> testing http://pastebin.com/kg3YhxxL
>>>>
>>>> Test steps:
>>>>
>>>> - creates an entity
>>>>
>>>> - queries for the entity
>>>>
>>>> - verify that the query cache hit count is zero.
>>>>
>>>> - query again for the entity
>>>>
>>>> - verify that the query cache hit count is one (this fails as the
>>>> query cache hit count is still zero)
>>>>
>>>> The failing test code is at
>>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/SFSB2LC.java#L255
>>>>
>>>>
>>>> And is called from
>>>> https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/secondlevelcache/JPA2LCTestCase.java#L229
>>>>
>>>>
>>>> This hurts my WF10 upgrade to ORM 5.0.0.CR3
>>>> https://github.com/wildfly/wildfly/pull/7842
>>>>
>>>> On 07/29/2015 11:37 AM, Steve Ebersole wrote:
>>>>> The release is done minus announcing and SF upload.  Also I decided
>>>>> to not
>>>>> upload the docs yet since they are still incomplete and i still
>>>>> have work
>>>>> to do there prior to Final.
>>>>>
>>>>>
>>>>> On Wed, Jul 29, 2015 at 10:06 AM Steve Ebersole
>>>>>  wrote:
>>>>>
>>>>>> per $subject
>>>>>>
>>>>> ___
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>> ___
>>>> hibernate-dev mailing list
>>>> hibernate-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.0 defaults

[Scott Marlow]

On 08/03/2015 02:17 PM, Steve Ebersole wrote:
> Scott has been asking about making some setting defaults consistent between
> Hibernate and WildFly.  Most I think WildFly should just use the ORM
 > defaults.

If ORM 5.0 used the same defaults as the WildFly (JPA) deployer, then 
WildFly could stop setting them.

> But 3 in particular I thought we should all discuss and decide
> on..
>
> 1) hibernate.implicit_naming_strategy - by default Hibernate uses its
> legacy implicit naming strategy which predates the clarifications made in
> JPA 2.0 by many years.  The question here is whether we want to change this
> (now/ever) to use the JPA (2.0) compliant one?

 From a few weeks ago on 
https://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg12650.html:

"
Question: Should 
hibernate.implicit_naming_strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyJpaCompliantImpl
 
be the default for Hibernate 5?

Answer:

This is one of those things similar to "use new id generator mappings".
For new development I think it probably makes sense for WildFly users to
expect JPA-compliant implicit naming.The difficulty is how changing
that would affect existing applications.
"

Is the ORM default exactly the same as pre-5?  If not, is there a jira 
that explains the difference?

>
> 2) hibernate.auto_quote_keyword - by default we decided to have Hibernate
> automatically quote identifiers it thinks are key/reserved words in the
> underlying database.  We know at the moment this is a bit too aggressive as
> it pulls in all of SQL:2003 defined keywords.  The question is whether we
> disable this by default?
>
> 3) hibernate.id.new_generator_mappings - by default we currently still map
> to the old identifier generators.  I personally also think it is time to
> change this default.  There are some risks here though.

WildFly has been defaulting hibernate.id.new_generator_mappings=true for 
the past four years but I don't think that makes this proposed change 
any easier for applications that aren't using WildFly EE (JPA) based 
deployments.

>
> Take an example... Legacy JPA users would have gotten
> MultipleHiLoPerTableGenerator
> when they used table-generation.  The new mapping for table-generation
> would be to use org.hibernate.id.enhanced.TableGenerator.  In theory the
> enhanced TableGenerator could be made to mimic the same "hi lo" based
> values using the correct optimizer (in *theory* because I have not tried
> it).  If selecting the proper optimizer works this one might not be a
> problem and there is no need for data migration.  But if it does not, we
> really have no migration path for user to migrate data.
>
> Another "difficulty" is that AUTO is mapped *very* differently.  AUTO used
> to map to the idea of a "native" generator which would choose between
> IDENTITY, SEQUENCE, etc.  The new mapping is to use the enhanced
> SequenceStyleGenerator.  For dialects where the old mapping picked
> IDENTITY, this is a very difficult migration point.  Granted they could
> change all the needed id mappings to specify identity...
>
> And of course we could also just say "this is a (painful) migration point"
> and document the known migration issues for existing apps in the migration
> guide.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 5.0 defaults

[Scott Marlow]

On 08/03/2015 04:00 PM, Steve Ebersole wrote:
> On Mon, Aug 3, 2015 at 2:07 PM Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
>
>
> On 08/03/2015 02:17 PM, Steve Ebersole wrote:
>  > Scott has been asking about making some setting defaults
> consistent between
>  > Hibernate and WildFly.  Most I think WildFly should just use the ORM
>   > defaults.
>
> If ORM 5.0 used the same defaults as the WildFly (JPA) deployer, then
> WildFly could stop setting them.
>
>
> This is such a non-argument. We could of course say the inverse:
>
> If WildFly used the same defaults as ORM then (obviously) WildFly could
> stop setting them.  Not to mention Hibernate users would get a more
> consistent experience across environments.

True.  Stating both sides, gives a little more information to others 
that are reading this discussion.  Your point being that changing either 
ORM or WildFly to use the others defaults, brings more consistency 
across environments.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

https://github.com/wildfly/wildfly/pull/7909 uses the Narayana 
org.jboss.tm.listener.TransactionListenerRegistry to be notified when 
the transaction is associated/deassociated with the JTA transaction.

I think that Hibernate ORM could do something similar with the 
org.jboss.tm.listener.TransactionListenerRegistry to protect against 
clearing the persistence context from a non-application thread, while 
the application thread may be actively using the persistence context.

I think this approach is simpler than the thread id tracking.

On 03/10/2015 01:51 PM, Scott Marlow wrote:
>>
>> So what is this buying us?
>>
>
> The current Hibernate ORM thread id checking, does not properly handle
> the case when the application thread changes between calls to the
> Hibernate session.  The new approach does handle the application thread
> changing between session invocations and also covers a few other cases
> as well (like clearing the persistence context after the application may
> of added another entity after the background thread rolled back the
> transaction).
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Default fetching

[Scott Marlow]

On 08/07/2015 11:41 AM, Steve Ebersole wrote:
> I thought we had discussed this once upon a time, but I could not find any
> email.  In overhauling the documentation I ran across our long-standing
> recommendation that all associations be defined in metadata as lazy.  JPA
> of course came along said that for to-one associations the default should
> eager.
>
> Do we want to add a setting to allow folks to alter these defaults?

Yes, I think users would like having the option to alter these defaults.

> I know
> that's tough in terms of portability between providers, but that is
> ultimately the user's choice.


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

Re: [hibernate-dev] new proposal for tx timeout handling using transaction DISASSOCIATING event notification...

[Scott Marlow]

On 08/07/2015 02:41 PM, Steve Ebersole wrote:
> Yeah, which is great when you can rely on impl-specific apis.

Agreed.  I'm not sure of what we should do when ORM is running in 
environments that cannot rely on a NarayanaJtaPltaform.  Especially, 
when every call into Hibernate ORM is from a different thread (e.g. 
remote EJB invocations).

I think the below idea of deferring to the JtaPlatform to indicate the 
"type of timeout tracking" to do, is the best approach.

>
> I'll consider this, but its not super high on my priority list.  I guess
> we could implement some kind of way for the JtaPlatform to indicate the
> "type of timeout tracking" to do and develop a new NarayanaJtaPltaform
> that does this.

Is this more of an ORM 5.1 or 6.0 change?

>
>
> On Fri, Aug 7, 2015 at 11:30 AM Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> https://github.com/wildfly/wildfly/pull/7909 uses the Narayana
> org.jboss.tm.listener.TransactionListenerRegistry to be notified when
> the transaction is associated/deassociated with the JTA transaction.
>
> I think that Hibernate ORM could do something similar with the
> org.jboss.tm.listener.TransactionListenerRegistry to protect against
> clearing the persistence context from a non-application thread, while
> the application thread may be actively using the persistence context.
>
> I think this approach is simpler than the thread id tracking.
>
> On 03/10/2015 01:51 PM, Scott Marlow wrote:
>  >>
>  >> So what is this buying us?
>  >>
>  >
>  > The current Hibernate ORM thread id checking, does not properly
> handle
>  > the case when the application thread changes between calls to the
>  > Hibernate session.  The new approach does handle the application
> thread
>  > changing between session invocations and also covers a few other
> cases
>  > as well (like clearing the persistence context after the
> application may
>  > of added another entity after the background thread rolled back the
>  > transaction).
>  > ___
>  > hibernate-dev mailing list
>  > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>  > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate 2lc settings in WildFly

[Scott Marlow]

I didn't know about 'immutable-entity', should that be listed in [1] for 
the WildFly standalone*.xml, so users can configure 'immutable-entity'?

[2] describes the possible Infinispan subsystem settings for [1].

Scott

[1] 
https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/subsystem-templates/infinispan.xml#L39

[2] 
https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate 2lc settings in WildFly

[Scott Marlow]

On 08/18/2015 01:10 PM, Sanne Grinovero wrote:
> I think such options should not be an aspect of the Cache
> configuration but only a property of the Hibernate configuration.

The time to do that would of been about four years ago (now we have to 
be configuration compatible on the WildFly side at least).  Still, not 
all applications include Hibernate configuration settings but they do 
expect to use a second level cache.

If we were to remove the Hibernate section from [1], where would that 
configuration live and what code would deal with that?

>
> Why should that be known to the Infinispan configuration?

In WildFly, that happens to be where we start/stop Infinispan caches, 
which makes sense since that is where we also deal with clustering.

>
>
> On 18 August 2015 at 14:29, Scott Marlow  wrote:
>> I didn't know about 'immutable-entity', should that be listed in [1] for
>> the WildFly standalone*.xml, so users can configure 'immutable-entity'?
>>
>> [2] describes the possible Infinispan subsystem settings for [1].
>>
>> Scott
>>
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/subsystem-templates/infinispan.xml#L39
>>
>> [2]
>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate 2lc settings in WildFly

[Scott Marlow]

Thanks Radim, I created https://issues.jboss.org/browse/WFLY-5137 for 
adding 'immutable-entities' to the WildFly standalone*.xml.  I included 
a copy of the proposed change in the jira.

Scott

On 08/19/2015 06:02 AM, Radim Vansa wrote:
> I think that it was my mistake to not make this 'immutable-entities' get
> its configuration from 'entities', when it's not declared explicitly. I
> believe that adding that cache configuration to WF configs is the
> easiest way to fix things; though, if users use their own configs, they
> won't be notified that something is missing in their standalone.xml -
> the same problem as with overridden infinispan configuration, though
> this shouldn't be that common and users should pay more attention if
> they do that.
>
> AFAIK, there is no place but the default infinispan config where it is
> documented which caches need to be defined and what kind of config do
> they need. There is also no validation in the code. The defaults are
> just in the default config, not in the code, and therefore user can
> override all or nothing. Users can even think that all entities are
> stored in single cache (while each entity type has its own) .
>
> I don't think that serializing Infinispan configuration into properties
> is the best way.
>
> I plan to add some configuration sanity checks as part of HHH-10030, but
> I have not thought about any systematic approach, so I'd welcome any
> discussion.
>
> Radim
>
> On 08/18/2015 07:44 PM, Scott Marlow wrote:
>> On 08/18/2015 01:10 PM, Sanne Grinovero wrote:
>>> I think such options should not be an aspect of the Cache
>>> configuration but only a property of the Hibernate configuration.
>> The time to do that would of been about four years ago (now we have to
>> be configuration compatible on the WildFly side at least).  Still, not
>> all applications include Hibernate configuration settings but they do
>> expect to use a second level cache.
>>
>> If we were to remove the Hibernate section from [1], where would that
>> configuration live and what code would deal with that?
>>
>>> Why should that be known to the Infinispan configuration?
>> In WildFly, that happens to be where we start/stop Infinispan caches,
>> which makes sense since that is where we also deal with clustering.
>>
>>>
>>> On 18 August 2015 at 14:29, Scott Marlow  wrote:
>>>> I didn't know about 'immutable-entity', should that be listed in [1] for
>>>> the WildFly standalone*.xml, so users can configure 'immutable-entity'?
>>>>
>>>> [2] describes the possible Infinispan subsystem settings for [1].
>>>>
>>>> Scott
>>>>
>>>> [1]
>>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/subsystem-templates/infinispan.xml#L39
>>>>
>>>> [2]
>>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd
>>>> ___
>>>> hibernate-dev mailing list
>>>> hibernate-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM 5.0 Final - delayed

[Scott Marlow]

Please let me know if you want me to do any testing before the release.

On 08/19/2015 02:34 PM, Steve Ebersole wrote:
> I am going to delay releasing 5.0 Final until tomorrow at earliest.  The CI
> server is having some massive trouble at the moment and I'd prefer to make
> sure that we are getting clean builds there before I start the release.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM 5.0 Final - delayed

[Scott Marlow]

On 08/20/2015 10:33 AM, Scott Marlow wrote:
> Please let me know if you want me to do any testing before the release.

Passed testing and merged into WildFly 10.0.0.Beta2.
>
> On 08/19/2015 02:34 PM, Steve Ebersole wrote:
>> I am going to delay releasing 5.0 Final until tomorrow at earliest.  The CI
>> server is having some massive trouble at the moment and I'd prefer to make
>> sure that we are getting clean builds there before I start the release.
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Bytecode enhancement and collections

[Scott Marlow]

On 09/10/2015 09:45 AM, Steve Ebersole wrote:
> Wanted to get some opinions.  I am working on HHH-10055 which is basically
> a report of problems with that "lazy loading outside of a
> session/transaction" feature when used in combination with bytecode
> enhancement.  The initial problem was that bytecode interception was not
> accounting for collection attributes properly; it was not building the
> appropriate PersistentCollection to return.  I changed that code to now
> build the PersistentCollection.
>
> But that led to another issue later on that made me question how I was
> building the PersistentCollection during interception.  Essentially I was
> trying to still build an uninitialized PersistentCollection.  The
> interception code immediately tries to read the size of that collection as
> and up-front part of its in-line dirty checking capabilities which
> triggered another interception back in to an inconsistent state.
>
> But what I started thinking about is the assumption that this interception
> ought to prefer to return an uninitialized PersistentCollection.  I now
> think that is not a good assumption.  Why?  Consider code like:
>
>
> Well the idea of an uninitialized PersistentCollection comes from the
> scenario of proxy-based laziness.  In proxy-based laziness, code like:
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> System.out.println( myEntity.getName() );
>
> In the case of proxy-based laziness, the second line immediately causes the
> entire proxy to become initialized.  Part of that is to set any of its
> collection attributes.  However, as the collections are not accessed here
> we want to further delay initializing them.  But since the proxy is
> initialized completely that means the only way to achieve that here is
> setting an uninitialized version of the PersistentCollection as state,
> which will initialize itself later when accessed.
>
> For bytecode enhancement, the situation is a little bit different.  There
> we'd not even build the PersistentCollection instance until that attribute
> is accessed.  So in the above code the collection attributes would never be
> built.  So when we are in the interception code I mentioned above, we know
> that something is trying to access that collection attribute specifically.
> This is the difference.
>
> Back to the initial problem... I think the solution is not just to have the
> bytecode interception code build the PersistentCollection, but to also have
> it make sure that the PersistentCollection is initialized.
>
> Going back to the sample code, and adding a line:
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> print( myEntity.getName() );
> myEntity.getChildren();
>
> In the proxy-based solution the collection is still uninitialized after
> this.  For bytecode interception I am proposing that the collection would
> be initialized by that 3rd line.  Again we could return the uninitialized
> collection here, and wait for PersistentCollection to initialize itself on
> first "further access" (calling size(), iterating, etc).  I am more think
> through intent; because we know specifically that the collection attribute
> itself was accessed it seems reasonable to go ahead and initialize it.
>
> And if we do not go that route, then we need a different tact as well for
> dealing with the in-line dirty checking aspect of this.
>
> Really the only time this distinction becomes an issue is in code that
> explicitly tries to check whether certain attributes are initialized.  So
> whereas this works for the proxy-based approach:
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> if ( !Hibernate.isInitialized( myEntity.getChildren() ) ) {
>  // do something with the uninitialized collection
>  ...
> }
>
> It will fail with the bytecode interception approach I propose, because the
> call to `myEntity.getChildren()` itself causes the initialization.  There
> you'd have to use:
>
> MyEntity myEntity = session.load( MyEntity.class, 1 );
> if ( !Hibernate.isPropertyInitialized( myEntity, "children" ) ) {
>  // do something with the uninitialized collection
>  ...
> }
>
> which has always been the suggested way to deal with questioning bytecode
> initialization state and which matches the JPA call too.
>
> So any thoughts?

What happens if the session is closed after the session.load?  Will the 
collection still be initialized by the time myEntity.getChildren() is 
called?

MyEntity myEntity = session.load( MyEntity.class, 1 );
session.close();
print( myEntity.getName() );
myEntity.getChildren();


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

Re: [hibernate-dev] No ValidatorFactory exposed through "javax.persistence.validation.factory" in WF 10 CR1

[Scott Marlow]

Gunnar,

In a standard bootstrap, the map parameter in the call to 
createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map), 
should have the ValidatorFactory.

For the path that your debugging (2 phase bootstrap), 
org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder.withValidatorFactory(Object)
 
should of been called.  If the Hibernate ORM version is 4.3 or 5.0, we 
should be calling EntityManagerFactoryBuilder.withValidatorFactory, 
could you check if that was called or not?

Scott

On 09/23/2015 07:38 AM, Gunnar Morling wrote:
> Scott,
>
> Upgrading the Hibernate Validator integration tests to run on WF 10
> CR1, two tests fail for me DefaultValidatorFactoryInPersistenceUnitIT
> and CustomValidatorFactoryInPersistenceUnitIT.
>
> These are about accessing the validator factory from the entity
> manager factory through the "javax.persistence.validation.factory"
> property. The look-up returns null, though. I tried to debug that a
> bit but I am a bit lost in WF's PersistenceUnitServiceImpl. The code
> in start() populates the property in a map, but that map is not used
> for the EMF actually bootstrapped (which happens through the
> EntityManagerFactoryBuilder
> phaseOnePersistenceUnitService.getEntityManagerFactoryBuilder(), which
> does not get this property set).
>
> Could you check this one out? Maybe JipiJapa's
> EntityManagerFactoryBuilder should set that property to VF given via
> withValidatorFactory()?
>
> Thanks,
>
> --Gunnar
>
> [1] 
> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/DefaultValidatorFactoryInPersistenceUnitIT.java
> [2] 
> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/CustomValidatorFactoryInPersistenceUnitIT.java
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] No ValidatorFactory exposed through "javax.persistence.validation.factory" in WF 10 CR1

[Scott Marlow]

Gunnar,

Regarding the "javax.persistence.validation.factory" property setting, I 
think it would also be passed to 
org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(info, map). 


Scott
On 09/23/2015 09:24 AM, Gunnar Morling wrote:
> Scott,
>
> Yes, EntityManagerFactoryBuilder#withValidatorFactory() is called (see
> https://github.com/wildfly/wildfly/blob/10.0.0.CR1/jpa/subsystem/src/main/java/org/jboss/as/jpa/service/PersistenceUnitServiceImpl.java#L150,
> I see it actually happening in the debugger), so I suppose Hibernate
> ORM has the VF at its hands correctly.
>
> Only that it is not exposed via the
> "javax.persistence.validation.factory" key via the EMF-exposed
> property map any more. So the call to
>
>  entityManagerFactory().getProperties().get(
> "javax.persistence.validation.factory" );
>
> returns null whereas it used to return the VF in earlier versions.
>
> But reading the spec again, it seems it only describes the
> "javax.persistence.validation.factory" key as means of passing the VF
> *to* JPA but not as means of obtaining it. Apparently that's just
> something that happened to be the case in WF before, comments at the
> test even states that this behaviour is not portable across
> containers.
>
> So I suppose I'll have to rework that test in the course of the upgrade.
>
> --Gunnar
>
>
> 2015-09-23 14:51 GMT+02:00 Scott Marlow :
>> Gunnar,
>>
>> In a standard bootstrap, the map parameter in the call to
>> createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map),
>> should have the ValidatorFactory.
>>
>> For the path that your debugging (2 phase bootstrap),
>> org.hibernate.jpa.boot.spi.EntityManagerFactoryBuilder.withValidatorFactory(Object)
>> should of been called.  If the Hibernate ORM version is 4.3 or 5.0, we
>> should be calling EntityManagerFactoryBuilder.withValidatorFactory, could
>> you check if that was called or not?
>>
>> Scott
>>
>>
>> On 09/23/2015 07:38 AM, Gunnar Morling wrote:
>>>
>>> Scott,
>>>
>>> Upgrading the Hibernate Validator integration tests to run on WF 10
>>> CR1, two tests fail for me DefaultValidatorFactoryInPersistenceUnitIT
>>> and CustomValidatorFactoryInPersistenceUnitIT.
>>>
>>> These are about accessing the validator factory from the entity
>>> manager factory through the "javax.persistence.validation.factory"
>>> property. The look-up returns null, though. I tried to debug that a
>>> bit but I am a bit lost in WF's PersistenceUnitServiceImpl. The code
>>> in start() populates the property in a map, but that map is not used
>>> for the EMF actually bootstrapped (which happens through the
>>> EntityManagerFactoryBuilder
>>> phaseOnePersistenceUnitService.getEntityManagerFactoryBuilder(), which
>>> does not get this property set).
>>>
>>> Could you check this one out? Maybe JipiJapa's
>>> EntityManagerFactoryBuilder should set that property to VF given via
>>> withValidatorFactory()?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>>
>>> [1]
>>> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/DefaultValidatorFactoryInPersistenceUnitIT.java
>>> [2]
>>> https://github.com/hibernate/hibernate-validator/blob/master/integration/src/test/java/org/hibernate/validator/integration/wildfly/CustomValidatorFactoryInPersistenceUnitIT.java
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] hibernate-infinispan tests - part... oh I've lost track

[Scott Marlow]

Hi Radim,

I'm consistently seeing a WildFly 2lc test failure with Hibernate ORM 
5.0.2 (see [1]).  This also recreates for me locally.  Were there 
additional 2lc changes in ORM 5.0.2?

Scott

[1] https://github.com/wildfly/wildfly/pull/8220

On 10/01/2015 03:14 AM, Radim Vansa wrote:
> Sorry Steve, as I am on a meeting this week, I did not have a chance of
> looking into that this week, I'll make that my priority the next week.
> Sanne has told me that I can run the tests in CI on custom branch
> myself, so I hope I'll get some indication what's stalling the testsuite.
>
> Radim
>
> On 09/30/2015 09:21 PM, Steve Ebersole wrote:
>> Its failing on the second run as well.  So for now I am disabling the
>> hibernate-infinispan tests again.
>>
>> On Wed, Sep 30, 2015 at 2:01 PM Steve Ebersole > > wrote:
>>
>>  So this just bit me (again) doing the release. I get transient
>>  test failures in hibernate-infinispan trying to run the release.
>>  This is getting frustrating.
>>
>>  So can we get this to be a priority?  Or else I am going to
>>  seriously contemplate moving hibernate-infinispan into a new
>>  project on its own.
>>
>>
>>
>>  On Sat, Sep 26, 2015 at 6:26 AM Sanne Grinovero
>>  mailto:sa...@hibernate.org>> wrote:
>>
>>  Hi Radim,
>>
>>  the ci.hibernate.org  server grants
>>  permissions based on your github
>>  id, AFAIR you should be able to create/edit jobs since you
>>  have commit
>>  permissions.
>>  Clone the Hibernate ORM main job into a personal one, edit it
>>  (like
>>  have it build from a personal branch and disable spammy
>>  notifications)
>>  and test like as you prefer.
>>  If it's not allowing you such permissions, let me know.
>>
>>  If it's not enough to diagnose this, next week I can show you
>>  how to
>>  get a root terminal on the build slaves.
>>
>>  Thanks for helping on this!
>>
>>  Sanne
>>
>>
>>  On 25 September 2015 at 19:05, Radim Vansa >  > wrote:
>>  > Since we can't reproduce the test on local machine (I was
>>  once runnning
>>  > the testsuite whole night again and again and did not get
>>  any crash),
>>  > the only option I can think of is running
>>  hibernate-infinispan with
>>  > verbose logging in CI.
>>  > To properly diagnose what has happened, we should set up
>>  > org.jgroups TRACE
>>  > org.infinispan TRACE
>>  > org.infinispan.marshall DEBUG
>>  > org.infinispan.commons.marshall DEBUG
>>  >
>>  > (the other two just reduce the verbosity in the parts we
>>  don't need). If
>>  > the build fails in CI and I can get my hands on the log, I
>>  can investigate.
>>  >
>>  > Steve, should I prepare a PR switching the log level when
>>  running
>>  > testsuite, or could you do that only in the CI?
>>  >
>>  > Radim
>>  >
>>  > On 09/25/2015 04:28 PM, Steve Ebersole wrote:
>>  >> We are again running into problems with
>>  hibernate-infinispan tests.  We are
>>  >> seeing false test failures on CI.  I cannot reproduce these
>>  failures
>>  >> locally, and even out on CI the test(s) that fil change
>>  each time.
>>  >>
>>  >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1121/
>>  >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1122/
>>  >> http://ci.hibernate.org/job/hibernate-orm-master-h2/1123/
>>  >>
>>  >> Are 3 job runs showing what I mean.  There is no code
>>  change between any of
>>  >> these runs.
>>  >> ___
>>  >> hibernate-dev mailing list
>>  >> hibernate-dev@lists.jboss.org
>>  
>>  >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>  >
>>  >
>>  > --
>>  > Radim Vansa mailto:rva...@redhat.com>>
>>  > JBoss Performance Team
>>  >
>>  > ___
>>  > hibernate-dev mailing list
>>  > hibernate-dev@lists.jboss.org
>>  
>>  > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>  ___
>>  hibernate-dev mailing list
>>  hibernate-dev@lists.jboss.org
>>  
>>  https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/list

Re: [hibernate-dev] hibernate-infinispan tests - part... oh I've lost track

[Scott Marlow]

Thanks Radim,

I thought I sent this via private email but noticed after I included 
hibernate-dev@lists.jboss.org.  Oops :-)

Not that there is anything wrong with sending issues to 
hibernate-dev@lists.jboss.org, just didn't intend to bring up a separate 
(but possibly related) test failure in this thread.

Scott

On 10/02/2015 04:52 AM, Radim Vansa wrote:
> Responded on the GitHub issue. There were changes but these should not
> have affected query cache afaik. When Scott sends me the trace logs,
> I'll investigate what's wrong.
>
> I am already running test for hibernate-infinispan with trace logs in
> CI, though I'll be offline for the rest of the day.
>
> Radim
>
> On 10/01/2015 06:14 PM, Scott Marlow wrote:
>> Hi Radim,
>>
>> I'm consistently seeing a WildFly 2lc test failure with Hibernate ORM
>> 5.0.2 (see [1]).  This also recreates for me locally.  Were there
>> additional 2lc changes in ORM 5.0.2?
>>
>> Scott
>>
>> [1] https://github.com/wildfly/wildfly/pull/8220
>>
>> On 10/01/2015 03:14 AM, Radim Vansa wrote:
>>> Sorry Steve, as I am on a meeting this week, I did not have a chance of
>>> looking into that this week, I'll make that my priority the next week.
>>> Sanne has told me that I can run the tests in CI on custom branch
>>> myself, so I hope I'll get some indication what's stalling the
>>> testsuite.
>>>
>>> Radim
>>>
>>> On 09/30/2015 09:21 PM, Steve Ebersole wrote:
>>>> Its failing on the second run as well. So for now I am disabling the
>>>> hibernate-infinispan tests again.
>>>>
>>>> On Wed, Sep 30, 2015 at 2:01 PM Steve Ebersole >>> <mailto:st...@hibernate.org>> wrote:
>>>>
>>>>  So this just bit me (again) doing the release. I get transient
>>>>  test failures in hibernate-infinispan trying to run the release.
>>>>  This is getting frustrating.
>>>>
>>>>  So can we get this to be a priority?  Or else I am going to
>>>>  seriously contemplate moving hibernate-infinispan into a new
>>>>  project on its own.
>>>>
>>>>
>>>>
>>>>  On Sat, Sep 26, 2015 at 6:26 AM Sanne Grinovero
>>>>  mailto:sa...@hibernate.org>> wrote:
>>>>
>>>>  Hi Radim,
>>>>
>>>>  the ci.hibernate.org <http://ci.hibernate.org> server grants
>>>>  permissions based on your github
>>>>  id, AFAIR you should be able to create/edit jobs since you
>>>>  have commit
>>>>  permissions.
>>>>  Clone the Hibernate ORM main job into a personal one, edit it
>>>>  (like
>>>>  have it build from a personal branch and disable spammy
>>>>  notifications)
>>>>  and test like as you prefer.
>>>>  If it's not allowing you such permissions, let me know.
>>>>
>>>>  If it's not enough to diagnose this, next week I can show you
>>>>  how to
>>>>  get a root terminal on the build slaves.
>>>>
>>>>  Thanks for helping on this!
>>>>
>>>>  Sanne
>>>>
>>>>
>>>>  On 25 September 2015 at 19:05, Radim Vansa >>>  <mailto:rva...@redhat.com>> wrote:
>>>>  > Since we can't reproduce the test on local machine (I was
>>>>  once runnning
>>>>  > the testsuite whole night again and again and did not get
>>>>  any crash),
>>>>  > the only option I can think of is running
>>>>  hibernate-infinispan with
>>>>  > verbose logging in CI.
>>>>  > To properly diagnose what has happened, we should set up
>>>>  > org.jgroups TRACE
>>>>  > org.infinispan TRACE
>>>>  > org.infinispan.marshall DEBUG
>>>>  > org.infinispan.commons.marshall DEBUG
>>>>  >
>>>>  > (the other two just reduce the verbosity in the parts we
>>>>  don't need). If
>>>>  > the build fails in CI and I can get my hands on the log, I
>>>>  can investigate.
>>>>  >
>>>>  > Steve, should I prepare a PR switching the log level whe

[hibernate-dev] OGM on WildFly11 ...

[Scott Marlow]

Hi,

After our discussion last week about improving OGM use on WildFly (by 
adding a Jipijapa integration adapter for OGM), I wanted to share some 
feedback.

A few years ago, we decided that having a 1-1 (bidirectional) dependency 
between ORM + the Jipijapa adapter was okay. With OGM, we need to 
discuss again.  I think that our choices are to update ORM properties 
that identify class names, to also allow a class instance to be 
specified.  This doesn't have to be all ORM integration properties but 
likely should include the ones currently set by Jipijapa.

hibernate.cache.region.factory_class is currently used by Jipijapa to 
specify the name of the cache region factory class name. I think this 
implies that the Hibernate ORM classloader will need access to the 
Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, 
the ORM module (org.hibernate:main) depends on the 
org.hibernate.jipijapa-hibernate5:main module to resolve this class.

Some alternatives to changing hibernate.cache.region.factory_class to 
allow a class to be specified:

1.  OGM could bundle the ORM classes or depend on a duplicate ORM module 
(with a dependency on a jipi_ogm module).

2.  OGM could avoid using the 2lc on WildFly.

Any preferences or suggestions?

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

Re: [hibernate-dev] OGM on WildFly11 ...

[Scott Marlow]

On 10/21/2015 10:48 AM, Sanne Grinovero wrote:
> Hi Scott,
> I would prefer to have ORM accept instances, and so not need the
> bi-directional dependency across modules.
>
> Hibernate OGM already bundles/depends on some ORM classes but it would
> be much better for everyone if we could keep flexibility about which
> versions exactly.
>
> Regarding 2LC: is the RegionFactory the only thing which is currently
> being injected as classname rather than instance?

Yes, that is the only classname setting that Jipijapa depends on currently.

> If so I think this would be acceptable for a first preview version,
> but I'd still prefer we could clean that up soon.

We could start by not specifying the RegionFactory in the Jipijapa-OGM.

>
> In terms of module dependencies: Jipijapa/OGM should depend on a (user
> selectable) slot of Hibernate OGM. The Hibernate OGM module will
> export the dependency of Hibernate ORM which it targets, so the
> Jipijapa/OGM module would not need to depend directly on any ORM
> module.

As of yet, I don't think that Jipijapa-OGM needs to depend directly on 
any OGM classes (biggest initial improvement is to specify the SCANNER 
so we automatically recognize entity classes in VFS based deployments).

>
> Thanks,
> Sanne
>
>
>
> On 21 October 2015 at 15:14, Scott Marlow  wrote:
>> Hi,
>>
>> After our discussion last week about improving OGM use on WildFly (by
>> adding a Jipijapa integration adapter for OGM), I wanted to share some
>> feedback.
>>
>> A few years ago, we decided that having a 1-1 (bidirectional) dependency
>> between ORM + the Jipijapa adapter was okay. With OGM, we need to
>> discuss again.  I think that our choices are to update ORM properties
>> that identify class names, to also allow a class instance to be
>> specified.  This doesn't have to be all ORM integration properties but
>> likely should include the ones currently set by Jipijapa.
>>
>> hibernate.cache.region.factory_class is currently used by Jipijapa to
>> specify the name of the cache region factory class name. I think this
>> implies that the Hibernate ORM classloader will need access to the
>> Jipijapa supplied class (as mentioned above). Currently, in WildFly 10,
>> the ORM module (org.hibernate:main) depends on the
>> org.hibernate.jipijapa-hibernate5:main module to resolve this class.
>>
>> Some alternatives to changing hibernate.cache.region.factory_class to
>> allow a class to be specified:
>>
>> 1.  OGM could bundle the ORM classes or depend on a duplicate ORM module
>> (with a dependency on a jipi_ogm module).
>>
>> 2.  OGM could avoid using the 2lc on WildFly.
>>
>> Any preferences or suggestions?
>>
>> Scott
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] OGM on WildFly11 ...

[Scott Marlow]

On 10/21/2015 10:56 AM, Steve Ebersole wrote:
> Well first...I am not sure why you are passing a custom RegionFactory.
> What does your custom RegionFactory do that is missing in the
> hibernate-infinispan impls?

AS7/WildFly needs to starts the underlying Infinispan cache and add a 
PersistenceUnitService service dependency on the CacheService.  We 
currently extend the 
org.hibernate.cache.infinispan.InfinispanRegionFactory.  This also 
depends on the WildFly clustering/Infinispan configuration settings as well.

It has been years since I tried to use the built in hibernate-infinispan 
RegionFactory impls, I don't recall if they work (as is) on WildFly.

>
> There is a lot to this discussion under the covers.
>
> To re-iterate our discussion from f2f... Hibernate is moving toward
> being able to accept a number of forms of config settings: String, Class
> and instance.  The idea with the String is that we generally accept
> short-names in addition to FQN.  This 3-piece resolution occurs inside a
> Service (org.hibernate.boot.registry.selector.spi.StrategySelector).  So
> usually this is nice and clean.
>
> RegionFactory does not fit into this cleanliness though, because by
> convention its ctors accept an argument.  The generic StrategySelector
> only works with no-arg ctors.  So one option is to update the
> RegionFactory convention to not expect the Properties as a ctor
> argument; we'd leverage the org.hibernate.service.spi.Configurable
> instead post-instantiation.  This would require discussion with the
> RegionFactory developers and a major release.
>
> Another option, as you suggest is to allow
> hibernate.cache.region.factory_class to identify a Class reference, in
> addition to just the name (FQN or short-name).  We could have it accept
> an instance here, but it would not tie in cleanly with StrategySelector
> because of the ctor arg difference, which means I'd end up having to
> duplicate code.
>
> Yet another option would be to allow Jipijapa to explicitly register
> org.hibernate.boot.registry.selector.StrategyRegistration with the
> EntityManagerFactoryBuilder.  We have discussed this in the past for
> other things.  A StrategyRegistration is a way to hook into the process
> done by StrategySelector.  So you'd pass EntityManagerFactoryBuilder a
> StrategyRegistration that registers the resolution of the name you want
> for your RegionFactory to its Class.  This would in fact be the Class
> reference.

+1, StrategyRegistration sounds like the cleanest solution (IMO).

>
> Or of course, to the first questions I asked.. you could also use one of
> the hibernate-infinispan impls.
>
>
>
> On Wed, Oct 21, 2015 at 9:14 AM Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> Hi,
>
> After our discussion last week about improving OGM use on WildFly (by
> adding a Jipijapa integration adapter for OGM), I wanted to share some
> feedback.
>
> A few years ago, we decided that having a 1-1 (bidirectional) dependency
> between ORM + the Jipijapa adapter was okay. With OGM, we need to
> discuss again.  I think that our choices are to update ORM properties
> that identify class names, to also allow a class instance to be
> specified.  This doesn't have to be all ORM integration properties but
> likely should include the ones currently set by Jipijapa.
>
> hibernate.cache.region.factory_class is currently used by Jipijapa to
> specify the name of the cache region factory class name. I think this
> implies that the Hibernate ORM classloader will need access to the
> Jipijapa supplied class (as mentioned above). Currently, in WildFly 10,
> the ORM module (org.hibernate:main) depends on the
> org.hibernate.jipijapa-hibernate5:main module to resolve this class.
>
> Some alternatives to changing hibernate.cache.region.factory_class to
> allow a class to be specified:
>
> 1.  OGM could bundle the ORM classes or depend on a duplicate ORM module
> (with a dependency on a jipi_ogm module).
>
> 2.  OGM could avoid using the 2lc on WildFly.
>
> Any preferences or suggestions?
>
> Scott
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] OGM on WildFly11 ...

[Scott Marlow]

On 10/21/2015 11:43 AM, Sanne Grinovero wrote:
> On 21 October 2015 at 16:37, Scott Marlow  wrote:
>>
>>
>> On 10/21/2015 10:48 AM, Sanne Grinovero wrote:
>>>
>>> Hi Scott,
>>> I would prefer to have ORM accept instances, and so not need the
>>> bi-directional dependency across modules.
>>>
>>> Hibernate OGM already bundles/depends on some ORM classes but it would
>>> be much better for everyone if we could keep flexibility about which
>>> versions exactly.
>>>
>>> Regarding 2LC: is the RegionFactory the only thing which is currently
>>> being injected as classname rather than instance?
>>
>>
>> Yes, that is the only classname setting that Jipijapa depends on currently.
>>
>>> If so I think this would be acceptable for a first preview version,
>>> but I'd still prefer we could clean that up soon.
>>
>>
>> We could start by not specifying the RegionFactory in the Jipijapa-OGM.
>>
>>>
>>> In terms of module dependencies: Jipijapa/OGM should depend on a (user
>>> selectable) slot of Hibernate OGM. The Hibernate OGM module will
>>> export the dependency of Hibernate ORM which it targets, so the
>>> Jipijapa/OGM module would not need to depend directly on any ORM
>>> module.
>>
>>
>> As of yet, I don't think that Jipijapa-OGM needs to depend directly on any
>> OGM classes (biggest initial improvement is to specify the SCANNER so we
>> automatically recognize entity classes in VFS based deployments).
>
> You're talking about compile time: yes you should be able to compile
> Jipijapa-OGM by simply having Maven point to the correct version of
> Hibernate ORM.

I was actually thinking runtime, not compile time.

>
> But I'm pointing out that the module XML definition should *not*
> depend on the hibernate-orm main slot, but only to the slot containing
> the configured Hibernate OGM module:
> this way the OGM module packager can specify which ORM version to use,
> and export that to clients like jipijapa-ogm and/or end users.

Thanks for explaining, this makes sense.

>
> Thanks,
> Sanne
>
>>
>>
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>>
>>> On 21 October 2015 at 15:14, Scott Marlow  wrote:
>>>>
>>>> Hi,
>>>>
>>>> After our discussion last week about improving OGM use on WildFly (by
>>>> adding a Jipijapa integration adapter for OGM), I wanted to share some
>>>> feedback.
>>>>
>>>> A few years ago, we decided that having a 1-1 (bidirectional) dependency
>>>> between ORM + the Jipijapa adapter was okay. With OGM, we need to
>>>> discuss again.  I think that our choices are to update ORM properties
>>>> that identify class names, to also allow a class instance to be
>>>> specified.  This doesn't have to be all ORM integration properties but
>>>> likely should include the ones currently set by Jipijapa.
>>>>
>>>> hibernate.cache.region.factory_class is currently used by Jipijapa to
>>>> specify the name of the cache region factory class name. I think this
>>>> implies that the Hibernate ORM classloader will need access to the
>>>> Jipijapa supplied class (as mentioned above). Currently, in WildFly 10,
>>>> the ORM module (org.hibernate:main) depends on the
>>>> org.hibernate.jipijapa-hibernate5:main module to resolve this class.
>>>>
>>>> Some alternatives to changing hibernate.cache.region.factory_class to
>>>> allow a class to be specified:
>>>>
>>>> 1.  OGM could bundle the ORM classes or depend on a duplicate ORM module
>>>> (with a dependency on a jipi_ogm module).
>>>>
>>>> 2.  OGM could avoid using the 2lc on WildFly.
>>>>
>>>> Any preferences or suggestions?
>>>>
>>>> Scott
>>>> ___
>>>> hibernate-dev mailing list
>>>> hibernate-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate5 migration

[Scott Marlow]

Should the ORM 5 migration documentation [3] mention that 
"hibernate.transaction.factory_class" can no longer be set to 
"org.hibernate.transaction.CMTTransactionFactory"?  I think that 
CMTTransactionFactory is deleted in 5.0.

Scott

[3] 
https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc


On 08/13/2015 08:38 AM, Steve Ebersole wrote:
> For a lot of your questions, I'd highly suggest reading [1] and [2].  They
> are mostly the same content (asciidoc versus docbook).
>
> [1] -
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
> [2] -
> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#bootstrap-native
>
>
>
>
> On Wed, Aug 12, 2015 at 11:58 PM Koen Serneels  wrote:
>
>> Hi Steve,
>>
>>
>>
>> Let me clarify the first two questions:
>>
>>
>>
>> I’m looking for an entry point/hook in H5 for altering existing class
>> mappings. For example; some of our entities are supposed to be immutable,
>> but only in production mode.
>>
>> When running our tests we are using that same model to setup data in an
>> in-memory database. If the entities would be hardcoded immutable then we
>> would be problematic to use them fully for manipulating setup data in our
>> tests. So, in test mode we actually need the entities to be mutable instead.
>>
>> To accomplish this we  are retrieving  the classMappings from the
>> Configuration which gives us the PersistentClass meta-data. On  this which
>> we can then toggle the mutable flag depending.
>>
>> Since that functionality has now been refactored, I thought that
>> MetadataContributor was the way to go in H5 as it lets me access
>> InFlightMetadataCollector which gives access to getEntityBindingMap which
>> allows to retrieved the PersistentClasses.
>>
>>
>>
>> However, from the source code I understand that the MetadataContributor
>> can only be configured using ServiceLoader. This means it will not be so
>> straightforward/clean to enable or disable that said MetadataContributor
>> dynamically. Now you suggest:  *But if a piece of code is able to
>> determine whether or not to register a MetadataContributor, it could simply
>> contribute said metadata, no?* yes, but this is probably where my
>> understanding is falling short; I was under the impression that the
>> MetadataContributor is **the** new way for contributing changes or
>> additions to existing meta-data. If there is another (programmatic) way
>> without having to register MetadataContributor, then by all means, but
>> how/where?
>>
>>
>>
>> On the JTA question:
>>
>>
>>
>> My question has been answered, thanks, but just to clarify: when using
>> JTA, we can configure the shorthand alias ‘jta’ for the coordinator as you
>> state.
>>
>> With the second part I meant; what if we are _*not*_ using JTA but are in
>> local transaction mode, should we then also explicitly configure the
>> coordinator (with short name ‘jdbc’ in that case) or will it be the
>> default? Again you confirm that ‘jdbc’ is the default so when not using JTA
>> no coordinator setting is required
>>
>>
>>
>> For the last question:
>>
>>
>>
>> Ok thanks for pointing that out. Is there an easy way to get hold of the
>> org.hibernate.boot.Metadata which I need to pass to
>> SchemaCreator/SchemaDropper?
>>
>> I could also use SchemaExport directly from within code, but afaik it will
>> rebuild the metadata which will probably take longer…
>>
>>
>>
>> To give some background how I’m using this:  in some types of test we
>> actually commit data to our in-memory database. In order to clear the
>> database between tests, we simply drop and recreate the entire schema based
>> on the DDL. This was the fastest solution with the least amount of impact.
>> For the record: I’m aware there are other solutions for this, but not all
>> of them are feasible. I’m leaving out the details here as it would go off
>> topic – at the moment I’m just looking for a way to migrate it to H5
>> keeping the same functionality we have been using (extract the create/drop
>> DDL from a live SF as fast as possible)
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Koen.
>>
>>
>>
>> *From:* Steve Ebersole [mailto:st...@hibernate.org]
>> *Sent:* donderdag 13 augustus 2015 4:24
>> *To:* Koen Serneels; hibernate-dev@lists.jboss.org
>> *Subject:* Re: [hibernate-dev] Hibernate5 migration
>>
>>
>>
>> There is a migration guide:
>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md.
>> It is still a work in progress as in its is not "prettified" yet (as 5.0 is
>> not final yet.  If things are missing please let us know.
>>
>>
>>
>> Some answers inline...
>>
>>
>>
>>
>>
>> - In Hibernate4 we modified mappings on-the-fly by overriding Spring's
>> LocalSessionFactoryBean#buildSessionFactory.
>>
>>
>> Doing so we could first access the getClassMapping on
>> org.hibernate.cfg.Configuration before letting the SF actually build.
>>
>> However, in Hibernate5 the metadata access has been refactored a

Re: [hibernate-dev] Hibernate5 migration

[Scott Marlow]

On 11/02/2015 11:02 AM, Steve Ebersole wrote:
> This is mentioned...
> https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc#transactions
>
> Its not just org.hibernate.transaction.CMTTransactionFactory that was
> removed; all of the TransactionFactory classes were removed. Actually I
> think we should add them as resolvable names:
>
> * org.hibernate.transaction.CMTTransactionFactory
> -> 
> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
> * org.hibernate.transaction.JTATransactionFactory
> -> 
> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl
> * org.hibernate.transaction.JDBCTransactionFactory ->
> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorBuilderImpl
>
> Add a Jira if you'd like to see them mapped.

I added HHH-9411 for mapping the transaction factory classes.

Thanks,
Scott

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

Re: [hibernate-dev] Pooled Optimiser Improvements

[Scott Marlow]

Should this be a specialized pooled optimizer that is only used in 
environments that do not suffer from leaving the ThreadLocal around 
after the application is undeployed?  In other words, the expectation is 
that classloader leaks with this pooled optimizer are expected (e.g. 
user must restart the jvm to really undeploy the application completely).

I am thinking that there are at least three typical situations:

1.  Applications are deployed in Java standalone edition.  Generally, 
when the app undeploys the jvm is shutting down.

2. Applications are deployed as part of some container (e.g. an EE 
server) and the Hibernate jars are on the global classloader path (or 
something like that).  On each shared container thread, there would be 
one Optimizer for all deployed applications.  I wonder if instead, we 
would want one Optimizer instance per Hibernate SessionFactory 
associated with the many container threads?

3. Applications are deployed as part of some container (e.g. an EE 
server) and the Hibernate jars are deployed with the application. The 
ThreadLocals are associated with threads that are shared by different 
deployed applications. The application classloader contains the 
Hibernate classes. Each deployed application has its own Optimizer 
threadlocal. On each shared container thread, there would be one 
Optimizer per application (since each application has its Optimizer TL). 
  Like (2), there would be sharing of the same Optimizer with the many 
application session factories.  Should we instead have an optimizer per 
session factory?

Scott

On 12/10/2015 11:31 PM, Stuart Douglas wrote:
> Hello,
>
> I have been working on a change to the pooled optimizer that we have been 
> seeing good performance results with. Basically it hands out blocks of ID's 
> to a thread local, rather than having every thread contend on the lock every 
> time an ID is required.
>
> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>
> What would I need to do to get a change like this in? In particular:
>
> - Does it need to be a new type of optimizer, or is modifying the existing 
> one like I have done OK?
> - How should it be configured?
>
> I am happy to do up a PR for this, but I am just not really sure what would 
> be required to get it to a point where it would be acceptable for inclusion.
>
> Stuart
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Pooled Optimiser Improvements

[Scott Marlow]

On 12/13/2015 08:44 PM, Stuart Douglas wrote:
>
>
> - Original Message -
>> From: "Scott Marlow" 
>> To: "Stuart Douglas" , hibernate-dev@lists.jboss.org
>> Sent: Friday, 11 December, 2015 10:54:15 PM
>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>>
>> Should this be a specialized pooled optimizer that is only used in
>> environments that do not suffer from leaving the ThreadLocal around
>> after the application is undeployed?  In other words, the expectation is
>> that classloader leaks with this pooled optimizer are expected (e.g.
>> user must restart the jvm to really undeploy the application completely).
>>
>> I am thinking that there are at least three typical situations:
>>
>> 1.  Applications are deployed in Java standalone edition.  Generally,
>> when the app undeploys the jvm is shutting down.
>
> In this case it is a non-issue, as the JVM will be destroyed on shutdown.
>
>>
>> 2. Applications are deployed as part of some container (e.g. an EE
>> server) and the Hibernate jars are on the global classloader path (or
>> something like that).  On each shared container thread, there would be
>> one Optimizer for all deployed applications.  I wonder if instead, we
>> would want one Optimizer instance per Hibernate SessionFactory
>> associated with the many container threads?
>
> AFAIK there is one optimiser per table, not one global optimiser. On undeploy 
> these Optimisers will no longer be referenced and should be eligible for GC, 
> which will clean up the thread local.

Good point.  Looks like its associated with each mapped entity class 
(which is per Hibernate session factory).

>
> It is importable to note that this is not a static thread local, which are 
> very prone to leaks.

Good point, so no leak.

>
>>
>> 3. Applications are deployed as part of some container (e.g. an EE
>> server) and the Hibernate jars are deployed with the application. The
>> ThreadLocals are associated with threads that are shared by different
>> deployed applications. The application classloader contains the
>> Hibernate classes. Each deployed application has its own Optimizer
>> threadlocal. On each shared container thread, there would be one
>> Optimizer per application (since each application has its Optimizer TL).
>>Like (2), there would be sharing of the same Optimizer with the many
>> application session factories.  Should we instead have an optimizer per
>> session factory?
>
> The same this applied here, once the application is undeployed the 
> ThreadLocal should be eligible for GC.
>
> Stuart
>
>>
>> Scott
>>
>> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>>> Hello,
>>>
>>> I have been working on a change to the pooled optimizer that we have been
>>> seeing good performance results with. Basically it hands out blocks of
>>> ID's to a thread local, rather than having every thread contend on the
>>> lock every time an ID is required.
>>>
>>> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>>>
>>> What would I need to do to get a change like this in? In particular:
>>>
>>> - Does it need to be a new type of optimizer, or is modifying the existing
>>> one like I have done OK?
>>> - How should it be configured?
>>>
>>> I am happy to do up a PR for this, but I am just not really sure what would
>>> be required to get it to a point where it would be acceptable for
>>> inclusion.
>>>
>>> Stuart
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Pooled Optimiser Improvements

[Scott Marlow]

On 12/11/2015 09:30 AM, Steve Ebersole wrote:
> It's hard to say without understanding the scenario where you are seeing
> this as a problem.  I have some guesses as to what may be the problem,
> but without understanding more about why you see this as a problem in
> the first place it is hard to give you an answer.  For example, I wonder
> if for environments not using multi-tenancy whether the recent changes
> for the generators to support multi-tenancy might be the culprit.  If
> that is the case, and those changes are in fact the underlying cause of
> the perf issues you see then I think there is actually a better
> solution.  But again, its hard to say unless we understand the reason
> this "shows up" as a perf problem for you.

As best as I can tell from looking at the current PooledLoOptimizer, 
versus the proposed change (to have a chunk of ids per thread), we went 
from accessing a contented lock, to instead using per thread memory 
(eliminating the contended lock on PooledLoOptimizer.generate()).

>
> Until we hear more I think at this stage I'd vote for a separate
> optimizer.  And maybe even not one that is upstream.
>
> Also I agree with Scott that I am VERY leery of not cleaning up a
> ThreadLocal.

My mistake, as Stuart pointed out, the TL is not static, so we shouldn't 
introduce any leaks.

>
> On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow  <mailto:smar...@redhat.com>> wrote:
>
> Should this be a specialized pooled optimizer that is only used in
> environments that do not suffer from leaving the ThreadLocal around
> after the application is undeployed?  In other words, the expectation is
> that classloader leaks with this pooled optimizer are expected (e.g.
> user must restart the jvm to really undeploy the application
> completely).
>
> I am thinking that there are at least three typical situations:
>
> 1.  Applications are deployed in Java standalone edition.  Generally,
> when the app undeploys the jvm is shutting down.
>
> 2. Applications are deployed as part of some container (e.g. an EE
> server) and the Hibernate jars are on the global classloader path (or
> something like that).  On each shared container thread, there would be
> one Optimizer for all deployed applications.  I wonder if instead, we
> would want one Optimizer instance per Hibernate SessionFactory
> associated with the many container threads?
>
> 3. Applications are deployed as part of some container (e.g. an EE
> server) and the Hibernate jars are deployed with the application. The
> ThreadLocals are associated with threads that are shared by different
> deployed applications. The application classloader contains the
> Hibernate classes. Each deployed application has its own Optimizer
> threadlocal. On each shared container thread, there would be one
> Optimizer per application (since each application has its Optimizer TL).
>Like (2), there would be sharing of the same Optimizer with the many
> application session factories.  Should we instead have an optimizer per
> session factory?
>
> Scott
>
> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
>  > Hello,
>  >
>  > I have been working on a change to the pooled optimizer that we
> have been seeing good performance results with. Basically it hands
> out blocks of ID's to a thread local, rather than having every
> thread contend on the lock every time an ID is required.
>  >
>  >
> 
> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
>  >
>  > What would I need to do to get a change like this in? In particular:
>  >
>  > - Does it need to be a new type of optimizer, or is modifying the
> existing one like I have done OK?
>  > - How should it be configured?
>  >
>  > I am happy to do up a PR for this, but I am just not really sure
> what would be required to get it to a point where it would be
> acceptable for inclusion.
>  >
>  > Stuart
>  > ___
>  > hibernate-dev mailing list
>  > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>  > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>  >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev