February 2008 - jboss-jira - Jboss List Archives

[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, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-5239) Failover with a distributed transaction manager

by Brian Stansberry (JIRA)

Failover with a distributed transaction manager ----------------------------------------------- Key: JBAS-5239 URL: http://jira.jboss.com/jira/browse/JBAS-5239 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Backlog Our existing HA proxies and ClusterChooserInterceptor do not allow requests to fail over once the transaction associated with a request has reached a target server. If all nodes in a cluster use a distributed transaction manager, this requirement need not be enforced. Need to provide such an option. -- 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, 5 months

2
1
0 / 0

[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, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1250) Allow option to completely remove an asset from the repository

by Shahad Ahmed (JIRA)

Allow option to completely remove an asset from the repository -------------------------------------------------------------- Key: JBRULES-1250 URL: http://jira.jboss.com/jira/browse/JBRULES-1250 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.1 Reporter: Shahad Ahmed Assigned To: Mark Proctor If you use the archive feature to remove a rule or package from the BRMS it is not really seen as gone, as if you attempt to create a new rule or package with the same name as the archived rules or package then you get an error saying that the rule or package already exists (looking at the source code, the repository does not care if an item is archived or not, so it will always throw an error if an asset with an existing name is created). I'm assuming this is the designed behaviour and not a bug (I've asked about this a couple of times on the user list and got no replies to the contrary). However, it would be very useful to be able to remove a rule or package so that you can then recreate it (e.g by importing new versions from a drl file). At present, you have to laboriously rename the rules and packages you want to remove, so that when they are archived their names do not clash with the new versions of the rules and packages you want to import or recreate. Perhaps all that is involved in implementing this new remove feature is to just automatically rename the package and its rules before archiving it? -- 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, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1467) Concurrency errors when parsing strings to dates in rules

by Edson Tirelli (JIRA)

Concurrency errors when parsing strings to dates in rules --------------------------------------------------------- Key: JBRULES-1467 URL: http://jira.jboss.com/jira/browse/JBRULES-1467 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.4 Reporter: Edson Tirelli Assigned To: Edson Tirelli Fix For: 4.0.5, 5.0.0-M1 A static reference to SimpleDateFormat is throwing exception. -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1192) Hiding old versions of documents

by Nils Kassube (JIRA)

Hiding old versions of documents --------------------------------- Key: JBPORTAL-1192 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1192 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4.1 Final Reporter: Nils Kassube Assigned To: Roy Russo To improve usability it's a good idea to hide old versions of a document, e.g. using paging or a "More versions..." link. Currently you have to export and import stuff to get rid of the distracting display of dozens of old versions. -- 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, 5 months

6
8
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1842) Login form should have a cancel option

by Chris Laprun (JIRA)

Login form should have a cancel option -------------------------------------- Key: JBPORTAL-1842 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1842 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.3 Final Reporter: Chris Laprun Assigned To: Julien Viet Fix For: 2.6.4 Final It is not currently possible to get out of the login screen apart from using the back button or modifying the URL in the browser. Bad usability... -- 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, 5 months

3
11
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1184) test for EntityManager injection in @PostConstruct

by William DeCoste (JIRA)

test for EntityManager injection in @PostConstruct -------------------------------------------------- Key: EJBTHREE-1184 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1184 Project: EJB 3.0 Issue Type: Task Reporter: William DeCoste Assigned To: William DeCoste -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5237) EJB2 Proxies should pass security domain name for use by client proxy SecurityInterceptor

by Anil Saldhana (JIRA)

EJB2 Proxies should pass security domain name for use by client proxy SecurityInterceptor ----------------------------------------------------------------------------------------- Key: JBAS-5237 URL: http://jira.jboss.com/jira/browse/JBAS-5237 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.CR1 The ProxyFactory should pass the security domain name configured for the ejb deployment via the InvocationContext in the proxies. The client side Security Interceptor will need the name for passing the Security Context over the invocation. -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1392) Rules behave incorrectly (randomly) in multi-threaded environment

by Brian Stiles (JIRA)

