[JBoss JIRA] (AS7-6063) Deadlock in Module FallbackClassLoader
by Steve Reed (JIRA)
[ https://issues.jboss.org/browse/AS7-6063?page=com.atlassian.jira.plugin.s... ]
Steve Reed commented on AS7-6063:
---------------------------------
Have pulled the latest jboss-as/master build and will try and re-create.
> Deadlock in Module FallbackClassLoader
> --------------------------------------
>
> Key: AS7-6063
> URL: https://issues.jboss.org/browse/AS7-6063
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Steve Reed
> Assignee: Thomas Diesler
> Attachments: jboss-dead-lock.txt
>
>
> Actually the version is 2.0.1.final - jbosgi-framework-core-2.0.1.Final.jar
> Commit reference for JBOSS AS :- https://github.com/jbossas/jboss-as/commit/ed2bc551a55ec6a8167a8657cbb5d8...
> During start up of JBOSS AS7.0 two GeminiBlueprintExtender Threads deadlock, and services in the JBOSS OSGI container are not started.
> The deadlock appears to be concerned with a Module FallbackLoader, which acquires a lock during a call to loadClassLocal() and then proceeds to use an alternate Module to load the class, if this results in the alternate Module using it's FallbackLoader to load a class or resource, then it must also acquire a lock first. Obviously if two or more threads are attempting this, then a dead lock is possible.
> I will attach the thread dump to this issue as supporting evidence.
--
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
11 years, 5 months
[JBoss JIRA] (JASSIST-183) API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has dissapeared
by Andrei Ivanov (JIRA)
Andrei Ivanov created JASSIST-183:
-------------------------------------
Summary: API breakage: javassist.util.proxy.RuntimeSupport.findSuperMethod has dissapeared
Key: JASSIST-183
URL: https://issues.jboss.org/browse/JASSIST-183
Project: Javassist
Issue Type: Bug
Affects Versions: 3.17.0-GA, 3.17.1-GA
Environment: Seam 2.2.2 / 2.3.0, Java 7u9
Reporter: Andrei Ivanov
Assignee: Shigeru Chiba
Priority: Blocker
Checking how some applications run with Java 7, I've tried to upgrade to the newly released Javassist just to notice Seam is no longer working:
{noformat}
java.lang.NoSuchMethodError: javassist.util.proxy.RuntimeSupport.findSuperMethod(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/reflect/Method;
at eu.comparegroup.checkout.order.OrderInitializer_$$_javassist_seam_0.writeReplace(OrderInitializer_$$_javassist_seam_0.java)
at org.jboss.seam.Component.postConstructJavaBean(Component.java:1461)
at org.jboss.seam.Component.postConstruct(Component.java:1379)
at org.jboss.seam.Component.newInstance(Component.java:2155)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.ServletLifecycle.endInitialization(ServletLifecycle.java:143)
at org.jboss.seam.init.Initialization.init(Initialization.java:744)
at org.jboss.seam.mock.AbstractSeamTest.startSeam(AbstractSeamTest.java:929)
at org.jboss.seam.mock.SeamTest.startSeam(SeamTest.java:69)
{noformat}
It seems some public methods have dissapeared from {{javassist.util.proxy.RuntimeSupport}}
--
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
11 years, 5 months
[JBoss JIRA] (AS7-5907) Assign an unique NodeID automatically
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-5907?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated AS7-5907:
-------------------------------
Priority: Optional (was: Major)
> Assign an unique NodeID automatically
> -------------------------------------
>
> Key: AS7-5907
> URL: https://issues.jboss.org/browse/AS7-5907
> Project: Application Server 7
> Issue Type: Feature Request
> Reporter: Clebert Suconic
> Assignee: Stefano Maestri
> Priority: Optional
>
> It shouldn't be needed to assign the node-id manually IMO.
> You could store the node-id on a file and recover it for subsequent starts.
> On hornetQ for instance, we look for the nodeID on a file, if the file doesn't exist we assign a UUID and write to the file.
> In our previous experience UUID would be a best fit to assign the nodes since that was the only way we could guarantee unique IDs between the nodes.
--
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
11 years, 5 months
[JBoss JIRA] (AS7-6016) Intermittent failure in OSGi StompletTestCase
by jaikiran pai (JIRA)
jaikiran pai created AS7-6016:
---------------------------------
Summary: Intermittent failure in OSGi StompletTestCase
Key: AS7-6016
URL: https://issues.jboss.org/browse/AS7-6016
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Environment: AS7 upstream - November 22 2012
Reporter: jaikiran pai
Assignee: Thomas Diesler
Just saw this NPE on lightning and the StompletTestCase failed:
{code}
Error Message
java.lang.Exception: {"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"}}
Stacktrace
org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper$ServerDeploymentException: java.lang.Exception: {"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"}}
at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:56)
at org.jboss.as.test.integration.osgi.stilts.StompletTestCase$StompletTestCaseServerSetup.setup(StompletTestCase.java:90)
at org.jboss.as.arquillian.container.ServerSetupObserver.handleBeforeDeployment(ServerSetupObserver.java:107)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:155)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.Exception: {"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"}}
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:50)
... 96 more
Standard Output
[0m03:09:18,898 INFO [org.jboss.web] (ServerService Thread Pool -- 30) JBAS018224: Unregister web context: /simple-endpoint
[0m[0m03:09:18,903 INFO [org.jboss.as.webservices] (MSC service thread 1-6) JBAS015540: Stopping service jboss.ws.endpoint."simple-endpoint.war"."org.jboss.as.test.integration.osgi.jaxws.bundle.EndpointImpl"
[0m[0m03:09:18,903 INFO [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022051: Endpoint unregistered: jboss.ws:context=simple-endpoint,endpoint=org.jboss.as.test.integration.osgi.jaxws.bundle.EndpointImpl
[0m[0m03:09:18,910 INFO [org.jboss.as.webservices] (MSC service thread 1-5) JBAS015540: Stopping service jboss.ws.port-component-link
[0m[0m03:09:18,929 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment simple-endpoint.war in 33ms
[0m[0m03:09:18,935 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 3) JBAS014627: Attribute failover-on-server-shutdown is deprecated, and it might be removed in future version!
[0m[0m03:09:18,936 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 3) JBAS014627: Attribute discovery-initial-wait-timeout is deprecated, and it might be removed in future version!
[0m[0m03:09:18,936 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 3) JBAS014627: Attribute failover-on-server-shutdown is deprecated, and it might be removed in future version!
[0m[0m03:09:18,936 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 3) JBAS014627: Attribute discovery-initial-wait-timeout is deprecated, and it might be removed in future version!
[0m[0m03:09:18,937 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 3) JBAS014627: Attribute failover-on-server-shutdown is deprecated, and it might be removed in future version!
[0m[0m03:09:18,937 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 3) JBAS014627: Attribute discovery-initial-wait-timeout is deprecated, and it might be removed in future version!
[0m[0m03:09:18,944 INFO [org.jboss.as.repository] (management-handler-thread - 3) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/osgi/target/jbossas/standalone/data/content/3e/bce80f886395fad32b517fc67a1bbd498b5751/content
[0m[0m03:09:18,944 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018558: Undeployed "simple-endpoint.war"
[0m[0m03:09:18,956 INFO [org.jboss.osgi.framework] (MSC service thread 1-5) JBOSGI011003: Bundle stopped: simple-client.jar:0.0.0
[0m[0m03:09:18,961 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011005: Bundle uninstalled: simple-client.jar:0.0.0
[0m[0m03:09:18,965 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment simple-client.jar in 12ms
[0m[0m03:09:18,971 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 1) JBAS014627: Attribute failover-on-server-shutdown is deprecated, and it might be removed in future version!
[0m[0m03:09:18,971 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 1) JBAS014627: Attribute discovery-initial-wait-timeout is deprecated, and it might be removed in future version!
[0m[0m03:09:18,972 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 1) JBAS014627: Attribute failover-on-server-shutdown is deprecated, and it might be removed in future version!
[0m[0m03:09:18,972 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 1) JBAS014627: Attribute discovery-initial-wait-timeout is deprecated, and it might be removed in future version!
[0m[0m03:09:18,973 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 1) JBAS014627: Attribute failover-on-server-shutdown is deprecated, and it might be removed in future version!
[0m[0m03:09:18,973 INFO [org.jboss.as.controller.management-deprecated] (management-handler-thread - 1) JBAS014627: Attribute discovery-initial-wait-timeout is deprecated, and it might be removed in future version!
[0m[0m03:09:19,060 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014901: Content removed from location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/osgi/target/jbossas/standalone/data/content/40/14f8ce31e3e156d06efe22c44318d763587d8b/content
[0m[0m03:09:19,061 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018558: Undeployed "simple-client.jar"
[0m[0m03:09:19,130 INFO [org.jboss.as.repository] (management-handler-thread - 4) JBAS014900: Content added at location /home/jenkins/jenkins-work/workspace/as7-master-testsuite-ip6/testsuite/integration/osgi/target/jbossas/standalone/data/content/6e/3c278ae96ddf3a12da4bff9bb6adea4703b7ea/content
[0m[0m03:09:19,132 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "stomplet-server-provider"
[0m[0m03:09:19,150 INFO [org.jboss.osgi.framework] (MSC service thread 1-6) JBOSGI011001: Bundle installed: stomplet-server-provider:0.0.0
[0m[33m03:09:19,215 WARN [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011915: Cannot deploy from management operation, bypassing deployment unit processors: [org.jboss.netty:3.4.5.Final,location=org.jboss.netty:main]
[0m[0m03:09:20,040 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: org.jboss.netty:3.4.5.Final
[0m[33m03:09:20,047 WARN [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011915: Cannot deploy from management operation, bypassing deployment unit processors: [stilts-stomplet-server-bundle:0.1.26,location=org.projectodd.stilts:main]
[0m[0m03:09:20,100 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011001: Bundle installed: stilts-stomplet-server-bundle:0.1.26
[0m[31m03:09:20,226 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) 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_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
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
[0m[31m03:09:20,447 ERROR [org.jboss.as.server] (management-handler-thread - 4) 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"}}
[0m[0m03:09:20,452 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011005: Bundle uninstalled: stomplet-server-provider:0.0.0
[0m[0m03:09:20,455 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment stomplet-server-provider in 9ms
[0m
{code}
--
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
11 years, 5 months
[JBoss JIRA] (AS7-5929) :reload operation clears up the restart-required process-state
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5929:
--------------------------------
Summary: :reload operation clears up the restart-required process-state
Key: AS7-5929
URL: https://issues.jboss.org/browse/AS7-5929
Project: Application Server 7
Issue Type: Bug
Reporter: Jeff Mesnil
For the patching service, the patch command leaves the server in a restart-required state
{noformat}
[standalone@localhost:9999 /] patch /home/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/patch.zip
{
"outcome" : "success",
"response-headers" : {
"operation-requires-restart" : true,
"process-state" : "restart-required"
}
}
{noformat}
If I try to change the AS7 configuration, the CLI warns me that a restart is required, for example:
{codeformat}
[standalone@localhost:9999 hornetq-server=default] ./queue=foo:add(queue-address=foo)
{
"outcome" => "success",
"response-headers" => {"process-state" => "restart-required"}
}
{codeformat}
However, when I reload the server using the /:reload command, the process-state header is cleared out:
{codeformat}
[standalone@localhost:9999 hornetq-server=default] /:reload
{"outcome" => "success"}
[standalone@localhost:9999 hornetq-server=default] ./queue=bar:add(queue-address=bar)
{"outcome" => "success"}
{codeformat}
This is not correct: until the server is restarted (not reloaded), the result of my patch operation will not be taken into account (eg changing the AS7 module path).
Reloading the server should not clear its process-state if it is set to "restart-required"
--
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
11 years, 5 months
[JBoss JIRA] (AS7-6076) Use own JSSE Provider for http Connector
by Hauke Mehrtens (JIRA)
Hauke Mehrtens created AS7-6076:
-----------------------------------
Summary: Use own JSSE Provider for http Connector
Key: AS7-6076
URL: https://issues.jboss.org/browse/AS7-6076
Project: Application Server 7
Issue Type: Feature Request
Components: Web
Affects Versions: 7.1.2.Final (EAP)
Reporter: Hauke Mehrtens
Assignee: Remy Maucherat
Fix For: 7.2.0.CR1
We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider.
In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one.
To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us.
With this patch we are able to specify our JSSE provider like this:
<connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true">
<ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/>
</connector>
This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors"
--
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
11 years, 5 months
[JBoss JIRA] (AS7-6075) Provide access to OSGiMetaData for server, web, etc
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-6075:
-----------------------------------
Summary: Provide access to OSGiMetaData for server, web, etc
Key: AS7-6075
URL: https://issues.jboss.org/browse/AS7-6075
Project: Application Server 7
Issue Type: Feature Request
Components: OSGi, Server
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Currently we have a policy that server does not have a dependency on OSGi API and as a result to OSGiMetaData.
In several places we do a check like this
{code}
if (depUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
...
}
{code}
This however implies that the Manifest is the only possible source of valid OSGi metadata. The OSGi webapp spec allows for metadata to be specified as part of a "webbundle://" URI (see AS7-6006)
To make this work, the integration code currently generates a Manifest and later OSGiMetaData from it. The above code still works even if the deployment content does not have a Manifest.
I propose to move the OSGiMetaData one level down so that
{code}
if (depUnit.hasAttachment(Attachments.OSGI_METADATA)) {
...
}
{code}
is the deciding criteria. As a additional benefit web would no longer need to produce/consume the raw Manifest headers and OSGi metadata would be treated like all other metadata structures.
--
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
11 years, 5 months
[JBoss JIRA] (AS7-5995) After deploy an application with a wrong module slot dependency the module loader does not recover
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created AS7-5995:
-------------------------------------
Summary: After deploy an application with a wrong module slot dependency the module loader does not recover
Key: AS7-5995
URL: https://issues.jboss.org/browse/AS7-5995
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.2.0.Alpha1
Environment: Tested with 7.2. upstream
commit ed2bc551a55ec6a8167a8657cbb5d8abc6e07748
Date: Thu Nov 15 10:15:22 2012 +0100
standalone mode, no difference whether CLI or file-system scanner
Reporter: Wolf-Dieter Fink
If an application is deployed with a dependency and specify a slot in jboss-deployment-structure.xml:
<module name="wfink.tools.performance" slot="1.0" export="true"/>
the module loader will not correct load a new deployment after failing with 'JBAS018759' Caused by: org.jboss.modules.ModuleNotFoundException: Module wfink.tools.performance:1.1 is not found in local module loader.
If after such message the application.ear contain a correct slot, or even no slot entry, the module loader fail with the message above. The slot number is the same as of the failed deployment.
If the server is restarted the application deploy succeeds.
--
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
11 years, 5 months