[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Dan Cimpoesu updated DROOLS-1270:
---------------------------------
Labels: (was: kie)
> support fact handle operations for REST APIs on kie server
> ----------------------------------------------------------
>
> Key: DROOLS-1270
> URL: https://issues.jboss.org/browse/DROOLS-1270
> Project: Drools
> Issue Type: Enhancement
> Components: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> Fix For: 6.5.0.Final
>
>
> Please support fact handle operations for REST APIs on kie server.
> Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1270?page=com.atlassian.jira.plugi... ]
Dan Cimpoesu updated DROOLS-1270:
---------------------------------
Labels: kie (was: )
> support fact handle operations for REST APIs on kie server
> ----------------------------------------------------------
>
> Key: DROOLS-1270
> URL: https://issues.jboss.org/browse/DROOLS-1270
> Project: Drools
> Issue Type: Enhancement
> Components: kie server
> Affects Versions: 6.5.0.CR1
> Environment: kie server
> Reporter: Dan Cimpoesu
> Assignee: Edson Tirelli
> Labels: kie
> Fix For: 6.5.0.Final
>
>
> Please support fact handle operations for REST APIs on kie server.
> Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1270) support fact handle operations for REST APIs on kie server
by Dan Cimpoesu (JIRA)
Dan Cimpoesu created DROOLS-1270:
------------------------------------
Summary: support fact handle operations for REST APIs on kie server
Key: DROOLS-1270
URL: https://issues.jboss.org/browse/DROOLS-1270
Project: Drools
Issue Type: Enhancement
Components: kie server
Affects Versions: 6.5.0.CR1
Environment: kie server
Reporter: Dan Cimpoesu
Assignee: Edson Tirelli
Fix For: 6.5.0.Final
Please support fact handle operations for REST APIs on kie server.
Fact handle operations are currently not supported in kie server as they usually bring less value in rule based systems where most of the operations are stateless. Though they do provide rather big value for processes integrated with rules.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1758) WFLYCC0034: Closing leaked controller client
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1758?page=com.atlassian.jira.plugi... ]
Martin Choma commented on WFCORE-1758:
--------------------------------------
I understand that it is very delicately piece of code. So most importantly pottential change shouldn't break anything else. If you will decide, that finalize method can be enhanced, note, there are couple of others finalize() implementation with custom logic in wildfly core, which could be checked.
DeploymentPlanImpl
RemotingModelControllerClient
ConnectionImpl
MountHandle
Errors caused by implemented finalize() method occur probably very very rarely. So users probably can't reproduce it - hence doesn't report it.
> WFLYCC0034: Closing leaked controller client
> --------------------------------------------
>
> Key: WFCORE-1758
> URL: https://issues.jboss.org/browse/WFCORE-1758
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Martin Choma
> Assignee: James Perkins
> Attachments: server.log
>
>
> We are intermittently getting "WFLYCC0034: Closing leaked controller client" from RemotingModelControllerClient#finalize method.
> I wonder, isn't implementation of RemotingModelControllerClient#finalize() method [1] example of dangerous "safety net" implementation discussed in presentation "JVM finalize pitfalls" [2] ?
> *Reproducer:*
> 1. using ibm java 1.8
> 2. setting <startup-timeout>1</startup-timeout>
> [1] https://github.com/wildfly/wildfly-core/blob/master/controller-client/src...
> [2] https://www.youtube.com/watch?v=UrGP6pfb0H8
> [3]
> {noformat}
> 05:54:10 Aug 16, 2016 5:54:10 AM org.jboss.as.controller.client.impl.RemotingModelControllerClient finalize
> 05:54:10 WARN: WFLYCC0034: Closing leaked controller client
> 05:54:10 WFLYCC0030: Allocation stack trace:
> 05:54:10 at java.lang.Thread.getStackTrace(Thread.java:1552)
> 05:54:10 at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:74)
> 05:54:10 at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:567)
> 05:54:10 at org.wildfly.plugin.common.ManagementClient.<init>(ManagementClient.java:37)
> 05:54:10 at org.wildfly.plugin.common.AbstractServerConnection.createClient(AbstractServerConnection.java:126)
> 05:54:10 at org.wildfly.plugin.server.StartMojo.execute(StartMojo.java:269)
> 05:54:10 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 05:54:10 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> 05:54:10 at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> 05:54:10 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> 05:54:10 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> 05:54:10 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 05:54:10 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 05:54:10 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> 05:54:10 at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 05:54:10 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 05:54:10 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 05:54:10 at java.lang.reflect.Method.invoke(Method.java:498)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 05:54:10 at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1269) RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1269?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1269:
-----------------------------------
Description:
... regardless of the real KieBase they actually belong to.
Ref example screenshot:
!rhqjon.png|thumbnail!
was:
... regardless of the real KieBase they actually belong to.
Ref example screenshot:
!rhqjon.png!
> RHQ / JON plug-in display wrong hierarchy and repeatedly nesting KieSession under KieBase
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-1269
> URL: https://issues.jboss.org/browse/DROOLS-1269
> Project: Drools
> Issue Type: Bug
> Components: integration
> Affects Versions: 6.1.0.Final, 6.2.0.Final, 6.3.0.Final, 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: rhqjon.png
>
>
> ... regardless of the real KieBase they actually belong to.
> Ref example screenshot:
> !rhqjon.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff edited comment on WFLY-6596 at 9/2/16 3:19 AM:
------------------------------------------------------------------------
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country id=100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in:
{code}
Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
{code}
(I changed the data a bit so we have new id's here)
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine. So it doesn't seems to be an application problem.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
was (Author: gvwolf3d):
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country id=100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in:
{code}
Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
{code}
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine. So it doesn't seems to be an application problem.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache
by Gunther v. Wolffersdorff (JIRA)
[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ]
Gunther v. Wolffersdorff edited comment on WFLY-6596 at 9/2/16 3:18 AM:
------------------------------------------------------------------------
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country id=100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in:
{code}
Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
{code}
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine. So it doesn't seems to be an application problem.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
was (Author: gvwolf3d):
I don't think so. We are running a big application hitting this bug in Wildly 10.0.0.Final. So I created a little sample
application just for bug reporting. Our application (and the sample application) runs fine using Wildly 8.2.0 and Infinispan 7.2.5 for months.
I digged a little bit deeper and stripped the data loaded by the sample application a bit (new sample-10.1.0.Final-2.zip with smaller import.sql file).
So the simple class model is a follows:
{code}
+----------------+
| Country |
+----------------+
| id : long |
| name : string |
| iso : string |
+----------------+
| 1
|
|
| 0..*
+----------------------+
| Member |
+----------------------+
| id : long |
| name : string |
| email : string |
| phoneNumber : string |
| country ; Country |
+----------------------+
{code}
Both classes are @Cacheable .
The tables are populated by import.sql as shown below:
{code:sql}
insert into Country(id, name, iso) values (100, 'Deutschland', 'DE')
insert into Country(id, name, iso) values (102, 'Espana', 'ES')
insert into Member(id, name, email, phone_number, country_id) values (100, 'John Smith', 'john.smith(a)mailinator.com', '2125551212', 102 )
insert into Member(id, name, email, phone_number, country_id) values (110, 'Ed Moos', 'ed.moos(a)mailinator.com', '212500', 100 )
{code}
As you can see we have two countries (id=100 and id=102). Also we have a member id=100 referencing country id=102 . And we have a second member id=110 referencing country 100;
The Hibernate entity cache has a remote-store.
We can now query all members order by id:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdAsc
{code}
So hibernate fetches at first member (id=100). When hibernate will fetch the second member (id=110). This member references country (id=100). But instead to fetch this country hibernate gets member (id=100) from cache.
This results in Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member .(I changed the data a bit so we have new id's here)
If we remove the remote-store configuration from the cache-container configuration (<invalidation-cache name="entity">) everything runs fine.
Also if we query the members in the reverse order no error occurs:
{code}
curl http://localhost:2680/sample-web/rest/members/listAllOrderedByIdDesc
{code}
This makes sense because no country is in cache having the same id as an already known (fetched) member.
> WrongClassException when using infinispan as remote-store for hibernate entity cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6596
> URL: https://issues.jboss.org/browse/WFLY-6596
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Java version: 1.8.0_45, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_45\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos"
> Infifnspan 8.1.2 or 8.2.0
> Reporter: Gunther v. Wolffersdorff
> Assignee: Scott Marlow
> Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store
> Attachments: clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml
>
>
> Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes:
> {code}
> 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final]
> at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:]
> at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:]
> at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> ... 43 more
> Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member
> at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final]
> ... 58 more
> {code}
> Entity cache is configured like this:
> {code:xml}
> ...
> <invalidation-cache name="entity" mode="SYNC">
> <eviction strategy="LRU" max-entries="1000"/>
> <expiration lifespan="45000" max-idle="30000"/>
> <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/>
> </invalidation-cache>
> ...
> <outbound-socket-binding name="local-cache-server">
> <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/>
> </outbound-socket-binding>
> ...
> {code}
> see standalone.sample.ha-10.1.0.Final.xml .
> *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .*
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7027) MBeans with ObjectName attributes throw ClassNotFoundException
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7027?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-7027:
----------------------------------------
Assignee: Bartosz Baranowski (was: Kabir Khan)
> MBeans with ObjectName attributes throw ClassNotFoundException
> --------------------------------------------------------------
>
> Key: WFLY-7027
> URL: https://issues.jboss.org/browse/WFLY-7027
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 10.0.0.Final
> Reporter: Dennis Reed
> Assignee: Bartosz Baranowski
>
> An MBean with:
> public void setObj(javax.management.ObjectName someObject)
> <mbean ...>
> <attribute name="Obj" />
> causes "java.lang.ClassNotFoundException: javax.management.MalformedObjectNameException from [Module \"org.jboss.common-beans:main\"
> org.jboss.common.beans.property.ObjectNameEditor in that module is used to convert to ObjectName objects, and requires MalformedObjectNameException but it is not on the classpath of that module.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months