[JBoss JIRA] (JBEE-158) EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/JBEE-158?page=com.atlassian.jira.plugin.s... ]
Scott Marlow closed JBEE-158.
-----------------------------
> EL 3 LambdaExpression failing with an exception irreversibly pollutes variable scope
> ------------------------------------------------------------------------------------
>
> Key: JBEE-158
> URL: https://issues.jboss.org/browse/JBEE-158
> Project: JBoss Enterprise Spec APIs
> Issue Type: Bug
> Components: jboss-el-api
> Affects Versions: jboss-el-api_3.0_spec-1.0.2.Final
> Reporter: Paul Pogonyshev
> Assignee: Tomaž Cerar
> Priority: Major
> Labels: el-expresion, patch
> Fix For: jboss-el-api_3.0_spec-1.0.6.Final
>
> Attachments: lambda-expression-scoping-fix.diff
>
>
> When a lambda expression is exited with an exception, its variables are left on stack and cannot be removed from it without hacks. My usecase is a customly defined function that uses exceptions as means of non-local exit, but the bug triggers even without custom functions, as demonstrated below.
> Test case:
> {noformat}
> ELProcessor processor = new ELProcessor ();
> processor.defineBean ("x", null);
> try {
> processor.eval ("(x -> x.bug ()) ('bug')");
> }
> catch (RuntimeException exception) {
> // This is expected, there is no method bug() on strings.
> }
> processor.eval ("x"); // This must evaluate to null, but instead evaluates to "bug".
> {noformat}
> Proposed fix will be attached as a short patch against 'javax/el/LambdaExpression.java'.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (WFWIP-167) EAP Operator handling ConfigMap internally
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-167?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFWIP-167:
-----------------------------------
The ConfigMap is the standard way to provide configuration to Kubernetes application and is well suited for this feature.
Having a file that must be accessible to the operator pod would be more complex to setup and less secure.
This should be considered as an advanced feature and should only be used if the provided standalone configuration can not match the application requirements with all the caveats you mention (ConfigMap are not immutable).
> EAP Operator handling ConfigMap internally
> ------------------------------------------
>
> Key: WFWIP-167
> URL: https://issues.jboss.org/browse/WFWIP-167
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
>
> If I understand description in [1] correctly. To specify custom standalone.xml I have to create ConfigMap with standalone.xml first and afterwards link operator to this ConfigMap.
> Is it possible to handle creation of ConfigMap and storing standalone.xml for me? Ideally I just specify file URI where custom standalone.xml is located. This location have to be accessible from operator pod. In this way we can look at it as hiding internals (implementation details) from users.
> Currently when user wants to change standalone.xml he does in ConfigMap, not operator. When changing standalone.xml through config map, I assume pod have to be restarted manually. Operator could do that for me.
> However this can be triggered by storing newer version of standalone.xml under another key, eg `standalone.xml.v2` and changing `StandaloneConfigMapSpec.key` in operator.
> What do you think? Have you considered this approach?
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#sta...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (WFCORE-4525) Fix failing tests on IBM JDK
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4525?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-4525:
---------------------------------------
[~ropalka] Sorry yeah only the {{SilentModeTestCase}} now passes. I did start looking at the other two failures, I just haven't had time to really dig on. What it looks like is the wrong log context is being used. There might be a simple workaround for it, I just need to find time to test it. Maybe I'll get some time today if it's as simple as I think it might be.
> Fix failing tests on IBM JDK
> ----------------------------
>
> Key: WFCORE-4525
> URL: https://issues.jboss.org/browse/WFCORE-4525
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Richard Opalka
> Assignee: James Perkins
> Priority: Major
> Attachments: forked-booter.png, ibm-jdk8.png, oracle-jdk.png
>
>
> The following tests are failing on latest IBM JDK 8:
> ---
> # testsuite/standalone
> SilentModeTestCase
> # testsuite/manualmode
> CLIEmbedHostControllerTestCase
> CLIEmbedServerTestCase
> ---
> Tested on:
> ---
> java version "1.8.0_211"
> Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled)
> OpenJ9 - 46e57f9
> OMR - 06a046a
> IBM - 0b909bf)
> JCL - 20190409_01 based on Oracle jdk8u211-b25
> ---
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months