July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8942) Request Scope is not active during Batchlet

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-8942?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-8942: -------------------------------- Attachment: batch-chunk.war > Request Scope is not active during Batchlet > ------------------------------------------- > > Key: WFLY-8942 > URL: https://issues.jboss.org/browse/WFLY-8942 > Project: WildFly > Issue Type: Bug > Components: Batch, CDI / Weld > Affects Versions: 10.1.0.Final > Environment: Wildfly 10.1.0 Final > Reporter: Cody Lerum > Assignee: James Perkins > Attachments: batch-chunk.war > > > When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted. > Example > {noformat} > 20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped > at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165) > at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8942) Request Scope is not active during Batchlet

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-8942?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-8942: ------------------------------------- [~clerum] I believe it would have to be yes. The lifecycle would have to be of the Batchlet and each Batchlet would get a separate context. > Request Scope is not active during Batchlet > ------------------------------------------- > > Key: WFLY-8942 > URL: https://issues.jboss.org/browse/WFLY-8942 > Project: WildFly > Issue Type: Bug > Components: Batch, CDI / Weld > Affects Versions: 10.1.0.Final > Environment: Wildfly 10.1.0 Final > Reporter: Cody Lerum > Assignee: James Perkins > > When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted. > Example > {noformat} > 20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped > at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165) > at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8942) Request Scope is not active during Batchlet

by Cody Lerum (JIRA)

