[JBoss JIRA] (WFLY-2611) Unify JSF action listener and CDI integration
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Description:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/actionlist.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
was:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
> Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/actionlist.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (WFLY-1380) Undertow: Error initialize the net.jawr.web.servlet.JawrServlet with undertow
by Laszlo Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-1380?page=com.atlassian.jira.plugin.... ]
Laszlo Varga commented on WFLY-1380:
------------------------------------
I have the same error message, but not with Liferay.
Do you use drw spring integration? In case yes, this might cause the problem.
> Undertow: Error initialize the net.jawr.web.servlet.JawrServlet with undertow
> -----------------------------------------------------------------------------
>
> Key: WFLY-1380
> URL: https://issues.jboss.org/browse/WFLY-1380
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Igor Shulika
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> I'm deploying a OSGi WAB file on the latest WildFly 8.0.0.Alpha2-SNAPSHOT server. Can not initialize the JavascriptServlet from JAWR Bundle. Note: When I used the <extension module="org.jboss.as.web"/> insted of <extension module="org.wildfly.extension.undertow"/> it works.
> Please see error trace below.
> Thanks!
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Jawr servlet with name JavascriptServlet failed to initialize properly.
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Cause:
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Illegal char <:> at index 3: dwr:WebServiceDocService: java.nio.file.InvalidPathException: Illegal char <:> at index 3: dwr:WebServiceDocService
> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255) [rt.jar:1.7.0_21]
> at sun.nio.fs.AbstractPath.resolve(AbstractPath.java:53) [rt.jar:1.7.0_21]
> at io.undertow.server.handlers.resource.FileResourceManager.getResource(FileResourceManager.java:57) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.resource.CachingResourceManager.getResource(CachingResourceManager.java:68) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.ServletContextImpl.getResourceAsStream(ServletContextImpl.java:175) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at net.jawr.web.resource.handler.reader.ServletContextResourceReader.getResource(ServletContextResourceReader.java:70) [ServletContextResourceReader.class:]
> at net.jawr.web.resource.handler.reader.ServletContextResourceReaderHandler.getResource(ServletContextResourceReaderHandler.java:192) [ServletContextResourceReaderHandler.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostprocessBundle(ResourceBundlesHandlerImpl.java:892) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostProcessBundle(ResourceBundlesHandlerImpl.java:835) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndStoreBundle(ResourceBundlesHandlerImpl.java:766) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.initAllBundles(ResourceBundlesHandlerImpl.java:542) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.CachedResourceBundlesHandler.initAllBundles(CachedResourceBundlesHandler.java:126) [CachedResourceBundlesHandler.class:]
> at net.jawr.web.resource.bundle.factory.BundlesHandlerFactory.buildResourceBundlesHandler(BundlesHandlerFactory.java:233) [BundlesHandlerFactory.class:]
> at net.jawr.web.resource.bundle.factory.PropertiesBasedBundlesHandlerFactory.buildResourceBundlesHandler(PropertiesBasedBundlesHandlerFactory.java:204) [PropertiesBasedBundlesHandlerFactory.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initializeJawrConfig(JawrRequestHandler.java:349) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initRequestHandler(JawrRequestHandler.java:262) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.<init>(JawrRequestHandler.java:184) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrServlet.init(JawrServlet.java:56) [JawrServlet.class:]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244) [jboss-servlet-api_3.1_spec-1.0.0.Alpha1.jar:1.0.0.Alpha1]
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:145) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:62) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:599) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:77)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1376:
------------------------------------------
I don't see this issue with Undertow 1.0.0.CR1 in the latest WildFly snapshot
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
> Key: WFLY-1376
> URL: https://issues.jboss.org/browse/WFLY-1376
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
> <error-page>
> <error-code>404</error-code>
> <location>/error/pageNotFound.jsf</location>
> </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (DROOLS-410) Drools invokes superclass static method
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-410?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-410:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1057550|https://bugzilla.redhat.com/show_bug.cgi?id=1057550] from ASSIGNED to MODIFIED
> Drools invokes superclass static method
> ---------------------------------------
>
> Key: DROOLS-410
> URL: https://issues.jboss.org/browse/DROOLS-410
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Michaël Mathieu
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta1
>
>
> For a very simple rule, with same parameter, the result is sometimes different.
> Drools invokes superclass static method.
> {code}
> package test;
> public class ARef {
> private String ref;
> protected ARef(String ref) {
> this.ref = ref;
> }
> public static ARef valueOf(String ref) {
> System.out.println("ARef> " + ref);
> return new ARef(ref);
> }
> @Override
> public String toString() {
> return ref;
> }
> @Override
> public int hashCode() {
> final int prime = 31;
> int result = 1;
> result = prime * result + ((ref == null) ? 0 : ref.hashCode());
> return result;
> }
> @Override
> public boolean equals(Object obj) {
> if (this == obj) return true;
> if (obj == null) return false;
> if (getClass() != obj.getClass()) return false;
> ARef other = (ARef) obj;
> if (ref == null) {
> if (other.ref != null) return false;
> } else if (!ref.equals(other.ref)) return false;
> return true;
> }
> }
> {code}
> {code}
> package test;
> public class BRef extends ARef {
> private BRef(String ref) {
> super(ref);
> }
> public static BRef valueOf(String ref) {
> System.out.println("BRef> " + ref);
> return new BRef(ref);
> }
> }
> {code}
> {code}
> package test;
> public class Criteria {
> private BRef ref;
> private boolean ok = false;
> public Criteria(BRef ref) {
> this.ref = ref;
> }
> public BRef getRef() {
> return ref;
> }
> public boolean isOk() {
> return ok;
> }
> public void setOk() {
> this.ok = true;
> }
> }
> {code}
> {code}
> package test;
> import java.io.StringReader;
> import org.drools.RuleBase;
> import org.drools.RuleBaseFactory;
> import org.drools.StatelessSession;
> import org.drools.compiler.PackageBuilder;
> import org.drools.rule.Package;
> public class Test {
> private static final String DRL = "package test\r\n" + "dialect \"mvel\"\r\n" + "import test.*;\r\n" + "rule \"myRule\"\r\n" + "when\r\n"
> + " criteria:Criteria(ref == BRef.valueOf(\"toto\"))\r\n" + "then\r\n" + " criteria.setOk();\r\n" + "end";
> public static void main(String[] args) {
> System.out.println(DRL);
> try {
> PackageBuilder builder = new PackageBuilder();
> builder.addPackageFromDrl(new StringReader(DRL));
> Package pkg = builder.getPackage();
> RuleBase ruleBase = RuleBaseFactory.newRuleBase();
> ruleBase.addPackage(pkg);
> for (int i = 0; i < 1000; i++) {
> Criteria criteria = new Criteria(BRef.valueOf("toto"));
> StatelessSession session = ruleBase.newStatelessSession();
> session.execute(criteria);
> System.out.println("[" + i + "] " + criteria.isOk());
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> {code}
> Output:
> {code}
> package test
> dialect "mvel"
> import test.*;
> rule "myRule"
> when
> criteria:Criteria(ref == BRef.valueOf("toto"))
> then
> criteria.setOk();
> end
> BRef> toto
> BRef> toto
> BRef> toto
> [0] true
> BRef> toto
> BRef> toto
> [1] true
> BRef> toto
> BRef> toto
> [2] true
> ...
> BRef> toto
> ARef> toto
> [109] false
> BRef> toto
> ARef> toto
> [110] false
> ...
> BRef> toto
> ARef> toto
> [998] false
> BRef> toto
> ARef> toto
> [999] false
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (JBLOGGING-95) Add Logger/LoggerProvider to support new Log4j 2 to improve performance
by Nicholas Williams (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-95?page=com.atlassian.jira.plug... ]
Nicholas Williams edited comment on JBLOGGING-95 at 2/2/14 2:46 PM:
--------------------------------------------------------------------
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. I'd at least like to get 3.2.0.Beta1 rolling in the next week or two. There haven't been many changes at all to this version. :-)
Is there anything I can do to help move things along?
was (Author: beamerblvd):
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. :-)
Is there anything I can do to help move things along?
> Add Logger/LoggerProvider to support new Log4j 2 to improve performance
> -----------------------------------------------------------------------
>
> Key: JBLOGGING-95
> URL: https://issues.jboss.org/browse/JBLOGGING-95
> Project: JBoss Logging
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: jboss-logging-spi
> Affects Versions: 3.2.0.Beta1
> Reporter: Nicholas Williams
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 3.2.0.Beta1
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> The new Log4j 2 project will be released soon. It has major improvements over Log4j and Logback. Currently, JBoss Logging can log to Log4j 2 indirectly by way of SLF4J (if the log4j-slf4j artifact is on the classpath) or the Log4j 1.2 API (if the log4j-1.2-api artifact is on the classpath and when JBLOGGING-94 is fixed). However, performance would be improved if JBoss Logging could log directly to the Log4j 2 API.
> Looks like we just need a new {{Log4j2Logger}} and {{Log4j2LoggerProvider}}. I'll try to submit a pull request in the next few weeks. I'm currently working on other tasks in Log4j 2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (JBLOGGING-95) Add Logger/LoggerProvider to support new Log4j 2 to improve performance
by Nicholas Williams (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-95?page=com.atlassian.jira.plug... ]
Nicholas Williams commented on JBLOGGING-95:
--------------------------------------------
Huh. I didn't even notice that this had been merged and close. Guess I didn't get the email update or something. Thanks!
Since this didn't get backported and included in 3.1.4.GA (sad face), when do we expect 3.2.0 to come out? Log4j 2 is going GA in the next couple of weeks, my book goes to the printers next week, and I'd really like this to all line up. :-)
Is there anything I can do to help move things along?
> Add Logger/LoggerProvider to support new Log4j 2 to improve performance
> -----------------------------------------------------------------------
>
> Key: JBLOGGING-95
> URL: https://issues.jboss.org/browse/JBLOGGING-95
> Project: JBoss Logging
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: jboss-logging-spi
> Affects Versions: 3.2.0.Beta1
> Reporter: Nicholas Williams
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 3.2.0.Beta1
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> The new Log4j 2 project will be released soon. It has major improvements over Log4j and Logback. Currently, JBoss Logging can log to Log4j 2 indirectly by way of SLF4J (if the log4j-slf4j artifact is on the classpath) or the Log4j 1.2 API (if the log4j-1.2-api artifact is on the classpath and when JBLOGGING-94 is fixed). However, performance would be improved if JBoss Logging could log directly to the Log4j 2 API.
> Looks like we just need a new {{Log4j2Logger}} and {{Log4j2LoggerProvider}}. I'll try to submit a pull request in the next few weeks. I'm currently working on other tasks in Log4j 2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (JGRP-1789) Fix host binding of tests involving GossipRouter
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1789?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1789:
---------------------------
Fix Version/s: 3.5
> Fix host binding of tests involving GossipRouter
> ------------------------------------------------
>
> Key: JGRP-1789
> URL: https://issues.jboss.org/browse/JGRP-1789
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Windows
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> Tests like TUNNEL_Test, TUNNELDeadlockTest, and GossipRouterTest make use of the following:
> - a GosspiRouter which binds to a certain host address and port
> - a GossipRouter client whose TUNNEL protocol binds to a certain host address and port
> - a property gossip_router_hosts which specifies the gossip router hosts the client can connect to
> If these bind addresses are not specified, we often get test failures involving an inability of the client to communicate with the GossipRouter, due to each not having the other's correct address, or one being on local host and the other on a non-localhost interface:
> {noformat}
> ------------- startRouter -----------
> -- starting GossipRouter on 127.0.0.1[23003]
> ------------- testConnectThree -----------
> -------------------------------------------------------------------
> GMS: address=B, cluster=TUNNEL_Test, physical address=192.168.5.141:61373
> -------------------------------------------------------------------
> 605382 [WARN] TUNNEL: - Failed connecting to GossipRouter at /127.0.0.1:23003
> 605383 [WARN] TUNNEL: - failed reconnecting stub to GR at /127.0.0.1:23003: java.lang.Exception: Could not connect to /127.0.0.1:23003
> 605383 [ERROR] TUNNEL: - failed sending message to cluster (94 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=/192.168.5.141:51802,router_host=127.0.0.1::23003,connected=false]] accepted a multicast message, cause: null
> {noformat}
> TUNNEL_Test and GossipRouterTest are failing on Windows, for example, due to this sort of issue.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months
[JBoss JIRA] (JGRP-1786) 3.5
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1786:
---------------------------
Summary: 3.5 (was: TimeSchedulerTest.test2Tasks fails repeatably with DefaultTimeScheduler)
Fix Version/s: 3.5
Hi Richard,
good analysis, I'm trying to resolve this in 3.5 and backport if needed. Note though that DefaultScheduler (despite its name) is not used anymore...
> 3.5
> ---
>
> Key: JGRP-1786
> URL: https://issues.jboss.org/browse/JGRP-1786
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL 5 x86_64
> Windows x86_64
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute
> Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted.
> The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 3 months