[hibernate-dev] Re: Hibernate ORM 6.4.4.Final has been released

Congratulations on the release and thank you! On Thu, Feb 8, 2024 at 8:53 AM Marco Belladelli wrote: > Hello everyone, > we've just released Hibernate ORM version 6.4.4.Final > > For details: > https://in.relation.to/2024/02/08/orm-644-final/ > > Regards, > Marco >

[hibernate-dev] help needed integrating WildFly main + ORM 6.4.0.Final due to build failure...

I just tried to build WildFly with Hibernate ORM 6.4.0.Final and am seeing a build failure due to WildFly [1] depending on an internal ORM class org.hibernate.cache.internal.NaturalIdCacheKey [2] that has a private constructor. Would it make sense to add a NaturalIdCacheKey#from method that has

[hibernate-dev] Re: Hibernate ORM 6.2.2 Final Release

Yay!!! Congratulations on the release! On Fri, Apr 28, 2023 at 10:35 AM Marco Belladelli wrote: > Hibernate ORM 6.2.2 Final has just been released. > See https://in.relation.to/2023/04/28/hibernate-orm-622-final/ for the > details. > ___ >

[hibernate-dev] Re: Possible paths for applications with "hibernate.id.new_generator_mappings" set to false and are migrating to ORM 6.0 with WildFly

On 5/18/22 9:15 AM, Scott Marlow wrote: WildFly is currently failing to deploy applications that have "hibernate.id.new_generator_mappings" (USE_NEW_ID_GENERATOR_MAPPINGS) set to false [1], since that option is removed from Hibernate ORM 6. Words matter :-)  I meant to say th

[hibernate-dev] Possible paths for applications with "hibernate.id.new_generator_mappings" set to false and are migrating to ORM 6.0 with WildFly

WildFly is currently failing to deploy applications that have "hibernate.id.new_generator_mappings" (USE_NEW_ID_GENERATOR_MAPPINGS) set to false [1], since that option is removed from Hibernate ORM 6. The application deployment failure message [2] is basically: "

[hibernate-dev] Re: ORM 6 + staged Jakarta Persistence 3.1 SPEC API jar...

