[JBoss JIRA] Created: (JBRULES-1389) using eval after using or causes ClassCastException
by Jan Boboli (JIRA)
using eval after using or causes ClassCastException
---------------------------------------------------
Key: JBRULES-1389
URL: http://jira.jboss.com/jira/browse/JBRULES-1389
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.3
Environment: Windows XP, Linux,
Reporter: Jan Boboli
Priority: Blocker
when using eval after using or the ClassCastException occurs.
Here is a code of the rule causing classcast :
when
CccObject()
BbbObject($bbb:bbb)
$aaa:AaaObject(aaa==$bbb)
or
AaaObject(aaa=="ccc")
eval($aaa.getAaa().equals($bbb))
then
System.out.println( "Success!!" );
end
here is the stacktrace:
org.drools.RuntimeDroolsException: java.lang.ClassCastException: com.sample.CccObjectShadowProxy cannot be cast to com.sample.BbbObject
at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:76)
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 6 months
[JBoss JIRA] Created: (JBAS-4951) Retry debug message within UnifiedInvokerHAProxy.invoke() is misleading
by Galder Zamarreno (JIRA)
Retry debug message within UnifiedInvokerHAProxy.invoke() is misleading
-----------------------------------------------------------------------
Key: JBAS-4951
URL: http://jira.jboss.com/jira/browse/JBAS-4951
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.2.2.GA, JBossAS-5.0.0.Beta2
Reporter: Galder Zamarreno
Assigned To: Brian Stansberry
Priority: Minor
UnifiedInvokerHAProxy.invoke():
...
failoverAuthorized = txContextAllowsFailover(invocation);
failoverCounter++;
invocation.setValue("FAILOVER_COUNTER", new Integer(failoverCounter), PayloadKey.AS_IS);
log.debug("Received GenericClusteringException where request was not completed. Will retry.");
continue;
...
The debug message before continue is misleading. The call will only be retried if the failover is authorised and
there're any targets available, otherwise it won't. The log message should be reworded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 6 months
[JBoss JIRA] Created: (JBAS-5043) Don't find the good persistence unit when multiple ear with same pu name
by Jerome Poittevin (JIRA)
Don't find the good persistence unit when multiple ear with same pu name
------------------------------------------------------------------------
Key: JBAS-5043
URL: http://jira.jboss.com/jira/browse/JBAS-5043
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA
Environment: JBoss 4.2.2 on linux Red Hat 4 AS 4 or Windows XP, using Sun JVM version 5
Reporter: Jerome Poittevin
Assigned To: Carlo de Wolf
When using multiple ear with multiple persistence unit having the same name, Jboss uses the wrong persistence unit when deploying ejb and the exception "Entity is not mapped" occures when entities are accessed.
This behaviour seams to be in contradiction with the Java Persistence API Spec (see § 6.2.2).
Example :
app1.ear and app2.ear with two persistence unit having the same persistence unit name "pu".
While deploying app2.ear, the following message can be seen in the JBoss log :
2007-11-30 15:13:03,865 DEBUG [org.jboss.injection.PersistenceUnitHandler] ***** adding PU dependency from located persistence unit: persistence.units:ear=app1.ear,unitName=pu
When accessing EJB deployed in app2.ear, the following exception occures :
javax.ejb.EJBTransactionRolledbackException: org.hibernate.hql.ast.QuerySyntaxException: TestEntity is not mapped [From TestEntity t where t.id = :id]
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleInCallerTx(Ejb3TxPolicy.java:87)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:130)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:166)
at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:115)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:240)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:210)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:84)
The following patch seems to make JBoss find the good persistence unit :
In file org.jboss.ejb3.enc.DeploymentPersistenceUnitResolver.java on line 106 :
replace :
if (deployment.getEntityManagerName().equals(unitName)) return deployment;
with :
if (deployment.getEntityManagerName().equals(unitName) && deployment.getKernelName().contains(deploymentScope.getBaseName())) return deployment;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 6 months