April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11884) Mutations following HttpSession.setAttribute(...) lost on failover when using ATTRIBUTE granularity distributed web session with a non-transactional cache

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFLY-11884?page=com.atlassian.jira.plugin... ] Ilia Vassilev updated WFLY-11884: --------------------------------- Labels: downstream_dependency (was: ) > Mutations following HttpSession.setAttribute(...) lost on failover when using ATTRIBUTE granularity distributed web session with a non-transactional cache > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11884 > URL: https://issues.jboss.org/browse/WFLY-11884 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Labels: downstream_dependency > Fix For: 17.0.0.Beta1 > > > Consider the following code: > AtomicInteger value = new AtomicInteger(1); > session.setAttribute("a", value); > value.incrementAndGet(); > On failover, the value of attribute "a" will still be 1. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11882) Mutable getAttribute(...) and setAttribute(...) combination triggers redundant cache operation when using ATTRIBUTE granularity distributed web sessions with a transactional cache

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFLY-11882?page=com.atlassian.jira.plugin... ] Ilia Vassilev updated WFLY-11882: --------------------------------- Labels: downstream_dependency (was: ) > Mutable getAttribute(...) and setAttribute(...) combination triggers redundant cache operation when using ATTRIBUTE granularity distributed web sessions with a transactional cache > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11882 > URL: https://issues.jboss.org/browse/WFLY-11882 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Labels: downstream_dependency > Fix For: 17.0.0.Beta1 > > > When using a transactional cache with ATTRIBUTE granularity, the following code will trigger a redundant cache operation upon request completion: > [1] > AtomicInteger value = (AtomicInteger) session.getAttribute("a"); > value.incrementAndGet(); > session.setAttribute("a", value); > [2] > session.setAttribute("a", new AtomicInteger()); > AtomicInteger value = (AtomicInteger) session.getAttribute("a"); > value.incrementAndGet(); > In case [1], the initial mutable getAttribute(...) triggers an eager mutate, which becomes redundant by the subsequent setAttribute(...). > In case [2], the subsequent mutable getAttribute(...) does not need to trigger a mutation, as the previous setAttribute(...) already has. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4239) WARN if system-property is already set and is being overridden

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4239?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4239: ---------------------------------- Labels: downstream_dependency (was: ) > WARN if system-property is already set and is being overridden > -------------------------------------------------------------- > > Key: WFCORE-4239 > URL: https://issues.jboss.org/browse/WFCORE-4239 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brad Maxwell > Assignee: Chao Wang > Priority: Major > Labels: downstream_dependency > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > WARN if system-property is already set and is being overridden > If user sets a system property using the java opts or on the command line and the same system property is defined in the standalone.xml, then the standalone.xml value overrides that passed on the commandline/JAVA_OPTS, a warning would be useful as looking at the logs (and ps), it shows value1 passed on the command line and nothing indicating that the value was changed later. > JAVA_OPTS="$JAVA_OPTS -Dmy.system.property=value1" > {code} > <system-properties> > <property name="my.system.property" value="value2"/> > </system-properties> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4239) WARN if system-property is already set and is being overridden

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4239?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4239: ---------------------------------- Labels: (was: dawnst) > WARN if system-property is already set and is being overridden > -------------------------------------------------------------- > > Key: WFCORE-4239 > URL: https://issues.jboss.org/browse/WFCORE-4239 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brad Maxwell > Assignee: Chao Wang > Priority: Major > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > WARN if system-property is already set and is being overridden > If user sets a system property using the java opts or on the command line and the same system property is defined in the standalone.xml, then the standalone.xml value overrides that passed on the commandline/JAVA_OPTS, a warning would be useful as looking at the logs (and ps), it shows value1 passed on the command line and nothing indicating that the value was changed later. > JAVA_OPTS="$JAVA_OPTS -Dmy.system.property=value1" > {code} > <system-properties> > <property name="my.system.property" value="value2"/> > </system-properties> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4239) WARN if system-property is already set and is being overridden

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4239?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4239: ---------------------------------- Labels: dawnst (was: ) > WARN if system-property is already set and is being overridden > -------------------------------------------------------------- > > Key: WFCORE-4239 > URL: https://issues.jboss.org/browse/WFCORE-4239 > Project: WildFly Core > Issue Type: Enhancement > Components: Management > Reporter: Brad Maxwell > Assignee: Chao Wang > Priority: Major > Labels: dawnst > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > WARN if system-property is already set and is being overridden > If user sets a system property using the java opts or on the command line and the same system property is defined in the standalone.xml, then the standalone.xml value overrides that passed on the commandline/JAVA_OPTS, a warning would be useful as looking at the logs (and ps), it shows value1 passed on the command line and nothing indicating that the value was changed later. > JAVA_OPTS="$JAVA_OPTS -Dmy.system.property=value1" > {code} > <system-properties> > <property name="my.system.property" value="value2"/> > </system-properties> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11584) Legacy Web migrate op fails if a connector has scheme https and no SSL config

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFLY-11584?page=com.atlassian.jira.plugin... ] Ilia Vassilev updated WFLY-11584: --------------------------------- Labels: downstream_dependency (was: ) > Legacy Web migrate op fails if a connector has scheme https and no SSL config > ----------------------------------------------------------------------------- > > Key: WFLY-11584 > URL: https://issues.jboss.org/browse/WFLY-11584 > Project: WildFly > Issue Type: Bug > Components: Migration > Affects Versions: 15.0.1.Final > Reporter: Teresa Miyar Gil > Assignee: Teresa Miyar Gil > Priority: Major > Labels: downstream_dependency > Fix For: 16.0.0.Beta1, 16.0.0.Final > > Attachments: standalone.xml > > > If we set an attribute 'scheme' of 'http' connector as 'https' [ scheme="https" ] and no SSL config, in 'web' subsystem, then migrate op fails: > {code} > [standalone@localhost:9990 /] /subsystem=web:migrate > { > "outcome" => "failed", > "result" => {"[(\"extension\" => \"org.wildfly.extension.undertow\")]" => { > "outcome" => "failed", > "result" => [("undertow" => "4.0.0")], > "rolled-back" => true > }}, > "failure-description" => "WFLYWEB0004: Could not migrate SSL connector as no SSL config is defined", > "rolled-back" => true > } > {code} > Steps to Reproduce: > 1. Replace EAP 7.1 default standalone.xml configuration with the one attached > 2. Start JBoss EAP 7.1 in mode admin-only > 3. Start CLI and invoke web subsystem migrate op [^standalone.xml] -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4346) ChildFirstClassLoader and LegacyKernelServicesInitializer should allow exclusion of resources from the paren

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4346?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4346: ---------------------------------- Labels: downstream_dependency (was: ) > ChildFirstClassLoader and LegacyKernelServicesInitializer should allow exclusion of resources from the paren > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-4346 > URL: https://issues.jboss.org/browse/WFCORE-4346 > Project: WildFly Core > Issue Type: Enhancement > Components: Management, Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Labels: downstream_dependency > Fix For: 9.0.0.Beta1 > > > ChildFirstClassLoader and LegacyKernelServicesInitializer have hooks to allow tests to prevent classes from being loaded from the parent CL, but there's no way to prevent resources being loaded. In particular META-INF/services files, which bit us with https://github.com/wildfly/wildfly-core/pull/3685 as a META-INF/services file in the parent was being found when trying to load services for an interface in the child CL. The impls in the parent could not implement the child CL version of the interface. Excluding loading of the META-INF/services file in the paren solved the problem. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4374) security-manager minimum-set for MBeanServerPermission createMBeanServer not working but permissions.xml does

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4374?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4374: ---------------------------------- Labels: downstream_dependency (was: ) > security-manager minimum-set for MBeanServerPermission createMBeanServer not working but permissions.xml does > ------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4374 > URL: https://issues.jboss.org/browse/WFCORE-4374 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Bartosz Spyrko > Assignee: Bartosz Spyrko > Priority: Major > Labels: downstream_dependency > Fix For: 9.0.0.Beta1 > > > When configuring a jdbc driver deployment jar with permissions.xml it I was able to resolve all of the needed permissions. But then when I remove the permissions.xml from the deployment and define the same permissions in the security-manager, it fails saying it requires the javax.management.MBeanServerPermission createMBeanServer even though it is defined in the subsystem. > {code} > 23:41:13,007 ERROR [stderr] (ServerService Thread Pool -- 81) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("javax.management.MBeanServerPermission" "createMBeanServer")" in code source "(vfs:/Users/bmaxwell/Downloads/02291781/jboss-eap-7.3/standalone/deployments/createMBeanServer.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.createMBeanServer.jar" from Service Module Loader") > {code} > {code} > <minimum-set> > <permission class="javax.management.MBeanServerPermission" name="createMBeanServer"/> > </minimum-set> > {code} > If you put a permissions.xml in the deployment's META-INF with this below then it works fine. The other permissions I used for the jdbc driver seemed to work fine, it is just this one that seems inconsistent for some reason. > {code} > <?xml version="1.0" encoding="UTF-8"?> > <permissions 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/permissions_7.xsd" > version="7"> > <permission> > <class-name>javax.management.MBeanServerPermission</class-name> > <name>createMBeanServer</name> > </permission> > </permissions> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4373) org.jboss.log4j.logmanager module requires java.sql module

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFCORE-4373?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-4373: ---------------------------------- Labels: downstream_dependency (was: ) > org.jboss.log4j.logmanager module requires java.sql module > ---------------------------------------------------------- > > Key: WFCORE-4373 > URL: https://issues.jboss.org/browse/WFCORE-4373 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Affects Versions: 8.0.0.Final > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > Labels: downstream_dependency > Fix For: 9.0.0.Beta1 > > > org.jboss.logmanager module requires java.sql module > {code} > Caused by: java.lang.ClassNotFoundException: java.sql.SQLException from [Module "org.jboss.log4j.logmanager" version 1.1.6.Final-redhat-00001 from local module loader @7d3a22a9 (finder: local module finder @1d082e88 (roots: /opt/jboss/modules,/opt/jboss/modules/system/layers/base))] > {code} > It looks like in EAP 6.4 java.* was visible to everything. In EAP 7.2 with JBoss Modules changes likely due to JDK 11 modular changes, it looks like java.* is no longer just visible and JBoss Modules has some internal modules such as java.sql which would be needed to see these classes. > Tattletale says that logmanager jar has this class org.apache.log4j.jdbc.JDBCAppender which uses java.sql.* , so we should add a dependency on java.sql (javax.sql.api exports java.sql , but javax.sql.api module is marked deprecated) > EAP 6.4 > {code} > <module xmlns="urn:jboss:module:1.1" name="org.jboss.log4j.logmanager"> > <resources> > <resource-root path="log4j-jboss-logmanager-1.1.4.Final-redhat-1.jar"/> >  > </resources> > <dependencies> > <module name="javax.api"/> > <module name="javax.mail.api" optional="true"/> > <module name="javax.jms.api" optional="true"/> > <module name="org.dom4j" optional="true"/> > <module name="org.jboss.logmanager"/> > <module name="org.jboss.modules"/> > </dependencies> > </module> > {code} > {code} > grep -r java.sql `f module.xml` > <nothing> > {code} > EAP 7.2: > {code} > <module name="org.jboss.log4j.logmanager" xmlns="urn:jboss:module:1.8"> > <properties> > <property name="jboss.api" value="private"/> > </properties> > <resources> > <resource-root path="log4j-jboss-logmanager-1.1.6.Final-redhat-00001.jar"/> > </resources> > <dependencies> >  > <module name="java.desktop"/> > <module name="java.logging"/> > <module name="java.xml"/> > <module name="javax.mail.api" optional="true"/> > <module name="javax.jms.api" optional="true"/> > <module name="org.dom4j" optional="true"/> > <module name="org.jboss.logmanager"/> > <module name="org.jboss.modules"/> > </dependencies> > </module> > {code} > {code} > grep -r java.sql `f module.xml` > ./modules/system/layers/base/sun/jdk/main/module.xml:  > ./modules/system/layers/base/org/wildfly/extension/elytron/main/module.xml: <module name="java.sql"/> > ./modules/system/layers/base/org/wildfly/security/elytron-private/main/module.xml: <module name="java.sql"/> > ./modules/system/layers/base/io/undertow/core/main/module.xml: <module name="java.sql"/> > ./modules/system/layers/base/javax/sql/api/main/module.xml: <module name="java.sql" export="true"/> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11819) max-allowed-connected-nodes element in jboss-ejb-client.xml not used

by Ilia Vassilev (Jira)

[ https://issues.jboss.org/browse/WFLY-11819?page=com.atlassian.jira.plugin... ] Ilia Vassilev updated WFLY-11819: --------------------------------- Labels: downstream_dependency (was: ) > max-allowed-connected-nodes element in jboss-ejb-client.xml not used > -------------------------------------------------------------------- > > Key: WFLY-11819 > URL: https://issues.jboss.org/browse/WFLY-11819 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final > Reporter: Joerg Baesner > Assignee: Joerg Baesner > Priority: Major > Labels: downstream_dependency > Fix For: 17.0.0.Beta1 > > > An application uses {{remote-outbound-connections}} for remote EJB invocations and the {{jboss-ejb-client.xml}} contains a {{clusters}} definition containing the {{max-allowed-connected-nodes}}, like below: > {code} > <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.2"> > ... > <clusters> > <cluster name="ejb" ... max-allowed-connected-nodes="20"> > </cluster> > </clusters> > </client-context> > </jboss-ejb-client> > {code} > In the actually used {{EJBClientContext}} this value doesn't get assigned and the hard coded default value of _10_ is being used. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 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 April 2019