.  In a few hours, that will be updated with the latest staged JPA 3.1 TCK (if all goes well with https://ci.eclipse.org/jakartaee-tck/job/10/job/eftl-standalonetck-build-run-100/56). Scott [1] https://github.com/hibernate/hibernate-orm/pull/4832 Am 21.01.2022 um 18:18 schrieb Scott Marlow: Hi

[hibernate-dev] ORM 6 + staged Jakarta Persistence 3.1 SPEC API jar...

Hi, In the next few weeks, we can expect that a final release of Jakarta Persistence 3.1 SPEC API *may* become available (time permitting :-).  In the mean time there is a staged jakarta.persistence-api-3.1.0-RC2.jar [1].  Technically, artifacts like jakarta.persistence-api-3.1.0-RC2.jar

[hibernate-dev] Jakarta Persistence 3.1 will add AutoClosable support and possibly other features added...

Hi, I asked via [1] if other features may be added to Jakarta Persistence 3.1 (target would be the Jakarta EE 10/10.1 Platform).  Response [2] indicated that more features are expected (as we know many feature requests remain to be sifted through). If we feel strongly about any one feature

Re: [hibernate-dev] Bad boot performance since 5.4 switched to ByteBuddy

On Tue, Aug 4, 2020, 11:27 AM Christian Beikov wrote: > I'm moving this discussion from Zulip to the mailing list as Rafael does > not seem to be on Zulip. Try to ping him on Twitter then with a link to this email thread. Ask him what your options are to improve proxy generation performance.

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

it make sense for the above condition (cl.getResource() returning null) be detected differently in the callstack [1] and just fall through + return to the caller? Scott [1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd On 3/26/19 9:53 AM, Scott Marlow wrote: > Hi To

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

the actual bytecode is added. Scott On 3/26/19 9:17 AM, Tomasz Adamski wrote: > Hi Scott, > > Added to my TODO. WIll try to look at it this week. > > Regards, > Tomek > > On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow <mailto:smar...@redhat.com>> wrote: > >

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

Adding Tomek + Cheng, as they have been working on the WildFly EJB layer recently, which seems to use https://github.com/jbossas/jboss-classfilewriter for generating the EJB stub classes like org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class. Perhaps Tomek or

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

> > > > > https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57 We should try to recreate without WildFly, perhaps hacking the SerializationHackProxy code into a Hibernate unit test or ByteBuddy test, could be our next

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

t like these generated classes for some reason (or something like that). > > On Fri, Mar 22, 2019 at 12:34 PM Scott Marlow <mailto:smar...@redhat.com>> wrote: > > > On 3/22/19 1:53 PM, Gail Badner wrote: > > I just wa

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

Fri, Mar 22, 2019 at 7:22 AM Scott Marlow <mailto:smar...@redhat.com>> wrote: > > > > On 3/22/19 10:08 AM, Scott Marlow wrote: > > > > > > On 3/22/19 9:24 AM, Scott Marlow wrote: > >> > >> > >> On 3

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

On 3/22/19 10:08 AM, Scott Marlow wrote: > > > On 3/22/19 9:24 AM, Scott Marlow wrote: >> >> >> On 3/22/19 9:11 AM, Scott Marlow wrote: >>> >>> >>> On 3/22/19 7:49 AM, Guillaume Smet wrote: >>>> Hi

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

On 3/22/19 9:24 AM, Scott Marlow wrote: > > > On 3/22/19 9:11 AM, Scott Marlow wrote: >> >> >> On 3/22/19 7:49 AM, Guillaume Smet wrote: >>> Hi Gail, >>> >>> Do we have any idea of what this class is supposed to be: >>> org.jbos

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

On 3/22/19 9:11 AM, Scott Marlow wrote: > > > On 3/22/19 7:49 AM, Guillaume Smet wrote: >> Hi Gail, >> >> Do we have any idea of what this class is supposed to be: >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ? > > This is

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

On 3/22/19 7:49 AM, Guillaume Smet wrote: > Hi Gail, > > Do we have any idea of what this class is supposed to be: > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5 ? This is a unit test class that is not an entity class, but instead it happens to be an EJB stateless

Re: [hibernate-dev] Should the TransactionSynchronizationRegistry be cached by the JtaPlatform or perhaps at the SessionFactory level?

ott, > > I see that the issue is resolved and your commit is merged. Is this no > longer an issue? > > Thanks, > Gail > > On Wed, Nov 28, 2018 at 1:12 PM Scott Marlow <mailto:smar...@redhat.com>> wrote: > > Hi, > > I started wor

[hibernate-dev] Should the TransactionSynchronizationRegistry be cached by the JtaPlatform or perhaps at the SessionFactory level?

Hi, I started working on a WildFly change WFLY-11243 [1] to cache the TransactionSynchronizationRegistry inside of the WildFly JtaPlatform instance. The purpose of caching the TransactionSynchronizationRegistry is to avoid repeated JndiService.locate() calls, like during entity manager

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

On 9/21/18 10:29 AM, Steve Ebersole wrote: > Honestly Scott, I am thoroughly confused now as to what you are wanting > and what you are reporting. > > Your last code fragment[1] is close.  As I said earlier, building a > SessionFactory typically involves individual service registries being >

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

I verified that SessionFactoryServiceContributor doesn't help WF either, as we see the same problem. I did hack together a unit test under ORM (using the WF integration testing) that shows that we don't see the same problem when the

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

On 9/20/18 3:17 PM, Scott Marlow wrote: > I'm going to try some more changes on the WF side, to see if I can work > around this problem.  I'll report back on how that goes. :) I tried overriding the ServiceRegistryImplementor#initiateService(Map configurationValues, ServiceRegistryImple

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

I'm going to try some more changes on the WF side, to see if I can work around this problem. I'll report back on how that goes. :) On 9/20/18 12:05 PM, Scott Marlow wrote: > Is https://gist.github.com/scottmarlow/63241549820243923aab16e664c3c6c3 > closer to what we need? > > On

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