Rules behave incorrectly (randomly) in multi-threaded environment ----------------------------------------------------------------- Key: JBRULES-1392 URL: http://jira.jboss.com/jira/browse/JBRULES-1392 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: Brian Stiles Rules behave seemingly indeterminately when sessions are created from the same RuleBase and executed in multiple threads. The problem is a bit difficult to reproduce. The following code demonstrates the behavior in my environment (single processor PowerBook), but not on every try. I've had up to 5 consecutive executions not exhibit the problem before the failure was exhibited, so you may need to run the class a number of times to see the problem. Also, I periodically get OutOfMemoryErrors when using the default heap size (64m). I've had better success with -Xmx256m. That, by the way, is suspiciously coincidental to the random nature of the incorrect rule firing problem. I've experienced this behavior in my application, and it manifests by rules firing from time to time that shouldn't have fired. I can't see a pattern to the rules that fire inappropriately, and there absolutely were not facts asserted that would support the firing of the rule. Synchronizing the calls to insert, fireAllRules, and dispose on the session object seems to get rid of the problem, giving further evidence to the guess that it's a multithreading bug. Please, please, please find a solution to this problem. This will be a serious scalability problem for my application. I'm more than happy to help however I can. I've stepped through Drools code before and found solutions, but I really don't know where to go with this one. Following is the code (self-contained class with main method) that I've used to demonstrate the problem. Thank you! -- package sample; import java.io.StringReader; import java.util.ArrayList; import org.drools.RuleBase; import org.drools.RuleBaseConfiguration; import org.drools.RuleBaseFactory; import org.drools.StatefulSession; import org.drools.compiler.PackageBuilder; import org.drools.compiler.PackageBuilderConfiguration; public class MultithreadedRuleBaseProblem { public static void main(String[] args) throws Exception { final PackageBuilderConfiguration packageBuilderConfiguration = new PackageBuilderConfiguration(); final PackageBuilder packageBuilder = new PackageBuilder(packageBuilderConfiguration); packageBuilder.addPackageFromDrl(new StringReader("\n" + "package sample\n" + "\n" + "import java.lang.Integer;\n" + "global java.util.ArrayList shouldFireList;\n" + "global java.util.ArrayList shouldNotFireList;\n" + "\n" + "rule should_fire\n" + " when\n" + " $e : Integer(intValue == -1)\n" + " $f : Integer(intValue > $e)\n" + " then \n" + " shouldFireList.add($f);\n" + "end \n" + "\n" + "rule should_not_fire\n" + " when\n" + " $f : String()\n" + " then \n" + " shouldNotFireList.add($f);\n" + "end \n")); final RuleBaseConfiguration ruleBaseConfiguration = new RuleBaseConfiguration(); final RuleBase ruleBase = RuleBaseFactory.newRuleBase(ruleBaseConfiguration); ruleBase.addPackage(packageBuilder.getPackage()); final Exception[] exception = { null }; final Thread t[] = new Thread[50]; for (int i = 0; i < t.length; i++) { final int count = i; t[i] = new Thread(new Runnable() { public void run() { try { System.out.println("Start " + count); final int iterations = count * 15 + 3000; final ArrayList shouldFireList = new ArrayList(); final ArrayList shouldNotFireList = new ArrayList(); final StatefulSession session2 = ruleBase.newStatefulSession(); session2.setGlobal("shouldFireList", shouldFireList); session2.setGlobal("shouldNotFireList", shouldNotFireList); session2.insert(new Integer(- 1)); for (int k = 0; k < iterations; k++) { session2.insert(new Integer(k)); } session2.insert("foo"); System.out.println("Fire " + count); session2.fireAllRules(); session2.dispose(); if (shouldFireList.size() != iterations) { System.out.println("Thread " + count + " shouldFireList.size(): expected " + iterations + " was " + shouldFireList.size() + "\n!!!!! Thread " + count + " rule didn't fire as many times as it should have!!!!!!!!!!!!!!!!!!"); } } catch (Exception e) { e.printStackTrace(); exception[0] = e; } System.out.println("Thread " + count + " done"); } }); t[i].start(); } for (int i = 0; i < t.length; i++) { t[i].join(); } System.out.println("done"); } } -- 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, 5 months

5
22
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2008