March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10029) bean-discovery-mode="annotated" is not working like described in the spec

by Ralph Soika (JIRA)

Ralph Soika created WFLY-10029: ---------------------------------- Summary: bean-discovery-mode="annotated" is not working like described in the spec Key: WFLY-10029 URL: https://issues.jboss.org/browse/WFLY-10029 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 10.1.0.Final Reporter: Ralph Soika Assignee: Martin Kouba Priority: Minor I think we have a problem in Wildfly 10 concerning scanning of CDI Beans. Take a look at the following example: {code:java} @Stateless @LocalBean public class SomeService { ... } public class SomeClass { @EJB SomeService someService; .... } {code} We have a stateless session ejb an a bean which is not annotated with a scope but is injecting the service EJB. If you use a beans.xml with the tag {noformat} bean-discovery-mode="annotated" {noformat} This works in wildfly 10. But this is not correct behavior as stated in the specification. It says that in this case only beans with a scope annotation should be threaded as CDI which is not hte case for SomeClass. Normally as a developer you would not complain much about this. I recognized this after I tried to run my application on Glassfish/Payara4 which did no longer work until I changge the beans.xml tag to: {noformat} bean-discovery-mode="all" {noformat} Now it works in both application servers. I think in wildfly we are misinterpreting the attribute "bean-discovery-mode". I think this should be changed in the next versions for EE8. I don't know if this behavior is a known issue and maybe it is still under development. I know that with such a change some projects (also my own ones) will break. So maybe a new configuration switch like "strict-cdi-scanning" is helpful. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10028) Move XML/XSD validation test case to dist module

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-10028: ---------------------------------- Summary: Move XML/XSD validation test case to dist module Key: WFLY-10028 URL: https://issues.jboss.org/browse/WFLY-10028 Project: WildFly Issue Type: Task Components: Test Suite Affects Versions: 12.0.0.Final Reporter: Jeff Mesnil The StandardConfigsXMLValidationUnitTestCase and XSDValidationUnitTestCase tests validates that the XML and XSD files that are shipped with WildFly are valid. However, these tests are run by the smoke test suite and it is possible that previous tests have modified the configuration file that is used by the running WildFly server for the tests. This is mostly harmless (as these tests should cleaned up any modification when they are teared down) except when WildFly core is changing its schemas and the WildFly integration CI job is checking that WildFly core snapshots behave correctly. At this point, the WildFly XML configuration files references the latest XML version that is released with Core but the core snapshots introduced more recent versions. The tests uses the special property jboss.test.xml.validation.future.schemas to ignore the latest schema when using core snapshots. Unfortunately, the previous smoke tests may have modified the configuration file that will be written with the latest core schema version. To fix this issue, these 2 tests should be moved to the dist maven module so that they validate the *actual* configuration files shipped with WildFly before any test has an opportunity to modify them. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3686) Allow Nashorn Shell (jjs) in sun.scripting module

by Sean Flanigan (JIRA)

