[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2103?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2103:
---------------------------
Fix Version/s: 3.6.12
> GroupRequest times out when the only recipient leaves too soon
> --------------------------------------------------------------
>
> Key: JGRP-2103
> URL: https://issues.jboss.org/browse/JGRP-2103
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.12
>
>
> There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
> If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
> {code}
> public void testCastToMissingNode() throws Exception {
> d1.setRequestHandler(new MyHandler(new byte[10]));
> b = createChannel(a);
> b.setName("B");
> final CountDownLatch targetLatch = new CountDownLatch(1);
> d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
> @Override
> public Object handle(Message msg) throws Exception {
> targetLatch.await();
> return null;
> }
> });
> b.connect("MessageDispatcherUnitTest");
> Assert.assertEquals(2, b.getView().size());
> final CountDownLatch futureLatch = new CountDownLatch(1);
> FutureListener listener = new FutureListener() {
> @Override
> public void futureDone(Future future) {
> futureLatch.countDown();
> }
> };
> List<Address> dests = Collections.singletonList(b.getAddress());
> byte[] buf = new byte[1];
> Message msg = new Message();
> msg.setBuffer(buf);
> NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
> b.disconnect();
> Thread.sleep(100);
> future.setListener(listener);
> assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
> targetLatch.countDown();
> }
> {code}
> If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2103?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2103:
--------------------------------
I'll take a look. I assume this doesn't happen in 4.0?
> GroupRequest times out when the only recipient leaves too soon
> --------------------------------------------------------------
>
> Key: JGRP-2103
> URL: https://issues.jboss.org/browse/JGRP-2103
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.12
>
>
> There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
> If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
> {code}
> public void testCastToMissingNode() throws Exception {
> d1.setRequestHandler(new MyHandler(new byte[10]));
> b = createChannel(a);
> b.setName("B");
> final CountDownLatch targetLatch = new CountDownLatch(1);
> d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
> @Override
> public Object handle(Message msg) throws Exception {
> targetLatch.await();
> return null;
> }
> });
> b.connect("MessageDispatcherUnitTest");
> Assert.assertEquals(2, b.getView().size());
> final CountDownLatch futureLatch = new CountDownLatch(1);
> FutureListener listener = new FutureListener() {
> @Override
> public void futureDone(Future future) {
> futureLatch.countDown();
> }
> };
> List<Address> dests = Collections.singletonList(b.getAddress());
> byte[] buf = new byte[1];
> Message msg = new Message();
> msg.setBuffer(buf);
> NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
> b.disconnect();
> Thread.sleep(100);
> future.setListener(listener);
> assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
> targetLatch.countDown();
> }
> {code}
> If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Dan Berindei (JIRA)
Dan Berindei created JGRP-2103:
----------------------------------
Summary: GroupRequest times out when the only recipient leaves too soon
Key: JGRP-2103
URL: https://issues.jboss.org/browse/JGRP-2103
Project: JGroups
Issue Type: Bug
Reporter: Dan Berindei
Assignee: Bela Ban
There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
{code}
public void testCastToMissingNode() throws Exception {
d1.setRequestHandler(new MyHandler(new byte[10]));
b = createChannel(a);
b.setName("B");
final CountDownLatch targetLatch = new CountDownLatch(1);
d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
@Override
public Object handle(Message msg) throws Exception {
targetLatch.await();
return null;
}
});
b.connect("MessageDispatcherUnitTest");
Assert.assertEquals(2, b.getView().size());
final CountDownLatch futureLatch = new CountDownLatch(1);
FutureListener listener = new FutureListener() {
@Override
public void futureDone(Future future) {
futureLatch.countDown();
}
};
List<Address> dests = Collections.singletonList(b.getAddress());
byte[] buf = new byte[1];
Message msg = new Message();
msg.setBuffer(buf);
NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
b.disconnect();
Thread.sleep(100);
future.setListener(listener);
assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
targetLatch.countDown();
}
{code}
If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-2103?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated JGRP-2103:
-------------------------------
Affects Version/s: 3.6.10
> GroupRequest times out when the only recipient leaves too soon
> --------------------------------------------------------------
>
> Key: JGRP-2103
> URL: https://issues.jboss.org/browse/JGRP-2103
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dan Berindei
> Assignee: Bela Ban
>
> There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
> If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
> {code}
> public void testCastToMissingNode() throws Exception {
> d1.setRequestHandler(new MyHandler(new byte[10]));
> b = createChannel(a);
> b.setName("B");
> final CountDownLatch targetLatch = new CountDownLatch(1);
> d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
> @Override
> public Object handle(Message msg) throws Exception {
> targetLatch.await();
> return null;
> }
> });
> b.connect("MessageDispatcherUnitTest");
> Assert.assertEquals(2, b.getView().size());
> final CountDownLatch futureLatch = new CountDownLatch(1);
> FutureListener listener = new FutureListener() {
> @Override
> public void futureDone(Future future) {
> futureLatch.countDown();
> }
> };
> List<Address> dests = Collections.singletonList(b.getAddress());
> byte[] buf = new byte[1];
> Message msg = new Message();
> msg.setBuffer(buf);
> NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
> b.disconnect();
> Thread.sleep(100);
> future.setListener(listener);
> assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
> targetLatch.countDown();
> }
> {code}
> If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7234) Ability to identify primary singleton provider node
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7234:
----------------------------------
Summary: Ability to identify primary singleton provider node
Key: WFLY-7234
URL: https://issues.jboss.org/browse/WFLY-7234
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The current Singleton interface only allow a user to tell whether or not the current node is the singleton provider. Most backup services will proxy the service of the primary node, and thus will need to be able to identify which node is the current primary provider.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2102:
---------------------------
Fix Version/s: (was: 4.0)
{{bind_interface}} is not present in 4.0 anymore
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7226:
-------------------------------------
Hi [~honza889], do you mind if I work on this one?
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Steve Ebersole edited comment on JASSIST-261 at 9/28/16 9:02 AM:
-----------------------------------------------------------------
Initially I had incorrectly run the Hibernate tests with this Javassist SNAPSHOT using JDK 8 and all the tests passed. The changes also got those tests previously failing due to Javassist in Java 9 to pass when running with JDK 9. So it would seem to me (limited to Hibernate's usage) that your changes leave Javassist simultaneously compatible with Java 8 and Java 9. Therefore I'd personally not worry about Java 9 still being ea. However Java 9 is still evolving, and as Scott pointed out, one of the current change proposals specifically targets better operability with reflective libraries (such as Javassist) so I'd anticipate having to at least verify this all works with later Java 9 releases.
If you want to start "Java 9 support" with a new version increment (3.20 -> 3.21) then I'd suggest a 3.21.0.CR1 for now. That gives Hibernate and others a named Javassist release to target, but still gives you the flexibility to adjust for later changes made in coming Java 9 updates prior to a 3.21 GA/Final
was (Author: sebersole):
Did you had to make code changes in Javassist to make it Java 9 compatible? And if so, did those changes make it incompatible with Java 8?
Initially I had incorrectly run the Hibernate tests with this Javassist SNAPSHOT using JDK 8 and all the tests passed. The changes also got those tests previously failing due to Javassist in Java 9 to pass. So it would seem to me (limited to Hibernate's usage) that your changes leave Javassist simultaneously compatible with Java 8 and Java 9. Therefore I'd personally not worry about Java 9 still being ea. However Java 9 is still evolving, and as Scott pointed out, one of the current change proposals specifically targets better operability with reflective libraries (such as Javassist) so I'd anticipate having to at least verify this all works with later Java 9 releases.
If you want to start "Java 9 support" with a new version increment (3.20 -> 3.21) then I'd suggest a 3.21.0.CR1 for now. That gives Hibernate and others a named Javassist release to target, but still gives you the flexibility to adjust for later changes made in coming Java 9 updates prior to a 3.21 GA/Final
> 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, 7 months