[ https://issues.jboss.org/browse/WFLY-8942?page=com.atlassian.jira.plugin.... ] Cody Lerum commented on WFLY-8942: ---------------------------------- [~jamezp] There would be a separate RequestScopeContext per Batchlet right? > Request Scope is not active during Batchlet > ------------------------------------------- > > Key: WFLY-8942 > URL: https://issues.jboss.org/browse/WFLY-8942 > Project: WildFly > Issue Type: Bug > Components: Batch, CDI / Weld > Affects Versions: 10.1.0.Final > Environment: Wildfly 10.1.0 Final > Reporter: Cody Lerum > Assignee: James Perkins > > When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted. > Example > {noformat} > 20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped > at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165) > at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8942) Request Scope is not active during Batchlet

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-8942?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-8942: ------------------------------------- The problem seems to be the {{RequestScopeContext}} is destroyed before the injected bean is used. My guess is since the HTTP request is complete, the context is destroyed. We may need something similar to what is being done for EJB {{@RequestScope}}. Part of the EJB implementation seems to be in Weld Core and the other part in WildFly. [~mkouba] We may need your thoughts here. I'll attach a WAR which will easily reproduce this issue. Currently batch creates the beans like [this|https://github.com/wildfly/wildfly/blob/master/batch/extension-jbere...]. This creation part would happen before a new batch thread is launched. This is why I think the bean has essentially fell out of scope because it lazily loads the injected {{@RquestScope}} bean in a new thread. Is there an easy way to handle this? > Request Scope is not active during Batchlet > ------------------------------------------- > > Key: WFLY-8942 > URL: https://issues.jboss.org/browse/WFLY-8942 > Project: WildFly > Issue Type: Bug > Components: Batch, CDI / Weld > Affects Versions: 10.1.0.Final > Environment: Wildfly 10.1.0 Final > Reporter: Cody Lerum > Assignee: James Perkins > > When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted. > Example > {noformat} > 20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped > at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165) > at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1651) FEEL String marshaller fails on list of null

by Mélanie Gauthier (JIRA)

Mélanie Gauthier created DROOLS-1651: ---------------------------------------- Summary: FEEL String marshaller fails on list of null Key: DROOLS-1651 URL: https://issues.jboss.org/browse/DROOLS-1651 Project: Drools Issue Type: Bug Components: dmn engine Reporter: Mélanie Gauthier Assignee: Edson Tirelli Attachments: Invalid function.dmn For example, if you execute the invalid attached file (kind attribute of the function isn't right - it is set to undefined) it produces an array of null. When calling FEELStringMarshaller.INSTANCE.marshall(decisionResult.getResult()) you get a NPE. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1650) Exclude the jsr94 from Drools build

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1650?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1650: ----------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Exclude the jsr94 from Drools build > ----------------------------------- > > Key: DROOLS-1650 > URL: https://issues.jboss.org/browse/DROOLS-1650 > Project: Drools > Issue Type: Bug > Reporter: Ryan Zhang > Assignee: Mario Fusco > > This is requesting to retire jsr94 because we can't find the source code license information for it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1629) PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1629?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1629: -------------------------------- Description: We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles. When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy. The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space. This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now. Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation. In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors. was: We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles. When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy. The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space. This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now. Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation. In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors. Steps to Reproduce: Define two marshalling strategies mapping different persistence units. This problem only happens while using the same implementation class of a ObjectMarshallingStrategy but initialized with different parameters. was: Define two marshalling strategies mapping different persistence units. This problem only happens while using the same implementation class of a ObjectMarshallingStrategy but initialized with different parameters. Sprint: 2017 Week 26-27 > PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies > ---------------------------------------------------------------------------------------- > > Key: DROOLS-1629 > URL: https://issues.jboss.org/browse/DROOLS-1629 > Project: Drools > Issue Type: Bug > Components: core engine, kie server > Affects Versions: 6.4.0.Final, 6.5.0.Final > Reporter: Manuel Castro > Assignee: Mario Fusco > Original Estimate: 3 days > Remaining Estimate: 3 days > > We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles. > When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy. > The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space. > This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now. > Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation. > In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1583) Refactor KnowledgeBaseImpl

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1583?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1583: ------------------------------------- Also https://github.com/kiegroup/drools/commit/e1561acc99e4ddbb75385b6b606bb1a... > Refactor KnowledgeBaseImpl > -------------------------- > > Key: DROOLS-1583 > URL: https://issues.jboss.org/browse/DROOLS-1583 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Matteo Mortari > Fix For: 7.1.0.Beta3 > > > It is required to review the KnowledgeBaseImpl and lower the technical debt accumulated on it by: > # Remove unnecessary duplicated methods that at the moment are there only for backward compatibility reasons. > # Review the locks and in particular check if some of them can be removed since now the kbase changes are enqueued. > # Review the rules/packages addition lifecycle emitting events before and after them (and in general reviewing the existing events). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2935) Wildfly Elytron Tool, PowerShell elytron-tool.ps1 script doesn't work with arguments.

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2935?page=com.atlassian.jira.plugi... ] Ilia Vassilev commented on WFCORE-2935: --------------------------------------- The issue is resoled by the PR [1] submitted for WFCORE-2976. [1] https://github.com/wildfly/wildfly-core/pull/2556 > Wildfly Elytron Tool, PowerShell elytron-tool.ps1 script doesn't work with arguments. > ------------------------------------------------------------------------------------- > > Key: WFCORE-2935 > URL: https://issues.jboss.org/browse/WFCORE-2935 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > Priority: Critical > > PowerShell elytron-tool.ps1 script doesn't work with arguments. > When I add *$args* at the end of line in elytron-tool.ps1 script [1] > {code} > & $JAVA -jar $JBOSS_HOME'\bin\wildfly-elytron-tool.jar' $JAVA_OPTS $args > {code} > it works. > *How to reproduce* > {code} > PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l testBasicWildflyElytronTool.jceks > {code} > There is shown general help output for all commands in tool. > [1] https://github.com/wildfly/wildfly-core/blob/3.0.0.Beta24/core-feature-pa... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2935) Wildfly Elytron Tool, PowerShell elytron-tool.ps1 script doesn't work with arguments.

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2935?page=com.atlassian.jira.plugi... ] Ilia Vassilev reassigned WFCORE-2935: ------------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Wildfly Elytron Tool, PowerShell elytron-tool.ps1 script doesn't work with arguments. > ------------------------------------------------------------------------------------- > > Key: WFCORE-2935 > URL: https://issues.jboss.org/browse/WFCORE-2935 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > Priority: Critical > > PowerShell elytron-tool.ps1 script doesn't work with arguments. > When I add *$args* at the end of line in elytron-tool.ps1 script [1] > {code} > & $JAVA -jar $JBOSS_HOME'\bin\wildfly-elytron-tool.jar' $JAVA_OPTS $args > {code} > it works. > *How to reproduce* > {code} > PowerShell -ExecutionPolicy Bypass -File elytron-tool.ps1 credential-store --add secret_alias --password pass123 --create -x secret_password -l testBasicWildflyElytronTool.jceks > {code} > There is shown general help output for all commands in tool. > [1] https://github.com/wildfly/wildfly-core/blob/3.0.0.Beta24/core-feature-pa... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2017