[JBoss JIRA] (WFLY-835) @Resource UserTransaction error when file passivation store is selected
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.s... ]
Michael Musgrove updated WFLY-835:
----------------------------------
Fix Version/s: 11.0.0.Alpha1
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
> Key: WFLY-835
> URL: https://issues.jboss.org/browse/WFLY-835
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.CR2
> Environment: Ubuntu 11.10, Intel® Core™ i3-2120 CPU @ 3.30GHz × 4
> Reporter: Abraham Cabanillas Piera
> Assignee: Michael Musgrove
> Priority: Critical
> Labels: jboss
> Fix For: 11.0.0.Alpha1
>
> Attachments: serializationerr_server.log
>
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> ... 15 more
> Caused by: an exception which occurred:
> in field userTransaction
> in field instance
> in field instance
> in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl@6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="10000" cache-ref="passivating"/>
> <singleton default-access-timeout="5000"/>
> </session-bean>
> <mdb>
> <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple" aliases="NoPassivationCache"/>
> <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
> </caches>
> <passivation-stores>
> <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
> </passivation-stores>
> <async thread-pool-name="default"/>
> <timer-service thread-pool-name="default">
> <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
> </timer-service>
> <remote connector-ref="remoting-connector" thread-pool-name="default"/>
> <thread-pools>
> <thread-pool name="default">
> <max-threads count="100"/>
> <keepalive-time time="100" unit="milliseconds"/>
> </thread-pool>
> </thread-pools>
> <iiop enable-by-default="false" use-qualified-name="false"/>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 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:
--------------------------------------
hmm, now I see:
{code}
[INFO] --- maven-gpg-plugin:1.4:sign (sign-artifacts) @ javassist ---
gpg: no default secret key: unusable secret key
gpg: signing failed: unusable secret key
{code}
To see the above failure, I did:
{quote}
git pull upstream master --tags
git checkout rel_3_21_0_ga
mvn -P centralRelease javadoc:jar deploy
{quote}
I think that I need to renew my public key as it expired on 2016-05-07. I'll look into that and try again :)
> 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)
7 years, 7 months
[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:
---------------------------------------
Ah, I fixed typos and committed.
Can you try to build again?
> 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)
7 years, 7 months
[JBoss JIRA] (WFLY-7172) Complex type properties-realm in Elytron subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7172:
-----------------------------
Description:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
-*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.-
1. The 'path' attributes should not be nillable, i.e. if the ObjectType that holds them is defined the path should be specified.
2. The 'relative-to' attributes should not support expressions.
was:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.
> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
> Key: WFLY-7172
> URL: https://issues.jboss.org/browse/WFLY-7172
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> -*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.-
> 1. The 'path' attributes should not be nillable, i.e. if the ObjectType that holds them is defined the path should be specified.
> 2. The 'relative-to' attributes should not support expressions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFLY-7172) Complex type properties-realm in Elytron subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7172:
-----------------------------
Description:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.
was:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple ?_PATH+?_RELATIVE_TO attributes.
> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
> Key: WFLY-7172
> URL: https://issues.jboss.org/browse/WFLY-7172
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFLY-7172) Complex type properties-realm in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7172:
----------------------------------------
[~honza889] As I mention in JBEAP-6120 we do not want to remove the object types, all we need to do for this is ensure path is a required attribute if the ObjectType is defined and the relative-to attribute can not support expressions.
> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
> Key: WFLY-7172
> URL: https://issues.jboss.org/browse/WFLY-7172
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by 4 simple ?_PATH+?_RELATIVE_TO attributes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFLY-7172) Complex type properties-realm in Elytron subsystem
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7172?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7172:
-----------------------------
Description:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple ?_PATH+?_RELATIVE_TO attributes.
was:
Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
*Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple *_PATH+*_RELATIVE_TO attributes.
> Complex type properties-realm in Elytron subsystem
> --------------------------------------------------
>
> Key: WFLY-7172
> URL: https://issues.jboss.org/browse/WFLY-7172
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> Elytron subsystem uses complex type in properties-realm resource which is difficult to use and can result to bad user experience, see description of JBEAP-6100 for more details.
> *Summary:* Two OBJECTs (USERS_PROPERTIES+GROUPS_PROPERTIES) should be replaced by two simple ?_PATH+?_RELATIVE_TO attributes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months