[JBoss JIRA] (WFLY-6766) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6766?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-6766:
----------------------------------------
[~kabirkhan] this one is WFCORE, right?
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-6766
> URL: https://issues.jboss.org/browse/WFLY-6766
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Kabir Khan
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-644) Creating LDAP security realm fails with cryptic error message
by Zach Rhoads (JIRA)
Zach Rhoads created ELY-644:
-------------------------------
Summary: Creating LDAP security realm fails with cryptic error message
Key: ELY-644
URL: https://issues.jboss.org/browse/ELY-644
Project: WildFly Elytron
Issue Type: Bug
Reporter: Zach Rhoads
Assignee: Darran Lofthouse
When creating an LDAP security realm via CLI, setup fails with cryptic error message.
For example, creating a dir-context works fine:
/subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
But when creating an ldap-realm:
/subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
It fails:
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
"rolled-back" => true
}
Full log in wildfly:
14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("ldap-realm" => "exampleLR")
]): java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7230) Undertow subsystem template missing changes latest schema updates.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7230?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7230:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Undertow subsystem template missing changes latest schema updates.
> ------------------------------------------------------------------
>
> Key: WFLY-7230
> URL: https://issues.jboss.org/browse/WFLY-7230
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> The following error message is reported starting domain.sh -c domain-elytron.xml
> {noformat}
> [Host Controller] 16:45:45,433 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> [Host Controller] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:721)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
> [Host Controller] at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[780,21]
> [Host Controller] Message: WFLYCTL0376: Unexpected attribute 'security-domain' encountered. Valid attributes are: 'http-authentication-factory, override-deployment-config'
> [Host Controller] at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)
> [Host Controller] at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributes(PersistentResourceXMLDescription.java:198)
> [Host Controller] at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributeGroups(PersistentResourceXMLDescription.java:140)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-6599 at 9/27/16 2:58 PM:
---------------------------------------------------------------
-See JGRP-2063 for changes that need to be done in JGroups directly.-
Proposed fix without changes in JGroups.
was (Author: rhusar):
-See JGRP-2063 for changes that need to be done in JGroups directly.-
Fixed without changes in JGroups.
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-6599 at 9/27/16 2:57 PM:
---------------------------------------------------------------
-See JGRP-2063 for changes that need to be done in JGroups directly.-
Fixed without changes in JGroups.
was (Author: rhusar):
See JGRP-2063 for changes that need to be done in JGroups directly.
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7230) Undertow subsystem template missing changes latest schema updates.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7230?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved JBEAP-6231 to WFLY-7230:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7230 (was: JBEAP-6231)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR5)
> Undertow subsystem template missing changes latest schema updates.
> ------------------------------------------------------------------
>
> Key: WFLY-7230
> URL: https://issues.jboss.org/browse/WFLY-7230
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> The following error message is reported starting domain.sh -c domain-elytron.xml
> {noformat}
> [Host Controller] 16:45:45,433 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> [Host Controller] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:721)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
> [Host Controller] at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[780,21]
> [Host Controller] Message: WFLYCTL0376: Unexpected attribute 'security-domain' encountered. Valid attributes are: 'http-authentication-factory, override-deployment-config'
> [Host Controller] at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)
> [Host Controller] at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributes(PersistentResourceXMLDescription.java:198)
> [Host Controller] at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributeGroups(PersistentResourceXMLDescription.java:140)
> {noformat}
--
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:
--------------------------------------
[~sebersole] I just pushed a 3.21.0-SNAPSHOT:
{quote}
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (719 KB at 296.1 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (10 KB at 20.4 KB/sec)
Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (365 B at 0.5 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (990 B at 1.8 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (344 B at 0.6 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (515 KB at 345.2 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (990 B at 1.6 KB/sec)
{quote}
> 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 Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Steve Ebersole commented on JASSIST-261:
----------------------------------------
Is that pushed to a Maven repo? If so I could try in the Hibernate build.
> 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] (DROOLS-1308) Rules compilation failure depending on condition ordering
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1308?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1308:
-------------------------------------
I reproduced this problem with this simple rule
{code}
rule R when
$l : List( )
String() from $l
(String() or Number())
then end
{code}
The problem there is that the parser reads the from expression as
{code}
from $l (String() or Number())
{code}
and it is impossible to disambiguate this from a function call. The straightforward fix to this is wrapping also the from clause in parenthesis as it follows:
{code}
rule R when
$l : List( )
(String() from $l)
(String() or Number())
then end
{code}
We will fix the DRL marshaller accordingly.
> Rules compilation failure depending on condition ordering
> ---------------------------------------------------------
>
> Key: DROOLS-1308
> URL: https://issues.jboss.org/browse/DROOLS-1308
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Martin Weiler
> Assignee: Mario Fusco
>
> When creating rules in guided editor, we are running into validation errors depending on the order of the conditions. The problem is that the order of the conditions is important:
> {noformat}
> when
> COND_X
> COND_Y => works
> when
> COND_Y
> COND_X => fails
> java.lang.AssertionError: [10,18]: [ERR 101] Line 10:18 no viable alternative at input 'Number' in rule "ATO_Negative_AU_Test"
> [0,0]: Parser returned a null Package
> {noformat}
> Test cases showing the compilation failures (@Test testOrder1 vs
> testOrder2) can be found here:
> https://gist.github.com/martinweiler/e684a0e75a2c9f4de4dee5a13affb8b0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months