[JBoss JIRA] (WFCORE-1512) DelegatingBasicLogger could delegate to a Logger provider
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1512?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-1512:
---------------------------------------
The {{DelegatingBasicLogger}} is part of the [jboss-logging|https://github.com/jboss-logging/jboss-logging] which is just a logging facade. The {{LogContext}} is from the [jboss-logmanager|https://github.com/jboss-logging/jboss-logmanager] project which is an extension of the JUL log manager. The generated logger interfaces don't have any knowledge of the log manager.
The main issue is we're using static loggers. The loggers are created on a log context once since the modules are only loaded once.
> DelegatingBasicLogger could delegate to a Logger provider
> ---------------------------------------------------------
>
> Key: WFCORE-1512
> URL: https://issues.jboss.org/browse/WFCORE-1512
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Jean-Francois Denise
> Assignee: James Perkins
>
> Today the DelegatingBasicLogger subclass generated from @MessageLogger annotation is bound to a Logger at construction time. It could be of interest (e.g: I ran by accident on WFCORE-1187) to have the logger to be resolved dynamically.
> I didn't evaluate the impact on the logging project/tools/performances of a solution like the following but it captures the idea of a logger provider.
> public class DelegatingBasicLogger {
> public interface LoggerProvider
> { public Logger getLogger(); }
> DelegatingBasicLogger(Logger logger) {
> { this(()->{return logger;})}
> DelegatingBasicLogger(LoggerProvider provider)
> { this.provider = provider; }
> ....
> }
> A subclass could use LogContext to retrieve the right Logger.
> class MyLogger extends DelegatingBasicLogger {
> MyLogger(String category)
> { super(()->LogContext.getLogContext().getLogger()); }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6565) add and remove operation of jaxrs subsystem under deployment are useles and should not be available
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6565?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-4388 to WFLY-6565:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6565 (was: JBEAP-4388)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: REST
(was: REST)
Target Release: (was: 7.backlog.GA)
> add and remove operation of jaxrs subsystem under deployment are useles and should not be available
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-6565
> URL: https://issues.jboss.org/browse/WFLY-6565
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> *Description of problem:*
> "add" and "remove" operation of jaxrs subsystem under deployment are useles and should not be available.
> This operations were added by WFLY-3045.
> *How reproducible:*
> Always
> *Steps to Reproduce (remove):*
> # ./standalone.sh
> # deploy /home/mkopecky/playground/resteasy/single-application/target/jaxrs-eap.war
> # /deployment=jaxrs-eap.war/subsystem=jaxrs:remove
> # :reload
> # # jaxrs subsystem is not removed
> *Steps to Reproduce (add):*
> # deploy /home/mkopecky/playground/resteasy/empty-deployment/target/empty-eap.war
> # /deployment=empty-eap.war/subsystem=jaxrs:add()
> # :reload
> # # jaxrs subsystem is not added
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6564) show-resources operation of jaxrs subsystem shows wrong path in resource-methods attribute
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6564?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-4387 to WFLY-6564:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6564 (was: JBEAP-4387)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: REST
(was: REST)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.CR2)
> show-resources operation of jaxrs subsystem shows wrong path in resource-methods attribute
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6564
> URL: https://issues.jboss.org/browse/WFLY-6564
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> *Description of problem:*
> Show-resources operation of jaxrs subsystem shows wrong path in resource-methods attribute. There are double slash in path. Eg.: "/jaxrs-eap//sample", but correct path is "/jaxrs-eap/sample" (http://localhost:8080/jaxrs-eap/sample)
> This operation was added by WFLY-3045.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./standalone.sh
> # deploy /home/mkopecky/playground/resteasy/single-application/target/jaxrs-eap.war
> # /deployment=jaxrs-eap.war/subsystem=jaxrs:show-resources
> *Actual results:*
> {noformat}
> ...
> "resource-methods" => ["GET /jaxrs-eap//sample - org.resteasy.simple.deployment.AdvancedService.get()"]
> ...
> {noformat}
> *Expected results:*
> {noformat}
> ...
> "resource-methods" => ["GET /jaxrs-eap/sample - org.resteasy.simple.deployment.AdvancedService.get()"]
> ...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGMGR-135) Create an EmailHandler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-135?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-135:
--------------------------------------
This can be tricky to get right is the main problem. Logging is configured before anything else in the container. You can see in that example that it attempts to initialize from JNDI and if the session can't be initialized nothing is logged. If a failure occurred before the mail subsystem was up and running then the error would never be handled with this handler. Nothing would be logged via this handler until both EJB, JNDI and mail services are started.
I'm not 100% sure, but I think {{org.jboss.ejb.client.naming}} is for remote EJB JNDI lookups. This means that both the EJB and mail subsystems would be required for the log handler to work. Maybe that's not a huge deal.
> Create an EmailHandler
> ----------------------
>
> Key: LOGMGR-135
> URL: https://issues.jboss.org/browse/LOGMGR-135
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.3.Final
> Reporter: Yann Le Tallec
> Labels: task
>
> It would be useful if there were a built-in EmailHandler that uses wildfly/jboss default email service.
> This thread: https://developer.jboss.org/wiki/CreatingACustomLoggingHandlerInJBOSSAs71...
> suggests an approach but having an "official" handler would certainly be more robust.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6522) Mutable session variables do not replicate correctly using non-tx session cache
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6522?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6522:
-------------------------------
Summary: Mutable session variables do not replicate correctly using non-tx session cache (was: Improve support for mutable session variables with non-tx session cache)
> Mutable session variables do not replicate correctly using non-tx session cache
> -------------------------------------------------------------------------------
>
> Key: WFLY-6522
> URL: https://issues.jboss.org/browse/WFLY-6522
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final
>
>
> Currently, mutable session attributes require a transactional cache configuration in order to replicate properly. To support non-tx caches, we can record which mutable session attributes were accessed on a given session and re-set them at the end of the request.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-549) Issue with adding server-group and server-config in one composite operation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-549?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFCORE-549.
-------------------------------------
Resolution: Out of Date
Thanks, Martin.
> Issue with adding server-group and server-config in one composite operation
> ---------------------------------------------------------------------------
>
> Key: WFCORE-549
> URL: https://issues.jboss.org/browse/WFCORE-549
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: JBoss EAP 6.1.0 GA
> DC and two HC
> Reporter: Oleg Koropita
>
> I used such request to add two server-groups and four servers
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "socket-binding-port-offset" => 0,
> "status" => "STOPPED",
> "auto-start" => false,
> "group" => "primary-server-group",
> "socket-binding-group" => "standard-sockets",
> "address" => [
> ("host" => "node02"),
> ("server-config" => "system2-server1")
> ]
> },
> {
> "operation" => "stop",
> "name" => "server",
> "value" => "system2-server1",
> "address" => [
> ("host" => "node02"),
> ("server-config" => "system2-server1")
> ]
> },
> {
> "operation" => "add",
> "socket-binding-port-offset" => 150,
> "status" => "STOPPED",
> "auto-start" => false,
> "group" => "secondary-server-group",
> "socket-binding-group" => "standard-sockets",
> "address" => [
> ("host" => "node02"),
> ("server-config" => "system2-server2")
> ]
> },
> {
> "operation" => "stop",
> "name" => "server",
> "value" => "system2-server2",
> "address" => [
> ("host" => "node02"),
> ("server-config" => "system2-server2")
> ]
> },
> {
> "operation" => "add",
> "socket-binding-port-offset" => 0,
> "status" => "STOPPED",
> "auto-start" => false,
> "group" => "primary-server-group",
> "socket-binding-group" => "standard-sockets",
> "address" => [
> ("host" => "node01"),
> ("server-config" => "system1-server1")
> ]
> },
> {
> "operation" => "stop",
> "name" => "server",
> "value" => "system1-server1",
> "address" => [
> ("host" => "node01"),
> ("server-config" => "system1-server1")
> ]
> },
> {
> "operation" => "add",
> "socket-binding-port-offset" => 150,
> "status" => "STOPPED",
> "auto-start" => false,
> "group" => "secondary-server-group",
> "socket-binding-group" => "standard-sockets",
> "address" => [
> ("host" => "node01"),
> ("server-config" => "system1-server2")
> ]
> },
> {
> "operation" => "stop",
> "name" => "server",
> "value" => "system1-server2",
> "address" => [
> ("host" => "node01"),
> ("server-config" => "system1-server2")
> ]
> },
> {
> "operation" => "add",
> "socket-binding-group" => "standard-sockets",
> "profile" => "default",
> "address" => [("server-group" => "primary-server-group")]
> },
> {
> "operation" => "add",
> "socket-binding-group" => "standard-sockets",
> "profile" => "default",
> "address" => [("server-group" => "secondary-server-group")]
> }
> ]
> }
> And I received such result:
> {
> "outcome" => "success",
> "result" => {
> "step-1" => {"outcome" => "success"},
> "step-2" => {
> "outcome" => "success",
> "result" => "STOPPED"
> },
> "step-3" => {"outcome" => "success"},
> "step-4" => {
> "outcome" => "success",
> "result" => "STOPPED"
> },
> "step-5" => {"outcome" => "success"},
> "step-6" => {
> "outcome" => "success",
> "result" => "STOPPED"
> },
> "step-7" => {"outcome" => "success"},
> "step-8" => {
> "outcome" => "success",
> "result" => "STOPPED"
> },
> "step-9" => undefined,
> "step-10" => undefined
> },
> "server-groups" => undefined
> }
> But, when I checked admin console, there were no server-groups.
> The same with domain.xml on DC side.
> So server-groups wasn't addedd.
> But if I try to add server-groups one more time:
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "socket-binding-group" => "standard-sockets",
> "profile" => "default",
> "address" => [("server-group" => "primary-server-group")]
> },
> {
> "operation" => "add",
> "socket-binding-group" => "standard-sockets",
> "profile" => "default",
> "address" => [("server-group" => "secondary-server-group")]
> }
> ]
> }
> I will get such result:
> {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-2" => {
> "outcome" => "failed",
> "rolled-back" => true
> }
> },
> "failure-description" => {"host-failure-descriptions" => {
> "node02" => {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS014803: Duplicate resource [(\"server-group\" => \"primary-server-group\")]"}},
> "node01" => {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS014803: Duplicate resource [(\"server-group\" => \"primary-server-group\")]"}}
> }},
> "rolled-back" => true
> }
> Then I need to restart DC to restore server. And after that, I can successuflly add server-groups.
> So, after first request, JBoss AS stuck on some uncommited state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-549) Issue with adding server-group and server-config in one composite operation
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFCORE-549?page=com.atlassian.jira.plugin... ]
Martin Simka edited comment on WFCORE-549 at 4/27/16 10:57 AM:
---------------------------------------------------------------
I'm able to reproduce this with EAP 6.1.0, but I'm not with WildFly Core built from master branch. I think this can be closed.
was (Author: simkam):
I'm able to reproduce this with EAP 6.1.0, but I'm not with WildFly Core from master. I think this can be closed.
> Issue with adding server-group and server-config in one composite operation
> ---------------------------------------------------------------------------
>
> Key: WFCORE-549
> URL: https://issues.jboss.org/browse/WFCORE-549
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: JBoss EAP 6.1.0 GA
> DC and two HC
> Reporter: Oleg Koropita
>
> I used such request to add two server-groups and four servers
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "socket-binding-port-offset" => 0,
> "status" => "STOPPED",
> "auto-start" => false,
> "group" => "primary-server-group",
> "socket-binding-group" => "standard-sockets",
> "address" => [
> ("host" => "node02"),
> ("server-config" => "system2-server1")
> ]
> },
> {
> "operation" => "stop",
> "name" => "server",
> "value" => "system2-server1",
> "address" => [
> ("host" => "node02"),
> ("server-config" => "system2-server1")
> ]
> },
> {
> "operation" => "add",
> "socket-binding-port-offset" => 150,
> "status" => "STOPPED",
> "auto-start" => false,
> "group" => "secondary-server-group",
> "socket-binding-group" => "standard-sockets",
> "address" => [
> ("host" => "node02"),
> ("server-config" => "system2-server2")
> ]
> },
> {
> "operation" => "stop",
> "name" => "server",
> "value" => "system2-server2",
> "address" => [
> ("host" => "node02"),
> ("server-config" => "system2-server2")
> ]
> },
> {
> "operation" => "add",
> "socket-binding-port-offset" => 0,
> "status" => "STOPPED",
> "auto-start" => false,
> "group" => "primary-server-group",
> "socket-binding-group" => "standard-sockets",
> "address" => [
> ("host" => "node01"),
> ("server-config" => "system1-server1")
> ]
> },
> {
> "operation" => "stop",
> "name" => "server",
> "value" => "system1-server1",
> "address" => [
> ("host" => "node01"),
> ("server-config" => "system1-server1")
> ]
> },
> {
> "operation" => "add",
> "socket-binding-port-offset" => 150,
> "status" => "STOPPED",
> "auto-start" => false,
> "group" => "secondary-server-group",
> "socket-binding-group" => "standard-sockets",
> "address" => [
> ("host" => "node01"),
> ("server-config" => "system1-server2")
> ]
> },
> {
> "operation" => "stop",
> "name" => "server",
> "value" => "system1-server2",
> "address" => [
> ("host" => "node01"),
> ("server-config" => "system1-server2")
> ]
> },
> {
> "operation" => "add",
> "socket-binding-group" => "standard-sockets",
> "profile" => "default",
> "address" => [("server-group" => "primary-server-group")]
> },
> {
> "operation" => "add",
> "socket-binding-group" => "standard-sockets",
> "profile" => "default",
> "address" => [("server-group" => "secondary-server-group")]
> }
> ]
> }
> And I received such result:
> {
> "outcome" => "success",
> "result" => {
> "step-1" => {"outcome" => "success"},
> "step-2" => {
> "outcome" => "success",
> "result" => "STOPPED"
> },
> "step-3" => {"outcome" => "success"},
> "step-4" => {
> "outcome" => "success",
> "result" => "STOPPED"
> },
> "step-5" => {"outcome" => "success"},
> "step-6" => {
> "outcome" => "success",
> "result" => "STOPPED"
> },
> "step-7" => {"outcome" => "success"},
> "step-8" => {
> "outcome" => "success",
> "result" => "STOPPED"
> },
> "step-9" => undefined,
> "step-10" => undefined
> },
> "server-groups" => undefined
> }
> But, when I checked admin console, there were no server-groups.
> The same with domain.xml on DC side.
> So server-groups wasn't addedd.
> But if I try to add server-groups one more time:
> {
> "operation" => "composite",
> "address" => [],
> "steps" => [
> {
> "operation" => "add",
> "socket-binding-group" => "standard-sockets",
> "profile" => "default",
> "address" => [("server-group" => "primary-server-group")]
> },
> {
> "operation" => "add",
> "socket-binding-group" => "standard-sockets",
> "profile" => "default",
> "address" => [("server-group" => "secondary-server-group")]
> }
> ]
> }
> I will get such result:
> {
> "outcome" => "failed",
> "result" => {
> "step-1" => {
> "outcome" => "failed",
> "rolled-back" => true
> },
> "step-2" => {
> "outcome" => "failed",
> "rolled-back" => true
> }
> },
> "failure-description" => {"host-failure-descriptions" => {
> "node02" => {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS014803: Duplicate resource [(\"server-group\" => \"primary-server-group\")]"}},
> "node01" => {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS014803: Duplicate resource [(\"server-group\" => \"primary-server-group\")]"}}
> }},
> "rolled-back" => true
> }
> Then I need to restart DC to restore server. And after that, I can successuflly add server-groups.
> So, after first request, JBoss AS stuck on some uncommited state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years