September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-600) Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-600?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-600: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults. > --------------------------------------------------------------------------------- > > Key: ELY-600 > URL: https://issues.jboss.org/browse/ELY-600 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-583) Add ability for outbound clients to directly consume IdentityCredentials

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-583?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-583: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add ability for outbound clients to directly consume IdentityCredentials > ------------------------------------------------------------------------ > > Key: ELY-583 > URL: https://issues.jboss.org/browse/ELY-583 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta11 > > > Outbound clients can gain substantial flexibility by being able to use {{IdentityCredentials}} directly. This allows a non-type-specific object like a {{byte[]}} to be interpreted as many different types of credentials. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-595) Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-595?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-595: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded. > ------------------------------------------------------------------------------------------------------ > > Key: ELY-595 > URL: https://issues.jboss.org/browse/ELY-595 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-649) Make the exists and create methods on HttpScope default

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-649?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-649: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Make the exists and create methods on HttpScope default > ------------------------------------------------------- > > Key: ELY-649 > URL: https://issues.jboss.org/browse/ELY-649 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-643) On the SSLContextBuilder support setUseCipherSuitesOrder

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-643?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-643: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > On the SSLContextBuilder support setUseCipherSuitesOrder > -------------------------------------------------------- > > Key: ELY-643 > URL: https://issues.jboss.org/browse/ELY-643 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.1.0.Beta11 > > > Currently we hard code this value to 'true' which should remain the default as the OpenSSL style cipher suite selection includes preferred mechanism ordering - however it should be possible to override this and set it to false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-639) SecurityIdentity and PeerIdentity should have more runAs* variants

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-639?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-639: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > SecurityIdentity and PeerIdentity should have more runAs* variants > ------------------------------------------------------------------ > > Key: ELY-639 > URL: https://issues.jboss.org/browse/ELY-639 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Fix For: 1.1.0.Beta11 > > > The XxxIdentity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-628: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-648) Release WildFly Elytron 1.1.0.Beta10

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-648?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-648. ---------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta10 > ------------------------------------ > > Key: ELY-648 > URL: https://issues.jboss.org/browse/ELY-648 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-261: --------------------------------------- Yes, just the building process (by maven) needs Java 9. Since the code refers to a class available only in Java 9 but that class is not instantiated or accessed if the JVM is not Java 9, the code runs in Java 8. The class files are compiled to be able to run even in Java 6. > 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, 2 months

1
0
0 / 0

[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: ---------------------------------------- [~chiba] the jar [~smarlow] built for me that I used in testing Hibernate was Java 8 compatible (I was able to run the Hibernate tests fine using that SNAPSHOT and Java 8). Do you mean that just the build is sensitive to the JDK used? Not being able to work in both Java 8 and 9 at runtime is going to be a big headache. > 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, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016