November 2012 - jboss-jira - Jboss List Archives

[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

12 years, 1 month

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

12 years, 1 month

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

12 years, 1 month

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

12 years, 1 month

1
2
0 / 0

[JBoss JIRA] (AS7-5998) Failure in org.jboss.as.test.integration.osgi.stilts.StompletTestCase

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5998: ------------------------------------- Summary: Failure in org.jboss.as.test.integration.osgi.stilts.StompletTestCase Key: AS7-5998 URL: https://issues.jboss.org/browse/AS7-5998 Project: Application Server 7 Issue Type: Bug Components: OSGi Reporter: Brian Stansberry Assignee: Thomas Diesler StompletTestCase failed on http://teamcity.cafe-babe.org/viewLog.html?buildId=1589&tab=buildResultsD... Relevant details from the server log are below. It looks like BundleStateRevision.getModuleClassLoader() can return null if a ModuleLoadException is thrown, resulting in the NPE in the log. 16:45:42,074 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "stomplet-server-provider" 16:45:42,078 INFO [org.jboss.osgi.framework] (MSC service thread 1-5) JBOSGI011001: Bundle installed: stomplet-server-provider:0.0.0 16:45:42,090 WARN [org.jboss.as.osgi] (MSC service thread 1-7) JBAS011915: Cannot deploy from management operation, bypassing deployment unit processors: [org.jboss.netty:3.4.5.Final,location=org.jboss.netty:main] 16:45:42,353 INFO [org.jboss.osgi.framework] (MSC service thread 1-6) JBOSGI011001: Bundle installed: org.jboss.netty:3.4.5.Final 16:45:42,356 WARN [org.jboss.as.osgi] (MSC service thread 1-7) JBAS011915: Cannot deploy from management operation, bypassing deployment unit processors: [stilts-stomplet-server-bundle:0.1.26,location=org.projectodd.stilts:main] 16:45:42,394 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: stilts-stomplet-server-bundle:0.1.26 16:45:42,424 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit.stomplet-server-provider.Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit.stomplet-server-provider.Activate: JBAS011968: Cannot start bundle: stomplet-server-provider:0.0.0 at org.jboss.as.osgi.deployment.BundleActivateProcessor$BundleActivateService.start(BundleActivateProcessor.java:130) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_32] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_32] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32] Caused by: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: stilts-stomplet-server-bundle:0.1.26 at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:110) at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:167) at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292) at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228) at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:516) at org.jboss.as.test.integration.osgi.stilts.bundle.StompletServerActivator.start(StompletServerActivator.java:41) at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:84) at org.jboss.as.osgi.service.BundleLifecycleIntegration.start(BundleLifecycleIntegration.java:174) at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:292) at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:228) at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:522) at org.jboss.as.osgi.deployment.BundleActivateProcessor$BundleActivateService.start(BundleActivateProcessor.java:127) ... 5 more Caused by: java.lang.NullPointerException at org.jboss.osgi.framework.internal.HostBundleRevision.loadClass(HostBundleRevision.java:121) at org.jboss.osgi.framework.internal.AbstractBundleState.loadClass(AbstractBundleState.java:444) at org.jboss.osgi.framework.internal.HostBundleState.loadClass(HostBundleState.java:102) at org.jboss.osgi.framework.internal.DefaultBundleLifecycleHandler.start(DefaultBundleLifecycleHandler.java:76) ... 16 more 16:45:42,631 INFO [org.jboss.osgi.framework] (MSC service thread 1-7) JBOSGI011005: Bundle uninstalled: stomplet-server-provider:0.0.0 16:45:42,633 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015877: Stopped deployment stomplet-server-provider in 4ms 16:45:42,634 ERROR [org.jboss.as.server] (management-handler-thread - 2) JBAS015870: Deploy of deployment "stomplet-server-provider" was rolled back with the following failure message: {"JBAS014671: Failed services" => {"jboss.deployment.unit.stomplet-server-provider.Activate" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.stomplet-server-provider.Activate: JBAS011968: Cannot start bundle: stomplet-server-provider:0.0.0 Caused by: org.osgi.framework.BundleException: JBOSGI011254: Cannot start bundle: stilts-stomplet-server-bundle:0.1.26 Caused by: java.lang.NullPointerException"}} -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-5993) Drop BARRIER from default JGroups protocol stacks

by Paul Ferraro (JIRA)

Paul Ferraro created AS7-5993: --------------------------------- Summary: Drop BARRIER from default JGroups protocol stacks Key: AS7-5993 URL: https://issues.jboss.org/browse/AS7-5993 Project: Application Server 7 Issue Type: Component Upgrade Components: Clustering Affects Versions: 7.1.3.Final (EAP) Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) BARRIER is only useful when a state transfer protocol is used. We dropped this a while ago, and should have dropped BARRIER too. -- 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

12 years, 1 month

1
2
0 / 0

[JBoss JIRA] (AS7-2177) TS: Check logging

by Ondrej Zizka (Created) (JIRA)

TS: Check logging ----------------- Key: AS7-2177 URL: https://issues.jboss.org/browse/AS7-2177 Project: Application Server 7 Issue Type: Sub-task Components: Test Suite Reporter: Ondrej Zizka Assignee: Ondrej Zizka Some tests print to System.out, and also ex.printStackTrace(). Turn it to proper logging. Also check logging config. -- 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

12 years, 1 month

3
3
0 / 0

[JBoss JIRA] (AS7-5815) Upgrading JBossTS to 4.17.2.Final

by Paul Robinson (JIRA)

Paul Robinson created AS7-5815: ---------------------------------- Summary: Upgrading JBossTS to 4.17.2.Final Key: AS7-5815 URL: https://issues.jboss.org/browse/AS7-5815 Project: Application Server 7 Issue Type: Component Upgrade Components: Transactions Reporter: Paul Robinson Assignee: Paul Robinson Fix For: 7.2.0.Alpha1 Note: this upgrade is for 7.2 branch, not the 7.1 branch. 7.1 branch must stay on JBossTS 4.16.x. -- 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

12 years, 1 month

1
2
0 / 0

[JBoss JIRA] (AS7-5890) JdrService assumes auth is required if http code !=200

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created AS7-5890: --------------------------------------- Summary: JdrService assumes auth is required if http code !=200 Key: AS7-5890 URL: https://issues.jboss.org/browse/AS7-5890 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.2.0.Alpha1 Reporter: Bartosz Baranowski Assignee: Bartosz Baranowski Priority: Minor https://github.com/jbossas/jboss-as/commit/44ada8238bbe962ffd35cf4bd8216a... JDR service asssumes that if return code is different than 200, it needs to ask user for auth. What if code is 500 ? -- 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

12 years, 1 month

4
6
0 / 0

[JBoss JIRA] (AS7-5871) The default redirect port for the 8080 connector is current 8433. Should be 8443 instead.

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created AS7-5871: ------------------------------------- Summary: The default redirect port for the 8080 connector is current 8433. Should be 8443 instead. Key: AS7-5871 URL: https://issues.jboss.org/browse/AS7-5871 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.3.Final (EAP) Reporter: Wolf-Dieter Fink Assignee: Wolf-Dieter Fink The default redirect port for the 8080 connector is 8433. Seems that this is wrong as socket-bindings use 8443 (and former releases also) [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource { "outcome" => "success", "result" => { ..., "name" => "http", "protocol" => "HTTP/1.1", "redirect-port" => 8433, "scheme" => "http", "secure" => false, "socket-binding" => "http", "ssl" => undefined, "virtual-server" => undefined } } The pre-configured "https" socket binding conversely is 8443: [standalone@localhost:9999 socket-binding=https] /socket-binding-group=standard-sockets/socket-binding=https:read-resource { "outcome" => "success", "result" => { "client-mappings" => undefined, "fixed-port" => false, "interface" => undefined, "multicast-address" => undefined, "multicast-port" => undefined, "name" => "https", "port" => 8443 } } -- 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

12 years, 1 month

3
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2012