July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2043 at 7/12/16 3:17 AM: --------------------------------------------------------- This correlates with what Ralf observed in Munich: populate ClassConfigurator map with {{id|Constructor}} pairs rather than {{id|Class}} pairs. was (Author: belaban): This correlates with what Ralf observed in Munich: popupate ClassConfigurator map with {{id|Constructor}} pairs rather than {{id|Class}} pairs. > Improve performance of Message#readHeader > ----------------------------------------- > > Key: JGRP-2043 > URL: https://issues.jboss.org/browse/JGRP-2043 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > A CPU hot spot highlighed by profiling via JFR: > {noformat}Stack Trace Sample Count Percentage(%) > java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392 > java.lang.Class.newInstance() 71 2.392 > org.jgroups.Message.readHeader(DataInput) 71 2.392 > {noformat} > I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into. > It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2043: -------------------------------- [~sannegrinovero] Do you have the JMH test so I can try to reproduce this? When warming up the JVM reflective, constructor and method-handle creations are about the same speed in my test... > Improve performance of Message#readHeader > ----------------------------------------- > > Key: JGRP-2043 > URL: https://issues.jboss.org/browse/JGRP-2043 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > A CPU hot spot highlighed by profiling via JFR: > {noformat}Stack Trace Sample Count Percentage(%) > java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392 > java.lang.Class.newInstance() 71 2.392 > org.jgroups.Message.readHeader(DataInput) 71 2.392 > {noformat} > I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into. > It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1226) Eclipse Plugin not working with Eclipse Neon 4.6

by Ganesh Subbanarasimhan (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1226?page=com.atlassian.jira.plugi... ] Ganesh Subbanarasimhan commented on DROOLS-1226: ------------------------------------------------ I am a newbie to both Drools and Eclipse. It is not a great start. It will be great if this could be fixed. Thanks > Eclipse Plugin not working with Eclipse Neon 4.6 > ------------------------------------------------ > > Key: DROOLS-1226 > URL: https://issues.jboss.org/browse/DROOLS-1226 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Reporter: Bernhard Mayer > Assignee: Robert (Bob) Brodt > > The eclipse integration plugin stopped working properly with Eclipse Neon 4.6. > When editing rules in the rules editor of a Drools Project the following error is produced for *any* rule: > {panel:title=Error Message} > Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > {panel} > The Plugin works fine with Eclipse Mars 4.5 and earlier releases. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6809) Web authentication not treating "**" role constraint as expected

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6809?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6809: -------------------------------------- After re-reading the spec I am not 100% sure that your interpretation is correct. The section you mention only applies to isUserInRole, while the section on declarative security has no corresponding section. I have created a servlet spec issue to ask for clarification on this: https://java.net/jira/browse/SERVLET_SPEC-158 As it is though Undertow currently follows the letter of the spec. > Web authentication not treating "**" role constraint as expected > ---------------------------------------------------------------- > > Key: WFLY-6809 > URL: https://issues.jboss.org/browse/WFLY-6809 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Guillermo González de Agüero > Assignee: Stuart Douglas > Attachments: rolestest.war > > > Servlet spec 3.1 states at point 13.3: > ??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.?? > But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403): > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" > version="3.1"> > <security-constraint> > <web-resource-collection> > <url-pattern>/*</url-pattern> > </web-resource-collection> > <auth-constraint> > <role-name>**</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > </login-config> > </web-app> > {code} > With the following, and authenticating a user that has a role "**", the requested page is shown: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" > version="3.1"> > <security-constraint> > <web-resource-collection> > <url-pattern>/*</url-pattern> > </web-resource-collection> > <auth-constraint> > <role-name>**</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > </login-config> > <security-role> > <role-name>**</role-name> > </security-role> > </web-app> > {code} > Reproducer war is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6818) Web authentication not treating "**" role constraint as expected

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6818: ------------------------------------ Summary: Web authentication not treating "**" role constraint as expected Key: WFLY-6818 URL: https://issues.jboss.org/browse/WFLY-6818 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Guillermo González de Agüero Assignee: Stuart Douglas Servlet spec 3.1 states at point 13.3: ??If the role-name of the security-role to be tested is “**”, and the application has NOT declared an application security-role with role-name “**”, isUserInRole must only return true if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.?? But Undertow treats the special role "**" as any other. With the following web.xml authorization succeeds, but authorization fails (403): {code:xml} <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> <security-constraint> <web-resource-collection> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>**</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> </web-app> {code} With the following, and authenticating a user that has a role "**", the requested page is shown: {code:xml} <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> <security-constraint> <web-resource-collection> <url-pattern>/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>**</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <role-name>**</role-name> </security-role> </web-app> {code} Reproducer war is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6817) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee

by Aaron Ogburn (JIRA)

Aaron Ogburn created WFLY-6817: ---------------------------------- Summary: JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee Key: WFLY-6817 URL: https://issues.jboss.org/browse/WFLY-6817 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Final Reporter: Aaron Ogburn Assignee: Stuart Douglas JASPICSecureResponseHandler.handleRequest can throw a NPE for a redirect from a CONFIDENTIAL transport guarantee: {code} java.lang.NullPointerException at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:35) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} This occurs because io.undertow.security.handlers.AbstractConfidentialityHandler generates the redirect before any JASPICContext is placed on the request, so JASPICSecureResponseHandler sees the null. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6817) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/WFLY-6817?page=com.atlassian.jira.plugin.... ] Aaron Ogburn updated WFLY-6817: ------------------------------- Attachment: standalone.xml > JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6817 > URL: https://issues.jboss.org/browse/WFLY-6817 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Aaron Ogburn > Assignee: Stuart Douglas > Attachments: standalone.xml > > > JASPICSecureResponseHandler.handleRequest can throw a NPE for a redirect from a CONFIDENTIAL transport guarantee: > {code} > java.lang.NullPointerException > at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:35) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} > This occurs because io.undertow.security.handlers.AbstractConfidentialityHandler generates the redirect before any JASPICContext is placed on the request, so JASPICSecureResponseHandler sees the null. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6816) messaging-artemis xsd is missing the initial-connect-attempts attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6816?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6816: ----------------------------------- Summary: messaging-artemis xsd is missing the initial-connect-attempts attribute (was: messaging-artemix xsd is missing the initial-connect-attempts attribute) > messaging-artemis xsd is missing the initial-connect-attempts attribute > ----------------------------------------------------------------------- > > Key: WFLY-6816 > URL: https://issues.jboss.org/browse/WFLY-6816 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 10.1.0.Final > > > The cluster-connection element is missing the initial-connect-attempts attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6816) messaging-artemismq xsd is missing the initial-connect-attempts attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6816?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6816: ----------------------------------- Summary: messaging-artemismq xsd is missing the initial-connect-attempts attribute (was: messaging-artemis xsd is missing the initial-connect-attempts attribute) > messaging-artemismq xsd is missing the initial-connect-attempts attribute > ------------------------------------------------------------------------- > > Key: WFLY-6816 > URL: https://issues.jboss.org/browse/WFLY-6816 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 10.1.0.Final > > > The cluster-connection element is missing the initial-connect-attempts attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6816) messaging-artemix xsd is missing the initial-connect-attempts attribute

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-6816: -------------------------------------- Summary: messaging-artemix xsd is missing the initial-connect-attempts attribute Key: WFLY-6816 URL: https://issues.jboss.org/browse/WFLY-6816 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.0.0.Final Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 10.1.0.Final The cluster-connection element is missing the initial-connect-attempts attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016