February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6263) Apostrophe in an attribute with multiple EL parts breaks function lookup

by Paul Pogonyshev (JIRA)

[ https://issues.jboss.org/browse/WFLY-6263?page=com.atlassian.jira.plugin.... ] Paul Pogonyshev commented on WFLY-6263: --------------------------------------- Please note that the attached patch does not fix the bug in question. It only improves the error message. > Apostrophe in an attribute with multiple EL parts breaks function lookup > ------------------------------------------------------------------------ > > Key: WFLY-6263 > URL: https://issues.jboss.org/browse/WFLY-6263 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Paul Pogonyshev > Assignee: Jason Greene > Priority: Critical > Attachments: jastow-bug.war.zip, jastow.diff > > > Certain EL pieces result in unexplained org.apache.jasper.JasperException "contains invalid expression(s)" (the exception _does not_ explain what is invalid). After lots of tries, I have narrowed it down: 1) there must be several EL pieces in one string; 2) there must be an apostrophe in between. > This looks very similar to bug WFLY-4455. It breaks several pages in our application, blocking upgrade to WildFly 10. > Example is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1402) Add support for metaspacesize to jvm options and remove permgen

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1402?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1402: ------------------------------------------ We can't remove permgen from domain wide resources (i.e. stuff that persists to domain.xml); it's needed for legacy slave support. We shouldn't drop it from /host=* until we are working toward EAP 8; i.e. not in Core 3.x. Where would the Metaspace data be displayed? The actual effective metaspace settings for a server depend on the merging of the jvm configs from the various levels. I guess at the /host=*/server-config=* level the full set of data is known. > Add support for metaspacesize to jvm options and remove permgen > --------------------------------------------------------------- > > Key: WFCORE-1402 > URL: https://issues.jboss.org/browse/WFCORE-1402 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > We could display the configured Metaspace values, and we should remove the now deprecated permgen values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6263) Apostrophe in an attribute with multiple EL parts breaks function lookup

by Paul Pogonyshev (JIRA)

[ https://issues.jboss.org/browse/WFLY-6263?page=com.atlassian.jira.plugin.... ] Paul Pogonyshev updated WFLY-6263: ---------------------------------- Attachment: jastow.diff Tangentially related: improve Jastow to not (completely) swallow error message. Before the patch: ... contains invalid expression(s) After the patch: ... contains invalid expression(s): javax.el.ELException: Function 'fn:length' not found > Apostrophe in an attribute with multiple EL parts breaks function lookup > ------------------------------------------------------------------------ > > Key: WFLY-6263 > URL: https://issues.jboss.org/browse/WFLY-6263 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Paul Pogonyshev > Assignee: Jason Greene > Priority: Critical > Attachments: jastow-bug.war.zip, jastow.diff > > > Certain EL pieces result in unexplained org.apache.jasper.JasperException "contains invalid expression(s)" (the exception _does not_ explain what is invalid). After lots of tries, I have narrowed it down: 1) there must be several EL pieces in one string; 2) there must be an apostrophe in between. > This looks very similar to bug WFLY-4455. It breaks several pages in our application, blocking upgrade to WildFly 10. > Example is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1993) ENCRYPTAsymmetricTest fails on IBM jdk 1.8

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/JGRP-1993?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reopened JGRP-1993: ----------------------------------- Assignee: Tristan Tarrant (was: Bela Ban) > ENCRYPTAsymmetricTest fails on IBM jdk 1.8 > ------------------------------------------ > > Key: JGRP-1993 > URL: https://issues.jboss.org/browse/JGRP-1993 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.6 > Environment: IBM jdk 1.8 > Reporter: Richard Janík > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 3.6.8 > > > org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange fails on IBM jdk 1.8 (JGroups 3.6.6.Final): > {code} > Error Message > expected [javax.crypto.spec.SecretKeySpec@174de] but found [com.ibm.crypto.provider.AESSecretKey@e562eaa8] > Stacktrace > java.lang.AssertionError > at org.testng.Assert.fail(Assert.java:94) > at org.testng.Assert.failNotEquals(Assert.java:496) > at org.testng.Assert.assertEquals(Assert.java:125) > at org.testng.Assert.assertEquals(Assert.java:167) > at org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange(ENCRYPTAsymmetricTest.java:404) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:774) > at org.testng.TestRunner.run(TestRunner.java:624) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:359) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312) > at org.testng.SuiteRunner.run(SuiteRunner.java:261) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) > at org.testng.TestNG.run(TestNG.java:1048) > at org.testng.TestNG.privateMain(TestNG.java:1355) > at org.testng.TestNG.main(TestNG.java:1324) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6263) Apostrophe in an attribute with multiple EL parts breaks function lookup

by Paul Pogonyshev (JIRA)

Paul Pogonyshev created WFLY-6263: ------------------------------------- Summary: Apostrophe in an attribute with multiple EL parts breaks function lookup Key: WFLY-6263 URL: https://issues.jboss.org/browse/WFLY-6263 Project: WildFly Issue Type: Bug Affects Versions: 10.0.0.Final Reporter: Paul Pogonyshev Assignee: Jason Greene Priority: Critical Attachments: jastow-bug.war.zip Certain EL pieces result in unexplained org.apache.jasper.JasperException "contains invalid expression(s)" (the exception _does not_ explain what is invalid). After lots of tries, I have narrowed it down: 1) there must be several EL pieces in one string; 2) there must be an apostrophe in between. This looks very similar to bug WFLY-4455. It breaks several pages in our application, blocking upgrade to WildFly 10. Example is attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-250) Javassist gets confused by certain synthetic bridges, produces invalid bytecode

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-250?page=com.atlassian.jira.plugi... ] Shigeru Chiba resolved JASSIST-250. ----------------------------------- Fix Version/s: 3.21.0-GA Resolution: Done > Javassist gets confused by certain synthetic bridges, produces invalid bytecode > ------------------------------------------------------------------------------- > > Key: JASSIST-250 > URL: https://issues.jboss.org/browse/JASSIST-250 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Environment: Ubuntu 15.04, JDK 1.8.0_51. > Reporter: Jari Juslin > Assignee: Shigeru Chiba > Fix For: 3.21.0-GA > > Attachments: Bar.java, BaseFoo.java, Foo.java, IBarProvider.java, IExpirationProvider.java, JavassistSyntheticBridgeTest.java > > > Javassist gets confused by synthetic bridge methods javac has implicitly created and then creates method calls to the bytecode that don't pass the JVM verify stage. > The situation here is that we have a class Foo, that has superclass BaseFoo implementing an interface IBarProvider. BaseFoo has method Bar getBar(), which is also in the IBarProvider. The IBarProvider defines the method as IExpirationProvider getBar(), where IExpirationProvider is an interface implemented by Bar. > Now, for some reason I am not completely sure about, javac creates a synthetic bridge method to Foo class with erasure of IExpirationProvider getBar which then just passes the call to the Bar BaseFoo.getBar. When Javassist load the class, it misses the fact that the superclass contains method with same name and wider return scope and instead calls the Foo level method also in cases where Bar is needed, not just IExpirationProvider. If it just ignored the synthetic bridge methods altogether, this would work as expected and as Oracle javac handles it. > The resulting error: > Exception in thread "main" java.lang.VerifyError: Bad return type > Exception Details: > Location: > InstrumentedClass.getBar()LBar; @4: areturn > Reason: > Type 'IExpirationProvider' (current frame, stack[0]) is not assignable to 'Bar' (from method signature) > Current Frame: > bci: @4 > flags: { } > locals: { 'InstrumentedClass' } > stack: { 'IExpirationProvider' } > Bytecode: > 0x0000000: 2ab7 000b b0 > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) > at java.lang.Class.getConstructor0(Class.java:3075) > at java.lang.Class.getConstructor(Class.java:1825) > at JavassistSyntheticBridgeTest.main(JavassistSyntheticBridgeTest.java:19) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-250) Javassist gets confused by certain synthetic bridges, produces invalid bytecode

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-250?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-250. --------------------------------- > Javassist gets confused by certain synthetic bridges, produces invalid bytecode > ------------------------------------------------------------------------------- > > Key: JASSIST-250 > URL: https://issues.jboss.org/browse/JASSIST-250 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Environment: Ubuntu 15.04, JDK 1.8.0_51. > Reporter: Jari Juslin > Assignee: Shigeru Chiba > Fix For: 3.21.0-GA > > Attachments: Bar.java, BaseFoo.java, Foo.java, IBarProvider.java, IExpirationProvider.java, JavassistSyntheticBridgeTest.java > > > Javassist gets confused by synthetic bridge methods javac has implicitly created and then creates method calls to the bytecode that don't pass the JVM verify stage. > The situation here is that we have a class Foo, that has superclass BaseFoo implementing an interface IBarProvider. BaseFoo has method Bar getBar(), which is also in the IBarProvider. The IBarProvider defines the method as IExpirationProvider getBar(), where IExpirationProvider is an interface implemented by Bar. > Now, for some reason I am not completely sure about, javac creates a synthetic bridge method to Foo class with erasure of IExpirationProvider getBar which then just passes the call to the Bar BaseFoo.getBar. When Javassist load the class, it misses the fact that the superclass contains method with same name and wider return scope and instead calls the Foo level method also in cases where Bar is needed, not just IExpirationProvider. If it just ignored the synthetic bridge methods altogether, this would work as expected and as Oracle javac handles it. > The resulting error: > Exception in thread "main" java.lang.VerifyError: Bad return type > Exception Details: > Location: > InstrumentedClass.getBar()LBar; @4: areturn > Reason: > Type 'IExpirationProvider' (current frame, stack[0]) is not assignable to 'Bar' (from method signature) > Current Frame: > bci: @4 > flags: { } > locals: { 'InstrumentedClass' } > stack: { 'IExpirationProvider' } > Bytecode: > 0x0000000: 2ab7 000b b0 > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) > at java.lang.Class.getConstructor0(Class.java:3075) > at java.lang.Class.getConstructor(Class.java:1825) > at JavassistSyntheticBridgeTest.main(JavassistSyntheticBridgeTest.java:19) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1234) DuplicateServiceException or there is no activation, if the ServiceActivator is moved from the jar module to the EAR deployment level.

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1234?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos commented on WFCORE-1234: ------------------------------------------------- The PR does enable the activation of the service if the the ServiceActivator only exists on the EAR deployment level (It should be inside the jar module as well). > DuplicateServiceException or there is no activation, if the ServiceActivator is moved from the jar module to the EAR deployment level. > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1234 > URL: https://issues.jboss.org/browse/WFCORE-1234 > Project: WildFly Core > Issue Type: Bug > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > If one EAR contains more than one module with a META-INF/services/org.jboss.msc.service.ServiceActivator, > If the file is moved to the ear/META-INF as the only one there is no activation. > If the ear and a jar contain it it will fail with a org.jboss.msc.service.DuplicateServiceException. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1561) Fluent configuration for JChannel and other classes; make attrs accessible via ResourceDMBean

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1561?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1561. ---------------------------- Resolution: Done > Fluent configuration for JChannel and other classes; make attrs accessible via ResourceDMBean > --------------------------------------------------------------------------------------------- > > Key: JGRP-1561 > URL: https://issues.jboss.org/browse/JGRP-1561 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > E.g. JChannel.connect() should return JChannel, so we can say > JChannel a=createChannel().name("A").connect("cluster"); > Once we have getters / setters like JChannel name(String n), we need to change ResourceDMBean as it expects getters and setters to start with getXXX() and setXXX(). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1234) DuplicateServiceException or there is no activation, if the ServiceActivator is moved from the jar module to the EAR deployment level.

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1234?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos updated WFCORE-1234: -------------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1434 > DuplicateServiceException or there is no activation, if the ServiceActivator is moved from the jar module to the EAR deployment level. > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1234 > URL: https://issues.jboss.org/browse/WFCORE-1234 > Project: WildFly Core > Issue Type: Bug > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > If one EAR contains more than one module with a META-INF/services/org.jboss.msc.service.ServiceActivator, > If the file is moved to the ear/META-INF as the only one there is no activation. > If the ear and a jar contain it it will fail with a org.jboss.msc.service.DuplicateServiceException. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 February 2016