[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-4198:
------------------------------------------
I did not apply this patch. Logging should not hide whats happening( obscure MDC contract ) - it should work on what it gets. PR is in the pool
> NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4198
> URL: https://issues.jboss.org/browse/WFLY-4198
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Reporter: Sergiy Barlabanov
> Assignee: Bartosz Baranowski
> Attachments: patch.diff
>
>
> When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
> The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
> So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
> Currently there is no workaround for that :(.
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
> at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4489) NPE on missing name of <distributed-workmanager>
by Philippe Marschall (JIRA)
Philippe Marschall created WFLY-4489:
----------------------------------------
Summary: NPE on missing name of <distributed-workmanager>
Key: WFLY-4489
URL: https://issues.jboss.org/browse/WFLY-4489
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Philippe Marschall
Assignee: Jesper Pedersen
When the name attribute of {{<distributed-workmanager>}} is missing instead of a descriptive log message you get a {{NullPointerException}}. The issue is that the {{StringBuilder}} constructor is called with the value of the name attribute instead of the name of the name attribute ("name").
Something like this:
{code}
<subsystem xmlns="urn:jboss:domain:jca:2.0">
<distributed-workmanager/>
</subsystem>
{code}
Will produce a stack trace like this:
{code}
[org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
at org.jboss.as.server.ServerService.boot(ServerService.java:347)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at java.lang.StringBuilder.<init>(StringBuilder.java:112)
at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.parseDistributedWorkManager(JcaExtension.java:560)
at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:367)
at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:119)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1199)
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:457)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
{code}
After the patch the stack trace looks like this:
{code}
org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2]
at org.jboss.as.server.ServerService.boot(ServerService.java:347) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[274,13]
Message: WFLYCTL0133: Missing required attribute(s): name
at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.parseDistributedWorkManager(JcaExtension.java:563)
at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:368)
at org.jboss.as.connector.subsystems.jca.JcaExtension$ConnectorSubsystemParser.readElement(JcaExtension.java:120)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1]
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1]
at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1199) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2]
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:457) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106) [wildfly-server-1.0.0.Beta2.jar:1.0.0.Beta2]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Beta1.jar:1.2.0.Beta1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-1.0.0.Beta2.jar:1.0.0.Beta2]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-623) ModelControllerClient.Factory lacks some variants
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-623?page=com.atlassian.jira.plugin... ]
Ladislav Thon reassigned WFCORE-623:
------------------------------------
Assignee: Brian Stansberry (was: Ladislav Thon)
> ModelControllerClient.Factory lacks some variants
> -------------------------------------------------
>
> Key: WFCORE-623
> URL: https://issues.jboss.org/browse/WFCORE-623
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
>
> In the {{ModelControllerClient.Factory}} class, each factory method in fact has two varians: with a {{protocol}} as a first parameter, and without it. There are two exceptions -- two methods are lacking a {{protocol}}-less variant:
> - {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions)}}
> - {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions, final String clientBindAddress)}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-623) ModelControllerClient.Factory lacks some variants
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-623?page=com.atlassian.jira.plugin... ]
Ladislav Thon updated WFCORE-623:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/593, https://github.com/wildfly/wildfly-core/pull/600 (was: https://github.com/wildfly/wildfly-core/pull/593)
> ModelControllerClient.Factory lacks some variants
> -------------------------------------------------
>
> Key: WFCORE-623
> URL: https://issues.jboss.org/browse/WFCORE-623
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta2
> Reporter: Ladislav Thon
> Assignee: Ladislav Thon
>
> In the {{ModelControllerClient.Factory}} class, each factory method in fact has two varians: with a {{protocol}} as a first parameter, and without it. There are two exceptions -- two methods are lacking a {{protocol}}-less variant:
> - {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions)}}
> - {{ModelControllerClient create(final String protocol, final String hostName, final int port, final CallbackHandler handler, final SSLContext sslContext, final int connectionTimeout, final Map<String, String> saslOptions, final String clientBindAddress)}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4480) Websocket exception using async remote
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4480?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4480:
--------------------------------------
This should be fixed in Undertow upstream, although I can't reproduce it so it is hard to be sure.
> Websocket exception using async remote
> --------------------------------------
>
> Key: WFLY-4480
> URL: https://issues.jboss.org/browse/WFLY-4480
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 9.0.0.Beta2
> Reporter: nicolas desmaziers
> Assignee: Stuart Douglas
>
> Sending binary messages on the AsyncRemote endpoint throws an error in the log:
> 21:11:28,747 ERROR [org.xnio.listener] (default I/O-6) XNIO001007: A channel event listener threw an exception: java.lang.IllegalStateException: XNIO000017: Buffer was already freed
> at org.xnio.ByteBufferSlicePool$PooledByteBuffer.getResource(ByteBufferSlicePool.java:206)
> at org.xnio.ByteBufferSlicePool$PooledByteBuffer.getResource(ByteBufferSlicePool.java:176)
> at io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:490)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:793)
> at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:790)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:93)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> This happens after a few minutes and generally the number of errors increase rapidly and we can easily have a 2Go log after a few hours.
> Code is:
> session.getAsyncRemote.sendBinary(event.asReadOnlyBuffer(), new SendHandler(){
> override def onResult(result:SendResult) {
> }
> })
> It worked well with wildly 9.0 alpha 1 but bug appeared with beta 2.
> I generally receive a close event on the web socket session after the error logging.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4374) java.lang.IllegalAccessError and other classloader issues
by Anindhya Sharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4374?page=com.atlassian.jira.plugin.... ]
Anindhya Sharma commented on WFLY-4374:
---------------------------------------
Thanks for your response.
The Java EE 6 specification, section 8.2 Library Support and in it sub section 8.2.1 Bundled Libraries clearly states a JAR file may reference another JAR file using the Class-Path header in the manifest.
The above is what we have done in previous versions too of JBoss and other vendor products and it works as noted.
Here is an excerpt from the Wildfly documentation from the Developer's Guide, section on "Class Loading in Wildfly",
"If the ear-subdeployments-isolated is set to true then no automatic module dependencies between the sub-deployments are set up. User must manually setup the dependency with Class-Path entries, or by setting up explicit module dependencies."
Further it goes on to state
"
Portability
The Java EE specification says that portable applications should not rely on sub deployments having access to other sub deployments unless an explicit Class-Path entry is set in the MANIFEST.MF. So portable applications should always use Class-Path entry to explicitly state their dependencies.
"
So I am not sure how for Wildfly it can be stated that it meets EE specs (and your own documentation).
> java.lang.IllegalAccessError and other classloader issues
> ---------------------------------------------------------
>
> Key: WFLY-4374
> URL: https://issues.jboss.org/browse/WFLY-4374
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2
> Environment: Windows 7/Java 7 update 67
> Reporter: John Sipher
> Assignee: David Lloyd
> Attachments: problem-demo.zip
>
>
> Update 4/1/2015: I have verified that 9.0.0.Beta2 fixes the IllegalAccessError and the war file in problem-demo.zip/hello-world6/target now duplicates the original problem. The order of the jar files in the classpath should be
> WEB-INF/lib/patch/patch2.jar
> WEB-INF/lib/patch/patch1.jar
> WEB-INF/lib/base/helloworld-sans-cdi.jar
> org.jboss.as.quickstarts.helloworld.HelloService exists in both patch2.jar and helloworld-sans-cdi.jar. The version from patch2.jar should be used because it is first in the classpath, but the classloader is picking up the original class from helloworld-sans-cdi.jar instead.
> Original problem description follows:
> We use manifest-only jar files in our WAR and EAR files to control the order that jar files are searched for classes. When we issue patches, we put the modified class(es) in a separate jar file, add that jar file to the affected EAR or WAR file, and update the classpath in our manifest-only jar file to put the new patch at the beginning of the class path so that it will be used in place of the original class (which is still in the original jar file).
>
> For example, WEB-INF/lib will contain a single jar file named manifest.jar and sub-folders named 3rdparty, base, patch, and custom. The Class-Path entry in WEB-INF/lib/manifest.jar|META-INF/MANIFEST.MF looks like this:
> Class-Path: 3rdparty/manifest.jar patch/manifest.jar base/manifest.jar custom/manifest.jar
>
> When we publish a patch, the patch jar file is added to WEB-INF/lib/patch and to the front of the classpath in WEB-INF/lib/patch/manifest.jar's MANIFEST.MF.
>
> This worked fine for us for years with JBoss 4.2.3.GA, 5.1.0.GA, 7.1.2.Final, and 7.2.0.Final, but it's broken in WildFly 8.2.0.Final.
> When I run it in debug I can see where the problem shows up in this section of org.jboss.modules.Module (lines 562 - 573).
> final String path = pathOfClass(className);
> final Map<String, List<LocalLoader>> paths = getPathsUnchecked();
> final List<LocalLoader> loaders = paths.get(path);
> if (loaders != null) {
> Class<?> clazz;
> for (LocalLoader loader : loaders) {
> clazz = loader.loadClassLocal(className, resolve);
> if (clazz != null) {
> return clazz;
> }
> }
> }
> The modules in the loaders list at line 565 are
> * deployment.service.ear.lib/base/shared.jar:main
> * deployment.service.ear.lib/base/deployment.jar:main
> * deployment.service.ear.lib/patch/patch.jar:main
> The last one should actually be the first in the list. I haven't been able to track down the actual source of the error yet.
> I've been trying to create a simple example based on the helloworld quickstart to reproduce the problem, but I haven't been successful yet because of other classloader errors that I've run into. I decided to go ahead and open this issue and document the things I am able to reproduce. Those are:
> 1. CDI injection doesn't work when the annotated classes are in jar files under WEB-INF/lib instead of unpacked in WEB-INF/classes.
> 2. WildFly doesn't process the javax.servlet.annotation.WebServlet annotation if the jar file containing the annotated class is in a sub-folder of WEB-INF/lib.
> 3. WildFly throws a java.lang.IllegalAccessError trying to load a "patched" class.
> The first problem exists in both 7.2.0.Final and 8.2.0.Final. The other two problems are new in 8.2.0.Final.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-630) jboss-cli.xml should include timeout of 30 seconds
by Travis Rogers (JIRA)
[ https://issues.jboss.org/browse/WFCORE-630?page=com.atlassian.jira.plugin... ]
Travis Rogers moved WFLY-4367 to WFCORE-630:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-630 (was: WFLY-4367)
Affects Version/s: (was: 8.2.0.Final)
Component/s: CLI
(was: CLI)
> jboss-cli.xml should include timeout of 30 seconds
> ---------------------------------------------------
>
> Key: WFCORE-630
> URL: https://issues.jboss.org/browse/WFCORE-630
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Travis Rogers
> Assignee: Alexey Loubyansky
> Attachments: loop-cli-cmd.sh
>
>
> Description of problem:
> CLI commands use a default timeout of 5 seconds. Testing has shown that connection timeouts will occur with a timeout value this low. Recommended value is 30 seconds.
> The following default setting should be added to $JBOSS_HOME/bin/jboss-cli.xml:
> <connection-timeout>30000</connection-timeout>
> Version-Release number of selected component (if applicable):
> How to reproduce:
> Loop calling the CLI executing a command.
> Example command:
> jboss-cli.sh -c --command=":read-attribute(name=server-state)"
> Actual results:
> Connection timeout error will eventually be thrown.
> Expected results:
> No errors due to connection timeout.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month