November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6007) Logging 1.1 parsing is broken

by Kabir Khan (JIRA)

Kabir Khan created AS7-6007: ------------------------------- Summary: Logging 1.1 parsing is broken Key: AS7-6007 URL: https://issues.jboss.org/browse/AS7-6007 Project: Application Server 7 Issue Type: Bug Components: Logging Reporter: Kabir Khan Assignee: Josef Cacek Fix For: 7.2.0.Alpha1 Trying to debug an issue in logging transformers when old slaves connect to master's DC, I noticed that SubsystemParsing11Test was not getting run. It's name needs to be changed to SubsystemParsing11TestCase to be included in the run. Doing that I noticed that 1.1 parsing is broken, and the same probably goes for 1.0 parsing. 1.0 parsing also needs its own test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
1
0 / 0

[JBoss JIRA] (AS7-5595) Support custom transaction isolation levels

by Jesper Pedersen (JIRA)

Jesper Pedersen created AS7-5595: ------------------------------------ Summary: Support custom transaction isolation levels Key: AS7-5595 URL: https://issues.jboss.org/browse/AS7-5595 Project: Application Server 7 Issue Type: Task Components: JCA Affects Versions: 7.1.3.Final (EAP) Reporter: Jesper Pedersen Assignee: Stefano Maestri Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
1
0 / 0

[JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles using the deployments folder

by Paul Illingworth (JIRA)

Paul Illingworth created AS7-5951: ------------------------------------- Summary: Cannot reliably deploy OSGi host and fragment bundles using the deployments folder Key: AS7-5951 URL: https://issues.jboss.org/browse/AS7-5951 Project: Application Server 7 Issue Type: Bug Components: OSGi Affects Versions: 7.2.0.Alpha1 Environment: Windows XP SP3 Reporter: Paul Illingworth Assignee: Thomas Diesler If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist (fragment) into the "deployments" folder then the there is no guarantee the fragments will be installed before the host and so they may not be attached to the host when it resolves. This happens on starting the application server. Sometimes the fragments are attached, sometimes they aren't. If I install the bundles into the "bundles" folder structure and add capability entries to the standalone.xml file then it works as expected. I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
13
0 / 0

[JBoss JIRA] (JBRULES-3691) Property Reactive: using nested accessor in modify() seems to prevent the correct re-evaluation of the rules.

by Esteban Aliverti (JIRA)

Esteban Aliverti created JBRULES-3691: ----------------------------------------- Summary: Property Reactive: using nested accessor in modify() seems to prevent the correct re-evaluation of the rules. Key: JBRULES-3691 URL: https://issues.jboss.org/browse/JBRULES-3691 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Affects Versions: 6.0.0.Alpha1 Reporter: Esteban Aliverti Assignee: Mario Fusco The usage of nested accessors in modify() seems to prevent rules to be re-evaluated, or the re-evaluation result is not the expected one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
1
0 / 0

[JBoss JIRA] (AS7-5994) Infinispan cache container not displayed

by Heiko Braun (JIRA)

Heiko Braun created AS7-5994: -------------------------------- Summary: Infinispan cache container not displayed Key: AS7-5994 URL: https://issues.jboss.org/browse/AS7-5994 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.2.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
2
0 / 0

[JBoss JIRA] (AS7-3524) HostControllerConnectionService connection timeout is not configurable

by Dominik Pospisil (JIRA)

Dominik Pospisil created AS7-3524: ------------------------------------- Summary: HostControllerConnectionService connection timeout is not configurable Key: AS7-3524 URL: https://issues.jboss.org/browse/AS7-3524 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.0.Final Reporter: Dominik Pospisil Assignee: Jason Greene I am seeing intermittent failures when starting AS7 in domain mode. It seems that this is due to HostControllerConnectionService has hardcoded 15s timeout when trying to connect to DC. I think that this value should be configurable. HostControllerConnectionService.java: ... ProtocolChannelClient.Configuration configuration = new ProtocolChannelClient.Configuration(); configuration.setEndpoint(endpointInjector.getValue()); configuration.setConnectionTimeout(15000); configuration.setUri(new URI("remote://" + hcAddressInjector.getValue().getHostName() + ":" + hcAddressInjector.getValue().getPort())); client = ProtocolChannelClient.create(configuration); ... Exception I am getting: [Server:server-two] 13:52:54,766 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.host.controller.channel: org.jboss.msc.service.StartException in service jboss.host.controller.channel: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:103) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22] [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22] [Server:server-two] at java.lang.Thread.run(Thread.java:679) [:1.6.0_22] [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://localhost.localdomain:9999. The connection timed out [Server:server-two] at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:166) [jboss-as-protocol-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
9
0 / 0

[JBoss JIRA] (JBAS-9507) ThreadLocal variables are not cleared at the end of execution of the thread.

by Mohamad ABBAS (JIRA)

Mohamad ABBAS created JBAS-9507: ----------------------------------- Summary: ThreadLocal variables are not cleared at the end of execution of the thread. Key: JBAS-9507 URL: https://issues.jboss.org/browse/JBAS-9507 Project: Application Server 3 4 5 and 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-5.1.0.GA Environment: windows 7 Reporter: Mohamad ABBAS I am deploying a web application under Jboss AS 5.1.0.GA and in my application, I'm using some "java.lang.Threadlocal" and "java.lang.InheritableThreadLocal" variables. Threadlocal variables should be cleared at the end of execution of the thread. In my case , since jboss is using a thread pool, the threadlocal variables are not cleared. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
4
0 / 0

[JBoss JIRA] (AS7-6000) [EAP 6] validate-address fails for remote targets

by Derek Horton (JIRA)

Derek Horton created AS7-6000: --------------------------------- Summary: [EAP 6] validate-address fails for remote targets Key: AS7-6000 URL: https://issues.jboss.org/browse/AS7-6000 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.0.Final Reporter: Derek Horton Assignee: Emanuel Muckenhuber Priority: Blocker Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 the "validate-address" operation doesn't handle proxy-controllers when navigating the resource model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-5999) Upgrade PicketLink Module Dependencies

by Pedro Igor (JIRA)

Pedro Igor created AS7-5999: ------------------------------- Summary: Upgrade PicketLink Module Dependencies Key: AS7-5999 URL: https://issues.jboss.org/browse/AS7-5999 Project: Application Server 7 Issue Type: Component Upgrade Components: Security Reporter: Pedro Igor Assignee: Anil Saldhana Fix For: 7.2.0.Alpha1, 7.1.3.Final (EAP) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
1
0 / 0

[JBoss JIRA] (AS7-5997) Test WS-BA "cannotComplete" functionality in XTS integration tests

by Paul Robinson (JIRA)

Paul Robinson created AS7-5997: ---------------------------------- Summary: Test WS-BA "cannotComplete" functionality in XTS integration tests Key: AS7-5997 URL: https://issues.jboss.org/browse/AS7-5997 Project: Application Server 7 Issue Type: Bug Components: XTS Reporter: Paul Robinson Assignee: Paul Robinson Priority: Minor Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) When a WSBA participant employs the ParticipantCompletion protocol, it is the responsibility of the participant to notify the coordinator when it has completed its work. This notification is asynchronous. In the 'WSBAParticipantCompletionTestCase' test, the client invokes the participant's web service who notifies completion just before returning from the invocation. The client then sends a message to the coordinator requesting to close (complete) the activity. As the "complete" message (from the participant to coordinator) is asynchronous, we now have a race. If the Client's close message is processed by the coordinator before the participant's "complete" message, then the coordinator cancels the BA as not all participants have completed. This results in the client receiving a TransactionRolledBackException and the completed participant is (eventually) compensated. The outcome is atomic, but a BA that would have otherwise succeeded, is unsuccessful. In reality we only expect this scenario to happen in the rather artificial scenario where all parties (client, coordinator and participants) are on the same server. It also only seems to happen on very slow machines. Therefore, it's fine to fix the test to prevent this scenario from arising, rather than to somehow change the protocol (without breaking the WS-BA standard) to prevent it. We have two options, that I can see to fix the test: 1) Byteman Rendezvous. Here we would introduce a dependency on Byteman and write a script that delays the client's close message until all participants' 'complete' messages have been acknowledged by the coordinator. This is probably an over-engineered solution as we would be introducing Byteman, to these tests, for this single case. 2) We add a Thread.sleep(10000) to the test, just before the client sends the 'close' message to the coordinator. This is what we did to the XTS tests in the JBossTS project as a stop-gap until we decided how to do it "properly". I suggest we go with 2) as it is the simplest solution. The extra time added to the test is just 10s as there are is only one test affected by this. In the future, when we have more tests we should reduce this sleep period or consider using another solution (such as Byteman), in order to keep the test duration acceptable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
2
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 November 2012