[JBoss JIRA] (WFLY-6547) logging custom-handler does not load module with slot
by Erwan Lacoste (JIRA)
Erwan Lacoste created WFLY-6547:
-----------------------------------
Summary: logging custom-handler does not load module with slot
Key: WFLY-6547
URL: https://issues.jboss.org/browse/WFLY-6547
Project: WildFly
Issue Type: Bug
Components: Logging
Affects Versions: JBoss AS7 7.2.0.Final
Reporter: Erwan Lacoste
Assignee: James Perkins
Tested on EAP 6.4
when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
my/lognahdler/main
module.xml
my.jar
{code:xml}
<custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
{code}
Nevertheless I want to version the module, therefore package my module with a given slot:
my/lognahdler/1.0
module.xml
my.jar
{code:xml}
<custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
{code}
But this fails with following stacktrace:
{code}
11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
("subsystem" => "logging"),
("custom-handler" => "4H")
]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
... 13 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6546) jms-queue metrics appears in the profile in domain mode
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-6546:
---------------------------------
Summary: jms-queue metrics appears in the profile in domain mode
Key: WFLY-6546
URL: https://issues.jboss.org/browse/WFLY-6546
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Priority: Minor
Metrics associated to jms-queue resource are displayed in the profile in domain mode (under /profile=full/subsystem=messaging-activemq/server=artemis/jms-queue=XXX).
These metrics have no meaning in the domain controller and should only be exposed on the server (under /host=master/server=server-one/subsystem=messaging-activemq/server=default/jms-queue=XXX:read-resource(include-runtime=true) )
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2056) Measure latency for RPCs
by Bela Ban (JIRA)
Bela Ban created JGRP-2056:
------------------------------
Summary: Measure latency for RPCs
Key: JGRP-2056
URL: https://issues.jboss.org/browse/JGRP-2056
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0
Measure latency for single-thread tests between a sender and a receiver, and identify potential slow-downs. Look at
* message bundlers at the sender and
* message batch handling at the receiver
This needs to be done for both requests and responses
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by jukka sirviö (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
jukka sirviö commented on WFLY-4769:
------------------------------------
Dear George, Certainly, no problem, I did post ArtemisMQ code snippet to original forum:
https://developer.jboss.org/message/933327#933327
Please close this issues if you get it working and update the forum reference as answered!
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6543) Multiple Sessions are created over SSL Session Tracking
by Pradeep Kumar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6543?page=com.atlassian.jira.plugin.... ]
Pradeep Kumar updated WFLY-6543:
--------------------------------
Steps to Reproduce:
1. Enable SSL.
2. Deploy the attachment "SessionTrackingSsl.war".
3. Access the resource through the browser.
4. The Session Ids will be logged to the configured root logger.
Sometimes the session ids are consistent. In such cases, clearing the browser data and reloading the resource will help reproduce the bug. Also viewing the resource in Inprivate browsing will help too.
was:
1. Enable SSL.
2. Deploy the attachment "SessionTrackingSsl.war".
3. Access the resource through the browser.
4. The Session Ids will be logged to the configured root logger.
Sometimes the session ids are consistent. In such cases, clearing the browser data and reloading the resource will help reproduce the bug. But
> Multiple Sessions are created over SSL Session Tracking
> -------------------------------------------------------
>
> Key: WFLY-6543
> URL: https://issues.jboss.org/browse/WFLY-6543
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: oracle java version "1.8.0_74"
> Reporter: Pradeep Kumar
> Assignee: Stuart Douglas
> Labels: session, ssl
> Attachments: SessionTrackingSsl.war
>
>
> When using SSL as the session tracking method, there are multiple sessions created for subsequent HTTP requests, some of which are reused.
> This is the log obtained by using a filter to track the HTTP Sessions:
> {noformat}
> 14:08:45,766 INFO [com.test.SessionIdTrackFilter] (default task-17) Request URL : [/SessionTrackingSsl/], Session Id : [wkgBkT61gFQnJeSacPyLEgKWmJ6iPusT-8xcpXFP]
> 14:08:45,784 INFO [com.test.SessionIdTrackFilter] (default task-20) Request URL : [/SessionTrackingSsl/resources/css/font-awesome.min.css], Session Id : [uljMhXUsAK1BXXXmnmXzAD4EkFgFZn30I-wsFajD]
> 14:08:45,784 INFO [com.test.SessionIdTrackFilter] (default task-16) Request URL : [/SessionTrackingSsl/resources/js/jquery/jquery-1.12.3.min.js], Session Id : [SBZeTDPKSxLbgcwR_zCazx5heXwssOvrjSVI0sJV]
> 14:08:45,784 INFO [com.test.SessionIdTrackFilter] (default task-18) Request URL : [/SessionTrackingSsl/resources/css/bootstrap.min.css], Session Id : [wkgBkT61gFQnJeSacPyLEgKWmJ6iPusT-8xcpXFP]
> 14:08:45,785 INFO [com.test.SessionIdTrackFilter] (default task-16) Request URL : [/SessionTrackingSsl/resources/js/bootstrap.min.js], Session Id : [FETLRFRjQyjzktTUi29hTe3tqimJnGEgdpHZGu6e]
> 14:08:45,787 INFO [com.test.SessionIdTrackFilter] (default task-19) Request URL : [/SessionTrackingSsl/starter-template.css], Session Id : [eHGhpdreJJv8RKTmZul3hKXjORhAp8GIqJktTmgh]
> 14:08:45,814 INFO [com.test.SessionIdTrackFilter] (default task-26) Request URL : [/SessionTrackingSsl/resources/fonts/fontawesome-webfont.woff2], Session Id : [wkgBkT61gFQnJeSacPyLEgKWmJ6iPusT-8xcpXFP]
> {noformat}
> I have made the following changes to the standalone.xml to enable SSL:
> diff ../standalone/configuration/standalone.xml ../standalone/configuration/standalone_xml_history/standalone.initial.xml :
> {noformat}
> 1c1
> < <?xml version='1.0' encoding='UTF-8'?>
> ---
> > <?xml version="1.0" ?>
> 4d3
> <
> 33,34d31
> <
> <
> 47,51d43
> < <server-identities>
> < <ssl>
> < <keystore path="testks.keystore" relative-to="jboss.server.config.dir" keystore-password="Password" alias="testks" key-password="Password"/>
> < </ssl>
> < </server-identities>
> 89d80
> <
> 188a180
> > <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
> 206c198
> < <remote connector-ref="https-remoting-connector" thread-pool-name="default"/>
> ---
> > <remote connector-ref="http-remoting-connector" thread-pool-name="default"/>
> 305c297
> < <http-connector name="https-remoting-connector" connector-ref="default-https" security-realm="ApplicationRealm"/>
> ---
> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> 360c352
> < <https-listener name="default-https" security-realm="ApplicationRealm" socket-binding="https"/>
> ---
> > <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> 391d382
> <
> 400d390
> <
> {noformat}
> Apart from this, I have not made any changes to any of the configuration files. When the tracking method is set to COOKIE, the session ids are consistent.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1497) RBAC roles scoped to addresses that match a regex
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1497?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1497:
-------------------------------------
Description:
Host scoped roles and server group scoped roles work via a constraint that checks the address being manipulated against a calculated group of allowed addresses. That calculation is complex in the server group and host cases to account for the complex semantics of those kinds of scoping while requiring very little config from the user, but we could also have a similar kind of scoping that requires more config from the user but is also more flexible. The user configures one or more regex strings, and any address (or canonical mbean object name) that matches meets the constraint.
Example, a "log-maintainer" role that gets Maintainer privileges for the logging subsystem but is Monitor for everything else:
{code}
<pattern-scoped-role name="log-maintainer" base-role="Maintainer>
<patterns>
<!-- For domain controller -->
<pattern value="/profile={1}.*/subsystem=logging{1}.*"/>
<!-- For servers -->
<pattern value="/subsystem=logging{1}.*"/>
</patterns>
</pattern-scoped-role>
{code}
I use logging as an example as it's a use case I can imagine easily enough -- a server is largely locked down but tweaks to logging are allowed to allow diagnostic data to be gathered.
was:
Host scoped roles and server group scoped roles work via a constraint that checks the address being manipulated against a calculated group of allowed addresses. That calculation is complex in the server group and host cases to account for the complex semantics of those kinds of scoping while requiring very little config from the user, but we could also have a similar kind of scoping that requires more config from the user but is also more flexible. The user configures one or more regex strings, and any address (or canonical mbean object name) that matches meets the constraint.
Example, a "log-maintainer" role that gets Maintainer privileges for the logging subsystem but is Monitor for everything else:
{code}
<pattern-scoped-role name="log-maintainer" base-role="Maintainer>
<patterns>
<!-- For domain controller -->
<pattern value="/profile=*/subsystem=logging*"/>
<!-- For servers -->
<pattern value="/subsystem=logging*"/>
</patterns>
</pattern-scoped-role>
{code}
I use logging as an example as it's a use case I can imagine easily enough -- a server is largely locked down but tweaks to logging are allowed to allow diagnostic data to be gathered.
> RBAC roles scoped to addresses that match a regex
> -------------------------------------------------
>
> Key: WFCORE-1497
> URL: https://issues.jboss.org/browse/WFCORE-1497
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Host scoped roles and server group scoped roles work via a constraint that checks the address being manipulated against a calculated group of allowed addresses. That calculation is complex in the server group and host cases to account for the complex semantics of those kinds of scoping while requiring very little config from the user, but we could also have a similar kind of scoping that requires more config from the user but is also more flexible. The user configures one or more regex strings, and any address (or canonical mbean object name) that matches meets the constraint.
> Example, a "log-maintainer" role that gets Maintainer privileges for the logging subsystem but is Monitor for everything else:
> {code}
> <pattern-scoped-role name="log-maintainer" base-role="Maintainer>
> <patterns>
> <!-- For domain controller -->
> <pattern value="/profile={1}.*/subsystem=logging{1}.*"/>
> <!-- For servers -->
> <pattern value="/subsystem=logging{1}.*"/>
> </patterns>
> </pattern-scoped-role>
> {code}
> I use logging as an example as it's a use case I can imagine easily enough -- a server is largely locked down but tweaks to logging are allowed to allow diagnostic data to be gathered.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1497) RBAC roles scoped to addresses that match a regex
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1497:
----------------------------------------
Summary: RBAC roles scoped to addresses that match a regex
Key: WFCORE-1497
URL: https://issues.jboss.org/browse/WFCORE-1497
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Host scoped roles and server group scoped roles work via a constraint that checks the address being manipulated against a calculated group of allowed addresses. That calculation is complex in the server group and host cases to account for the complex semantics of those kinds of scoping while requiring very little config from the user, but we could also have a similar kind of scoping that requires more config from the user but is also more flexible. The user configures one or more regex strings, and any address (or canonical mbean object name) that matches meets the constraint.
Example, a "log-maintainer" role that gets Maintainer privileges for the logging subsystem but is Monitor for everything else:
{code}
<pattern-scoped-role name="log-maintainer" base-role="Maintainer>
<patterns>
<!-- For domain controller -->
<pattern value="/profile=*/subsystem=logging*"/>
<!-- For servers -->
<pattern value="/subsystem=logging*"/>
</patterns>
</pattern-scoped-role>
{code}
I use logging as an example as it's a use case I can imagine easily enough -- a server is largely locked down but tweaks to logging are allowed to allow diagnostic data to be gathered.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years