[JBoss JIRA] (DROOLS-680) "contains" operator behaves inconsistently when used with Maps
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-680?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-680:
------------------------------------------
Fix Version/s: 7.0.0.Beta3
(was: 7.0.0.Beta2)
> "contains" operator behaves inconsistently when used with Maps
> --------------------------------------------------------------
>
> Key: DROOLS-680
> URL: https://issues.jboss.org/browse/DROOLS-680
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final, 6.0.1.Final, 6.1.0.Final, 6.2.0.CR4
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta3
>
>
> In a rule
> {code}
> Bean( map contains "x" ) // assuming "map" is a property of type Map
> {code}
> "contains" is arbitrarily interpreted as "containsKey"
> The constrain will then fail after being jitted
> The documentation explicitly states that "contains" applies to collections
--
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 got a javadoc build error as AnnotationsAttribute doesn't seem to have invisibleTab but some javadoc links to that:
{code}
/mnt/ssd/work/javassist/src/main/javassist/bytecode/FieldInfo.java:236: error: reference not found
[ERROR] * {@link AnnotationsAttribute#invisibleTab}
{code}
Full output for "mvn -P centralRelease javadoc:jar deploy" is at [http://pastebin.com/2wTL6qX0].
> 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] (WFCORE-1847) PatchMerger overrides submodule's content merging the outer module
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-1847:
-----------------------------------------
Summary: PatchMerger overrides submodule's content merging the outer module
Key: WFCORE-1847
URL: https://issues.jboss.org/browse/WFCORE-1847
Project: WildFly Core
Issue Type: Bug
Components: Patching
Affects Versions: 3.0.0.Alpha9
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
PatchMerger merges two CPs into one. In case the first CP includes updates for modules like org.outermodule and org.outermodule.innermodule. And the second CP including an update for org.outermodule.innermodule only, the merge may not happen correctly in case the modification for the innermodule will appear before the modification for the outermodule in the first CP.
The merger will copy the innermodule's content first and then override it copying the outermodule's content (including the previous version of the innermodule).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[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:
------------------------------------
> It was coded because two standard mechanisms you mentioned were considered not sufficient. I'm not saying they didn't work - they did and still do, but we wished to free resources faster than they can. I didn't say that earlier, but there are actually +30 sessions per user to wipe (+30 apps we thought we needed coordinated logout for, to free resources).
The code in MainServlet will not free resources any faster than the standard mechanism. The distributed session manager in WF 10 does not rely on a polling mechanism (like older releases did), but instead schedules expiration eagerly. Thus sessions will be destroyed as soon as they are sufficiently idle.
> Now, in WF 10.1 (and only there) it's logging errors.
It's logging errors because this doesn't work in WF10. In WF10, the distributed HttpSession is not a traditional map of attributes, but rather a proxy to a distributed cache in which the session attributes are stored. This proxy is only functional within the context of a container thread (e.g. request thread, listener thread, async context thread, etc.).
> If I understood you right - then this is quite possibly what I want to happen.
I don't think you understood me fully. This would result in premature expiration. If a request fails over to another node, and the original node is still alive, it will expire the session even though it is still being used. I highly doubt that this is what you want to happen.
> 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, 7 months
[JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug... ]
Peter Palaga commented on SECURITY-930:
---------------------------------------
> I'll try to find this commit and check if it has made it into WildFly. I'll post again once I figure this out.
[~sguilhen], any update on this?
> 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] (WFLY-7255) Creating LDAP security realm fails with cryptic error message
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7255?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved ELY-644 to WFLY-7255:
--------------------------------------
Project: WildFly (was: WildFly Elytron)
Key: WFLY-7255 (was: ELY-644)
> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
> Key: WFLY-7255
> URL: https://issues.jboss.org/browse/WFLY-7255
> Project: WildFly
> Issue Type: Bug
> Reporter: Zach Rhoads
> Assignee: Jan Kalina
>
> 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