as creating two separate SFs and expecting the RegionFactoryInitiator to be called twice? On 9/19/18 9:52 AM, Scott Marlow wrote: > > > On 9/19/18 9:22 AM, Steve Ebersole wrote: >> Ohhh... Sorry I misunderstood.  I thought you were asking about ways >> to have the contribu

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

a test? Yes, I will work on a test. > > > On Wed, Sep 19, 2018, 8:12 AM Scott Marlow <mailto:smar...@redhat.com>> wrote: > > > > On 9/19/18 5:41 AM, Gunnar Morling wrote: > > Would SessionFactoryServiceContributor [1] be of use to you? It > l

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

rnate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/service/spi/SessionFactoryServiceContributor.java > > Am Di., 18. Sep. 2018 um 21:00 Uhr schrieb Scott Marlow > mailto:smar...@redhat.com>>: > > > > > > On 9/14/18 6:14 PM, Steve Ebersol

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

StandardServiceRegistryBuilder#build` > processing.  So we'd need a call to register a ServiceContributor > with the StandardServiceRegistryBuilder. > > Of course that also means you'd have to have access to the > StandardServiceRegistryBuilder > > On Fri, Sep 14, 201

Re: [hibernate-dev] Is there a way to have ServiceContributor per SessionFactory/EMF instead of per application classloader?

to register a ServiceContributor with > the StandardServiceRegistryBuilder. > > Of course that also means you'd have to have access to the > StandardServiceRegistryBuilder I don't have a way to add a programatic call while bootstrapping "not JPA container". > > On Fri, Sep 14, 20

Re: [hibernate-dev] How to enable Javassist when running a WildFly unit test?

Better to use WildFly -secmgr option, instead of -Dsecurity.manager. From what I recall, this helps avoid a boot time issue with -Dsecurity.manager. For enabling javassist for a one off test run, simply prestart your WildFly app server with the desired options and then launch. For more than

