[JBoss JIRA] (WFLY-9391) Validation errors with "jboss-web_11_0.xsd
by Wolfgang Knauf (JIRA)
Wolfgang Knauf created WFLY-9391:
------------------------------------
Summary: Validation errors with "jboss-web_11_0.xsd
Key: WFLY-9391
URL: https://issues.jboss.org/browse/WFLY-9391
Project: WildFly
Issue Type: Bug
Affects Versions: 11.0.0.CR1
Reporter: Wolfgang Knauf
Assignee: Jason Greene
Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee"
<xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
It would probably also make sense to include the full schemaLocation URL ;-).
After fixing the namespace, there are four more errors left:
*src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a(n) group component
src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a(n) 'simpleType definition' component
src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
src-resolve: Cannot resolve the name 'jboss:security-roleType' to a(n) 'type definition' component*
The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9391) Validation errors with "jboss-web_11_0.xsd
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-9391?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf updated WFLY-9391:
---------------------------------
Description:
Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee"
<xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
It would probably also make sense to include the full schemaLocation URL ;-).
After fixing the namespace, there are four more errors left:
*src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".
was:
Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee"
<xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
It would probably also make sense to include the full schemaLocation URL ;-).
After fixing the namespace, there are four more errors left:
*src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a(n) group component
src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a(n) 'simpleType definition' component
src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
src-resolve: Cannot resolve the name 'jboss:security-roleType' to a(n) 'type definition' component*
The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".
> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
> Key: WFLY-9391
> URL: https://issues.jboss.org/browse/WFLY-9391
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 11.0.0.CR1
> Reporter: Wolfgang Knauf
> Assignee: Jason Greene
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee"
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9372) NullpointerException in artemis-server-1.1.0.wildfly-017 (and artemis-server-1.5.5.jbossorg-007.jar) when using MQTT
by Justin Bertram (JIRA)
[ https://issues.jboss.org/browse/WFLY-9372?page=com.atlassian.jira.plugin.... ]
Justin Bertram commented on WFLY-9372:
--------------------------------------
When I tested with Wildfly 11.0.0.CR1 I didn't see any issue. Clients were able to subscribe, publish, etc. as expected. Here's my module.xml:
{code:xml}
<module xmlns="urn:jboss:module:1.5" name="org.apache.activemq.artemis.protocol.mqtt">
<resources>
<resource-root path="artemis-mqtt-protocol-1.5.5.jbossorg-007.jar" />
</resources>
<dependencies>
<module name="io.netty"/>
<!-- required to load ActiveMQ protocol SPI -->
<module name="org.apache.activemq.artemis"/>
<module name="org.jboss.logging"/>
</dependencies>
</module>
{code}
Note, this doesn't include netty-codec-mqtt-5.0.0.Alpha2.jar as those classes are already included in the io.netty module which contains Netty 4.1.9.Final.
I added this to standalone-full.xml:
{code:xml}
<profile>
...
<subsystem xmlns="urn:jboss:domain:messaging-activemq:2.0">
...
<security enabled="false"/>
...
<remote-acceptor name="mqtt-acceptor" socket-binding="mqtt">
<param name="protocols" value="MQTT"/>
</remote-acceptor>
...
</subsystem>
...
</profile>
...
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
...
<socket-binding name="mqtt" port="1883"/>
</socket-binding-group>
{code}
> NullpointerException in artemis-server-1.1.0.wildfly-017 (and artemis-server-1.5.5.jbossorg-007.jar) when using MQTT
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9372
> URL: https://issues.jboss.org/browse/WFLY-9372
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final, 11.0.0.CR1
> Environment: java8
> Reporter: Thomas Houtekier
> Assignee: Jeff Mesnil
> Attachments: screenshot.png, server.log, standalone-full-ha.xml
>
>
> When connecting a MQTT-client to a wildfly-10.1.0.Final (with embedded artemis 1.1.0), the following NPE is thrown.
> {code}
> Sep:12,15:57:48,464 WARNING (:Thread-2 (activemq-netty-threads-345981593):) [io.netty.channel.DefaultChannelPipeline] An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.: io.netty.handler.codec.DecoderException: java.lang.NullPointerException
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:391) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:311) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:218) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:204) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:828) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:625) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_112]
> Caused by: java.lang.NullPointerException
> at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:171) [artemis-server-1.1.0.wildfly-017.jar:]
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> ... 9 more
> {code}
> for more info, see https://developer.jboss.org/message/976007
> Reproducing in straightforward, see 'steps to reproduce'.
> I'm not sure if this is related to the integration of artemis into wildfly, or to the artemis server itself.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (JGRP-2217) TOA doesn't ignore DATA_MESSAGE from non-members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2217?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2217:
--------------------------------
No date set, perhaps a few weeks... unless a serious bug comes up then I'd release immediately after that fix. But nothing in sight so far... :-)
> TOA doesn't ignore DATA_MESSAGE from non-members
> ------------------------------------------------
>
> Key: JGRP-2217
> URL: https://issues.jboss.org/browse/JGRP-2217
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 4.0.8
>
>
> TOA accepts and handle DATA_MESSAGE from members that aren't in the view. In that case, the message stays in the queue, in the pending state, until a new view is installed and it is cleanup.
> This blocks the deliver queue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9388) There should be replaced stacktrace loggings to stderr with usage of logging.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9388?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9388:
-----------------------------------
Priority: Major (was: Critical)
> There should be replaced stacktrace loggings to stderr with usage of logging.
> -----------------------------------------------------------------------------
>
> Key: WFLY-9388
> URL: https://issues.jboss.org/browse/WFLY-9388
> Project: WildFly
> Issue Type: Enhancement
> Components: Server
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
>
> On many places both in server and in components there is called on exception printStackTrace, this results in having the stacktrace printed to stderr. This results in each line of the stacktrace to be considered a new error message in logs.
> Using stderr is
> 1) is inefficient from performance point of view and
> 2) it doesn't have such nice control of what and when should be printed (length of stacktrace,log level) as logging does.
> I believe occurrences of using the printStackTrace in the code should be reviewed and either removed or replaced with logging where appropriate.
> This one is reported for the server itself. If you agree that it is worth doing as I believe it is, then there should be created separate tasks for individual components.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9388) There should be replaced stacktrace loggings to stderr with usage of logging.
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9388?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-9388:
--------------------------------------
[~brian.stansberry] IHMO, it is not, but the EAP issue (JBEAP-12220) has been created with Critical as a severity, so I've set this issue to the same value. Feel free to disagree and lower done the severity.
> There should be replaced stacktrace loggings to stderr with usage of logging.
> -----------------------------------------------------------------------------
>
> Key: WFLY-9388
> URL: https://issues.jboss.org/browse/WFLY-9388
> Project: WildFly
> Issue Type: Enhancement
> Components: Server
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Critical
>
> On many places both in server and in components there is called on exception printStackTrace, this results in having the stacktrace printed to stderr. This results in each line of the stacktrace to be considered a new error message in logs.
> Using stderr is
> 1) is inefficient from performance point of view and
> 2) it doesn't have such nice control of what and when should be printed (length of stacktrace,log level) as logging does.
> I believe occurrences of using the printStackTrace in the code should be reviewed and either removed or replaced with logging where appropriate.
> This one is reported for the server itself. If you agree that it is worth doing as I believe it is, then there should be created separate tasks for individual components.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9388) There should be replaced stacktrace loggings to stderr with usage of logging.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9388?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9388:
----------------------------------------
How is this Critical?
> There should be replaced stacktrace loggings to stderr with usage of logging.
> -----------------------------------------------------------------------------
>
> Key: WFLY-9388
> URL: https://issues.jboss.org/browse/WFLY-9388
> Project: WildFly
> Issue Type: Enhancement
> Components: Server
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Critical
>
> On many places both in server and in components there is called on exception printStackTrace, this results in having the stacktrace printed to stderr. This results in each line of the stacktrace to be considered a new error message in logs.
> Using stderr is
> 1) is inefficient from performance point of view and
> 2) it doesn't have such nice control of what and when should be printed (length of stacktrace,log level) as logging does.
> I believe occurrences of using the printStackTrace in the code should be reviewed and either removed or replaced with logging where appropriate.
> This one is reported for the server itself. If you agree that it is worth doing as I believe it is, then there should be created separate tasks for individual components.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFLY-9372) NullpointerException in artemis-server-1.1.0.wildfly-017 (and artemis-server-1.5.5.jbossorg-007.jar) when using MQTT
by Thomas Houtekier (JIRA)
[ https://issues.jboss.org/browse/WFLY-9372?page=com.atlassian.jira.plugin.... ]
Thomas Houtekier commented on WFLY-9372:
----------------------------------------
When I try the same thing on Wildlfy-11.0.0.CR1, I hit a similar error. Not a nullpointer, but it is thrown at the same time: when connecting with an MQTT-client
{code}
2017-09-26 17:10:26,931 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 11.0.0.CR1 (WildFly Core 3.0.1.Final) started in 7908ms - Started 405 of 681 services (437 services are lazy, passive or on-demand)
2017-09-26 17:11:55,167 WARNING [io.netty.channel.DefaultChannelPipeline] (Thread-1 (activemq-netty-threads)) An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.: io.netty.handler.codec.DecoderException: java.lang.NoSuchFieldError: INSTANCE
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:128)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:624)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:559)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:476)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NoSuchFieldError: INSTANCE
at org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManager.addChannelHandlers(MQTTProtocolManager.java:113)
at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:181)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
... 16 more
{code}
> NullpointerException in artemis-server-1.1.0.wildfly-017 (and artemis-server-1.5.5.jbossorg-007.jar) when using MQTT
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9372
> URL: https://issues.jboss.org/browse/WFLY-9372
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final, 11.0.0.CR1
> Environment: java8
> Reporter: Thomas Houtekier
> Assignee: Jeff Mesnil
> Attachments: screenshot.png, server.log, standalone-full-ha.xml
>
>
> When connecting a MQTT-client to a wildfly-10.1.0.Final (with embedded artemis 1.1.0), the following NPE is thrown.
> {code}
> Sep:12,15:57:48,464 WARNING (:Thread-2 (activemq-netty-threads-345981593):) [io.netty.channel.DefaultChannelPipeline] An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.: io.netty.handler.codec.DecoderException: java.lang.NullPointerException
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:391) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:311) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:218) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:204) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:828) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.AbstractChannel$AbstractUnsafe$7.run(AbstractChannel.java:625) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_112]
> Caused by: java.lang.NullPointerException
> at org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:171) [artemis-server-1.1.0.wildfly-017.jar:]
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:360) [netty-all-4.0.33.Final.jar:4.0.33.Final]
> ... 9 more
> {code}
> for more info, see https://developer.jboss.org/message/976007
> Reproducing in straightforward, see 'steps to reproduce'.
> I'm not sure if this is related to the integration of artemis into wildfly, or to the artemis server itself.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
James Perkins closed WFCORE-3210.
---------------------------------
Resolution: Rejected
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 7 months