[JBoss JIRA] (WFLY-4185) Using annotated servlet listeners from modules
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4185?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4185:
--------------------------------------
Note that the test case still does not pass with this change, but fails with a different error
> Using annotated servlet listeners from modules
> ----------------------------------------------
>
> Key: WFLY-4185
> URL: https://issues.jboss.org/browse/WFLY-4185
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.0.Alpha1
> Reporter: Pedro Igor
> Assignee: Stuart Douglas
>
> PicketLink provides support for Http Security. Basically, it consists of an API to define security policies to the paths or resources of an application and a security filter (servlet filter) that is responsible to enforce those policies for every single request.
> The security filter is installed from a specific ServletContextListener (org.picketlink.http.internal.PicketLinkServletContextListener) that checks if the application has defined any security policy in order to decide if the filter must be installed or not.
> PicketLink also defines a ServletRequestListener (org.picketlink.http.internal.HttpServletRequestListener) that is used to produce a decorated HttpServletRequest instance. This decorated instance provides full integration between PL and the HttpServletRequest security methods plus some other goodies for PL users such as URL rewriting, etc.
> Both listeners (servletcontext and request) are CDI beans with injection points and/or producer methods.
> When using PL from modules, the producer method of org.picketlink.http.internal.HttpServletRequestListener#produce is not being recognized. And that makes impossible to use PL from modules.
> The same code works if you use PL jars inside the deployment.
> Another interesting behavior is that EAP and WildFly are behaving differently. In EAP (latest build), the ServletContextListener is only recognized as a CDI bean if you define it in the web.xml. While in WildFly this is not necessary.
> Also, in EAP the producer method of HttpServletRequestListener is properly recognized and everything works fine.
> I've created a branch [1] to test this issue. The test case is {code}org.wildfly.test.integration.security.picketlink.core.http.ServletListenerFromModuleTestCase{code}.
> [1] https://github.com/pedroigor/wildfly/tree/WFLY-4185
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-484) OperationContext.getResourceRegistrationForUpdate().registerAlias(...) throws AssertionError
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-484?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFCORE-484:
--------------------------------
Description:
OperationContext.getResourceRegistrationForUpdate().registerAlias(...) throws the following:
{noformat}
java.lang.AssertionError: Unknown alias type
at org.jboss.as.controller.registry.AbstractResourceRegistration.registerAlias(AbstractResourceRegistration.java:503)
at org.jboss.as.controller.registry.DelegatingManagementResourceRegistration.registerAlias(DelegatingManagementResourceRegistration.java:310)
at org.jboss.as.clustering.jgroups.subsystem.TransportResourceDefinition$5$1.execute(TransportResourceDefinition.java:360)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:728)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:563)
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:336)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:312)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1163)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:421)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:304)
at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:256)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:299)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:266)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This is because OperationContext.getResourceRegistrationForUpdate() returns a DelegatingManagementResourceRegistration, which does not extend AbstractResourceRegistration - so the assertion fails.
Is there a technical reason why this should not work?
was:
OperationContext.getResourceRegistrationForUpdate().registerAlias(...) throws the following:
{noformat}
java.lang.AssertionError: Unknown alias type
at org.jboss.as.controller.registry.AbstractResourceRegistration.registerAlias(AbstractResourceRegistration.java:503)
at org.jboss.as.controller.registry.DelegatingManagementResourceRegistration.registerAlias(DelegatingManagementResourceRegistration.java:310)
at org.jboss.as.clustering.jgroups.subsystem.TransportResourceDefinition$5$1.execute(TransportResourceDefinition.java:360)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:728)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:563)
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:336)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:312)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1163)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:421)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:304)
at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:256)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:299)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:266)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This is because OperationContext.getResourceRegistrationForUpdate() returns a DelegatingManagementResourceRegistration, which does not extend AbstractResourceRegistration - so the assertion fails.
> OperationContext.getResourceRegistrationForUpdate().registerAlias(...) throws AssertionError
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-484
> URL: https://issues.jboss.org/browse/WFCORE-484
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha14
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> OperationContext.getResourceRegistrationForUpdate().registerAlias(...) throws the following:
> {noformat}
> java.lang.AssertionError: Unknown alias type
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerAlias(AbstractResourceRegistration.java:503)
> at org.jboss.as.controller.registry.DelegatingManagementResourceRegistration.registerAlias(DelegatingManagementResourceRegistration.java:310)
> at org.jboss.as.clustering.jgroups.subsystem.TransportResourceDefinition$5$1.execute(TransportResourceDefinition.java:360)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:728)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:563)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:336)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:312)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1163)
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:421)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:304)
> at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:256)
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:299)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:266)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is because OperationContext.getResourceRegistrationForUpdate() returns a DelegatingManagementResourceRegistration, which does not extend AbstractResourceRegistration - so the assertion fails.
> Is there a technical reason why this should not work?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-484) OperationContext.getResourceRegistrationForUpdate().registerAlias(...) throws AssertionError
by Paul Ferraro (JIRA)
Paul Ferraro created WFCORE-484:
-----------------------------------
Summary: OperationContext.getResourceRegistrationForUpdate().registerAlias(...) throws AssertionError
Key: WFCORE-484
URL: https://issues.jboss.org/browse/WFCORE-484
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Alpha14
Reporter: Paul Ferraro
Assignee: Brian Stansberry
OperationContext.getResourceRegistrationForUpdate().registerAlias(...) throws the following:
{noformat}
java.lang.AssertionError: Unknown alias type
at org.jboss.as.controller.registry.AbstractResourceRegistration.registerAlias(AbstractResourceRegistration.java:503)
at org.jboss.as.controller.registry.DelegatingManagementResourceRegistration.registerAlias(DelegatingManagementResourceRegistration.java:310)
at org.jboss.as.clustering.jgroups.subsystem.TransportResourceDefinition$5$1.execute(TransportResourceDefinition.java:360)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:728)
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:563)
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:336)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:312)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1163)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:421)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:304)
at org.jboss.as.model.test.ModelTestModelControllerService.boot(ModelTestModelControllerService.java:256)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:299)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:266)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This is because OperationContext.getResourceRegistrationForUpdate() returns a DelegatingManagementResourceRegistration, which does not extend AbstractResourceRegistration - so the assertion fails.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-1126) Create ability to turn on logging levels per subsystem
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1126?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-1126.
-------------------------------
Resolution: Won't Fix
This is to vague. Subsystems would likely have to know about dependency logger names and turn some of those on as well. For example the jpa subsystem might want to turn on Hibernate log levels. Doesn't seem like a viable solution. Logger names should be defined in the documentation.
> Create ability to turn on logging levels per subsystem
> ------------------------------------------------------
>
> Key: WFLY-1126
> URL: https://issues.jboss.org/browse/WFLY-1126
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Possibly edit the change-level operation to accept a subsystem name, e.g. jpa, and enable the specified level for all the JPA categories.
> {code}
> /subsystem=logging:change-level(level=TRACE,subsystem=jpa)
> {code}
> More thought needs to go into this though. If the categories are already defined, changing them could cause confusion.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-483) Allow hooking into logging subsystem through Management API
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-483?page=com.atlassian.jira.plugin... ]
James Perkins moved WFLY-1048 to WFCORE-483:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-483 (was: WFLY-1048)
Component/s: Logging
(was: Logging)
> Allow hooking into logging subsystem through Management API
> -----------------------------------------------------------
>
> Key: WFCORE-483
> URL: https://issues.jboss.org/browse/WFCORE-483
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Ondrej Zizka
> Assignee: James Perkins
> Labels: logging
>
> Provide a way to poll log messages through the management API.
> Could be then used in the AS console. Some kind of detached window, or perhaps tab, with log, perhaps pushed through Servlet 3.2's onDataAvailable() ...
> Note that this is different from AS7-2213, which needs AS to keep some history. This doesn't.
> BTW, JBDS gets the logs through SSH, because the AS may fail booting before anything is able to hook in like this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
James Perkins moved WFLY-1037 to WFCORE-482:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-482 (was: WFLY-1037)
Component/s: Logging
(was: Logging)
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.jboss.org/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-481) Logging async-handler improvement - report number dropped logs
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-481?page=com.atlassian.jira.plugin... ]
James Perkins moved WFLY-4178 to WFCORE-481:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-481 (was: WFLY-4178)
Affects Version/s: (was: 8.0.0.Final)
Component/s: Logging
(was: Logging)
> Logging async-handler improvement - report number dropped logs
> --------------------------------------------------------------
>
> Key: WFCORE-481
> URL: https://issues.jboss.org/browse/WFCORE-481
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging
> Reporter: Todd Sandor
> Assignee: James Perkins
>
> The functional requirement is to know when logs are discarded and the number of logs discarded.
> When using a async-handler such as the one below, we do not know if/when logs are discarded, thousands could be dropped and we do not know it.
> <async-handler name="ASYNC">
> <queue-length value="300000"/>
> <overflow-action value="discard"/>
> <subhandlers>
> <handler name="FILE"/>
> </subhandlers>
> </async-handler>
> Potential solution/suggestion:
> Add a new property, call it max-discard-logs, with a default value of 1 - uses existing behavior when = 1 (when queue full, drop any new log).
> When > 1 and queue is full, at least max-discard-logs logs are removed from the queue and display a log indicating the queue is full an N logs were dropped.
> <async-handler name="ASYNC">
> <queue-length value="300000"/>
> <overflow-action value="discard"/>
> <max-discard-logs value="1000"/>
> <subhandlers>
> <handler name="FILE"/>
> </subhandlers>
> </async-handler>
> Depending upon the type of queue being used in the implementation, this could be a very simple change.
> e.g
> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/BlockingQu...
> int drainTo(Collection<? super E> c, int maxElements)
> Removes at most the given number of available elements from this queue and adds them to the given collection.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFCORE-480) Create more/better testing for custom logging handlers
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-480?page=com.atlassian.jira.plugin... ]
James Perkins moved WFLY-1579 to WFCORE-480:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-480 (was: WFLY-1579)
Component/s: Logging
(was: Logging)
> Create more/better testing for custom logging handlers
> ------------------------------------------------------
>
> Key: WFCORE-480
> URL: https://issues.jboss.org/browse/WFCORE-480
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> Custom handlers cannot be test in normal subsystem tests as they require a JBoss Modules class loader. A way to either launch surfire with JBoss Modules looked at or more and better ARQ tests need to be written. There have been several issues specifically around log4j appenders as custom handlers.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years