July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-1886) After clearBody() followed by QueueSession.recover() redelivered message is not correct

by Colin Mondesir (JIRA)

After clearBody() followed by QueueSession.recover() redelivered message is not correct --------------------------------------------------------------------------------------- Key: JBMESSAGING-1886 URL: https://issues.jboss.org/browse/JBMESSAGING-1886 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.0.SP3.CP13 Reporter: Colin Mondesir Assignee: Yong Hao Gao After calling clearBody() on a message followed by QueueSession.recover() the re-delivered message does not contain the original body. I've verified this behaviour on EAP 4.3 CP09. The spec states: ------------------------------------------ A consumer can modify a received message after calling either the clearBody or clearProperties method to make the body or properties writable. If the consumer modifies a received message, and the message is subsequently redelivered, the redelivered message must be the original, unmodified message ------------------------------------------ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (AS7-1303) TestNG not supported by Arquillian Service

by Aslak Knutsen (JIRA)

TestNG not supported by Arquillian Service ------------------------------------------ Key: AS7-1303 URL: https://issues.jboss.org/browse/AS7-1303 Project: Application Server 7 Issue Type: Bug Components: Test Suite Affects Versions: 7.0.0.Final Reporter: Aslak Knutsen Assignee: Andrew Rubinger Priority: Critical Fix For: 7.0.1.Final The Arquillian Service deployed during execution has a Deployment Processor hook to scan for "Test Deployments" so it can lookup the Module etc during execution. This scan assumes the TestDeployment will contain JUnits @RunWith annotation, which is true for JUnit, but not so much for other test frameworks. Arquillian is built to work with any test framework so TestNG/ScalaTest/Spock etc are all valid targets. Since the Arquillian Service is no longer a pre installed service, but deployed only during test execution, it could make sense to remove the scanning(used to filter out test deployment) and just consume all deployments during it's life time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (AS7-1325) Cannot create dependency on SNAPSHOT bundle

by Thomas Diesler (JIRA)

Cannot create dependency on SNAPSHOT bundle ------------------------------------------- Key: AS7-1325 URL: https://issues.jboss.org/browse/AS7-1325 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.0.Final Reporter: Thomas Diesler Assignee: Thomas Diesler 08:32:24,892 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]} 08:32:24,893 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report New missing/unsatisfied dependencies: service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
5
0 / 0

[JBoss JIRA] Created: (AS7-1316) add output redirection for commands and operations

by Alexey Loubyansky (JIRA)

add output redirection for commands and operations -------------------------------------------------- Key: AS7-1316 URL: https://issues.jboss.org/browse/AS7-1316 Project: Application Server 7 Issue Type: Task Components: CLI Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 7.0.1.Final e.g. operation > file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (AS7-1409) Expose OSGi subsystem configuration through console

by David Bosschaert (JIRA)

Expose OSGi subsystem configuration through console --------------------------------------------------- Key: AS7-1409 URL: https://issues.jboss.org/browse/AS7-1409 Project: Application Server 7 Issue Type: Sub-task Components: Console Reporter: David Bosschaert Assignee: David Bosschaert Fix For: 7.1.0.CR1 The configuration of the OSGi subsystem (urn:jboss:domain:osgi:1.0) should be manageable through the console. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2955) drools-spring: exception if you define a stateful ksession after a kagent in configuration file

by Esteban Aliverti (JIRA)

drools-spring: exception if you define a stateful ksession after a kagent in configuration file ----------------------------------------------------------------------------------------------- Key: JBRULES-2955 URL: https://issues.jboss.org/browse/JBRULES-2955 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-spring Affects Versions: 5.2.0.M1 Reporter: Esteban Aliverti Assignee: Esteban Aliverti Priority: Minor Fix For: 5.3.0.M1 An exception occurs if you define a stateful ksession AFTER a kagent in spring's config file. The problem is that drools-spring will try to set the kagent attribute of the session. This attribute only exists for stateless ksessions. The exception you get is: Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ksession2': Error setting property values; nested exception is org.springframework.beans.NotWritablePropertyException: Invalid property 'knowledgeAgent' of bean class [org.drools.container.spring.beans.StatefulKnowledgeSessionBeanFactory]: Bean property 'knowledgeAgent' is not writable or has an invalid setter method. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2913) SingleSessionCommandService Constructor Eats an Actual / Real Exception on Rollback

by Esteban Aliverti (JIRA)

