[JBoss JIRA] (DROOLS-1103) FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
by Juan Carlos Garcia (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1103?page=com.atlassian.jira.plugi... ]
Juan Carlos Garcia commented on DROOLS-1103:
--------------------------------------------
[~mfusco] thanks for taking a look into this as well.
BTW, it seems this testcase also seems to reproduce a NullPointerException (from time to time) in the *BinaryHeapQueue* do you want me to open a different ticket (with the same testcase) for that?
> FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1103
> URL: https://issues.jboss.org/browse/DROOLS-1103
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: RejectedExecutionExceptionBugReport.zip
>
>
> Under very rare circumstance we have found the following exception *java.util.concurrent.RejectedExecutionException* in our production log.
> Our guess is that the Drools Session is on its way to be dispose, while a new incoming request is in the middle of a fireAllRules operation (race condition).
> I will try to provide a reproducible testcase for this.
> {code}
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3e896443 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@71cc2f4c[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549)
> at org.drools.core.time.impl.JDKTimerService.internalSchedule(JDKTimerService.java:118)
> at org.drools.core.time.impl.JDKTimerService.scheduleJob(JDKTimerService.java:101)
> at org.drools.core.phreak.PhreakTimerNode.scheduleTimer(PhreakTimerNode.java:304)
> at org.drools.core.phreak.PhreakTimerNode.scheduleLeftTuple(PhreakTimerNode.java:233)
> at org.drools.core.phreak.PhreakTimerNode.doLeftUpdates(PhreakTimerNode.java:131)
> at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:357)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:260)
> at XXXXXX.XXXXX.XXXXX.processEventDrools(EventProcessorImpl.java:128)
> at XXXXXX.XXXXX.XXXXX.processEvent(EventProcessorImpl.java:101)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-1103) FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1103?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1103:
-------------------------------------
Thanks [~jcgarciam], I'll run your reproducer asap and keep you updated.
> FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1103
> URL: https://issues.jboss.org/browse/DROOLS-1103
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: RejectedExecutionExceptionBugReport.zip
>
>
> Under very rare circumstance we have found the following exception *java.util.concurrent.RejectedExecutionException* in our production log.
> Our guess is that the Drools Session is on its way to be dispose, while a new incoming request is in the middle of a fireAllRules operation (race condition).
> I will try to provide a reproducible testcase for this.
> {code}
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3e896443 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@71cc2f4c[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549)
> at org.drools.core.time.impl.JDKTimerService.internalSchedule(JDKTimerService.java:118)
> at org.drools.core.time.impl.JDKTimerService.scheduleJob(JDKTimerService.java:101)
> at org.drools.core.phreak.PhreakTimerNode.scheduleTimer(PhreakTimerNode.java:304)
> at org.drools.core.phreak.PhreakTimerNode.scheduleLeftTuple(PhreakTimerNode.java:233)
> at org.drools.core.phreak.PhreakTimerNode.doLeftUpdates(PhreakTimerNode.java:131)
> at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:357)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:260)
> at XXXXXX.XXXXX.XXXXX.processEventDrools(EventProcessorImpl.java:128)
> at XXXXXX.XXXXX.XXXXX.processEvent(EventProcessorImpl.java:101)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-1103) FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
by Juan Carlos Garcia (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1103?page=com.atlassian.jira.plugi... ]
Juan Carlos Garcia updated DROOLS-1103:
---------------------------------------
Attachment: RejectedExecutionExceptionBugReport.zip
Reproducible testcase submitted
*Environment*:
{code}
mvn --version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=1024m; support was removed in 8.0
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
Maven home: /usr/share/maven
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: /usr/lib/jvm/jdk-8-oracle-x64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-91-generic", arch: "amd64", family: "unix"
{code}
> FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1103
> URL: https://issues.jboss.org/browse/DROOLS-1103
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: RejectedExecutionExceptionBugReport.zip
>
>
> Under very rare circumstance we have found the following exception *java.util.concurrent.RejectedExecutionException* in our production log.
> Our guess is that the Drools Session is on its way to be dispose, while a new incoming request is in the middle of a fireAllRules operation (race condition).
> I will try to provide a reproducible testcase for this.
> {code}
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3e896443 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@71cc2f4c[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549)
> at org.drools.core.time.impl.JDKTimerService.internalSchedule(JDKTimerService.java:118)
> at org.drools.core.time.impl.JDKTimerService.scheduleJob(JDKTimerService.java:101)
> at org.drools.core.phreak.PhreakTimerNode.scheduleTimer(PhreakTimerNode.java:304)
> at org.drools.core.phreak.PhreakTimerNode.scheduleLeftTuple(PhreakTimerNode.java:233)
> at org.drools.core.phreak.PhreakTimerNode.doLeftUpdates(PhreakTimerNode.java:131)
> at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:357)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:260)
> at XXXXXX.XXXXX.XXXXX.processEventDrools(EventProcessorImpl.java:128)
> at XXXXXX.XXXXX.XXXXX.processEvent(EventProcessorImpl.java:101)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-1103) FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
by Juan Carlos Garcia (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1103?page=com.atlassian.jira.plugi... ]
Juan Carlos Garcia updated DROOLS-1103:
---------------------------------------
Affects Version/s: 6.4.0.Final
> FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1103
> URL: https://issues.jboss.org/browse/DROOLS-1103
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
>
> Under very rare circumstance we have found the following exception *java.util.concurrent.RejectedExecutionException* in our production log.
> Our guess is that the Drools Session is on its way to be dispose, while a new incoming request is in the middle of a fireAllRules operation (race condition).
> I will try to provide a reproducible testcase for this.
> {code}
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3e896443 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@71cc2f4c[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549)
> at org.drools.core.time.impl.JDKTimerService.internalSchedule(JDKTimerService.java:118)
> at org.drools.core.time.impl.JDKTimerService.scheduleJob(JDKTimerService.java:101)
> at org.drools.core.phreak.PhreakTimerNode.scheduleTimer(PhreakTimerNode.java:304)
> at org.drools.core.phreak.PhreakTimerNode.scheduleLeftTuple(PhreakTimerNode.java:233)
> at org.drools.core.phreak.PhreakTimerNode.doLeftUpdates(PhreakTimerNode.java:131)
> at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:357)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:260)
> at XXXXXX.XXXXX.XXXXX.processEventDrools(EventProcessorImpl.java:128)
> at XXXXXX.XXXXX.XXXXX.processEvent(EventProcessorImpl.java:101)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-593) Optimisation of Gs2SaslClientFactory.createSaslClient
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-593?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-593:
--------------------------------------
Ok so sounds like the only optimisation check is that the mechanism name is at least supported in principal before the callback.
> Optimisation of Gs2SaslClientFactory.createSaslClient
> -----------------------------------------------------
>
> Key: ELY-593
> URL: https://issues.jboss.org/browse/ELY-593
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Affects Versions: 1.1.0.Beta6
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 1.1.0.Beta7
>
>
> There are a couple of opportunities to optimise the createSaslClient method.
> # Check that one of the mechanisms in the list is supported in principal.
> # The ChannelBindingCallback can possibly also be delayed until the selection reaches a mechanism that requires it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (DROOLS-1103) FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
by Juan Carlos Garcia (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1103?page=com.atlassian.jira.plugi... ]
Juan Carlos Garcia commented on DROOLS-1103:
--------------------------------------------
Hi, [~mfusco] i was able to built a reproducible testcase for the problem. However as it seems a race conditions you may need to execute the test case several times for the error to shows up. I will clean it up little bit and upload it later on.
> FireAllRules can trigger java.util.concurrent.RejectedExecutionException from the JDKTimerService
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1103
> URL: https://issues.jboss.org/browse/DROOLS-1103
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
>
> Under very rare circumstance we have found the following exception *java.util.concurrent.RejectedExecutionException* in our production log.
> Our guess is that the Drools Session is on its way to be dispose, while a new incoming request is in the middle of a fireAllRules operation (race condition).
> I will try to provide a reproducible testcase for this.
> {code}
> Caused by: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3e896443 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@71cc2f4c[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:326)
> at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:549)
> at org.drools.core.time.impl.JDKTimerService.internalSchedule(JDKTimerService.java:118)
> at org.drools.core.time.impl.JDKTimerService.scheduleJob(JDKTimerService.java:101)
> at org.drools.core.phreak.PhreakTimerNode.scheduleTimer(PhreakTimerNode.java:304)
> at org.drools.core.phreak.PhreakTimerNode.scheduleLeftTuple(PhreakTimerNode.java:233)
> at org.drools.core.phreak.PhreakTimerNode.doLeftUpdates(PhreakTimerNode.java:131)
> at org.drools.core.phreak.PhreakTimerNode.doNode(PhreakTimerNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:357)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:67)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:935)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1200)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:957)
> at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:260)
> at XXXXXX.XXXXX.XXXXX.processEventDrools(EventProcessorImpl.java:128)
> at XXXXXX.XXXXX.XXXXX.processEvent(EventProcessorImpl.java:101)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.x
by Emmanuel Bernard (JIRA)
[ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.... ]
Emmanuel Bernard commented on WFLY-6854:
----------------------------------------
{quote}I should also mention that fixes backported to 5.0 have also been backported to 5.1 when relevant.{quote}
Ah that is good news. That was worrying me a bit.
> Upgrade Hibernate ORM to 5.1.x
> ------------------------------
>
> Key: WFLY-6854
> URL: https://issues.jboss.org/browse/WFLY-6854
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Emmanuel Bernard
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6865) org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-6865?page=com.atlassian.jira.plugin.... ]
Brad Maxwell commented on WFLY-6865:
------------------------------------
The issue is if I have framework.ear which contains say an AbstractBean , and app1.ear declares a dependency on framework.ear , then app1.ear can see AbstractBean, as the dependency is ensuring the classes are available. But if you change the flag of the module dependency from annotations=false to annotations=true it logs an error that deployment.framework.ear module does not exist. So it seems like since it works if it is not told to scan for annotations but then fails if told to look for annotations.
> org.jboss.modules.ModuleNotFoundException when setting annotations=true in jboss-deployment-structure.xml
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6865
> URL: https://issues.jboss.org/browse/WFLY-6865
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Jason Greene
> Attachments: reproducer.zip
>
>
> {code}
> helloWorld.ear
> - helloWorld-ejb.jar
> - HelloBean - @Stateless EJB extends AbstractBean
> - lib
> - helloWorld-api.jar
> - META-INF
> - jandex.idx
> - Hello - EJB interface
> - AbstractBean - abstract class which has @PostConstruct and implements Hello
> helloWorld2.ear
> - helloWorld2-ejb.jar
> - HelloBean2 - @Startup @Singleton extends AbstractBean
> - META-INF
> - jboss-deployment-structure.xml depends on deployment.helloWorld.ear export=true annotations=true
> {code}
> To have HelloBean2 pickup the annotations on AbstractBean, jandex.idx was generate for the helloWorld-api.jar and then the j-d-s.xml file dependency has export=true so helloWorld2-ejb.jar sees the classes and annotations=true set to pull in the annotations.
> When annotations is not set or annotations=false the helloWorld2.ear deploys (but the @PostConstruct is not run since annotations are not enabled). When annotations=true is set, helloWorld2.ear fails to deploy with the exception below.
> It looks like the annotations handling is possibly out of order as the j-d-s.xml dependency should ensure the deployment.helloWorld.ear module is there (which it does when annotations=false, but when true it seems the module is not ready)
> {code}
> 19:44:44,659 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."helloWorld2.ear".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloWorld2.ear".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "helloWorld2.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.helloWorld.ear:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223)
> at org.jboss.as.server.deployment.annotation.CompositeIndexProcessor.deploy(CompositeIndexProcessor.java:81)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-593) Optimisation of Gs2SaslClientFactory.createSaslClient
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-593?page=com.atlassian.jira.plugin.sy... ]
Farah Juma commented on ELY-593:
--------------------------------
For channel binding negotiation, we need to know whether or not the client supports channel binding. This information is used by a GS2 SASL client to set a flag that signals the channel binding mode. It's possible for a client to support channel binding even if the mechanism selected does not support it. This means that we actually need to handle the {{ChannelBindingCallback}} in {{Gs2SaslClientFactory.createSaslClient}} regardless of whether or not the GS2 mechanism being considered actually supports channel binding.
> Optimisation of Gs2SaslClientFactory.createSaslClient
> -----------------------------------------------------
>
> Key: ELY-593
> URL: https://issues.jboss.org/browse/ELY-593
> Project: WildFly Elytron
> Issue Type: Task
> Components: SASL
> Affects Versions: 1.1.0.Beta6
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 1.1.0.Beta7
>
>
> There are a couple of opportunities to optimise the createSaslClient method.
> # Check that one of the mechanisms in the list is supported in principal.
> # The ChannelBindingCallback can possibly also be delayed until the selection reaches a mechanism that requires it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1664) Introduce mixed domain testing for EAP 6.4.7
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1664?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1664:
-------------------------------------
I think this is only needed for core, as only thing that changed is core model version.
And we have core model tests here.
mixed-domain testsuite is different beast which should probably be tested. created WFLY-6872 for that
> Introduce mixed domain testing for EAP 6.4.7
> --------------------------------------------
>
> Key: WFCORE-1664
> URL: https://issues.jboss.org/browse/WFCORE-1664
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha4
>
>
> EAP 6.4.7 introduced kernel management API version 1.8 so we should add it as a mixed domain target.
> If this is only possible for core, please move this to WFCORE.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months