[JBoss JIRA] (WFLY-4517) Do not expose Infinispan bits to deployments importing the Hibernate main module
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-4517?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-4517:
------------------------------------
Currently, we have:
org.hibernate:main which has hibernate-core, hibernate-infinispan, hibernate-entitymanager
If we move hibernate-infinispan to a separate static module, the application classpath will still only contain the org.hibernate:main static module, which happens not contain the hibernate-infinispan classes anymore but I assume would still reference them.
In other words, org.hibernate.main currently is a {hibernate-core, hibernate-infinispan, hibernate-entitymanager} and has a reference to org.infinispan:main. If I understand this jira correctly, the change will be that org.hibernate.main is a {hibernate-code, hibernate-entitymanager} and has a reference to hibernate-infinspan (which has a reference to org.infinispan:main).
> Do not expose Infinispan bits to deployments importing the Hibernate main module
> --------------------------------------------------------------------------------
>
> Key: WFLY-4517
> URL: https://issues.jboss.org/browse/WFLY-4517
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
>
> This is mainly a follow up to
> https://bugzilla.redhat.com/show_bug.cgi?id=1202911
> But also a consequence of difficulties I had with Hibernate Search (which depends on both latest Infinispan and the Hibernate version in WildFly), and Hibernate OGM (which requires Hibernate ORM but has strong coupling with specific versions of Infinispan).
> The gist of the problem is that the module org.hibernate:main includes the integration code with Infinispan for second level caching.
> While I agree people will want to enable the second level caching, I don't think they should be exposed to it, so I'll propose some changes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4517) Do not expose Infinispan bits to deployments importing the Hibernate main module
by Sanne Grinovero (JIRA)
Sanne Grinovero created WFLY-4517:
-------------------------------------
Summary: Do not expose Infinispan bits to deployments importing the Hibernate main module
Key: WFLY-4517
URL: https://issues.jboss.org/browse/WFLY-4517
Project: WildFly
Issue Type: Enhancement
Components: JPA / Hibernate
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
This is mainly a follow up to
https://bugzilla.redhat.com/show_bug.cgi?id=1202911
But also a consequence of difficulties I had with Hibernate Search (which depends on both latest Infinispan and the Hibernate version in WildFly), and Hibernate OGM (which requires Hibernate ORM but has strong coupling with specific versions of Infinispan).
The gist of the problem is that the module org.hibernate:main includes the integration code with Infinispan for second level caching.
While I agree people will want to enable the second level caching, I don't think they should be exposed to it, so I'll propose some changes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4448) Batch creates a JdbcJobRepository per deployment where only one global repository should be used
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4448?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-4448:
----------------------------------
They are still backed by the same data store, right? Now that the repository cache and data store can contain different data, we must be careful not to pollute each application's JdbcRepository from running jdbc queries.
Using separate JdbcRepository gives better isolation, but can be difficult to work with from admin side. How do you show job data in admin console or CLI? Group them by application so each application can just display its own jobs, or aggregate them from all JdbcRepository?
> Batch creates a JdbcJobRepository per deployment where only one global repository should be used
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4448
> URL: https://issues.jboss.org/browse/WFLY-4448
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: James Perkins
> Assignee: James Perkins
>
> When the batch subsystem is configured to use a JDBC job repository a new {{JdbcJobRepository}} is created for each application deployed. A global {{JdbcJobRepository}} should be used.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (DROOLS-762) JIT Thread and Calling thread can cause simultaneous access to hibernate sessions
by Mark Torres (JIRA)
Mark Torres created DROOLS-762:
----------------------------------
Summary: JIT Thread and Calling thread can cause simultaneous access to hibernate sessions
Key: DROOLS-762
URL: https://issues.jboss.org/browse/DROOLS-762
Project: Drools
Issue Type: Bug
Affects Versions: 5.6.0.Final
Reporter: Mark Torres
Assignee: Mark Proctor
When evaluating drools involving uninitialized property of hibernate entities, simultaneous access to a hibernate session can occur. With the existing codebase on 5.5/6.x the jit thread is "launched" prior to rule evaluation. This can cause the calling thread, and jit thread to call lazy property initialization at the same time, which can cause hibernate to throw exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4515) Fix clustering transformers and reenable in mixed-domain tests
by Kabir Khan (JIRA)
Kabir Khan created WFLY-4515:
--------------------------------
Summary: Fix clustering transformers and reenable in mixed-domain tests
Key: WFLY-4515
URL: https://issues.jboss.org/browse/WFLY-4515
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 9.0.0.Beta2
Reporter: Kabir Khan
Assignee: Radoslav Husar
Priority: Critical
Fix For: 9.0.0.CR1
When running the jgroups and infinispan subsystem tests with -Djboss.test.transformers.eap there are some failures in the transformers tests.
Also, in the mixed domain tests it is not possible to enable these subsystems, so I have removed them from DomainAdjuster620 in https://github.com/wildfly/wildfly/pull/7350. They should be reenabled again as part of this Jira.
Some info from private mail:
{quote}
However, when transforming that to 7.2.0 by running:
mvn clean install -DallTests -Djboss.test.mixed.domain.dir=/Users/kabir/old-as7-releases/ -pl testsuite/mixed-domain/ -Dtest=MixedDomain_7_2_0_Final_TestSuite
I get the following error:
11:59:43,682 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.io.IOException: 1-$-WFLYCTL0300: Transforming resource [
("profile" => "full-ha"),
("subsystem" => "infinispan"),
("cache-container" => "server"),
("transport" => "TRANSPORT")
] for host controller 'slave' to subsystem 'infinispan' model version '1.4.0' --there were problems with some of the attributes and this resource will need to be ignored on that host. Details of problems: [WFLYCLINF0027: Could not determine 'stack' attribute from JGroups subsystem]
I am not totally sure if this is the right solution, but I attempted to add a stack attribute to the transport, but it does not seem to get persisted so it goes away after reloading the DC (out of admin-only to normal mode). I also tried in standalone mode, and executing
/subsystem=infinispan/cache-container=server/transport=TRANSPORT:write-attribute(name=stack, value=udp)
and the stack does not get persisted.
It is probably a simple fix, but since I am not sure if it is the right fix or not, especially since adding this to the writer it also seems to be ignored by the parser. Perhaps this is a candidate for something along the lines of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extensi... so that we can support old configs, but not actually use it on a server using the current version?
{quote}
Note that the above is when I was working on this, the 7.2.0 test has been removed. We now test EAP 6.2.0 and 6.3.0 compatibility. I believe the problem is similar there although I have not dug in very deeply.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months