[JBoss JIRA] Created: (JBAS-7913) Exception when adding HornetQ Core queues to hornetq-configuration.xml/hornetq-queues.xml
by Jeff Mesnil (JIRA)
Exception when adding HornetQ Core queues to hornetq-configuration.xml/hornetq-queues.xml
-----------------------------------------------------------------------------------------
Key: JBAS-7913
URL: https://jira.jboss.org/jira/browse/JBAS-7913
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS (HornetQ)
Reporter: Jeff Mesnil
Assignee: Clebert Suconic
On a running AS server, if the user edits hornetq-configuration.xml or hornetq-queues.xml files to add or remove HornetQ Core queues, HornetQ server will generate exception when it deploys the queues which were already defined in the configuration files:
16:37:31,936 WARN [org.jboss.as.integration.hornetq.deployers.pojo.HornetQCoreDeployment] Error on creating queue bar address = foo: HornetQException[errorCode=101 message=Queue bar already exists]
at org.hornetq.core.server.impl.HornetQServerImpl.createQueue(HornetQServerImpl.java:1294) [:]
at org.hornetq.core.server.impl.HornetQServerImpl.createQueue(HornetQServerImpl.java:676) [:]
at org.jboss.as.integration.hornetq.deployers.pojo.HornetQCoreDeployment.start(HornetQCoreDeployment.java:108) [:6.0.0-SNAPSHOT]
HornetQCodeDeployment must use HornetQServer.deployQueue() instead of createQueue() to ignore the queue if it already exists instead of throwing an exception
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JBAS-7920) Rename EJB3 testcases so that they are included in the default AS testsuite runs
by jaikiran pai (JIRA)
Rename EJB3 testcases so that they are included in the default AS testsuite runs
--------------------------------------------------------------------------------
Key: JBAS-7920
URL: https://jira.jboss.org/jira/browse/JBAS-7920
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: jaikiran pai
Assignee: jaikiran pai
Fix For: JBossAS-6.0.0.M3
The AS test build runs only those test cases whose name ends with UnitTestCase:
<target name="tests-standard-unit" depends="init">
<echo><![CDATA[
junit.timeout: ${junit.timeout}
jbosstest.iterationcount: ${jbosstest.iterationcount}
jbosstest.threadcount: ${jbosstest.threadcount}
jbosstest.beancount: ${jbosstest.beancount}
]]></echo>
....
<fileset dir="${build.classes}">
<include name="**/*UnitTestCase.class"/>
<patternset refid="all.excludes"/>
<exclude name="**/test/xa/test/XAUnitTestCase.class"/>
</fileset>
</batchtest>
</junit>
</target>
Rename some of the EJB3 testcases, so that they end up being run by the nightly AS hudson testsuite job.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JBAS-7631) NPE in EjbReferenceResolverBase.getMatch() method
by Richard Opalka (JIRA)
NPE in EjbReferenceResolverBase.getMatch() method
-------------------------------------------------
Key: JBAS-7631
URL: https://jira.jboss.org/jira/browse/JBAS-7631
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Reporter: Richard Opalka
Assignee: jaikiran pai
Fix For: JBossAS-6.0.0.M2
The following commit broke JBossWS/EJB3 integration:
http://fisheye.jboss.org/changelog/JBossAS/?cs=99498
Server side error is:
22:03:33,178 ERROR [org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS] SOAP request exception: org.jboss.wsf.common.injection.InjectionException: Cannot inject field annotated with @EJB annotation: private org.jboss.test.ws.jaxws.ejb3Integration.injection.shared.BeanIface org.jboss.test.ws.jaxws.ejb3Integration.injection.shared.handlers.TestHandler.bean1
at org.jboss.wsf.common.injection.InjectionException.rethrow(InjectionException.java:106)
at org.jboss.wsf.common.injection.InjectionHelper.injectEJBAnnotatedAccessibleObjects(InjectionHelper.java:367)
at org.jboss.wsf.common.injection.InjectionHelper.injectResources(InjectionHelper.java:111)
at org.jboss.ws.core.jaxws.handler.HandlerResolverImpl.addHandler(HandlerResolverImpl.java:174)
at org.jboss.ws.core.jaxws.handler.HandlerResolverImpl.initHandlerChain(HandlerResolverImpl.java:152)
at org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS.callRequestHandlerChain(HandlerDelegateJAXWS.java:89)
at org.jboss.ws.core.server.ServiceEndpointInvoker.callRequestHandlerChain(ServiceEndpointInvoker.java:125)
at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:172)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:502)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:299)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:206)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:131)
at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:87)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:336)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:276)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:366)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:872)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at org.jboss.ejb3.common.resolvers.spi.EjbReferenceResolverBase.getMatch(EjbReferenceResolverBase.java:104)
at org.jboss.ejb3.core.resolvers.ScopedEJBReferenceResolver.find(ScopedEJBReferenceResolver.java:44)
at org.jboss.ejb3.core.resolvers.ScopedEJBReferenceResolver.findWithin(ScopedEJBReferenceResolver.java:56)
at org.jboss.ejb3.core.resolvers.ScopedEJBReferenceResolver.findWithin(ScopedEJBReferenceResolver.java:77)
at org.jboss.ejb3.core.resolvers.ScopedEJBReferenceResolver.resolveEjb(ScopedEJBReferenceResolver.java:83)
at org.jboss.webservices.integration.injection.EJBBeanReferenceResolver.resolveField(EJBBeanReferenceResolver.java:88)
at org.jboss.wsf.common.injection.resolvers.AbstractReferenceResolver.resolve(AbstractReferenceResolver.java:80)
at org.jboss.wsf.common.injection.InjectionHelper.injectEJBAnnotatedAccessibleObjects(InjectionHelper.java:361)
... 29 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (EJBTHREE-2062) Fix the removedislocal testcase
by jaikiran pai (JIRA)
Fix the removedislocal testcase
-------------------------------
Key: EJBTHREE-2062
URL: https://jira.jboss.org/jira/browse/EJBTHREE-2062
Project: EJB 3.0
Issue Type: Task
Components: testsuite
Reporter: jaikiran pai
Assignee: jaikiran pai
The removedislocal testcase is failing with:
Error deploying removedislocal-test.jar: EJBTHREE-2020: No InjectionCallbackStack defined for domain org.jboss.aop.Domain@344986 of jboss.j2ee:jar=removedislocal-test.jar,name=StatelessBean,service=EJB3
at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189)
at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:59)
at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
This testcase uses its own server configuration, specifically the ejb3-interceptors-aop.xml maintained at ejb3/trunk/testsuite/src/test/resources/test-configs/removedislocal/deploy
We'll have to fix that ejb3-interceptors-aop.xml to include the InjectionCallbackStack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JBRULES-2475) DSL configuartion conditions with same beginnings cause errors
by Rudi Mentaer (JIRA)
DSL configuartion conditions with same beginnings cause errors
--------------------------------------------------------------
Key: JBRULES-2475
URL: https://jira.jboss.org/jira/browse/JBRULES-2475
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-guvnor
Affects Versions: 5.1.0.M1
Reporter: Rudi Mentaer
Assignee: Mark Proctor
To reproduce the error you can create a new DSL configuration:
[condition][]ArbitraryClass=$c: ArbitraryClass()
[condition][ArbitraryClass]- Client ID equals {id}=clientID == {id}
[condition][ArbitraryClass]- Client ID equals {id1} or {id2}=clientID == {id1} || clientID == {id2}
in the DSL:
when
Arbitrary
- Client ID equals 1 or 2
then
#arbitrary action
You will get the following errors:
[ERR 102] Line 3:39 mismatched input 'or' expecting ')' in rule '...' in pattern ArbitraryClass
[ERR 101] Line 3:42 no viable alternative at input '2' in rule '...'
However, if you change the second line of the DSL configuration to
[condition][SomeClass]- Client ID is {id}=clientID == {id}
it will work like a charm
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (JBRULES-2067) Compilation performance for rules degrades as the classpath increases
by Edson Tirelli (JIRA)
Compilation performance for rules degrades as the classpath increases
---------------------------------------------------------------------
Key: JBRULES-2067
URL: https://jira.jboss.org/jira/browse/JBRULES-2067
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.0.0.CR1
Reporter: Edson Tirelli
Assignee: Mark Proctor
Fix For: 5.0.0.GA
REPORTED BY: Christian Nedregård
=============================
This is now solved.
I noticed that the problem became worse the bigger the classpath was, even if the extra jars contained totally irrellevant classes.
Profiling revealed that the rule compilation generated an enomous amount of IO traffic from ClassLoader.loadClass originating from
org.mvel.ParserContext.checkForDynamicImport and org.drools.rule.PackageCompilationData$PackageClassLoader.
In both these places Drools generates a lot of loadClass calls for classes that does not exist.
It seems like the Sun classloaders does not cache the result of failed class lookups, but scans the whole classpath again and again looking for these non-existing classes.
That is why the problem gets bigger the larger your classpath is. Our classpath contains 100+ jars, so we got hit pretty bad.
I solved the problem by creating a caching classloader that also caches the result of failed lookups. When I added this as the context classloader scoped around all my compilation I saw a performance increase of a factor of 10 - 20 in our various environments.
Here are the stats from the caching classloader after compiling 850 rules:
Caching loader called 200608 times
119 actual successful loads
932 actual failed loads
73738 cache hits for successfull loads
125819 cache hits for failed loads
In other words: Drools generated 126751 loads for 932 non-existing classes. We saved 125819 full classapth scans by caching the failed lookups.
As mentioned above the caching classloader can be hooked into the system by setting it at the context classloader.
org.mvel.ParserContext.checkForDynamicImport uses the context classloader directly.
org.drools.rule.PackageCompilationData$PackageClassLoader uses the classloader configured in PackageBuilderConfiguration which is the context classloader by default.
This means you get the full effect only when you scope the caching class loader around all your PackageBuilderConfiguration and PackageBuilder usage.
Below is the code for our caching classloader for the reference of anybody else who might encounter this problem.
Regards
Chr
PS Edson:
This problem is related to compilation. The RETE building is usually very fast.
----------------------------------------------
package domain.rules;
import java.util.HashMap;
import java.util.Map;
/**
* Classloader that intercepts calls to the current context class loader and caches the result of the calls to {@link #loadClass}
* on it.
* <p/>
* The interception will start automagically when this class is instantiated. Make sure that you call {@link #stop()} from a finally
* block when you want the loader interception to stop, to avoid unnecessary caching.
*
* @author Christian Nedregård
* @see Thread#getContextClassLoader()
*/
public class CachingContextClassLoader extends ClassLoader {
private Map classLoaderResultMap = new HashMap();
private ClassLoader originalClassLoader;
private int successfulCalls = 0;
private int failedCalls = 0;
private int cacheHits = 0;
private int successfulLoads = 0;
private int failedLoads = 0;
/**
* Create an instance. The instance will automagically start intercepting {@link #loadClass(String)} calls to the current
* context class loader.
*
* @see Thread#getContextClassLoader()
*/
CachingContextClassLoader() {
super(Thread.currentThread().getContextClassLoader());
this.originalClassLoader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(this);
}
/**
* Try to load the class from the original context class loader and chache the result (also <code>ClassNotFoundException</code>s).
* Subsequent calls for the same class name will return the cached version, or throw a cached ClassNotFoundException if it was
* not found initially.
*
* @param name the name of the class to find.
* @return the cached result of a call to <code>loadClass</code> on the original context class loader.
* @throws ClassNotFoundException when the class of the given name could not be found.
*/
public Class loadClass(String name) throws ClassNotFoundException {
Object result;
if (classLoaderResultMap.containsKey(name)) {
++cacheHits;
result = classLoaderResultMap.get(name);
} else {
try {
result = super.loadClass(name);
++successfulLoads;
} catch (ClassNotFoundException e) {
++failedLoads;
result = e;
}
classLoaderResultMap.put(name, result);
}
if (result instanceof ClassNotFoundException) {
++failedCalls;
throw (ClassNotFoundException) result;
} else {
++successfulCalls;
return (Class) result;
}
}
/**
* Stop intercepting by resetting the original context classloader using {@link Thread#setContextClassLoader(ClassLoader)}.
*/
public void stop() {
Thread.currentThread().setContextClassLoader(originalClassLoader);
}
/**
* Get a textual report of the caching that was performed.
*
* @return a textual report of the caching that was performed.
*/
public String getReport() {
return new StringBuffer("Loader called ").append(successfulCalls + failedCalls).append(" times, ").append(successfulCalls)
.append(" successfull, ").append(failedCalls).append(" failed. Cache hits: ").append(cacheHits)
.append(", successful loads: ").append(successfulLoads).append(", Failed loads: ").append(failedLoads)
.append('.').toString();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months