[JBoss JIRA] (AS7-5958) Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5958?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-5958:
--------------------------------
Fix Version/s: (was: 7.2.0.Alpha1)
Assignee: (was: Thomas Diesler)
Ok, we are parking this until we know more.
> Incorrect Candidate permutation failed due to a conflict between imports exception when using host and fragment bundles
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5958
> URL: https://issues.jboss.org/browse/AS7-5958
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows XP SP3
> Reporter: Paul Illingworth
> Labels: OSGI
>
> I am getting the following exception when my bundle is being resolved. I don't believe this is correct.
> {noformat}
> 2012-11-15 15:10:41,403 DEBUG [org.jboss.osgi.resolver](qtp4105020-187) Candidate permutation failed due to a conflict between imports; will try another if possible.: org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]] because it is exposed to package 'com.google.inject' from resources com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] and com.google.inject [HostBundleRevision[com.google.inject:3.0.0]] via two dependency chains.
> Chain 1:
> resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.google.inject
> com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
> Chain 2:
> resource-console-web [HostBundleRevision[resource-console-web:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.saaconsultants.gwt.rpc.server.servlets; uses:=com.google.inject
> reims-gwt-rpc [HostBundleRevision[reims-gwt-rpc:1.0.0.SNAPSHOT]]
> import: null
> |
> export: osgi.wiring.package=com.google.inject
> com.google.inject [HostBundleRevision[com.google.inject:3.0.0]]
> at org.apache.felix.resolver.ResolverImpl.checkPackageSpaceConsistency(ResolverImpl.java:1142)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:197)
> at org.jboss.osgi.resolver.felix.StatelessResolver.resolve(StatelessResolver.java:56)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:152)
> at org.jboss.osgi.framework.internal.ResolverPlugin.resolveAndApply(ResolverPlugin.java:167)
> at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:598)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:214)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:520)
> at org.apache.felix.webconsole.internal.core.BundlesServlet.doPost(BundlesServlet.java:331)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:437)
> at org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:384)
> 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.ops4j.pax.web.service.internal.HttpServiceStarted$2.invoke(HttpServiceStarted.java:209)
> at org.ops4j.pax.web.service.internal.$Proxy39.service(Unknown Source)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
> at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:70)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
> at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
> at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
> at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:117)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
> at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
> at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:74)
> at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
> at org.eclipse.jetty.server.Server.handle(Server.java:349)
> at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
> at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:936)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
> at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
> at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
> at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
> at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
> at java.lang.Thread.run(Thread.java:662)
> 2012-11-15 15:10:41,403 TRACE [org.jboss.osgi.framework](qtp4105020-187) Release framework lock
> {noformat}
> It seems to be happening because the ResolverImpl.isCompatible() method is comparing two capabilities; one is an AbstractBundleCapability and the other is a WrappedCapability that contains the same instance of AbstractBundleCapability. The result of the comparison is false.
> As a quick hack I changed the equals method of WrappedCapability to
> {noformat}
> @Override
> public boolean equals(Object obj)
> {
> return m_cap.equals(obj);
> }
> {noformat}
> and that seemed to make it work and resolution was successful.
--
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, 4 months
[JBoss JIRA] (AS7-6232) DefaultAuthenticationCacheFactory should not use internal Infinispan classes
by Tristan Tarrant (JIRA)
Tristan Tarrant created AS7-6232:
------------------------------------
Summary: DefaultAuthenticationCacheFactory should not use internal Infinispan classes
Key: AS7-6232
URL: https://issues.jboss.org/browse/AS7-6232
Project: Application Server 7
Issue Type: Bug
Components: Security
Affects Versions: 7.1.3.Final (EAP)
Reporter: Tristan Tarrant
Assignee: Anil Saldhana
The DefaultAuthenticationCacheFactory class (and the AuthenticationCacheEvictionListener class) use internal Infinispan classes which are subject to change without API stability guarantees. The code should be rewritten to use an Infinispan cache instead.
--
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, 4 months
[JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler edited comment on AS7-5951 at 12/20/12 8:02 AM:
---------------------------------------------------------------
I think we need more data here.
I updated the framework and bootstrap integration code to produce better logging. You should now see something like this
{code}
[tdiesler@tdmac jboss-as-7.2.0.Alpha1-SNAPSHOT]$ cat standalone/log/server.log | grep "on behalf of"
17:00:43,353 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Install bootstrap deployments [[org.apache.felix.log:1.0.0,location=org.apache.felix.log], [jboss-osgi-logging:1.0.0,location=org.jboss.osgi.logging], [org.apache.felix.configadmin:1.2.8,location=org.apache.felix.configadmin], [jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT,location=org.jboss.as.osgi.configadmin]] on behalf of jbosgi.BootstrapBundles.INSTALL
17:00:43,379 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Resolve bootstrap bundles on behalf of jbosgi.BootstrapBundles.RESOLVE
17:00:43,481 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Activate bootstrap bundles on behalf of jbosgi.BootstrapBundles.ACTIVATE
17:00:43,487 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Complete bootstrap bundles on behalf of jbosgi.BootstrapBundles.COMPLETE
17:00:43,502 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Install persistent deployments [] on behalf of jbosgi.PersistentBundles.INSTALL
17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Resolve persistent bundles on behalf of jbosgi.PersistentBundles.RESOLVE
17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Activate persistent bundles on behalf of jbosgi.PersistentBundles.ACTIVATE
17:00:43,504 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-8) Complete persistent bundles on behalf of jbosgi.PersistentBundles.COMPLETE
{code}
The idea is that the persistent bundles get installed only after the bootstrap bundles (i.e. the configured capabilities) complete. Also, no persistent bundle should resolve before not all persistent bundles are installed. Could you please verify you output according to these rules.
For a fragment that does not attach, we need to find out why it is not included in the resolve attempt. If it is included, it might be a resolver issue.
The related code change is here: https://github.com/jbossas/jboss-as/pull/3727
was (Author: thomas.diesler):
I think we need more data here.
I updated the framework and bootstrap integration code to produce better logging. You should now see something like this
{code}
[tdiesler@tdmac jboss-as-7.2.0.Alpha1-SNAPSHOT]$ cat standalone/log/server.log | grep "on behalf of"
17:00:43,353 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Install bootstrap deployments [[org.apache.felix.log:1.0.0,location=org.apache.felix.log], [jboss-osgi-logging:1.0.0,location=org.jboss.osgi.logging], [org.apache.felix.configadmin:1.2.8,location=org.apache.felix.configadmin], [jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT,location=org.jboss.as.osgi.configadmin]] on behalf of jbosgi.BootstrapBundles.INSTALL
17:00:43,379 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Resolve bootstrap bundles on behalf of jbosgi.BootstrapBundles.RESOLVE
17:00:43,481 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Activate bootstrap bundles on behalf of jbosgi.BootstrapBundles.ACTIVATE
17:00:43,487 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Complete bootstrap bundles on behalf of jbosgi.BootstrapBundles.COMPLETE
17:00:43,502 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Install persistent deployments [] on behalf of jbosgi.PersistentBundles.INSTALL
17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Resolve persistent bundles on behalf of jbosgi.PersistentBundles.RESOLVE
17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Activate persistent bundles on behalf of jbosgi.PersistentBundles.ACTIVATE
17:00:43,504 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-8) Complete persistent bundles on behalf of jbosgi.PersistentBundles.COMPLETE
{code}
The idea is that the persistent bundles get installed only after the bootstrap bundles (i.e. the configured capabilities) complete. Also, no persistent bundle should resolve before not all persistent bundles are installed. Could you please verify you output according to these rules.
For a fragment that does not attach, we need to find out why it is not included in the resolve attempt. If it is included, it might be a resolver issue.
The related code change is [here|https://github.com/jbossas/jboss-as/pull/3713]
> Cannot reliably deploy OSGi host and fragment bundles on server restart
> -----------------------------------------------------------------------
>
> 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
> Labels: OSGI
> Fix For: 7.2.0.Alpha1
>
> Attachments: this_one_failed.txt, this_one_worked.txt
>
>
> 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, 4 months
[JBoss JIRA] (AS7-6231) Context initialization exceptions are swallowed on deployment
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6231?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori commented on AS7-6231:
----------------------------------------
Added. Should be self-contained: just a spring app with one controller and one bean, saying hello world.
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: AS7-6231
> URL: https://issues.jboss.org/browse/AS7-6231
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix the problem.
--
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, 4 months
[JBoss JIRA] (AS7-6231) Context initialization exceptions are swallowed on deployment
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6231?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori updated AS7-6231:
-----------------------------------
Attachment: spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: AS7-6231
> URL: https://issues.jboss.org/browse/AS7-6231
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix the problem.
--
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, 4 months
[JBoss JIRA] (AS7-6231) Context initialization exceptions are swallowed on deployment
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6231?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori updated AS7-6231:
-----------------------------------
Attachment: jboss-7.2.0.-stacktrace-namespace.txt
jboss-7.1.1.-stacktrace-beans.txt
jboss-7.1.1.-stacktrace-namespace.txt
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: AS7-6231
> URL: https://issues.jboss.org/browse/AS7-6231
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix the problem.
--
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, 4 months
[JBoss JIRA] (AS7-6086) Deadlock in org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6086?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins reassigned AS7-6086:
------------------------------------
Assignee: Eduardo Martins (was: jaikiran pai)
> Deadlock in org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler
> ---------------------------------------------------------------------------------------
>
> Key: AS7-6086
> URL: https://issues.jboss.org/browse/AS7-6086
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Doesn't matter.
> Reporter: Krzysztof Noceń
> Assignee: Eduardo Martins
> Fix For: No Release
>
>
> Class:
> {code}
> org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler
> {code}
> Method:
> {code}
> public void processMessage(ChannelAssociation, MessageInputStream) throws IOException;
> {code}
> This code fragment:
> {code}
> try {
> methodParams[i] = unmarshaller.readObject();
> } catch (ClassNotFoundException cnfe) {
> /.../
> return;
> }
> {code}
> doesn't catch *java.lang.IllegalArgumentException*.
> This causes the server hangs.
> Example stacktrace:
> {code}
> java.lang.IllegalArgumentException: No enum const org.example.ExampleEnum.ENUM_VALUE
> at java.lang.Enum.valueOf(Enum.java:196)
> at org.jboss.marshalling.river.RiverUnmarshaller.resolveEnumConstant(RiverUnmarshaller.java:1549)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1293)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:164)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:182)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:429)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> I caught *java.lang.Exception*. It helps.
--
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, 4 months
[JBoss JIRA] (AS7-5946) jboss-ejb3.xml faults fail silently and result in a hanging thread
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-5946?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins reassigned AS7-5946:
------------------------------------
Assignee: Eduardo Martins (was: David Lloyd)
> jboss-ejb3.xml faults fail silently and result in a hanging thread
> ------------------------------------------------------------------
>
> Key: AS7-5946
> URL: https://issues.jboss.org/browse/AS7-5946
> Project: Application Server 7
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
> Environment: MacOS X 10.8.2
> java version "1.6.0_35"
> Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
> Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
> Reporter: Stephen Coy
> Assignee: Eduardo Martins
> Attachments: migration-demo.tar.gz
>
>
> The attached maven application project has a subtle typo in a JNDI name in the jboss-ejb3.xml file.
> The deployment process results in a hanging thread shown below. There are no diagnostic log messages at all to indicate what the problem could be.
> A second consequence of this hung thread is that the server process can only be terminated with a "kill -9 <pid>".
> Note that it is deliberately a JEE5 compatible application.
> "management-handler-thread - 4" prio=5 tid=7f843c0bf000 nid=0x10a866000 in Object.wait() [10a864000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7d42d05f8> (a org.jboss.as.controller.ContainerStateMonitor)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158)
> - locked <7d42d05f8> (a org.jboss.as.controller.ContainerStateMonitor)
> at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:442)
> at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:147)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:261)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentHandlerUtil$1.execute(DeploymentHandlerUtil.java:123)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentDeployHandler.execute(DeploymentDeployHandler.java:75)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.server.deployment.DeploymentAddHandler.execute(DeploymentAddHandler.java:168)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.CompositeOperationHandler.execute(CompositeOperationHandler.java:85)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:473)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:126)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Locked ownable synchronizers:
> - <7d42a5150> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> - <7d4f3b598> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
--
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, 4 months
[JBoss JIRA] (AS7-5368) Lookup of UserTransaction should not be allowed in CMT beans
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-5368?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins reassigned AS7-5368:
------------------------------------
Assignee: Eduardo Martins (was: jaikiran pai)
> Lookup of UserTransaction should not be allowed in CMT beans
> ------------------------------------------------------------
>
> Key: AS7-5368
> URL: https://issues.jboss.org/browse/AS7-5368
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.2.0.Alpha1
> Reporter: Cheng Fang
> Assignee: Eduardo Martins
>
> EJB spec 8.3.4 Enterprise Beans Using Container-Managed Transaction Demarcation:
> The enterprise bean’s business methods, message listener methods, business method interceptor meth- ods, lifecycle callback interceptor methods, or timeout callback methods must not attempt to obtain or use the javax.transaction.UserTransaction interface.
> Currently lookup("java:comp/UserTransaction") returns an instance of org.jboss.tm.usertx.client.ServerVMClientUserTransaction.
> Similar to AS7-5331
--
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, 4 months