[JBoss JIRA] (WFLY-8542) StatefulSessionSynchronizationInterceptor fails weirdly if the transaction is in ROLLBACK_ONLY
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-8542?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-8542:
-----------------------------------
[~tomjenkinson] are beforeCompletion synchronizations run when the transaction is rollback-only at prepare time?
> StatefulSessionSynchronizationInterceptor fails weirdly if the transaction is in ROLLBACK_ONLY
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-8542
> URL: https://issues.jboss.org/browse/WFLY-8542
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: David Lloyd
>
> It's not really clear what the correct behavior is, but it definitely isn't this:
> {noformat}
> 2017-04-07 14:53:09 javax.ejb.EJBTransactionRolledbackException: WFLYTX0029: Syncs are not allowed to be registered when the tx is in state 1
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:160)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:257)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:334)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:327)
> 2017-04-07 14:53:09 at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 2017-04-07 14:53:09 at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:84)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:256)
> 2017-04-07 14:53:09 at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609)
> 2017-04-07 14:53:09 at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> 2017-04-07 14:53:09 at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 2017-04-07 14:53:09 at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:457)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:452)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:164)
> 2017-04-07 14:53:09 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2017-04-07 14:53:09 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2017-04-07 14:53:09 at java.lang.Thread.run(Thread.java:745)
> 2017-04-07 14:53:09 Caused by: java.lang.IllegalStateException: WFLYTX0029: Syncs are not allowed to be registered when the tx is in state 1
> 2017-04-07 14:53:09 at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.registerInterposedSynchronization(JCAOrderedLastSynchronizationList.java:76)
> 2017-04-07 14:53:09 at org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper.registerInterposedSynchronization(TransactionSynchronizationRegistryWrapper.java:78)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:118)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> 2017-04-07 14:53:09 at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> 2017-04-07 14:53:09 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:240)
> 2017-04-07 14:53:09 at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:255)
> 2017-04-07 14:53:09 ... 42 more
> {noformat}
> If the transaction is in ROLLBACK_ONLY, then any of these might possibly be correct behavior:
> * Reject the invocation with a specific exception explaining that the method cannot be invoked when the transaction is in ROLLBACK_ONLY (preferably with a spec citation)
> * Allow the invocation to proceed without registering the synchronization (this probably isn't correct but might be)
> * Allow the invocation to proceed and use a "backdoor" to register the user synchronization anyway
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9288) EJB session auto-creation is not working
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9288?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-9288:
---------------------------------
Assignee: David Lloyd
> EJB session auto-creation is not working
> ----------------------------------------
>
> Key: WFLY-9288
> URL: https://issues.jboss.org/browse/WFLY-9288
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: David Lloyd
> Assignee: David Lloyd
>
> In {{org.jboss.as.ejb3.remote.AssociationImpl#receiveInvocationRequest}}, when the EJB component is being looked up, two things need to happen which are not happening:
> * The incoming locator should be examined; if it is a stateful locator and the physical EJB is stateless, then {{Request#writeNotStateful()}} should be called and processing should be aborted.
> * If the incoming locator is a stateless locator and the physical EJB is stateful, then {{component#createSessionRemote()}} should be called and the resultant session ID should be set using {{Request#convertToStateful()}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9961) Annotations in applications, compiled using JDK 9, aren't recognized causing deployment issues
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9961?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9961:
----------------------------------------
We're aiming to release WF 13 on May 30.
> Annotations in applications, compiled using JDK 9, aren't recognized causing deployment issues
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-9961
> URL: https://issues.jboss.org/browse/WFLY-9961
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Final
> Reporter: cnsgithub cnsgithub
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 13.0.0.Beta1
>
>
> After upgrading to WFLY 12 Final, the WebApplicationInitializer class residing in the *.war classes Folder is no longer being detected when built with JDK 9. However with JDK 1.8 it works as expected.
> With WFLY 11, both variants JDK9, and JDK1.8 Build were working.
> {code:java}
> package de.test;
> import javax.servlet.ServletContext;
> import javax.servlet.ServletException;
> import org.springframework.web.WebApplicationInitializer;
> public class MyWebApplicationInitializer implements WebApplicationInitializer {
> @Override
> public void onStartup(ServletContext container) throws ServletException {
> System.out.println("!!!!!!!!!!!!!! ;-) !!!!!!!!!!!!");
> }
> }
> {code}
> Maybe(!) related to this: https://issues.jboss.org/browse/WFLY-9081
> Even more serious: the @WebListener doesn't seem to be recognized with JDK9 as well:
> {code:java}
> package de.test;
> import javax.servlet.ServletContextEvent;
> import javax.servlet.ServletContextListener;
> import javax.servlet.annotation.WebListener;
> import javax.servlet.http.HttpSessionEvent;
> import javax.servlet.http.HttpSessionIdListener;
> import javax.servlet.http.HttpSessionListener;
> @WebListener
> public class MyWebListener implements ServletContextListener, HttpSessionIdListener, HttpSessionListener {
> @Override
> public void contextInitialized(ServletContextEvent event) {
> System.out.println("contextInitialized !!!!!!!! I'm only working when i was built with JDK8");
> }
>
> @Override
> public void sessionIdChanged(HttpSessionEvent arg0, String arg1) {
> // TODO Auto-generated method stub
>
> }
> }
> {code}
> The actual error seems to happen quite early: JBossWebMetaData
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9961) Annotations in applications, compiled using JDK 9, aren't recognized causing deployment issues
by David Robison (JIRA)
[ https://issues.jboss.org/browse/WFLY-9961?page=com.atlassian.jira.plugin.... ]
David Robison commented on WFLY-9961:
-------------------------------------
Will there be a patch for this for WIldfly 12? Any idea when one may be available? Is there a projected release date for Wildfly 13?
> Annotations in applications, compiled using JDK 9, aren't recognized causing deployment issues
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-9961
> URL: https://issues.jboss.org/browse/WFLY-9961
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 12.0.0.Final
> Reporter: cnsgithub cnsgithub
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 13.0.0.Beta1
>
>
> After upgrading to WFLY 12 Final, the WebApplicationInitializer class residing in the *.war classes Folder is no longer being detected when built with JDK 9. However with JDK 1.8 it works as expected.
> With WFLY 11, both variants JDK9, and JDK1.8 Build were working.
> {code:java}
> package de.test;
> import javax.servlet.ServletContext;
> import javax.servlet.ServletException;
> import org.springframework.web.WebApplicationInitializer;
> public class MyWebApplicationInitializer implements WebApplicationInitializer {
> @Override
> public void onStartup(ServletContext container) throws ServletException {
> System.out.println("!!!!!!!!!!!!!! ;-) !!!!!!!!!!!!");
> }
> }
> {code}
> Maybe(!) related to this: https://issues.jboss.org/browse/WFLY-9081
> Even more serious: the @WebListener doesn't seem to be recognized with JDK9 as well:
> {code:java}
> package de.test;
> import javax.servlet.ServletContextEvent;
> import javax.servlet.ServletContextListener;
> import javax.servlet.annotation.WebListener;
> import javax.servlet.http.HttpSessionEvent;
> import javax.servlet.http.HttpSessionIdListener;
> import javax.servlet.http.HttpSessionListener;
> @WebListener
> public class MyWebListener implements ServletContextListener, HttpSessionIdListener, HttpSessionListener {
> @Override
> public void contextInitialized(ServletContextEvent event) {
> System.out.println("contextInitialized !!!!!!!! I'm only working when i was built with JDK8");
> }
>
> @Override
> public void sessionIdChanged(HttpSessionEvent arg0, String arg1) {
> // TODO Auto-generated method stub
>
> }
> }
> {code}
> The actual error seems to happen quite early: JBossWebMetaData
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3807) Persist extensions and subsystems in a consistent order
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3807:
----------------------------------------
Summary: Persist extensions and subsystems in a consistent order
Key: WFCORE-3807
URL: https://issues.jboss.org/browse/WFCORE-3807
Project: WildFly Core
Issue Type: Enhancement
Components: Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 5.0.0.Alpha6
Always persist extension resources to xml in alphabetical order of the extension module name.
Always persist subsystem resources to xml in alphabetical order of the subsystem name, except logging goes first just because it always has. (There has been no technical need for it to go first since probably before AS 7.0.0.Final.)
The above describes the "conventional" order for the extensions / subsystems in our standard config files that we've manually applied for many years.
The current persister behavior is to persist extension and subsystems in the order they were added. This follows the general rule applied everywhere: sibling resources of a type are persisted in the same order in which they were added. Since most extensions/subsystems are added at boot based on the parsing of our conventionally ordered standard configs, we typically persist in our conventional order.
This enhancement is to have the persister force extensions/subsystem persistence in our conventional order, ignoring the order in which the items were added.
This change has the following pros:
1) If an extension/subsystem is added after initial boot (e.g. via CLI) the placement of that added subsystem will now be in a more intuitive spot in the same order as the conventionally ordered others, versus now where it comes last.
2) The galleon provisioning tool when it provisions a server basically does a bunch of 1), with the adds happening based on dependency analysis of the features. This results in an ordering that can seem quite unintuitive. This enhancement prevents this.
3) With the current behavior if a galleon feature pack is upgraded, and the feature-spec reports new dependency information that was previously missing (e.g. proper capability/requirement wiring between subsystems was added whereas before only invisible-in-the-model service dependencies were used) then when galleon re-provisions the server the order of extensions/subsystems might mysteriously change.
This change has the following cons:
1) If users for some reason had deliberately organized their xml in a different order from our convention, the ability to do this would be lost. (We could add a system property hook to disable this enhancement, but it would need to be clear that it's not something the galleon tool itself supports. So probably not a great idea.)
2) The ordering that galleon will create without this enhancement does provide some value to the user since it gives a rough sense of dependency ordering. It's pretty rough though, as there can be numerous items A, B, C that come before other items X, Y, Z where there is no dependency relationship involved.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10338) Discovery subsystem is missing from the domain profiles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10338?page=com.atlassian.jira.plugin... ]
Brian Stansberry edited comment on WFLY-10338 at 5/7/18 4:24 PM:
-----------------------------------------------------------------
[~yersan] Can you handle this one? I took it from Alexey but am giving it away. :)
The WFCORE-3784 fix shows the basic thing that needs to be done, except in full feature-pack there are more profiles. Check with [~dmlloyd] which profiles should have this subsystem. It should be in full and full-ha for sure; and not in load-balancer. The others, I'm not sure. (Edit: the basic rule is the domain profiles should match the equivalent standaone[-xxx].xml files.)
Doing that will break the mixed-domain tests, same way the special tests of aloubyansky/galleon-pack are broken. The mixed domain tests have this concept of a DomainAdjuster which tweaks the DC config to remove things that are known to be unusable on legacy slaves. So those will need to be tweaked to account for this discovery subsystem being in the config.
Fixing the mixed-domain tests for this will fix the failures in aloubyansky/galleon-pack as well.
was (Author: brian.stansberry):
[~yersan] Can you handle this one? I took it from Alexey but am giving it away. :)
The WFCORE-3784 fix shows the basic thing that needs to be done, except in full feature-pack there are more profiles. Check with [~dmlloyd] which profiles should have this subsystem. It should be in full and full-ha for sure; and not in load-balancer. The others, I'm not sure.
Doing that will break the mixed-domain tests, same way the special tests of aloubyansky/galleon-pack are broken. The mixed domain tests have this concept of a DomainAdjuster which tweaks the DC config to remove things that are known to be unusable on legacy slaves. So those will need to be tweaked to account for this discovery subsystem being in the config.
Fixing the mixed-domain tests for this will fix the failures in aloubyansky/galleon-pack as well.
> Discovery subsystem is missing from the domain profiles
> -------------------------------------------------------
>
> Key: WFLY-10338
> URL: https://issues.jboss.org/browse/WFLY-10338
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Management
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Fix For: 13.0.0.Beta1
>
>
> Same problem as WFCORE-3784 except in the full feature-pack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9546) Enhance module descriptions with a version number
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9546?page=com.atlassian.jira.plugin.... ]
David Lloyd closed WFLY-9546.
-----------------------------
Resolution: Out of Date
We're automatically detecting version numbers now.
> Enhance module descriptions with a version number
> -------------------------------------------------
>
> Key: WFLY-9546
> URL: https://issues.jboss.org/browse/WFLY-9546
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System
> Reporter: David Lloyd
>
> Since JBoss Modules 1.6, a module descriptor may contain a version number. The version number will appear in stack traces starting in Java 9, so it's useful to add that information in the build process. It will require a bit of work though because that information will have to be extracted from Maven properties as part of the build process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9592) Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9592?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-9592.
-------------------------------
Fix Version/s: 11.0.0.Final
Resolution: Done
> Arrays in Method Parameters are causing EJBAccessException for @PermitAll Methods
> ---------------------------------------------------------------------------------
>
> Key: WFLY-9592
> URL: https://issues.jboss.org/browse/WFLY-9592
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0.Final in an Arquillian Managed Container Test
> Reporter: Marcus Handte
> Priority: Minor
> Fix For: 11.0.0.Final
>
>
> EJB methods with array parameters are causing EJBAccessExceptions when they are annotated with @PermitAll. This bug seemed to be present in 8.0.0.Alpha2 and was fixed (see WFLY-1658). But it seems to be present again in 10.1.0.Final.
> For my own use case, this is not a problem since I can simply change the method signatures to use lists instead of arrays. However, I can imagine that this could be a more significant problem for people trying to run existing code that they do not want to (or cannot) touch.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months