Sean Flanigan created WFCORE-3686: ------------------------------------- Summary: Allow Nashorn Shell (jjs) in sun.scripting module Key: WFCORE-3686 URL: https://issues.jboss.org/browse/WFCORE-3686 Project: WildFly Core Issue Type: Enhancement Components: Modules Reporter: Sean Flanigan Assignee: David Lloyd I would like to access JBoss CLI from a Nashorn {{jjs}} script (similar to https://developer.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJytho...), so that I can use conditionals, error recovery, functions, etc. To get the exactly correct version of the CLI jar, I want to get it from {{JBOSS_HOME}} as a module, which means I need to run {{jjs}} in a module environment, which I can do with a command like this: {code:bash} # jjs-module.sh JBOSS_HOME=$HOME/apps/wildfly-11.0.0.Final export JBOSS_HOME java \ -Djava.util.logging.manager=org.jboss.logmanager.LogManager \ -jar $JBOSS_HOME/jboss-modules.jar \ -modulepath $JBOSS_HOME/modules \ -dependencies org.jboss.as.cli,org.jboss.logmanager,sun.scripting \ -class jdk.nashorn.tools.Shell \ -scripting \ -strict \ configureAppServer.js {code} {code:javascript} // configureAppServer.js var cli = org.jboss.as.cli.scriptsupport.CLI.newInstance() cli.cmd("embed-server --std-out=echo") cli.cmd("stop-embedded-server") {code} Note: I had to test with WildFly 11 because of MODULES-271 (or similar) However, the script above currently doesn't work because the package {{jdk.nashorn.tools}} is not visible in the {{sun.scripting}} module. Given that several {{jdk.nashorn.internal.*}} packages are included, it doesn't seem like much of a stretch to include {{jdk.nashorn.tools}} too. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6634) Add remote-cache-container configuration to Infinispan subsystem

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-6634?page=com.atlassian.jira.plugin.... ] Richard Janík updated WFLY-6634: -------------------------------- Tester: (was: Richard Janík) > Add remote-cache-container configuration to Infinispan subsystem > ---------------------------------------------------------------- > > Key: WFLY-6634 > URL: https://issues.jboss.org/browse/WFLY-6634 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > Need to establish schema/model. > We probably want to create new capabilities for existing container/caches to expose generic BasicCache/BasicCacheContainer types. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2389) [DMN Editor] Add proper support for 3-part QName

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2389?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2389: -------------------------------- Tester: Jozef Marko > [DMN Editor] Add proper support for 3-part QName > ------------------------------------------------ > > Key: DROOLS-2389 > URL: https://issues.jboss.org/browse/DROOLS-2389 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > > The DMN Designer has a simplified {{QName}} that is composed of a single {{String}}. This needs to move to the standard 3-part (URI, prefix, local-part) version. May need a custom Form widget to present the three parts as a consolidated widget as opposed to three single {{TextBox}}'s. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6634) Add remote-cache-container configuration to Infinispan subsystem

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-6634?page=com.atlassian.jira.plugin.... ] Richard Janík commented on WFLY-6634: ------------------------------------- {quote} No, that's incorrect. {quote} Okay then. I think the RFE summary is misleading then - yes I read the analysis, but I still had the idea you plan on focusing on the security configuration of the {remote-cache-container}. I'll leave it be then, even though others may still have things to say. > Add remote-cache-container configuration to Infinispan subsystem > ---------------------------------------------------------------- > > Key: WFLY-6634 > URL: https://issues.jboss.org/browse/WFLY-6634 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > Need to establish schema/model. > We probably want to create new capabilities for existing container/caches to expose generic BasicCache/BasicCacheContainer types. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6634) Add remote-cache-container configuration to Infinispan subsystem

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-6634?page=com.atlassian.jira.plugin.... ] Richard Janík edited comment on WFLY-6634 at 3/15/18 3:16 AM: -------------------------------------------------------------- {quote} No, that's incorrect. {quote} Okay then. I think the RFE summary is misleading then - yes I read the analysis, but I still had the idea you plan on focusing on the security configuration of the {{remote-cache-container}}. I'll leave it be then, even though others may still have things to say. was (Author: rjanik): {quote} No, that's incorrect. {quote} Okay then. I think the RFE summary is misleading then - yes I read the analysis, but I still had the idea you plan on focusing on the security configuration of the {remote-cache-container}. I'll leave it be then, even though others may still have things to say. > Add remote-cache-container configuration to Infinispan subsystem > ---------------------------------------------------------------- > > Key: WFLY-6634 > URL: https://issues.jboss.org/browse/WFLY-6634 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > Need to establish schema/model. > We probably want to create new capabilities for existing container/caches to expose generic BasicCache/BasicCacheContainer types. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9996) Upgrade ActiveMQ Artemis to 1.5.5-010

by Viral Gohel (JIRA)

