[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-7260:
------------------------------------
So just document "If both are set to true then 'need' will always have the highest priority" . And I think documentation of difference between this two (similar) options would be also helpful for users, as not everybody is familiar with that. Btw. I like idea of "authentication mode", but not requesting it here, as I think better documentation will be enough.
Also don't forget to sync new model documentation with XSD documentation.
> Document in elytron model *-client-auth are mutual exclusive
> ------------------------------------------------------------
>
> Key: WFLY-7260
> URL: https://issues.jboss.org/browse/WFLY-7260
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Minor
>
> Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset.
> Now we just have:
> * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true."
> * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1852) Logging configuration service for dynamic deployment resources uses wrong service name for deployments
by James Perkins (JIRA)
James Perkins created WFCORE-1852:
-------------------------------------
Summary: Logging configuration service for dynamic deployment resources uses wrong service name for deployments
Key: WFCORE-1852
URL: https://issues.jboss.org/browse/WFCORE-1852
Project: WildFly Core
Issue Type: Bug
Reporter: James Perkins
Ideally if the use of a service can be removed that would be best. What's needed is a way to associate a deployments resource with a {{LogContextConfiguration}}. One option is to use a custom resource that the OSH can get the {{LogContextConfiguration}} from. This is already done for the child resources. See the {{LoggingDeploymentResources}}. The OSH can cast the resource and just get the configuration.
{quote}
[12:08 PM] Brian Stansberry: @jperkins this doesn't look right: https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java....
[12:09 PM] Brian Stansberry: AFAICT it is using the management name of a deployment to create an MSC ServiceName
[12:10 PM] James R Perkins: @BrianStansberry Hmm. ...yeah. Let me look at why I was doing that.
[12:13 PM] James R Perkins: @BrianStansberry Yes that's what it's doing which thinking about it does seem wrong. Essentially it's trying to figure out which service to use for a dynamic resource on the /deployment=some.war/subsystem=logging/configuration=whatever
[12:14 PM] Brian Stansberry: you need to use the runtime-name attribute of the deployment
[12:14 PM] James R Perkins: Really it's kind of a bad use case for a service.
[12:14 PM] Brian Stansberry: I guess subdeployment has one too, although it's redundant
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Maciej Swiderski commented on DROOLS-987:
-----------------------------------------
it looks like the change we have done to resolve the problem are still causing some issue in ejb based tests of jbpm. That at the moment is not found what is the issue but looks like really weird one as it fails most of the time with transaction rollback due to hibernate trying to do an update on an entity that was not yet inserted. Thus causing exception as such update on JDBC layer returns 0 rows updated while the expectation is 1.
So at the moment linked above PRs (especially one in jbpm) cannot be merged.
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Mario Fusco
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1845) Logging subsystem scans the CWD on server boot
by Brent Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1845?page=com.atlassian.jira.plugi... ]
Brent Douglas updated WFCORE-1845:
----------------------------------
Issue Type: Bug (was: Feature Request)
> Logging subsystem scans the CWD on server boot
> ----------------------------------------------
>
> Key: WFCORE-1845
> URL: https://issues.jboss.org/browse/WFCORE-1845
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Environment: OSX El Capitan, Oracle JDK 1.8.0_92 && 101, swarm 2016.8.1, WF 10.0.0.Final, WF-CORE 2.0.10.Final
> Reporter: Brent Douglas
> Assignee: James Perkins
>
> When booting the server from a directory where the subtree is large the server hangs for a long time. JStack shows that the logging subsystem is scanning the CWD.
> Booting the server from the root dir of a maven parent project containing 2 subprojects, a swarm project and a small NPM subproject added 33s to the server boot time compared to stepping into the swarm project and booting it.
> Stacktrace while the server is booting:
> {noformat}
> Thread 25859: (state = IN_NATIVE)
> - sun.nio.fs.UnixNativeDispatcher.lstat0(long, sun.nio.fs.UnixFileAttributes) @bci=0 (Compiled frame; information may be imprecise)
> - sun.nio.fs.UnixNativeDispatcher.lstat(sun.nio.fs.UnixPath, sun.nio.fs.UnixFileAttributes) @bci=10, line=300 (Compiled frame)
> - sun.nio.fs.UnixFileAttributes.get(sun.nio.fs.UnixPath, boolean) @bci=22, line=72 (Compiled frame)
> - sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes() @bci=15, line=52 (Compiled frame)
> - sun.nio.fs.UnixFileSystemProvider.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=57, line=144 (Compiled frame)
> - java.nio.file.Files.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=7, line=1737 (Compiled frame)
> - java.nio.file.FileTreeWalker.getAttributes(java.nio.file.Path, boolean) @bci=56, line=219 (Compiled frame)
> - java.nio.file.FileTreeWalker.visit(java.nio.file.Path, boolean, boolean) @bci=3, line=276 (Compiled frame)
> - java.nio.file.FileTreeWalker.next() @bci=134, line=372 (Compiled frame)
> - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.util.Set, int, java.nio.file.FileVisitor) @bci=256, line=2706 (Compiled frame)
> - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.nio.file.FileVisitor) @bci=9, line=2742 (Interpreted frame)
> - org.jboss.as.logging.LoggingResource.findFiles(java.lang.String, org.jboss.dmr.ModelNode, boolean) @bci=47, line=251 (Interpreted frame)
> - org.jboss.as.logging.LoggingResource.getChildrenNames(java.lang.String) @bci=37, line=157 (Interpreted frame)
> - org.jboss.as.logging.LoggingResource.getChildren(java.lang.String) @bci=11, line=171 (Interpreted frame)
> - org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(java.lang.String) @bci=5, line=362 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=99, line=289 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=189, line=291 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource) @bci=2, line=250 (Interpreted frame)
> - org.jboss.as.controller.ModelControllerImpl.writeModel(org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl, java.util.Set) @bci=19, line=769 (Interpreted frame)
> - org.jboss.as.controller.OperationContextImpl.createPersistenceResource() @bci=17, line=519 (Interpreted frame)
> - org.jboss.as.controller.AbstractOperationContext.executeDoneStage(org.jboss.dmr.ModelNode) @bci=22, line=708 (Interpreted frame)
> - org.jboss.as.controller.AbstractOperationContext.processStages() @bci=277, line=680 (Interpreted frame)
> - org.jboss.as.controller.AbstractOperationContext.executeOperation() @bci=27, line=370 (Interpreted frame)
> - org.jboss.as.controller.OperationContextImpl.executeOperation() @bci=20, line=1344 (Interpreted frame)
> - org.jboss.as.controller.ModelControllerImpl.boot(java.util.List, org.jboss.as.controller.client.OperationMessageHandler, org.jboss.as.controller.ModelController$OperationTransactionControl, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider, boolean, boolean) @bci=410, line=485 (Interpreted frame)
> - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider) @bci=16, line=387 (Interpreted frame)
> - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean) @bci=7, line=349 (Interpreted frame)
> - org.jboss.as.server.ServerService.boot(java.util.List, boolean) @bci=22, line=392 (Interpreted frame)
> - org.jboss.as.server.ServerService.boot(org.jboss.as.controller.BootContext) @bci=907, line=365 (Interpreted frame)
> - org.jboss.as.controller.AbstractControllerService$1.run() @bci=12, line=299 (Interpreted frame)
> - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug... ]
Stefan Guilhen commented on SECURITY-930:
-----------------------------------------
[~ppalaga] Yeah, I do have an update. The fix was applied a while ago to PicketBox master, which was not yet used by WildFly until recently. Now that Elytron is being integrated we have upgraded WildFly to use PicketBox 5.0.0 and we can now change the ModuleClassLoaderLocator to make use of the new API that allows for the registration of multiple modules.
So the issue affects two projects. The PicketBox side is covered by this issue and we already have a fix for it. I'll add a reference to the commit that fixes the issue here so we can close this issue. The WildFly side might need a different Jira to fix the ModuleClassLoaderLocator.
I'll try to open the WF Jira and send a PR for it tonight.
> A security-domain can only load login-modules from a single JBoss module
> --------------------------------------------------------------------------
>
> Key: SECURITY-930
> URL: https://issues.jboss.org/browse/SECURITY-930
> Project: PicketBox
> Issue Type: Bug
> Components: JBossSX, Security-SPI
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
>
> A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
> There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.
--
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 Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-261:
--------------------------------------
I uploaded 3.22.0-CR1 to the Maven repo, should be available now.
> 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
[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:
--------------------------------------
Excellent, I'll push to the maven repo!
> 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