April 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1880) Can fire rules after disposing the Stateful session

by Sravanthi Tipirneni (JIRA)

Can fire rules after disposing the Stateful session --------------------------------------------------- Key: JBRULES-1880 URL: https://jira.jboss.org/jira/browse/JBRULES-1880 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.7 Reporter: Sravanthi Tipirneni Assignee: Mark Proctor Priority: Minor I can access the session and fire rules even after the session is disposed using the dispose method -- 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

14 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-8337) handling of deployment failed at batch resolve time

by Alexey Loubyansky (JIRA)

handling of deployment failed at batch resolve time --------------------------------------------------- Key: JBAS-8337 URL: https://jira.jboss.org/browse/JBAS-8337 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 7.0.0.M1 Types of failures here include: duplicate service definition (i.e. a service was defined that already exists in the container), missing required dependency (i.e. a service was defined that depends on something that isn't there), circular dependency (i.e. two or more service definitions represent circularity in terms of their dependency links). Right now this erases the entire batch, which means that the server cannot start if any of these errors occur. The correct behavior is, in my opinion, to log each error and continue, possibly yielding a report of problem services after the batch is resolved (it is likely, however, that one failure will lead to others). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

4
6
0 / 0

[JBoss JIRA] Created: (JBAS-8336) handling of deployment failed the validation on the domain controller

by Alexey Loubyansky (JIRA)

handling of deployment failed the validation on the domain controller --------------------------------------------------------------------- Key: JBAS-8336 URL: https://jira.jboss.org/browse/JBAS-8336 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Alexey Loubyansky Fix For: 7.0.0.M1 A deployment can fail validation on the domain controller. In this event, the deployment is not added to the domain and an error is thrown from the deployer API, so this does not impact the server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

4
6
0 / 0

[JBoss JIRA] Created: (JBAS-9246) Create test to verify messages are not delivered to MDBs before EJB container is started.

by Dimitris Andreadis (JIRA)

Create test to verify messages are not delivered to MDBs before EJB container is started. ----------------------------------------------------------------------------------------- Key: JBAS-9246 URL: https://issues.jboss.org/browse/JBAS-9246 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: JBossAS-5.1.0.GA Environment: Version info: JBoss 5.1.0 GA (we use a local build, and have updated JBoss Cache to 3.2.1.GA, JBossTS to 4.6.1.GA_CP03 and JGroups to 2.6.13.GA to pick up bug fixes for issues we have encountered in production) ActiveMQ 5.3.0 GA HornetQ 2.0.0 GA Java 1.6.0_17 Mac OS 10.6.2 Reporter: Robert West Assignee: Carlo de Wolf Priority: Critical Fix For: No Release Testing scenario: Deployed JBoss 5.1.0.GA (with tweaks to the pom during build, see Environment) with a JCA adapter for an external JMS broker, used both ActiveMQ 5.3.0 and HornetQ 2.0.0, both clustered and standalone. Also tried an embedded HornetQ broker with the same results. Deployed an ear that has a simple MDB requiring container managed transactions listening to a queue with max sessions set to 2 and a simple jsp to publish an arbitrary number of text messages to that queue. The MDB simply prints the text information provided by the message, but also has a hard-coded 1 second pause for every even numbered message. When I shut down JBoss while messages are still being consumed, the BlockContainerShutdownInterceptor starts throwing DispatcherConnectExceptions, as the EJB container has been stopped or is in the process of being stopped. However, it doesn't mark the transaction for rollback itself, and MessageInflowLocalProxy.delivery() only marks the transaction for rollback if the invocation chain throws an Error or RuntimeException. Thus, in this case, JBoss failed to deliver the message to the MDB, but committed the transaction. According to the spec, for an MDB with a container managed transaction, the message should be ACK'd to the broker if the transaction successfully commits, and both the ActiveMQ and HornetQ JCA implementations dutifully do this, resulting in all messages that were attempted to be delivered after the EJB container shutdown being lost. When the BlockContainerShutdownInterceptor detects that the EJB container has been shutdown, it needs to take an action that will ensure the transaction is marked for rollback. After parsing through the code involved in the interceptor chain, I can see a few potential solutions: * Have BlockContainerShutdownInterceptor.invoke() call TxUtil.getTransactionManager().setRollbackOnly() before it would throw a DispatcherConnectException. Probably need to consume any exception thrown from setRollbackOnly() and log it first I suppose, although it's always a bit odd when you get an exception thrown when you intend to throw an exception anyway for a different reason. * Have BlockContainerShutdownInterceptor.invoke() put some state on the Invocation to indicate that delivery is being blocked. MessagingContainer.localInvoke() could then take some action based on this state to ensure the transaction is rolled back, either rolling it back itself or notifying its caller that the transaction should be rolled back. A bit odd here if BlockContainerShutdownInterceptor.invoke() continues to throw an exception, as there would be data about the exception being passed back outside the exception though. * Have MessageInflowLocalProxy handle DispatcherConnectExceptions. It might be better to introduce an additional class, say InvocationInterruptedException that DispatcherConnectException could extend, to allow for the possibility that invocations may be interrupted for other reasons, allowing MessageInflowLocalProxy to not care as much about the particular reason invocation was halted, but still be able to roll back the transaction whenever it is. I slightly favor the third approach based on what I've seen of that portion of the code so far, so I will probably work to put together a patch file along those lines. This is the first time I've delved deeply into the JBoss source code though. If I can find some examples of test cases in this part of the code base, I'll attempt to put together a verifying test case as well. I marked the priority as Critical, based on the guidelines, as this is resulting in data loss and as far as I best understand the spec is a violation of the spec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

