December 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3394) DMN DMNCompiler#getNamespaceAndName for DMNv1.2 assumes default prefix is DMN model namespace

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-3394: -------------------------------------- Summary: DMN DMNCompiler#getNamespaceAndName for DMNv1.2 assumes default prefix is DMN model namespace Key: DROOLS-3394 URL: https://issues.jboss.org/browse/DROOLS-3394 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10997) WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFLY-10997?page=com.atlassian.jira.plugin... ] Richard Opalka updated WFLY-10997: ---------------------------------- Component/s: Remoting (was: EJB) > WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-10997 > URL: https://issues.jboss.org/browse/WFLY-10997 > Project: WildFly > Issue Type: Bug > Components: Remoting > Reporter: Lin Gao > Assignee: Bartosz Baranowski > Priority: Major > Labels: downstream_dependency > Original Estimate: 3 days > Remaining Estimate: 3 days > > WildFlyInitialContextFactory EJB proxy security behavior inconsistent with different context lookups > Using WildFlyInitialContextFactory and calling a remote EJB server. > Observations: > 1) If the ejb lookup is "reproducer/TestSLSB!test.Test" (basically like a RemoteNaming lookup), the ejb is invoked successfully, but the caller is seen as anonymous instead of the ejbuser which is specified in the Context properties. > Using the ejb-client type lookup: ejb:/reproducer/TestSLSB!test.Test , then it shows up as ejbuser as expected > 2) if a client creates 2 InitialContexts and uses the lookup reproducer/TestSLSB!test.Test" on ctx1 , then uses the lookup "ejb:/reproducer/TestSLSB!test.Test " on ctx2 in that order, then they both show anonymous (as if it uses only the context that was created first). > If you switch the order, and use ejb:/reproducer/TestSLSB!test.Test first, then they both show ejbuser -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11453) [EAT] : Enablement of additional security tests

by Panagiotis Sotiropoulos (Jira)

