[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:
---------------------------------------
I implemented my idea mentioned above.
Scott, could you try the latest version available as Javassist 3.21.0 for Java 9 early access 2?
see https://github.com/jboss-javassist/javassist/releases/tag/rel_3_21_0-java...
> 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-1834) Unexpected attribute error message doesn't list 'name' attribute.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1834:
----------------------------------------
Summary: Unexpected attribute error message doesn't list 'name' attribute.
Key: WFCORE-1834
URL: https://issues.jboss.org/browse/WFCORE-1834
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Tomaz Cerar
Fix For: 3.0.0.Alpha9
I have recently updated one of our resource definitions and missed updating one of the subsystem templates so currently have the following error reported: -
{noformat}
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)
{noformat}
Previously my resource has been using the 'security-domain' attribute for it's name but now has been reverted to using 'name' for the name - in the above error message 'name' should have been listed as one of the valid attributes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7224:
-------------------------------------
[~dlofthouse] ok. I'll ask [~honza889]. Thanks!
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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)
> Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7224:
----------------------------------------
[~ivassile] For subsystem related tasks most importantly just coordinate with [~honza889] he is the engineer on our team handling the subsystem issues at the moment.
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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)
> Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1833) Temporarily workaround Jigsaw ServiceLoader regression
by Richard Opalka (JIRA)
Richard Opalka created WFCORE-1833:
--------------------------------------
Summary: Temporarily workaround Jigsaw ServiceLoader regression
Key: WFCORE-1833
URL: https://issues.jboss.org/browse/WFCORE-1833
Project: WildFly Core
Issue Type: Sub-task
Reporter: Richard Opalka
Assignee: Richard Opalka
There's ServiceLoader regression in recent Jigsaw JDK9 builds.
We will implement temporary workaround for this Jigsaw issue.
This issue can be closed / resolved once this workaround
will be eliminated from our code base.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7224:
-------------------------------------
[~dlofthouse] Do you mind if I work on this one and related https://issues.jboss.org/browse/WFLY-7225?
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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)
> Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-7212:
-------------------------------------
But hold on, isn't that what the second set of code I posted was trying to do? If so, then that didn't work, or at least it doesn't solve the issue of having the transaction-reaper come along in 5 minutes and shut things down. Am I missing something about UserTransaction? Thanks.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7226:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Dietrich Schmidt reopened WFLY-7101:
------------------------------------
Compare comment 3.
> Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
> --------------------------------------------------------------
>
> Key: WFLY-7101
> URL: https://issues.jboss.org/browse/WFLY-7101
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91
> Reporter: Dietrich Schmidt
> Assignee: Jason Greene
> Attachments: Verklemmung.zip
>
>
> Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected.
> This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended.
> I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Dietrich Schmidt edited comment on WFLY-7101 at 9/27/16 11:03 AM:
------------------------------------------------------------------
EJB spec 4.8.1 does not apply to this bug, please re-investigate.
Singleton bean A (=ServerImpl) with @startup calls in its @Postconstruct method a method in singleton bean B (=TestReaderImpl) - this works fine.
Now in this @PostConstruct several Threads are created with a ManagedExcecutorService - these threads start normally, but if they call a method iin singleton bean B, they are blocked. This must not happen and is a bug.
was (Author: rumpelstilzchen926):
EJB spec 4.8.1 does not apply to this bug, please re-investigate.
Singleton bean A (=ServerImpl) with @startup calls in its @Postconstruct method a method in singleton bean B (=TestReaderImpl) - this works fine.
Now in this @PostConstruct several Threads are created with a ManagedExcecutorService - these threads start normally, but if the call a method iin singleton bean B, they are blocked. This must not happen and is a bug.
> Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
> --------------------------------------------------------------
>
> Key: WFLY-7101
> URL: https://issues.jboss.org/browse/WFLY-7101
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91
> Reporter: Dietrich Schmidt
> Assignee: Jason Greene
> Attachments: Verklemmung.zip
>
>
> Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected.
> This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended.
> I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months