5
6
0 / 0

[JBoss JIRA] Created: (JBAS-8412) Algorithms for generating server names

by Brian Stansberry (JIRA)

Algorithms for generating server names -------------------------------------- Key: JBAS-8412 URL: https://jira.jboss.org/browse/JBAS-8412 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.M1 Right now we're identifying servers by the static "name" attribute value in the host.xml server element. We need pluggable algorithms for other mechanisms to come up with a name, particularly for cloud use cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2124) KnowledgeAgent should load knowledge bases directly from Resource (bypassing the ChangeSet)

by Jürgen Schiewe (JIRA)

KnowledgeAgent should load knowledge bases directly from Resource (bypassing the ChangeSet) ------------------------------------------------------------------------------------------- Key: JBRULES-2124 URL: https://jira.jboss.org/jira/browse/JBRULES-2124 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-api, drools-core Affects Versions: 5.0.1.FINAL Reporter: Jürgen Schiewe Assignee: Mark Proctor We develop Drools based applications and use Guvnor as a a repository. Hard-coding the hostname where Guvnor runs is not an option for us because the names are different in each installation and we do not want to modify all the changeset.xml files for each deployment. Instead we would pass one (or more) Resources to the KnowledgeAgent and let it do the monitoring. This would allow us to build URLs dynamically from our system environment configuration. -- 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

14 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (JGRP-1001) Use ByteMan / Metronome to inject faults for testing

by Bela Ban (JIRA)

Use ByteMan / Metronome to inject faults for testing ---------------------------------------------------- Key: JGRP-1001 URL: https://jira.jboss.org/jira/browse/JGRP-1001 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Use ByteMan (jboss.org/byteman) to simulate issues that can happen at runtime: do this in unit tests. For example: crash of merge leader after initial round (who frees the locks ?) (same for FLUSH) -- 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

14 years, 6 months

3
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2227) @Startup @Singleton (via switchboard) should take into account transitive ENC dependencies before instantiating the bean

by jaikiran pai (JIRA)

@Startup @Singleton (via switchboard) should take into account transitive ENC dependencies before instantiating the bean ------------------------------------------------------------------------------------------------------------------------ Key: EJBTHREE-2227 URL: https://issues.jboss.org/browse/EJBTHREE-2227 Project: EJB 3.0 Issue Type: Bug Components: singleton Affects Versions: depchain-1.0.0-alpha-43 Environment: JBoss AS 6.0 Final Reporter: jaikiran pai Assignee: jaikiran pai Consider the following beans: @Startup @Singleton public class A { @EJB private B slsb1; @PostConstruct public void onConstruct() { slsb1.doSomething(); } } @Stateless public class B { @EJB private C slsb2; } @Stateless public class C { .... } Currently, the @Startup @Singleton is instantiated when the ENC of that bean is fully invokable. However, it only waits for a populated ENC of transitive dependent bean(s). This can lead random failures with lookup. Please see the referenced forum thread for the complete details. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

5
11
0 / 0

[JBoss JIRA] Created: (JBAS-8422) Fix build warning for missing pom on ws-commons policy

by Paul Gier (JIRA)

Fix build warning for missing pom on ws-commons policy ------------------------------------------------------ Key: JBAS-8422 URL: https://jira.jboss.org/browse/JBAS-8422 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 6.0.0.M4 Reporter: Paul Gier Priority: Minor The AS 6 trunk build currently gives a warning about the pom missing from ws-commons:policy [WARNING] The POM for ws-commons:policy:jar:1.0 is missing, no dependency information available This is caused by a missing POM file in central http://repo2.maven.org/maven2/ws-commons/policy/1.0/ ws-commons:policy is now called project Neethi. Possible a recent version of Neethi can be used to replace the old policy jar. http://repo2.maven.org/maven2/org/apache/neethi/neethi/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1721) Implement @Asynchronous

by Andrew Lee Rubinger (JIRA)

Implement @Asynchronous ------------------------ Key: EJBTHREE-1721 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1721 Project: EJB 3.0 Issue Type: Task Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: EJB 3.1 Container task for @Asynchronous handling as specified by EJB 3.1 -- 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

14 years, 6 months

4
5
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 April 2011