[ https://issues.jboss.org/browse/WFLY-11453?page=com.atlassian.jira.plugin... ] Panagiotis Sotiropoulos reopened WFLY-11453: -------------------------------------------- > [EAT] : Enablement of additional security tests > ----------------------------------------------- > > Key: WFLY-11453 > URL: https://issues.jboss.org/browse/WFLY-11453 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > Additional security tests enabled. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11453) [EAT] : Enablement of additional security tests

by Panagiotis Sotiropoulos (Jira)

[ https://issues.jboss.org/browse/WFLY-11453?page=com.atlassian.jira.plugin... ] Panagiotis Sotiropoulos resolved WFLY-11453. -------------------------------------------- Resolution: Done > [EAT] : Enablement of additional security tests > ----------------------------------------------- > > Key: WFLY-11453 > URL: https://issues.jboss.org/browse/WFLY-11453 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > Additional security tests enabled. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11453) [EAT] : Enablement of additional security tests

by Panagiotis Sotiropoulos (Jira)

[ https://issues.jboss.org/browse/WFLY-11453?page=com.atlassian.jira.plugin... ] Panagiotis Sotiropoulos moved JBEAP-15970 to WFLY-11453: -------------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-11453 (was: JBEAP-15970) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) > [EAT] : Enablement of additional security tests > ----------------------------------------------- > > Key: WFLY-11453 > URL: https://issues.jboss.org/browse/WFLY-11453 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > Additional security tests enabled. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-218) JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/LOGMGR-218?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on LOGMGR-218: ----------------------------------------- [~jmesnil] [~luck3y] FYI. > JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11 > ----------------------------------------------------------------- > > Key: LOGMGR-218 > URL: https://issues.jboss.org/browse/LOGMGR-218 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: Brian Stansberry > Priority: Critical > > The current logmanager implementation is incompatible with use with the -Xbootclasspath/a option on JDK 11. The is because it is a multi-release jar which is incompatible with -Xbootclasspath/a. This is problematic because to allow Java Agents to work with JBoss Modules based applications (i.e. WildFly and derivatives) often it is necessary to include logmanager in -Xbootclasspath/a . > Here's me starting WildFly with a -Xbootclasspath/a setting and JDK 11: > {code} > $ build/target/wildfly-core-7.0.0.CR2-SNAPSHOT/bin/standalone.sh > ========================================================================= > JBoss Bootstrap Environment > JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly-core/build/target/wildfly-core-7.0.0.CR2-SNAPSHOT > JAVA: /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java > JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Djava.awt.headless=true -Xbootclasspath/a:/Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-7.0.0.CR2-SNAPSHOT/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.5.Final.jar -Djava.util.logging.manager=org.jboss.logmanager.LogManager --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-modules=java.se > ========================================================================= > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by org.jboss.logmanager.LogLevelInitTask to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level) > WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogLevelInitTask > WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations > WARNING: All illegal access operations will be denied in a future release > java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager") > at org.jboss.logmanager.Logger.getLogger(Logger.java:57) > at org.jboss.as.server@7.0.0.CR2-SNAPSHOT//org.jboss.as.server.Main.main(Main.java:89) > at org.jboss.modules.Module.run(Module.java:352) > at org.jboss.modules.Module.run(Module.java:320) > at org.jboss.modules.Main.main(Main.java:593) > {code} > Right now jboss-logmanager is a multi-release jar. But, per the MR jar spec (https://openjdk.java.net/jeps/238) that is incompatible with -Xbootclasspath: > {quote} > Multi-release jars and the boot loader > Multi-release JARs are not supported by the boot loader (for example, when a multi-release JAR file is declared with the -Xbootclasspath/a option). Such support would complicate the boot loader implementation for what is considered a rare use-case. > {quote} > At this point I've identified two java agents that are commonly used with WildFly derived apps that cannot be installed in a JDK 11 environment: Hawkular and the Prometheus jmx-exporter. The former I could perhaps work around (i.e. don't install it with JDK 11) as it's use is deprecated. But being able to use of jmx-exporter is quite important. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-218) JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11

by Brian Stansberry (Jira)

Brian Stansberry created LOGMGR-218: --------------------------------------- Summary: JBoss Logmanager is incompatibile with -Xbootclasspath and JDK 11 Key: LOGMGR-218 URL: https://issues.jboss.org/browse/LOGMGR-218 Project: JBoss Log Manager Issue Type: Bug Reporter: Brian Stansberry The current logmanager implementation is incompatible with use with the -Xbootclasspath/a option on JDK 11. The is because it is a multi-release jar which is incompatible with -Xbootclasspath/a. This is problematic because to allow Java Agents to work with JBoss Modules based applications (i.e. WildFly and derivatives) often it is necessary to include logmanager in -Xbootclasspath/a . Here's me starting WildFly with a -Xbootclasspath/a setting and JDK 11: {code} $ build/target/wildfly-core-7.0.0.CR2-SNAPSHOT/bin/standalone.sh ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /Users/bstansberry/dev/wildfly/wildfly-core/build/target/wildfly-core-7.0.0.CR2-SNAPSHOT JAVA: /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager -Djava.awt.headless=true -Xbootclasspath/a:/Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-7.0.0.CR2-SNAPSHOT/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.5.Final.jar -Djava.util.logging.manager=org.jboss.logmanager.LogManager --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-modules=java.se ========================================================================= WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.jboss.logmanager.LogLevelInitTask to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level) WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogLevelInitTask WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager") at org.jboss.logmanager.Logger.getLogger(Logger.java:57) at org.jboss.as.server@7.0.0.CR2-SNAPSHOT//org.jboss.as.server.Main.main(Main.java:89) at org.jboss.modules.Module.run(Module.java:352) at org.jboss.modules.Module.run(Module.java:320) at org.jboss.modules.Main.main(Main.java:593) {code} Right now jboss-logmanager is a multi-release jar. But, per the MR jar spec (https://openjdk.java.net/jeps/238) that is incompatible with -Xbootclasspath: {quote} Multi-release jars and the boot loader Multi-release JARs are not supported by the boot loader (for example, when a multi-release JAR file is declared with the -Xbootclasspath/a option). Such support would complicate the boot loader implementation for what is considered a rare use-case. {quote} At this point I've identified two java agents that are commonly used with WildFly derived apps that cannot be installed in a JDK 11 environment: Hawkular and the Prometheus jmx-exporter. The former I could perhaps work around (i.e. don't install it with JDK 11) as it's use is deprecated. But being able to use of jmx-exporter is quite important. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11450) Cannot get delegate of JMSContext during an beforeCompletion synch

by Jan-Willem Gmelig Meyling (Jira)

[ https://issues.jboss.org/browse/WFLY-11450?page=com.atlassian.jira.plugin... ] Jan-Willem Gmelig Meyling updated WFLY-11450: --------------------------------------------- Affects Version/s: 8.0.0.CR1 14.0.1.Final > Cannot get delegate of JMSContext during an beforeCompletion synch > ------------------------------------------------------------------ > > Key: WFLY-11450 > URL: https://issues.jboss.org/browse/WFLY-11450 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 14.0.1.Final, 8.0.0.CR1 > Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final > WildFly 8.0.0.CR1 > Reporter: Jan-Willem Gmelig Meyling > Assignee: Matej Novotny > Priority: Minor > Attachments: ARJUNA016082.log > > > The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction. (Because the synchronization cannot be placed) > *Use case* > I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}. > *Workaround* > Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization. > The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s... > (Which refers to WildFly 8.0.0.CR1) > Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead. > See the attached log for a full stack trace. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2018