February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBEE-174) Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.s... ] Ivo Studensky edited comment on JBEE-174 at 2/28/17 12:00 PM: -------------------------------------------------------------- [~rhatlapa] see JBEE-173 for the property way was (Author: istudens): [~rhatlapa] see JBEE-173 for property way > Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable > ----------------------------------------------------------------------- > > Key: JBEE-174 > URL: https://issues.jboss.org/browse/JBEE-174 > Project: JBoss JavaEE Spec APIs > Issue Type: Enhancement > Components: jboss-el-api > Reporter: Masafumi Miura > Assignee: Tomaz Cerar > > [UEL-38|https://java.net/jira/browse/UEL-38] introduced an EL 2.2 backward compatible switch {{"javax.el.bc2.2"}}. However, it's currently unable to enable this in EAP 7. Improve this and expose this properly via configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-174) Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.s... ] Ivo Studensky commented on JBEE-174: ------------------------------------ [~rhatlapa] see JBEE-173 for property way > Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable > ----------------------------------------------------------------------- > > Key: JBEE-174 > URL: https://issues.jboss.org/browse/JBEE-174 > Project: JBoss JavaEE Spec APIs > Issue Type: Enhancement > Components: jboss-el-api > Reporter: Masafumi Miura > Assignee: Tomaz Cerar > > [UEL-38|https://java.net/jira/browse/UEL-38] introduced an EL 2.2 backward compatible switch {{"javax.el.bc2.2"}}. However, it's currently unable to enable this in EAP 7. Improve this and expose this properly via configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-981) Coverity static analysis: Performace optimalization in map iterating

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-981?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev updated ELY-981: ------------------------------ Affects Version/s: 1.1.0.Beta27 > Coverity static analysis: Performace optimalization in map iterating > -------------------------------------------------------------------- > > Key: ELY-981 > URL: https://issues.jboss.org/browse/ELY-981 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.1.0.Beta27 > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Minor > > Coverity static analysis found iterating over map can be enhanced > https://scan7.coverity.com/reports.htm#v23632/p12664/fileInstanceId=84867... > Instead of Map.keySet() + Map.get() combo use just Map.entrySet(). > > {code:java|title=ElytronHttpExchange#getRequestParameters} > for (String name : queryParameters.keySet()) { > List<String> values = new ArrayList<>(queryParameters.get(name)); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugi... ] Ken Wills resolved WFCORE-2292. ------------------------------- Resolution: Duplicate Issue > HTTPS / Native Management protocol mismatch when using SSL > ---------------------------------------------------------- > > Key: WFCORE-2292 > URL: https://issues.jboss.org/browse/WFCORE-2292 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Ken Wills > Assignee: Ken Wills > > It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce88... may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large. > 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl@2ab25536 > 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@787e0a1f > 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192]) > ^^^^^^^ > 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192] > 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF > 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream > 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl@1cc4241b > This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with: > ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password > Relevant bits of config in use: > {quote} > <management> > <security-realms> > <security-realm name="sslSecurityRealm"> > <server-identities> > <ssl> > <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/> > </ssl> > </server-identities> > <authentication> > <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/> > </authentication> > </security-realm> > </security-realms> > <management-interfaces> > <native-interface security-realm="sslSecurityRealm"> > <socket-binding native="native"/> > </native-interface> > </management-interfaces> > </management> > <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> > <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> > <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/> > <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/> > </socket-binding-group> > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-981) Coverity static analysis: Performace optimalization in map iterating

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-981?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev moved WFLY-7956 to ELY-981: ----------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-981 (was: WFLY-7956) Component/s: HTTP (was: Security) Affects Version/s: (was: 11.0.0.Alpha1) > Coverity static analysis: Performace optimalization in map iterating > -------------------------------------------------------------------- > > Key: ELY-981 > URL: https://issues.jboss.org/browse/ELY-981 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Minor > > Coverity static analysis found iterating over map can be enhanced > https://scan7.coverity.com/reports.htm#v23632/p12664/fileInstanceId=84867... > Instead of Map.keySet() + Map.get() combo use just Map.entrySet(). > > {code:java|title=ElytronHttpExchange#getRequestParameters} > for (String name : queryParameters.keySet()) { > List<String> values = new ArrayList<>(queryParameters.get(name)); > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2342) CLI can't connect to DC on native port without defined remote protocol

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2342?page=com.atlassian.jira.plugi... ] Ken Wills moved JBEAP-9197 to WFCORE-2342: ------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2342 (was: JBEAP-9197) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI Remoting Security (was: CLI) (was: Remoting) (was: Security) Affects Version/s: (was: 7.1.0.DR12) Affects Testing: (was: Regression) > CLI can't connect to DC on native port without defined remote protocol > ---------------------------------------------------------------------- > > Key: WFCORE-2342 > URL: https://issues.jboss.org/browse/WFCORE-2342 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Remoting, Security > Reporter: Ken Wills > Assignee: Ken Wills > Priority: Blocker > Labels: cli, regression, remoting, ssl > > CLI is able to connect to DC to native port (9999) only when protocol _remote_ is specified. It is regression, EAP 7.0.0.GA is able to connect when no protocol is defined or with _remoting_ and _remote_ (maybe some others). > EAP 7.0.0.GA > {noformat} > msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 > [domain@127.0.0.1:9999 /] quit > msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=remoting://127.0.0.1:9999 > [domain@127.0.0.1:9999 /] quit > msimka@msimka-t450:/tmp/GA/jboss-eap-7.0$ ./bin/jboss-cli.sh -c --controller=remote://127.0.0.1:9999 > [domain@127.0.0.1:9999 /] quit > {noformat} > EAP 7.1.0.DR12 > {noformat} > msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 > Failed to connect to the controller: Unable to negotiate SSL connection with controller at 127.0.0.1:9999 > msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=remoting://127.0.0.1:9999 > Failed to connect to the controller: Unable to negotiate SSL connection with controller at 127.0.0.1:9999 > msimka@msimka-t450:/tmp/jboss-eap-7.1$ ./bin/jboss-cli.sh -c --controller=remote://127.0.0.1:9999 > [domain@127.0.0.1:9999 /] quit > {noformat} > Stacktrace from attached jboss-cli.log > {noformat} > 15:46:26,184 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection? > at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156) > at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868) > at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) > at org.xnio.ssl.JsseStreamConduit.performIO(JsseStreamConduit.java:1364) > at org.xnio.ssl.JsseStreamConduit.read(JsseStreamConduit.java:991) > at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123) > at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:165) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:160) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.ssl.JsseStreamConduit.run(JsseStreamConduit.java:446) > at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:468) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2217: ------------------------------------- Fix Version/s: 4.0.0.Alpha1 (was: 4.0.0.Beta1) (was: 3.0.0.Beta7) [~kabirkhan] I'm removing this from the 3.0.0 schedule, as it seems complex and risky but not critical. If I'm wrong about that please reschedule. > ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests > ----------------------------------------------------------------------------------- > > Key: WFCORE-2217 > URL: https://issues.jboss.org/browse/WFCORE-2217 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: Kabir Khan > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... does not get called. > The fix is quite simple: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full. > I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives. > For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > So although the fix is simple, the fallout of this is quite big. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-174) Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar commented on JBEE-174: ---------------------------------- [~rhatlapa] wdyt about introducing {{org.wildfly.el.bc2.2=true}} property for enabling this. > Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable > ----------------------------------------------------------------------- > > Key: JBEE-174 > URL: https://issues.jboss.org/browse/JBEE-174 > Project: JBoss JavaEE Spec APIs > Issue Type: Enhancement > Components: jboss-el-api > Reporter: Masafumi Miura > Assignee: Tomaz Cerar > > [UEL-38|https://java.net/jira/browse/UEL-38] introduced an EL 2.2 backward compatible switch {{"javax.el.bc2.2"}}. However, it's currently unable to enable this in EAP 7. Improve this and expose this properly via configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-174) Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-174?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar moved WFLY-7774 to JBEE-174: ---------------------------------------- Project: JBoss JavaEE Spec APIs (was: WildFly) Key: JBEE-174 (was: WFLY-7774) Issue Type: Enhancement (was: Bug) Workflow: classic default workflow (was: GIT Pull Request workflow ) Component/s: jboss-el-api (was: EE) Target Release: (was: 7.1.0.GA) Affects Version/s: (was: 10.1.0.Final) > Make an EL 2.2 backward compatible switch "javax.el.bc2.2" configurable > ----------------------------------------------------------------------- > > Key: JBEE-174 > URL: https://issues.jboss.org/browse/JBEE-174 > Project: JBoss JavaEE Spec APIs > Issue Type: Enhancement > Components: jboss-el-api > Reporter: Masafumi Miura > Assignee: Tomaz Cerar > > [UEL-38|https://java.net/jira/browse/UEL-38] introduced an EL 2.2 backward compatible switch {{"javax.el.bc2.2"}}. However, it's currently unable to enable this in EAP 7. Improve this and expose this properly via configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1958) Clean up testsuite Elytron registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1958?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1958: ------------------------------------------ Besides the one remaining test, I have no idea what this was about. :) I just reenabled a bunch of ignored tests because they pass and are needed to guard against regressions. But there may very well be some work that was meant to happen that still needs to happen. > Clean up testsuite Elytron registration > --------------------------------------- > > Key: WFCORE-1958 > URL: https://issues.jboss.org/browse/WFCORE-1958 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta7 > > > In a couple of places we have artificially registered the WildFly Elytron Security provider, we need to address this so tests can automatically have it available to them.. > Also re-enable the following test case: - > * org.jboss.as.test.integration.domain.suites.FullRbacProviderRunAsTestSuite -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2017