[ https://issues.jboss.org/browse/WFLY-9996?page=com.atlassian.jira.plugin.... ] Viral Gohel updated WFLY-9996: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/11016 > Upgrade ActiveMQ Artemis to 1.5.5-010 > ------------------------------------- > > Key: WFLY-9996 > URL: https://issues.jboss.org/browse/WFLY-9996 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Panagiotis Sotiropoulos > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10014) Unable to configure comma delimited enabled-protocols in remote-connector

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-10014?page=com.atlassian.jira.plugin... ] Miroslav Novak commented on WFLY-10014: --------------------------------------- [~jmesnil] I'll re-open this one as it's currently valid issue for WF12. This one can be set as resolved once Artemis is upgraded to 2.x version in WF next. > Unable to configure comma delimited enabled-protocols in remote-connector > ------------------------------------------------------------------------- > > Key: WFLY-10014 > URL: https://issues.jboss.org/browse/WFLY-10014 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 12.0.0.Final > Reporter: Nagaraju Chitimilla > Assignee: Jeff Mesnil > Priority: Critical > > When I want to configure enabled SSL protocols, Netty requires to use comma delimited list to be passed into enabled-protocols param in remote-connector > {noformat} > <param name="enabled-protocols" value="TLSv1.1,TLSv1.2"/> > {noformat} > But when comma is used in value in configuration string passed into ActiveMQRaUtils.parseConfig, parsing fails: > {code:java} > Caused by: java.lang.IllegalArgumentException: Invalid expression TLSv1.2 at enabledProtocols=TLSv1.1,TLSv1.2;trustStorePassword=N0tall0wed;keyStorePassword=N0tall0wed;port=61616;localAddress=0.0.0.0;sslEnabled=true;host=localhost;trustStorePath=C:/ActiveMQ/conf/keystore.p12;keyStorePath=C:/ActiveMQ/conf/keystore.p12 > at org.apache.activemq.artemis.ra.ActiveMQRaUtils.parseConfig(ActiveMQRaUtils.java:205) > at org.apache.activemq.artemis.ra.ActiveMQResourceAdapter.setConnectionParameters(ActiveMQResourceAdapter.java:342) > ... 18 more > {code} > I set this as critical as it prevent setting more then one allowed SSLContext protocol. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10014) Unable to configure comma delimited enabled-protocols in remote-connector

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-10014?page=com.atlassian.jira.plugin... ] Miroslav Novak reopened WFLY-10014: ----------------------------------- > Unable to configure comma delimited enabled-protocols in remote-connector > ------------------------------------------------------------------------- > > Key: WFLY-10014 > URL: https://issues.jboss.org/browse/WFLY-10014 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 12.0.0.Final > Reporter: Nagaraju Chitimilla > Assignee: Jeff Mesnil > Priority: Critical > > When I want to configure enabled SSL protocols, Netty requires to use comma delimited list to be passed into enabled-protocols param in remote-connector > {noformat} > <param name="enabled-protocols" value="TLSv1.1,TLSv1.2"/> > {noformat} > But when comma is used in value in configuration string passed into ActiveMQRaUtils.parseConfig, parsing fails: > {code:java} > Caused by: java.lang.IllegalArgumentException: Invalid expression TLSv1.2 at enabledProtocols=TLSv1.1,TLSv1.2;trustStorePassword=N0tall0wed;keyStorePassword=N0tall0wed;port=61616;localAddress=0.0.0.0;sslEnabled=true;host=localhost;trustStorePath=C:/ActiveMQ/conf/keystore.p12;keyStorePath=C:/ActiveMQ/conf/keystore.p12 > at org.apache.activemq.artemis.ra.ActiveMQRaUtils.parseConfig(ActiveMQRaUtils.java:205) > at org.apache.activemq.artemis.ra.ActiveMQResourceAdapter.setConnectionParameters(ActiveMQResourceAdapter.java:342) > ... 18 more > {code} > I set this as critical as it prevent setting more then one allowed SSLContext protocol. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 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 March 2018