May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1567) Threads in BLOCKED state in ProjectClassLoader and ParseTools

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1567?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1567: ------------------------------------- On a side note let me also say that the static blacklist cache you added in your ProjectClassLoader is totally wrong because it will be shared by all CL in your app and different CLs with different configurations may or may not resolve the same class name. > Threads in BLOCKED state in ProjectClassLoader and ParseTools > ------------------------------------------------------------- > > Key: DROOLS-1567 > URL: https://issues.jboss.org/browse/DROOLS-1567 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Arkady Syamtomov > Assignee: Mario Fusco > > Building the knowledge bases in parallel threads does not scale due to the recurrent synchronised call of Class.forName, detected in ProjectClassLoader and org.mvel2.util.ParceTools. > While in the org.drools.core.common.ProjectClassLoader the classes, if not found, are blacklisted, in the org.mvel2.util.ParceTools there is no blacklist logic implemented at all. > Nevertheless, even with org.drools.core.common.ProjectClassLoader the issue remains, since the internal DRL conditions query are submitted as class names to resolve and with the number of rules growing in the system, the blacklisting of invalid class names is not enough any more: it would be desirable to have an internal hook to filter the names matching a configurable pattern. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2805) Use Xalan from JRE rather than our own fork

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2805?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-2805: ------------------------------------- [~jason.greene]? > Use Xalan from JRE rather than our own fork > ------------------------------------------- > > Key: WFCORE-2805 > URL: https://issues.jboss.org/browse/WFCORE-2805 > Project: WildFly Core > Issue Type: Task > Reporter: Peter Palaga > Assignee: Peter Palaga > > As proposed by [~wolfc] we want to check if we can get rid of maintaining our own fork of Xalan. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1567) Threads in BLOCKED state in ProjectClassLoader and ParseTools

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1567?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1567. --------------------------------- Resolution: Rejected Hi [~arkadys], I investigated your reproducer but again I don't think that I can do anything about this. The problem you found is quite specific of your app and I don't want to pollute the ProjectClassLoader with configurable filter that (if misused) could also lead to very weird and difficult to track behaviours. Moreover the ProjectClassLoader already has a cache of non existing classes and this allow it to avoid the lookup more than once. Using your reproducer I verified that this cache is working as expected. The only suggestion to hugely alleviate this problem that I can give you is avoid using the mvel dialect. In this way you'll avoid mvel's ParseTool to keep invoking the ClassLoader because the consequences will be internally implemented in pure Java. I hope this helps. > Threads in BLOCKED state in ProjectClassLoader and ParseTools > ------------------------------------------------------------- > > Key: DROOLS-1567 > URL: https://issues.jboss.org/browse/DROOLS-1567 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Arkady Syamtomov > Assignee: Mario Fusco > > Building the knowledge bases in parallel threads does not scale due to the recurrent synchronised call of Class.forName, detected in ProjectClassLoader and org.mvel2.util.ParceTools. > While in the org.drools.core.common.ProjectClassLoader the classes, if not found, are blacklisted, in the org.mvel2.util.ParceTools there is no blacklist logic implemented at all. > Nevertheless, even with org.drools.core.common.ProjectClassLoader the issue remains, since the internal DRL conditions query are submitted as class names to resolve and with the number of rules growing in the system, the blacklisting of invalid class names is not enough any more: it would be desirable to have an internal hook to filter the names matching a configurable pattern. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2805) Use Xalan from JRE rather than our own fork

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2805?page=com.atlassian.jira.plugi... ] Peter Palaga commented on WFCORE-2805: -------------------------------------- I was able to do the following w.r.t. Xalan removal: In WF Core: * https://github.com/ppalaga/wildfly-core/tree/WFCORE-2805 * Xalan removed from pom.xml and module.xml files * Xalan left as a dependency of xml-maven-plugin - it could perhaps be removed from there too, but some work needs to be done. * The transformer and serializer packages were added to both ** OpenJDK https://github.com/ppalaga/wildfly-core/commit/501456f5fc524c3775360899dc... ** and IBM JDK modules https://github.com/ppalaga/wildfly-core/commit/501456f5fc524c3775360899dc... * Xalan added to banned deps in the config of enforcer plugin https://github.com/ppalaga/wildfly-core/commit/501456f5fc524c3775360899dc... * -DallTests is passing on Oracle JDK * -DallTests is passing on IBM with Elytron Subsystem tests excluded. Darran and Tomaž say Elytron Subsystem tests are known not to work on IBM JDK. In WF: * https://github.com/ppalaga/wildfly/tree/WFCORE-2805 * Added XsltClassLoadingTestCase to check as many in-XSLT class loading scenarios as possible: Loading a XSLT-processor built-in function, JRE Java method, custom method from the same module, custom method from a dependency module. https://github.com/ppalaga/wildfly/commit/e8c21f47cfec3f8629786f8a66fd74b... * Xalan removed from pom.xml and module.xml files * Xalan left as a dependency of xml-maven-plugin and maven-antrun-plugin - again, I see some potential to fix this * Xalan added to banned deps in the config of enforcer plugin https://github.com/ppalaga/wildfly/commit/97fbec8ef360be80dbe6a4abfd76d8e... * -DallTests is passing on Oracle JDK * -DallTests is passing on IBM with some LDAP SSL tests excluded [~dmlloyd] and [~ctomc] could you please to point me to some other specific scenarios that are not covered in [XsltClassLoadingTestCase|https://github.com/ppalaga/wildfly/commit/e8c21f...] where the Xalan removal could fail? > Use Xalan from JRE rather than our own fork > ------------------------------------------- > > Key: WFCORE-2805 > URL: https://issues.jboss.org/browse/WFCORE-2805 > Project: WildFly Core > Issue Type: Task > Reporter: Peter Palaga > Assignee: Peter Palaga > > As proposed by [~wolfc] we want to check if we can get rid of maintaining our own fork of Xalan. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1567) Threads in BLOCKED state in ProjectClassLoader and ParseTools

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1567?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1567: -------------------------------- Issue Type: Enhancement (was: Bug) > Threads in BLOCKED state in ProjectClassLoader and ParseTools > ------------------------------------------------------------- > > Key: DROOLS-1567 > URL: https://issues.jboss.org/browse/DROOLS-1567 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Arkady Syamtomov > Assignee: Mario Fusco > > Building the knowledge bases in parallel threads does not scale due to the recurrent synchronised call of Class.forName, detected in ProjectClassLoader and org.mvel2.util.ParceTools. > While in the org.drools.core.common.ProjectClassLoader the classes, if not found, are blacklisted, in the org.mvel2.util.ParceTools there is no blacklist logic implemented at all. > Nevertheless, even with org.drools.core.common.ProjectClassLoader the issue remains, since the internal DRL conditions query are submitted as class names to resolve and with the number of rules growing in the system, the blacklisting of invalid class names is not enough any more: it would be desirable to have an internal hook to filter the names matching a configurable pattern. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8806) Elytron integration with the legacy JSSE domains is broken after the SSL-related capabilities were changed in Elytron

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-8806?page=com.atlassian.jira.plugin.... ] Stefan Guilhen updated WFLY-8806: --------------------------------- Priority: Critical (was: Major) > Elytron integration with the legacy JSSE domains is broken after the SSL-related capabilities were changed in Elytron > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8806 > URL: https://issues.jboss.org/browse/WFLY-8806 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Priority: Critical > Fix For: 11.0.0.Beta1 > > > The SSL-related capabilities have been changed in the Elytron subsystem (name and expected type of the key and trust managers, for example), which broke the integration with the legacy JSSE security domains. > The integration has to be reworked to use the new capabilities names and types. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-1179) Support safe overriding of cipher suites defined for SSLContext

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1179?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1179: ---------------------------------- Summary: Support safe overriding of cipher suites defined for SSLContext (was: Support safe overriding of cipher suites deinfed for SSLContext) > Support safe overriding of cipher suites defined for SSLContext > --------------------------------------------------------------- > > Key: ELY-1179 > URL: https://issues.jboss.org/browse/ELY-1179 > Project: WildFly Elytron > Issue Type: Task > Components: SSL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > Clients using a wrapped SSLContext may want to further restrict the cipher suites offered, we should allow this by mapping to a union of those enabled by our configuration and those specified by the calling client. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-1179) Support safe overriding of cipher suites defined for SSLContext

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1179?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1179: ------------------------------------- Assignee: (was: Darran Lofthouse) > Support safe overriding of cipher suites defined for SSLContext > --------------------------------------------------------------- > > Key: ELY-1179 > URL: https://issues.jboss.org/browse/ELY-1179 > Project: WildFly Elytron > Issue Type: Task > Components: SSL > Reporter: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > Clients using a wrapped SSLContext may want to further restrict the cipher suites offered, we should allow this by mapping to a union of those enabled by our configuration and those specified by the calling client. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-1179) Support safe overriding of cipher suites deinfed for SSLContext

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1179: ------------------------------------- Summary: Support safe overriding of cipher suites deinfed for SSLContext Key: ELY-1179 URL: https://issues.jboss.org/browse/ELY-1179 Project: WildFly Elytron Issue Type: Task Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.0.0.Alpha1 Clients using a wrapped SSLContext may want to further restrict the cipher suites offered, we should allow this by mapping to a union of those enabled by our configuration and those specified by the calling client. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7192) 'name' attribute missing in XSD while required by web subsystem parser

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7192?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7192: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1365939|https://bugzilla.redhat.com/show_bug.cgi?id=1365939] from VERIFIED to CLOSED > 'name' attribute missing in XSD while required by web subsystem parser > ---------------------------------------------------------------------- > > Key: WFLY-7192 > URL: https://issues.jboss.org/browse/WFLY-7192 > Project: WildFly > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > Labels: downstream_dependency > Fix For: 11.0.0.Alpha1 > > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1365939 , originaly reported by [~paramjindal] > While configuring the global valve using the following article : > https://access.redhat.com/solutions/379813 > It is mandatory that the "name" attribute of valve must match the "auth-method" that is specified in the "WEB-INF/web.xml". > So "name" attribute is mandatory to configure this valve. > but it is not mentioned in the schema of valve as shown below : > {code:xml} > <xs:element name="valve"> > <xs:complexType> > <xs:sequence> > <xs:element name="param" minOccurs="0" maxOccurs="unbounded" type="paramType" /> > </xs:sequence> > <xs:attribute name="class-name" type="xs:string" use="required" /> > <xs:attribute name="module" type="xs:string" use="required" /> > <xs:attribute name="enabled" default="true" type="xs:boolean" /> > </xs:complexType> > </xs:element> > {code} > Version-Release number of selected component (if applicable): -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 12 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 May 2017