SingleSessionCommandService Constructor Eats an Actual / Real Exception on Rollback ------------------------------------------------------------------------------------ Key: JBRULES-2913 URL: https://issues.jboss.org/browse/JBRULES-2913 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL Reporter: Esteban Aliverti Assignee: Esteban Aliverti Priority: Minor Fix For: FUTURE Scenario: The constructor of SingleSessionCommandService tries to persist the created SessionInfo and fails. Problem: Because of the failure, SingleSessionCommandService tries to rollback the TX. If the rollback also fail, an exception is thrown with the cause, but the original problem (The failure on SessionInfo persistence) is swallowed. The code of the catch section demonstrate this: try { this.txm.begin(); //this.appScopedEntityManager.joinTransaction(); registerRollbackSync(); jpm.getApplicationScopedPersistenceContext().persist( this.sessionInfo ); this.txm.commit(); } catch ( Exception t1 ) { try { this.txm.rollback(); } catch ( Throwable t2 ) { throw new RuntimeException( "Could not commit session or rollback", t2 ); } throw new RuntimeException( "Could not commit session", t1 ); } If this.txm.rollback() fails, t1 is never logged. A similar issue was fixed in JBRULES-2656 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2960) ClassPathResource fails to get last version if the underlying ClassLoader uses a cache.

by Esteban Aliverti (JIRA)

ClassPathResource fails to get last version if the underlying ClassLoader uses a cache. --------------------------------------------------------------------------------------- Key: JBRULES-2960 URL: https://issues.jboss.org/browse/JBRULES-2960 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M1 Reporter: Esteban Aliverti Assignee: Esteban Aliverti Priority: Optional I'm deploying drools-camel-server in a Tomcat 7 container. Inside the WEB-INF/classes directory I have some DRL files that I want to use. My knowledge-services.xml file declares the following kagent: <drools:kagent id="kagent1" kbase="kbase1" new-instance="false"> <drools:resources> <drools:resource type="DRL" source="classpath:simple.drl"/> ... </drools:resources> </drools:kagent> When spring parses this configuration file it creates a KnowledgeAgent instance with a ChangeSet containing all the listed resources. The next step is to start ResourceChangeNotifierService and ResourceChangeScannerService. So far so good. The problem: The problem I'm having is not directly related to drools, but I think it is quite easy to provide a solution for the people that is in my same situation. ClassPathResource is the class that represents a resource defined as "classpath:" This class has 2 important methods: public long getLastModified(){ return this.classLoader.getResource( this.path ).openConnection().getLastModified(); } public InputStream getInputStream(){ return this.classLoader.getResourceAsStream( this.path ); } The first method is used by ResourceChangeScannerService to check whether the resource has changed or not. It works fine. When the resource in the filesystem changes, the scanner detects the change without any problem. The scanner ends up notifying the kagent about the change, and the kagent passes the Resource to an instance of KnowledgeBuilder. An here is when things fail. The kbuilder uses the second method of ClassPathResource (getInputStream()) to get the content of the resource. In the case of Tomcat (and probably some other environments), it seems that the classloader (Tomcat's classloader) is using a cache. So the InputStream returned doesn't reflect the current state of the resource. Long story short: the agent is notified about a change in the resource, but the change is never applied to the kbase because the kbuilder is unable to get it -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

3
10
0 / 0

[JBoss JIRA] Created: (JASSIST-142) Javassist throws a CannotCompileException on the org.codehaus.groovy.runtime.ArrayUtil class

by Robert Elliot (JIRA)

Javassist throws a CannotCompileException on the org.codehaus.groovy.runtime.ArrayUtil class -------------------------------------------------------------------------------------------- Key: JASSIST-142 URL: https://issues.jboss.org/browse/JASSIST-142 Project: Javassist Issue Type: Bug Affects Versions: 3.14.0.GA Environment: N/A Reporter: Robert Elliot Assignee: Shigeru Chiba With Groovy 1.7.5 on the classpath the following snippet throws a CannotCompileException: {noformat}ClassPool classPool = new ClassPool(); classPool.appendSystemPath(); CtClass ctClass = classPool.get("org.codehaus.groovy.runtime.ArrayUtil"); ctClass.toBytecode();{noformat} This is currently preventing me using PowerMock in a test case written in Groovy, which seems a shame. It appears to be due to an artificial limit imposed in ClassPoolTail.copyStream(InputStream, OutputStream). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (JASSIST-97) Javassist doesn't serialize the handler along with the proxy

by Pete Muir (JIRA)

Javassist doesn't serialize the handler along with the proxy ------------------------------------------------------------ Key: JASSIST-97 URL: https://jira.jboss.org/jira/browse/JASSIST-97 Project: Javassist Issue Type: Feature Request Reporter: Pete Muir Assignee: Shigeru Chiba When serializing a proxy, Javassist doesn't consider serializing the instance handler, but only the default handler. -- 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

13 years, 4 months

6
14
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011