Re: [hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14...

On 07/09/2018 11:27 AM, Guillaume Smet wrote: > On Mon, Jul 9, 2018 at 5:12 PM Sanne Grinovero > wrote: > > No, but there are some tests which are specific to Javassist. > > > That's what I suspected. Let's run the full test suite with the new > version of

[hibernate-dev] Javassist version alignment for Hibernate ORM 5.3 + WildFly 14...

We would like to update WildFly (14) to Javassist 3.23.1, has anyone tried using Javassist 3.23.1 with Hibernate ORM 5.3? I'd like to know that we at least can pass the Javassist tests with the ORM testsuite, preferably on JDK11 (since that is why we want to upgrade Javassist on WildFly).

Re: [hibernate-dev] What should be the contract for PersistenceUnitInfo#addTransformer with regard to multiple persistence units mapping the same entity class?

Team > <https://red.ht/sig> > On 06/05/2018 07:08 PM, Scott Marlow wrote: > > Thanks, I think they probably intended that the persistence provider would > use a marker interface like org.hibernate.engine.spi.Managed to ensure > that the enhancement is only done once. Response

Re: [hibernate-dev] What should be the contract for PersistenceUnitInfo#addTransformer with regard to multiple persistence units mapping the same entity class?

On Tue, Jun 5, 2018 at 1:06 PM, Sanne Grinovero wrote: > On 5 June 2018 at 14:43, Scott Marlow wrote: > > The PersistenceUnitInfo#addTransformer javadoc [1] mentions: > > > > " > > Add a transformer supplied by the provider that will be called for every &

Re: [hibernate-dev] What should be the contract for PersistenceUnitInfo#addTransformer with regard to multiple persistence units mapping the same entity class?

Thanks, I think they probably intended that the persistence provider would use a marker interface like org.hibernate.engine.spi.Managed to ensure that the enhancement is only done once. Responses to your questions are inline below. On Tue, Jun 5, 2018 at 12:19 PM, Luis Barreiro wrote: > Hi

[hibernate-dev] What should be the contract for PersistenceUnitInfo#addTransformer with regard to multiple persistence units mapping the same entity class?

The PersistenceUnitInfo#addTransformer javadoc [1] mentions: " Add a transformer supplied by the provider that will be called for every new class definition or class redefinition that gets loaded by the loader returned by the getClassLoader()

Re: [hibernate-dev] Is bytecode enhancement enabled by default in 5.3?

> > Well based on what you described it sounds to me like there ought to be at >> least 2 different log events here: >> >> 1. The transformer is registered (this could be either WF or Hibernate >> or both) >> 2. The transformer calls the Enhancer >> > >

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On 05/29/2018 10:05 AM, Steve Ebersole wrote: > On Tue, May 29, 2018 at 8:38 AM Scott Marlow <mailto:smar...@redhat.com>> wrote: > > > On 05/29/2018 08:48 AM, Steve Ebersole wrote: > > By "non-jpa container managed deployments" you mean inject

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

orm (so that we first check for WildFly Transaction Client classes, failing that, we then try the Arjuna classes.) > > On Mon, May 28, 2018 at 12:31 PM Scott Marlow <mailto:smar...@redhat.com>> wrote: > > A fix is merged to orm master branch, which should be in 5.3.2, as

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

probably the JtaPlatformInitiator. > We do, by default. > > On Sun, May 27, 2018, 3:58 PM Sanne Grinovero wrote: > >> On 27 May 2018 at 15:29, Scott Marlow wrote: >> > >> > >> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero >> > wrote: >> >>

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero <sa...@hibernate.org> wrote: > On 27 May 2018 at 00:30, Scott Marlow <smar...@redhat.com> wrote: > > Next idea, we should first look for the WFTC classes, if not found, then > > look for Arjuna classes. > > +1 t

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

Next idea, we should first look for the WFTC classes, if not found, then look for Arjuna classes. On Sat, May 26, 2018, 7:12 PM Scott Marlow <smar...@redhat.com> wrote: > > > On Sat, May 26, 2018, 6:05 PM Scott Marlow <smar...@redhat.com> wrote: > >> O

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On Sat, May 26, 2018, 6:05 PM Scott Marlow <smar...@redhat.com> wrote: > Or, maybe we should just remove the JBOSS_TM_CLASS_NAME > + JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using the > standard JBoss TM/UT JNDI names. > This wouldn't work for s

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

Or, maybe we should just remove the JBOSS_TM_CLASS_NAME + JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using the standard JBoss TM/UT JNDI names. On Sat, May 26, 2018 at 5:05 PM, Scott Marlow <smar...@redhat.com> wrote: > > On Sat, May 26, 2018 at 9:04 AM, Sanne G

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero wrote: > Hi Scott, > > I see you changed JBossStandAloneJtaPlatform to use a new API in WildFly; > More that in WildFly 13, applications shouldn't use the Arjuna TM classes directly anymore. The WildFly Transaction Client

Re: [hibernate-dev] Multiple ResultSets from JDBC execution

On Fri, May 25, 2018 at 8:59 AM, Steve Ebersole wrote: > Great that was actually my thought as well. > > Anyone else? > +1 for being able to treat the result sets as not the same. Scott ___ hibernate-dev mailing list

Re: [hibernate-dev] Is bytecode enhancement enabled by default in 5.3?

On 05/23/2018 09:17 AM, Steve Ebersole wrote: > I never understood this `DataSourceDefinitions` part.  Why can't they > just be discovered via jipijapa prior to doing anything with Hibernate/JPA? The @DataSourceDefinition DataSource that ORM needs, doesn't start until after application

[hibernate-dev] Suggestions for alternative due to deprecation of Configuration access in ServiceContributor...

For the WildFly use of ServiceContributor [1], which registers for each SF/EMF, the 2lc RegionFactoryInitiator + JtaPlatform, I am worried that we don't yet have a "per app deployment" way to disable the WF ServiceContributorImpl. I'm thinking that some applications (e.g. Spring) may not want

Re: [hibernate-dev] Is bytecode enhancement enabled by default in 5.3?

On 05/20/2018 08:48 AM, Sanne Grinovero wrote: > Hi Scott, > > could you explain what you mean by "tradeoff" in this context? Hi Sanne, Sure, see below for more details. > > Thanks! > > > On 20 May 2018 at 12:06, Scott Marlow <smar...@redhat.com

Re: [hibernate-dev] Is bytecode enhancement enabled by default in 5.3?

There is a tradeoff in WF deployment, between Hibernate bytecode (runtime) enhancing class transformers, being registered before CDI deployment, reads the entity classes. There is also the tradeoff between Hibernate bytecode (runtime) enhancing class transformers being registered too late because

Re: [hibernate-dev] Stride

Does Zulip have a Fedora (native) client that can be installed by Fedora dnf tool? I've been using Zulip in a browser [1] (as I do with hipchat) and it seems at least as good as hipchat. Has anyone looked at the Zulip multiple organization (team) support [2]? Scott [1]

Re: [hibernate-dev] 5.3 finalization plan

On 03/01/2018 02:37 PM, Steve Ebersole wrote: > In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified > discussion about the remaining currently unresolved discussions and what > exactly we are going to do for 5.3 mainly in regards to compatibility with > an eye to 6.0 > > > >

Re: [hibernate-dev] Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class

on what extensions should be considered public API *in the scope of WildFly's requirements*. Scott, do you have an update on that, or maybe refresh our memories? Thanks, Sanne On 8 February 2018 at 19:54, Scott Marlow <smar...@redhat.com> wrote: > > > On 02/08/2018 01:50

Re: [hibernate-dev] Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class

team looks at the latest/greatest version of Hibernate ORM to include, we will face pressure against bringing in any newer ORM version that requires application coding/configuration changes. > > > On Thu, Feb 8, 2018 at 12:30 PM Scott Marlow <smar...@redhat.com

Re: [hibernate-dev] Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class

On 01/31/2018 10:49 AM, Steve Ebersole wrote: > Not to mention, I'm really not even sure what this request "means".  As > we all understand 5.1 -> 5.2 unified SessionFactory/EntityManagerFactory > and Session/EntityManager, and that caused us to have to make changes to > certain method

[hibernate-dev] Could we have a Hibernate 5.3 compatibility layer that includes the ORM 5.1 Hibernate Session class

WildFly would like to have a version of 5.3+, that is compatible with ORM 5.1, with regard to the org.hibernate.session changes (including mapping of exceptions thrown, so that the same exceptions are thrown). Is it even possible to have an extra org.hibernate.Session interface + impl (bridge)

Re: [hibernate-dev] 5.3.0 release tomorrow

On Tue, Jan 30, 2018 at 11:00 PM, Steve Ebersole wrote: > Wanted to remind everyone that tomorrow is the next time-boxed release for > 5.3. > > I wanted to get everyone's opinions about the version number, whether this > should be Beta2 or CR1. IMO It depends how you view

[hibernate-dev] Does Hibernate ORM bytecode enhance application entity classes by default?

Hi, Did we change Hibernate to automatically enhance/rewrite application entity classes by default? I remember hearing a few times that we would but don't remember if that happened. This is related to WildFly jira WFLY-8858 [1], which I'm not yet sure of how to completely fix (involves deal

Re: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope

endedBeanManager/LifecycleListener, that should already be enough. Those things are already properly scoped to the SessionFactory, unless you are passing the same instance to multiple SessionFactory instances. On Wed, Jan 3, 2018 at 10:09 AM Scott Marlow <smar...@redhat.com> wrote: > On Tue, Jan

Re: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope

e fine. > I could pass the EMF to the org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager.LifecycleListener, if that helps. > > On Tue, Jan 2, 2018 at 1:39 PM Scott Marlow <smar...@redhat.com> wrote: > >> On Wed, Dec 20, 2017 at 9:48 AM, Sanne Grinovero <sa...@hibernate.org> >> wrote: >> >> > Any dependency inje

Re: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope

On Wed, Dec 20, 2017 at 9:48 AM, Sanne Grinovero wrote: > Any dependency injection framework will have some capability to define > the graph of dependencies across components, and such graph could be > very complex, with details only known to the framework. > > I don't think

Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing

On 08/30/2017 11:27 AM, Sanne Grinovero wrote: > Hi Gail, > > no I haven't opened a WFLY issue as I'm not sure if this is an issue. > > There seems to be some inconsistency and it certainly breaks some > Hibernate Search tests but we could of course adapt things to the new > reality.. if this

[hibernate-dev] progress update on wildfly-nosql project...

Hi, Wildfly Swarm now has the initial NoSQL (native NoSQL driver integration) fractions included [1], which should be in the next Swarm release. Applications can use @Inject @Named("MyDefinedNoSQLProfile") Cluster myCassandraCluster; to inject native NoSQL connections, where the injected

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

On 03/28/2017 11:30 AM, Scott Marlow wrote: > Hi, > > Would it be possible for a WildFly deployment unit processor to detect > Hibernate ORM native applications, by detecting the presence of a > particular configuration file that is always present? I'm not sure if >

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

the (supported) Hibernate orm module to the native application, if the deployment is clearly marked as a Hibernate native application, as well as also exporting Javassist to the deployment. Thoughts? Scott On Fri, Oct 28, 2016 at 9:44 AM, Scott Marlow <smar...@redhat.com> wrote: >>> Right,

Re: [hibernate-dev] Example of WildFly JPA container safely closing the EntityManager after the application calls transaction.rollback, which also handles background tx reaper thread time outs

Artifact that contains the org.jboss:jboss-transaction-spi (WildFly is currently using version 7.5.0.Final of this artifact). On Thu, Jan 26, 2017 at 9:28 AM, Scott Marlow <smar...@redhat.com> wrote: > Hi, > > [1] is an example of how the WildFly JPA container is ensuring that &

[hibernate-dev] Example of WildFly JPA container safely closing the EntityManager after the application calls transaction.rollback, which also handles background tx reaper thread time outs

Hi, [1] is an example of how the WildFly JPA container is ensuring that the background (transaction manager) reaper (transaction timeout) thread does not cause EntityManager.close() to be called, while the application is actively executing calls to EntityManager.*(). The idea, as suggested by

Re: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules

b61a6003f704221f66dcd9f418bcb7af88fb9ab/jpa/subsystem/src/main/java/org/jboss/as/jpa/processor/JPADependencyProcessor.java#L95 > > Is there any way I can prevent this injection from happening? Can I > override this JPADependencyProcessor? > > Thanks, > Sanne > > On 11 Jan

Re: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules

. +1 > > As I understand it, it is always ORM that does the enhancement, right Scott? Yes, ORM always does the enhancement. > > On Wed, Jan 11, 2017 at 10:12 AM Scott Marlow <smar...@redhat.com> wrote: >> >> Ahh, I was confused then, your talking about the WildF

Re: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules

Ahh, I was confused then, your talking about the WildFly ORM static module definition [1], which is not controlled by the JPA container or JipiJapa. >> >> We talked about this not long ago and possible solutions, the only >> agreed on solution was to eliminate the ORM requirement for Javassist >>

Re: [hibernate-dev] Javassist enhancement problems with the Hibernate ORM WildFly modules

>> ## Suggestions? >> I'm stuck again on Hibernate Search upgrading to latest ORM so I'll >> see to apply the workaround without waiting for the proper solution. >> Not sure which actions I should take on ORM? >> >> Personally I think I'd just patch the modules to use the older >> Javassist when

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

>> Right, Hibernate ORM's module should be the one exposing it, not the >> application nor JipiJapa. > > JipiJapa has zero to do with this, we will create a pr later today to > remove the unneeded dependencies, which has nothing to do with this > conversation.

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

On Thu, Oct 27, 2016 at 10:14 AM, Steve Ebersole wrote: > Dunno. To me this is a bug that Jipijapa/WF/DUP adds this dependency at > all. How that gets resolved or not is completely up to Jipijapa/WF/DUP as > it is the one(s) doing this. There is nothing Hibernate can do

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

applications with Hibernate ORM embedded in a small way, that has a tiny (one line change) workaround needed. :-) On Thu, Oct 27, 2016 at 10:39 AM, Scott Marlow <smar...@redhat.com> wrote: > On Thu, Oct 27, 2016 at 10:09 AM, Gunnar Morling <gun...@hibernate.org> wrote: >> 2016-

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

On Thu, Oct 27, 2016 at 10:09 AM, Gunnar Morling <gun...@hibernate.org> wrote: > 2016-10-27 15:55 GMT+02:00 Scott Marlow <smar...@redhat.com>: >> >> I remember now why I didn't remove the JPADependencyProcessor >> injection of Javassist in >> https://github.

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

;st...@hibernate.org> wrote: > I would argue that that is a bad deployment. IMO if you supply your own > Hibernate jars, you'd be responsible for supplying its dependency jars as > well. Javassist is currently a non-optional dependency of ORM. > > On Thu, Oct 27, 2016 at 8:55

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

ll request for the "don't inject javassist" hint handling. On Thu, Oct 27, 2016 at 9:40 AM, Gunnar Morling <gun...@hibernate.org> wrote: > > > 2016-10-27 14:59 GMT+02:00 Scott Marlow <smar...@redhat.com>: >> >> On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morli

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

On Thu, Oct 27, 2016 at 4:49 AM, Gunnar Morling <gun...@hibernate.org> wrote: > Hi, Hi, > > 2016-10-27 4:27 GMT+02:00 Scott Marlow <smar...@redhat.com>: >> >> >> > Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module >> > (th

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

hibernate.org>: >>> >>> We could fix 1) as well by incorporating the sources for >>> jipijapa-hibernate52 in ORM. >>> >>> I think it belongs within Hibernate, as it won't be the last time that a >>> new ORM version requires some adaptation of bootstrap.

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

> Unless I am mistaken, Gunnar is suggesting that the Hibernate ORM module (the WF module) export Javassist. Not the application. > I agree, that is what our WF pull request did, which I think is an incremental improvement but that wasn't approved for the reason I gave. >> Is the ORM testsuite

Re: [hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

Just to be clear, Jipijapa doesn't use Javassist at all. For JPA deployments that are using Hibernate, the (WildFly) JPA container is exporting the org.javassist:module to the application deployment classloader, so that the Javassist proxy runtime classes can be referenced by application classes

Re: [hibernate-dev] ORM and Java 9

On 09/27/2016 08:15 PM, Steve Ebersole wrote: > It seems like Shigeru and team have Javassist Java 9 compatible now. Per > https://issues.jboss.org/browse/JASSIST-261 I have played with the propsed > changes using a SNAPSHOT of that built and pushed by Scott. Using that > SNAPSHOT, all those

Re: [hibernate-dev] 5.3?

Small-Team > > > On Thu, Aug 18, 2016 at 7:42 AM Scott Marlow <smar...@redhat.com > <mailto:smar...@redhat.com>> wrote: > > > On 08/17/2016 03:54 PM, Steve Ebersole wrote: > > For whatever reason discussion about JavaMoney/Moneta support has > h

Re: [hibernate-dev] 5.3?

On 08/17/2016 03:54 PM, Steve Ebersole wrote: > For whatever reason discussion about JavaMoney/Moneta support has heated up > again the past few days. Is this important enough to warrant a 5.3 release? My (late) vote is to rename 5.2 -> 6.0 and have the 5.3 release be based on the current ORM

Re: [hibernate-dev] Hibernate ORM version for WildFly 10.1

ORM 5.1 in, as long as it's equally as hardened. > > As a user, I'd be surprised otherwise and be wondering why I had to > resort to the ORM module ZIP (see > http://in.relation.to/2016/07/07/updating-hibernate-orm-in-wildfly/) > instead of WF coming with the newer versio

Re: [hibernate-dev] Hibernate ORM version for WildFly 10.1

On 08/11/2016 10:45 AM, Sanne Grinovero wrote: > On 11 August 2016 at 15:19, Scott Marlow <smar...@redhat.com> wrote: >> >> On 08/11/2016 06:19 AM, Sanne Grinovero wrote: >>> >>> I've been watching this: >>> - https://github.com/wildfly/wildfly/p

Re: [hibernate-dev] Hibernate ORM version for WildFly 10.1

On 08/11/2016 06:19 AM, Sanne Grinovero wrote: > I've been watching this: > - https://github.com/wildfly/wildfly/pull/8984 > > And that's the reason I've been asking for a 5.1 release, as it has > been blocked by issues for long. > > Indeed if this wasn't being tracked for 10.1 that's sad as we

Re: [hibernate-dev] Hibernate ORM version for WildFly 10.1

Hi Gunnar, I'm not against ORM 5.1.1 being included in WildFly 10.1, but it is more likely to be in WildFly 11, since WildFly 10.1 is likely to be released before ORM 5.1.1. Scott On 08/11/2016 03:23 AM, Gunnar Morling wrote: > Hi Scott, all, > > Are there any plans to upgrade ORM in the WF

Re: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in WildFly

On 06/27/2016 11:44 AM, Sanne Grinovero wrote: > On 27 June 2016 at 16:23, Scott Marlow <smar...@redhat.com> wrote: >>> >>> That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks >>> a bit scary. My simple test passes, not sure whether that

Re: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in WildFly

> > That dependency to org.hibernate:main from org.jboss.as.ejb3 still looks > a bit scary. My simple test passes, not sure whether that may be a > problem in other cases, though? > Sorry, I missed this part of your email. EJB3 timers are using Hibernate [1]. Scott [1]

Re: [hibernate-dev] Module ZIP for upgrading Hibernate ORM in WildFly

On 06/25/2016 05:12 PM, Sanne Grinovero wrote: > On 25 June 2016 at 13:15, Gunnar Morling wrote: >> Ok, so this was caused by the module dependency >> from org.hibernate.jipijapa-hibernate5 to org.hibernate. Seems I need to >> create a 5.1-specific adapter module, too, and

[hibernate-dev] update on WildFly NoSQL prototype integration (e.g. OGM/native api use) ...

Hi, Feedback is welcome on the wildfly-dev mailing list regarding NoSQL integration [1]. Rather than cross posting or duplicating the content on different mailing lists, we just posted to wildfly-dev and will ping other mailing lists. If there is some OGM specific response that you would

Re: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

I squash commits next time). Let me know if you there is interest in reviewing this branch and I'll squash right away (easier to review squashed commits imo). [2] http://pastie.org/10822811 > > Thanks, > Sanne > > > On 21 April 2016 at 14:59, Scott Marlow <smar...@redhat.c

Re: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

On 04/18/2016 11:32 AM, Sanne Grinovero wrote: > I think there was some confusion in this thread, probably it wasn't > clear that WildFly 10 already does inject automatically OGM, and that > ship sailed so we have to keep in mind what Jipijapa is going to do by > default: > > The current state

Re: [hibernate-dev] Master

I'm curious if Search/OGM master branches would likely align with 5.2? Or some other branch? On 04/07/2016 11:34 AM, Steve Ebersole wrote: > As a follow up to this... > > Sanne had a great suggestion on HipChat. What about turning all this work > (sans SQM, etc) into a 5.2 as an "end of line

Re: [hibernate-dev] 6.0 planning

On 04/04/2016 11:36 AM, Sanne Grinovero wrote: > On 4 April 2016 at 15:48, Steve Ebersole <st...@hibernate.org> wrote: >> So there we go :) >> >> On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow <smar...@redhat.com> wrote: >>> >>> Hmm, just

Re: [hibernate-dev] 6.0 planning

actory? Is there a Jira for that? > > > On Mon, Apr 4, 2016 at 9:20 AM Scott Marlow <smar...@redhat.com > <mailto:smar...@redhat.com>> wrote: > > On 04/04/2016 08:55 AM, Sanne Grinovero wrote: > > On 4 April 2016 at 12:59, Gunnar Morling <gun...@hibernate.o

Re: [hibernate-dev] 6.0 planning

On 04/04/2016 08:55 AM, Sanne Grinovero wrote: > On 4 April 2016 at 12:59, Gunnar Morling wrote: >> One minor wish I'd have around bootstrapping: >> >> Can we make the initiators of services residing in the session factory >> service registry discoverable by means of a

Re: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

On 03/30/2016 12:15 PM, Sanne Grinovero wrote: > I'm reviewing how we expect people to use the Hibernate OGM modules on > WildFly. > > Scott mentioned that the JPA subsystem of WildFly automatically adds > the "org.hibernate.ogm" module when the > org.hibernate.ogm.jpa.HibernateOgmPersistence

  1   2   3   4   5   >