[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ]
Kabir Khan reopened WFLY-6784:
------------------------------
> Add possibility to enable websocket compression via management model
> --------------------------------------------------------------------
>
> Key: WFLY-6784
> URL: https://issues.jboss.org/browse/WFLY-6784
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Radim Hatlapatka
> Assignee: Ingo Weiss
> Priority: Critical
> Labels: downstream_dependency
> Fix For: 11.0.0.Alpha1
>
> Original Estimate: 2 days
> Time Spent: 2 days
> Remaining Estimate: 0 minutes
>
> In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client.
> There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1313:
---------------------------------------
I forgot to mention, we have thousands of rules, we use the approach outlined above to try to avoid rewriting the entire kfs when rules change. When a rule changes, we simply delete the old file and add a new one with a new name into the existing KieFileSystem.
-BillT
> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
> Key: DROOLS-1313
> URL: https://issues.jboss.org/browse/DROOLS-1313
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: SAVE_SimpleTest.java, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> - Create a new ReleaseId
> - Create a new KieFileSystem
> - Generate and write the PomXML for the ReleaseId created above
> - Create a new KieModuleModel
> - Create a new KieBaseModel
> - Write the ModuleModel XML to the KieFileSystem
> - Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> - Create a new KieBuilder
> - Do a buildall() with the KieBuilder
> - Create a new KieContainer
> - Create a new KieSession from the KieContainer
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> - Delete 2 rules from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
> - Rule_120_Triggered_Part_1_ 0 is not there
> - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> - Delete 1 rule from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
> - Rule_120_Triggered_Part_1_ 0 is STILL not there
> - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (WFLY-7209) Operation to list installed Resource Adapters
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero commented on WFLY-7209:
----------------------------------------------------
>From what I saw, it seemed to me that the resource adapter was automatically activated even without the ironjacamar.xml descriptor. I'll have to check it.
My use case is to list the currently deployed resource adapters (activated or not). As it currently works, in the web console you have to specify the deployment or module name by manually typing. This would basically allow graphical UIs to show a list of possible candidates, like it works for JDBC drivers.
As a side note, the resource-adapters subsystem is not listed on deployments (https://wildscribe.github.io/Wildfly/10.0.0.Final/deployment/index.html). Are there any technical reasons for that? Is it only present when there's an iconjacamar.xml descriptor present?
> Operation to list installed Resource Adapters
> ---------------------------------------------
>
> Key: WFLY-7209
> URL: https://issues.jboss.org/browse/WFLY-7209
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Guillermo González de Agüero
> Assignee: Stefano Maestri
> Fix For: 10.1.0.Final
>
>
> Currently there's no way to list all the installed Resource Adapters. Only configured resource adapters can be queried. However, they are automatically enabled at deployment time.
> I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Bill Tuminaro (JIRA)
Bill Tuminaro created DROOLS-1313:
-------------------------------------
Summary: Memory Leak - but is this a supported scenario for Dynamic rule management
Key: DROOLS-1313
URL: https://issues.jboss.org/browse/DROOLS-1313
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Bill Tuminaro
Assignee: Mario Fusco
Attachments: SAVE_SimpleTest.java, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG
I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
The attached source does this:
+*Initialize stuff*+
- Create a new ReleaseId
- Create a new KieFileSystem
- Generate and write the PomXML for the ReleaseId created above
- Create a new KieModuleModel
- Create a new KieBaseModel
- Write the ModuleModel XML to the KieFileSystem
- Write 2 rules into the KieFileSystem
+*1st build and dump*+
- Create a new KieBuilder
- Do a buildall() with the KieBuilder
- Create a new KieContainer
- Create a new KieSession from the KieContainer
- Print out the rules in the KieContainer for the package used in my rules
- Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
+*2nd build and dump*+
- Delete 2 rules from the KieFileSystem created above
- Call incrementalBuild() on the KieBuilder created above
- Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
- Add 2 new rules to the KieFileSystem created above
- Call incrementalBuild() on the KieBuilder created above
- Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
- Print out the rules in the KieContainer for the package used in my rules
- Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
- Rule_120_Triggered_Part_1_ 0 is not there
- Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
+*3rd build and dump*+
- Delete 1 rule from the KieFileSystem created above
- Call incrementalBuild() on the KieBuilder created above
- Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
- Add 2 new rules to the KieFileSystem created above
- Call incrementalBuild() on the KieBuilder created above
- Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
- Print out the rules in the KieContainer for the package used in my rules
- Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
- Rule_120_Triggered_Part_1_ 0 is STILL not there
- TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
- Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-7229:
------------------------------------
[~micnowak1] I had a look at your MainServlet. Your mechanism for invalidating the session is problematic. The servlet spec does not require containers to support the HttpSession interface outside the context of a request or listener. The HttpSession API already has a mechanism for controlling invalidation:
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html#s...
e.g.
session.setMaxInactiveInterval(10);
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Paul Ferraro
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-7229.
------------------------------
Resolution: Rejected
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Paul Ferraro
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-261:
---------------------------------------
Sounds good if Java 9 is released as scheduled. :-p
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-261:
--------------------------------------
[~chiba] I changed my mind. :-) How about if we first release master as 3.21.0 and then merge test/java9-jigsaw to master and release as 3.22.0-CR1.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years