[JBoss JIRA] (WFLY-8731) Unable to inject EJBs into web resources
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8731?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-8731:
--------------------------------------
I just had a quick look at your reproducer and it looks like you are trying to inject java:comp/EJBContext into a non-EJB and this is why it is failing (which is expected)?
If not you are going to need to provide exact details, this definitely works. It has extensive tests and is widely used.
> Unable to inject EJBs into web resources
> ----------------------------------------
>
> Key: WFLY-8731
> URL: https://issues.jboss.org/browse/WFLY-8731
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: WildFly 10.0 on Windows 10
> Reporter: Archimedes Trajano
> Assignee: Stuart Douglas
>
> There's an old bug on https://issues.jboss.org/browse/JBAS-8818 that talks about this issue on JBoss, but it still applies on WildFly up until now.
> Their comment was based on just WebListener, but I found it applied to the following as well
> * WebServlet
> * WebService (code first and contract first)
> * JAX-RS paths.
> One other thing to note, converting to @EJB from @Inject created another problem, but I'd rather get @Inject working first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2995) WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2995?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-2995:
---------------------------------------
Ah yes because both {{System.out}} and {{System.err}} are wrapped in loggers. This is so applications that use {{System.xxx.print}} will still see the messages if the console is disabled. So you'd only see this if in your logging configuration you're using a console handler/appender.
One, not ideal, option is to add a logger named {{stdout}} and have it only use a {{%s%n}} pattern. Again I realize this is not ideal, but will get around that issue.
> WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2995
> URL: https://issues.jboss.org/browse/WFCORE-2995
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Geoffrey De Smet
> Assignee: James Perkins
>
> Wildfly currently supports the following _Per deployment logging_ configurations [1]:
> logging.properties
> jboss-logging.properties
> log4j.properties
> log4j.xml
> jboss-log4j.xml
> All of these are stale because they are based on Log4j 1.x format which died about 8 years ago (along with using properties files for logging configuration).
> Modern popular options include Logback (with SLF4J), JBoss Logging and Log4j 2.x.
> *I regularly see WildFly users (included RH employees) that struggle to configure the logging configuration of their WildFly apps.* Spring Boot does not have this problem. _To fix this, WildFly should support logback.xml for Per deployment logging too._
> When I add a logback.xml in my war's WEB-INF/classes directory and explicitly add the logback-classic.jar in WEB-INF/lib directory - which works to configure Logback in any other JVM - then WildFly ignores it (~ it says GFY). My logs doesn't show up and developing on WildfFly is a pain due to blindness.
> Fake solution: Configuring the log files per WildFly installation is not practical for developers (it is for sys admins): the log configuration should be in my war's sources on github, so other developers automatically have it without needing to jump to wildfly installation hoops (which is sometimes not possible, think OpenShift).
> Although it's ok that WildFly favors JBoss Logging, it should not dictate it and support other logging systems such as Logback too for the war files at least (= per deployment).
> [1] https://docs.jboss.org/author/display/WFLY10/Logging+Configuration
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2995) WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2995?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on WFCORE-2995:
------------------------------------------
Hi James, thanks for looking into this.
I did originally exclude the logging subsystem in jboss-deployment-structure.xml, but then I got logging like this in my console:
{code}
10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124984), time spent (29999), score (0hard/200soft), best score (0hard/240soft), accepted/selected move count (1/12), picked move (Lights 2017-02-01T06:00-14:00 {Gus Rye -> Dan King}).
10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124985), time spent (29999), score (0hard/200soft), best score (0hard/240soft), accepted/selected move count (1/27), picked move (Engine 2017-02-02T14:00-22:00 {Hugo Watt} <-> Sunroof 2017-02-02T14:00-22:00 {Dan Li}).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124986), time spent (30000), score (-1hard/200soft), best score (0hard/240soft), accepted/selected move count (0/38), picked move (Sunroof 2017-02-01T06:00-14:00 {Flo Poe} <-> Lights 2017-02-01T14:00-22:00 {Ivy Watt}).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] INFO Local Search phase (1) ended: time spent (30000), best score (0hard/240soft), score calculation speed (66502/sec), step total (124987).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] INFO Solving ended: time spent (30000), best score (0hard/240soft), score calculation speed (65469/sec), phase total (2), environment mode (REPRODUCIBLE).
{code}
Every line says the time, level and thread twice.
The {code}10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1){code} prefix is from JBoss and shouldn't be there, so it only has the logback pattern {code}2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG ...{code}
> WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2995
> URL: https://issues.jboss.org/browse/WFCORE-2995
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Geoffrey De Smet
> Assignee: James Perkins
>
> Wildfly currently supports the following _Per deployment logging_ configurations [1]:
> logging.properties
> jboss-logging.properties
> log4j.properties
> log4j.xml
> jboss-log4j.xml
> All of these are stale because they are based on Log4j 1.x format which died about 8 years ago (along with using properties files for logging configuration).
> Modern popular options include Logback (with SLF4J), JBoss Logging and Log4j 2.x.
> *I regularly see WildFly users (included RH employees) that struggle to configure the logging configuration of their WildFly apps.* Spring Boot does not have this problem. _To fix this, WildFly should support logback.xml for Per deployment logging too._
> When I add a logback.xml in my war's WEB-INF/classes directory and explicitly add the logback-classic.jar in WEB-INF/lib directory - which works to configure Logback in any other JVM - then WildFly ignores it (~ it says GFY). My logs doesn't show up and developing on WildfFly is a pain due to blindness.
> Fake solution: Configuring the log files per WildFly installation is not practical for developers (it is for sys admins): the log configuration should be in my war's sources on github, so other developers automatically have it without needing to jump to wildfly installation hoops (which is sometimes not possible, think OpenShift).
> Although it's ok that WildFly favors JBoss Logging, it should not dictate it and support other logging systems such as Logback too for the war files at least (= per deployment).
> [1] https://docs.jboss.org/author/display/WFLY10/Logging+Configuration
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2995) WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2995?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet edited comment on WFCORE-2995 at 6/21/17 6:50 PM:
-------------------------------------------------------------------
Hi James, thanks for looking into this.
I did originally exclude the logging subsystem in jboss-deployment-structure.xml, but then I got logging like this in my console:
{code}
10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124984), time spent (29999), score (0hard/200soft), best score (0hard/240soft), accepted/selected move count (1/12), picked move (Lights 2017-02-01T06:00-14:00 {Gus Rye -> Dan King}).
10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124985), time spent (29999), score (0hard/200soft), best score (0hard/240soft), accepted/selected move count (1/27), picked move (Engine 2017-02-02T14:00-22:00 {Hugo Watt} <-> Sunroof 2017-02-02T14:00-22:00 {Dan Li}).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124986), time spent (30000), score (-1hard/200soft), best score (0hard/240soft), accepted/selected move count (0/38), picked move (Sunroof 2017-02-01T06:00-14:00 {Flo Poe} <-> Lights 2017-02-01T14:00-22:00 {Ivy Watt}).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] INFO Local Search phase (1) ended: time spent (30000), best score (0hard/240soft), score calculation speed (66502/sec), step total (124987).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] INFO Solving ended: time spent (30000), best score (0hard/240soft), score calculation speed (65469/sec), phase total (2), environment mode (REPRODUCIBLE).
{code}
Every line says the time, level and thread twice.
The {{10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1)}} prefix is from JBoss and shouldn't be there, so it only has the logback pattern {{2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG ...}}
was (Author: ge0ffrey):
Hi James, thanks for looking into this.
I did originally exclude the logging subsystem in jboss-deployment-structure.xml, but then I got logging like this in my console:
{code}
10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124984), time spent (29999), score (0hard/200soft), best score (0hard/240soft), accepted/selected move count (1/12), picked move (Lights 2017-02-01T06:00-14:00 {Gus Rye -> Dan King}).
10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124985), time spent (29999), score (0hard/200soft), best score (0hard/240soft), accepted/selected move count (1/27), picked move (Engine 2017-02-02T14:00-22:00 {Hugo Watt} <-> Sunroof 2017-02-02T14:00-22:00 {Dan Li}).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] DEBUG LS step (124986), time spent (30000), score (-1hard/200soft), best score (0hard/240soft), accepted/selected move count (0/38), picked move (Sunroof 2017-02-01T06:00-14:00 {Flo Poe} <-> Lights 2017-02-01T14:00-22:00 {Ivy Watt}).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] INFO Local Search phase (1) ended: time spent (30000), best score (0hard/240soft), score calculation speed (66502/sec), step total (124987).
10:42:20,437 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1) 2017-06-21 10:42:20,437 [EE-ManagedExecutorService-default-Thread-1] INFO Solving ended: time spent (30000), best score (0hard/240soft), score calculation speed (65469/sec), phase total (2), environment mode (REPRODUCIBLE).
{code}
Every line says the time, level and thread twice.
The {code}10:42:20,436 INFO [stdout] (EE-ManagedExecutorService-default-Thread-1){code} prefix is from JBoss and shouldn't be there, so it only has the logback pattern {code}2017-06-21 10:42:20,436 [EE-ManagedExecutorService-default-Thread-1] DEBUG ...{code}
> WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2995
> URL: https://issues.jboss.org/browse/WFCORE-2995
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Geoffrey De Smet
> Assignee: James Perkins
>
> Wildfly currently supports the following _Per deployment logging_ configurations [1]:
> logging.properties
> jboss-logging.properties
> log4j.properties
> log4j.xml
> jboss-log4j.xml
> All of these are stale because they are based on Log4j 1.x format which died about 8 years ago (along with using properties files for logging configuration).
> Modern popular options include Logback (with SLF4J), JBoss Logging and Log4j 2.x.
> *I regularly see WildFly users (included RH employees) that struggle to configure the logging configuration of their WildFly apps.* Spring Boot does not have this problem. _To fix this, WildFly should support logback.xml for Per deployment logging too._
> When I add a logback.xml in my war's WEB-INF/classes directory and explicitly add the logback-classic.jar in WEB-INF/lib directory - which works to configure Logback in any other JVM - then WildFly ignores it (~ it says GFY). My logs doesn't show up and developing on WildfFly is a pain due to blindness.
> Fake solution: Configuring the log files per WildFly installation is not practical for developers (it is for sys admins): the log configuration should be in my war's sources on github, so other developers automatically have it without needing to jump to wildfly installation hoops (which is sometimes not possible, think OpenShift).
> Although it's ok that WildFly favors JBoss Logging, it should not dictate it and support other logging systems such as Logback too for the war files at least (= per deployment).
> [1] https://docs.jboss.org/author/display/WFLY10/Logging+Configuration
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2996) Re-Use Named Log-Formatter In Logging Profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2996?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-2996:
---------------------------------------
This is because a logging profile uses a new context. Currently the log contexts are completely separate and don't share any state or configuration. In other words a logging-profile is essentially it's own logging "subsystem". You have to define anything you need in the {{logging-profile}} in the profile itself.
> Re-Use Named Log-Formatter In Logging Profile
> ---------------------------------------------
>
> Key: WFCORE-2996
> URL: https://issues.jboss.org/browse/WFCORE-2996
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging
> Reporter: Markus May
> Assignee: James Perkins
> Priority: Critical
>
> Right now, if I try to re-use the globally defined Named-Formatter "PATTERN" in my own logging profile, I do get an error-message stating that the Formatter "PATTERN" is not found.
> To be able to re-use the same Formatter in all logging-profiles, it would be good, to be able to use these globally defined Formatters.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2996) Re-Use Named Log-Formatter In Logging Profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2996?page=com.atlassian.jira.plugi... ]
James Perkins moved JBLOGGING-128 to WFCORE-2996:
-------------------------------------------------
Project: WildFly Core (was: JBoss Logging)
Key: WFCORE-2996 (was: JBLOGGING-128)
Component/s: Logging
(was: jboss-logging-logmanager)
> Re-Use Named Log-Formatter In Logging Profile
> ---------------------------------------------
>
> Key: WFCORE-2996
> URL: https://issues.jboss.org/browse/WFCORE-2996
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging
> Reporter: Markus May
> Assignee: James Perkins
> Priority: Critical
>
> Right now, if I try to re-use the globally defined Named-Formatter "PATTERN" in my own logging profile, I do get an error-message stating that the Formatter "PATTERN" is not found.
> To be able to re-use the same Formatter in all logging-profiles, it would be good, to be able to use these globally defined Formatters.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (LOGMGR-162) WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-162?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-162:
--------------------------------------
The problem is logback is a log manager as is the JBoss Log Manager. To get WildFly to work with log4j we forked log4j and replaced the log manager parts to delegate to the JBoss Log Manager. In order to get this to work log4j2 or logback we'd have to do the same type of thing.
However there is a chance we could attempt to check if a logback-*.jar is present in the deployment along with a logback and disable WildFly logging for that deployment. You'd also have to ensure you include any logging facades being used too, e.g. slf4j, jboss-logging, etc.
The simplest solution for now is to exclude the logging subsystem in a {{jboss-deployment-structure.xml}}. That would stop WildFly adding any explicit logging dependencies to your deployment.
> WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
> -------------------------------------------------------------------------------------------------
>
> Key: LOGMGR-162
> URL: https://issues.jboss.org/browse/LOGMGR-162
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Reporter: Geoffrey De Smet
>
> Wildfly currently supports the following _Per deployment logging_ configurations [1]:
> logging.properties
> jboss-logging.properties
> log4j.properties
> log4j.xml
> jboss-log4j.xml
> All of these are stale because they are based on Log4j 1.x format which died about 8 years ago (along with using properties files for logging configuration).
> Modern popular options include Logback (with SLF4J), JBoss Logging and Log4j 2.x.
> *I regularly see WildFly users (included RH employees) that struggle to configure the logging configuration of their WildFly apps.* Spring Boot does not have this problem. _To fix this, WildFly should support logback.xml for Per deployment logging too._
> When I add a logback.xml in my war's WEB-INF/classes directory and explicitly add the logback-classic.jar in WEB-INF/lib directory - which works to configure Logback in any other JVM - then WildFly ignores it (~ it says GFY). My logs doesn't show up and developing on WildfFly is a pain due to blindness.
> Fake solution: Configuring the log files per WildFly installation is not practical for developers (it is for sys admins): the log configuration should be in my war's sources on github, so other developers automatically have it without needing to jump to wildfly installation hoops (which is sometimes not possible, think OpenShift).
> Although it's ok that WildFly favors JBoss Logging, it should not dictate it and support other logging systems such as Logback too for the war files at least (= per deployment).
> [1] https://docs.jboss.org/author/display/WFLY10/Logging+Configuration
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2995) WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2995?page=com.atlassian.jira.plugi... ]
James Perkins moved LOGMGR-162 to WFCORE-2995:
----------------------------------------------
Project: WildFly Core (was: JBoss Log Manager)
Key: WFCORE-2995 (was: LOGMGR-162)
Component/s: Logging
(was: core)
> WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2995
> URL: https://issues.jboss.org/browse/WFCORE-2995
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Geoffrey De Smet
>
> Wildfly currently supports the following _Per deployment logging_ configurations [1]:
> logging.properties
> jboss-logging.properties
> log4j.properties
> log4j.xml
> jboss-log4j.xml
> All of these are stale because they are based on Log4j 1.x format which died about 8 years ago (along with using properties files for logging configuration).
> Modern popular options include Logback (with SLF4J), JBoss Logging and Log4j 2.x.
> *I regularly see WildFly users (included RH employees) that struggle to configure the logging configuration of their WildFly apps.* Spring Boot does not have this problem. _To fix this, WildFly should support logback.xml for Per deployment logging too._
> When I add a logback.xml in my war's WEB-INF/classes directory and explicitly add the logback-classic.jar in WEB-INF/lib directory - which works to configure Logback in any other JVM - then WildFly ignores it (~ it says GFY). My logs doesn't show up and developing on WildfFly is a pain due to blindness.
> Fake solution: Configuring the log files per WildFly installation is not practical for developers (it is for sys admins): the log configuration should be in my war's sources on github, so other developers automatically have it without needing to jump to wildfly installation hoops (which is sometimes not possible, think OpenShift).
> Although it's ok that WildFly favors JBoss Logging, it should not dictate it and support other logging systems such as Logback too for the war files at least (= per deployment).
> [1] https://docs.jboss.org/author/display/WFLY10/Logging+Configuration
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years