[JBoss JIRA] (WFLY-13802) The undertow layer can not deploy deployments without the ee layer
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-13802:
---------------------------------------
Summary: The undertow layer can not deploy deployments without the ee layer
Key: WFLY-13802
URL: https://issues.redhat.com/browse/WFLY-13802
Project: WildFly
Issue Type: Bug
Components: Build System, Web (Undertow)
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 21.0.0.Beta1
{code:java}
16:35:06,234 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-webapp.war".undertow-deployment.UndertowDeploymentInfoService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException
at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:50)
at org.jboss.as.ee.component.ComponentRegistry.createInstanceFactory(ComponentRegistry.java:76)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:709)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:276)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
... 6 more
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13771) Create a Galleon layers for the messaging subsystem
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13771?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13771:
-----------------------------------------
[~fwelland] WFLY-13354 is to add layers for EJB3. As Emmanuel noted the ones that include MDB would bring in what's needed without adding an embedded broker.
> Create a Galleon layers for the messaging subsystem
> ---------------------------------------------------
>
> Key: WFLY-13771
> URL: https://issues.redhat.com/browse/WFLY-13771
> Project: WildFly
> Issue Type: Feature Request
> Components: Build System, JMS
> Reporter: Yeray Borges Santana
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> We have three possible messaging-activemq configuration options that should be supplied via Galleon layers:
> # messaging-activemq subsystem configuration ready to be used as an Embedded broker. This configuration is useful to run quick demos only, it should not be used in production environments or cloud environments.
> # messaging-activemq subsystem configuration ready to be used with an external broker.
> # An empty messaging-activemq subsystem configuration and capabilities to deploy a Resource Adapter file to connect to an external broker. This .rar file has to be deployed by the user.
> The existing jms-activemq layer was meant to allow client-side JMS, it is almost covering the third option, however, the user should be able to deploy .rar files. The analysis document should clarify whether these capabilities should be included in a Galleon layer itself or by contrast, users should add the resource-adapters Galleon layer to provide it.
> Another point to clear up is if the Galleon layers will supply capabilities to invoke remote objects configured in the WildFly JNDI tree, hence the need for remoting naming.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13771) Create a Galleon layers for the messaging subsystem
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13771?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-13771:
------------------------------------------
[~fwelland] I guess you are in case number 3: you wouldn't need to specify the resource-adapters layer since it would be pulled by the empty messaging-activemq layer pulled by ejb3.
> Create a Galleon layers for the messaging subsystem
> ---------------------------------------------------
>
> Key: WFLY-13771
> URL: https://issues.redhat.com/browse/WFLY-13771
> Project: WildFly
> Issue Type: Feature Request
> Components: Build System, JMS
> Reporter: Yeray Borges Santana
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> We have three possible messaging-activemq configuration options that should be supplied via Galleon layers:
> # messaging-activemq subsystem configuration ready to be used as an Embedded broker. This configuration is useful to run quick demos only, it should not be used in production environments or cloud environments.
> # messaging-activemq subsystem configuration ready to be used with an external broker.
> # An empty messaging-activemq subsystem configuration and capabilities to deploy a Resource Adapter file to connect to an external broker. This .rar file has to be deployed by the user.
> The existing jms-activemq layer was meant to allow client-side JMS, it is almost covering the third option, however, the user should be able to deploy .rar files. The analysis document should clarify whether these capabilities should be included in a Galleon layer itself or by contrast, users should add the resource-adapters Galleon layer to provide it.
> Another point to clear up is if the Galleon layers will supply capabilities to invoke remote objects configured in the WildFly JNDI tree, hence the need for remoting naming.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (DROOLS-5591) Compilation fails on generated model
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5591?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5591:
---------------------------------
Sprint: 2020 Week 34-36 (from Aug 17)
> Compilation fails on generated model
> ------------------------------------
>
> Key: DROOLS-5591
> URL: https://issues.redhat.com/browse/DROOLS-5591
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.38.0.Final, 7.39.0.Final, 7.40.0.Final, 7.41.0.Final, 7.42.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> Given the following rule:
> {code:java}
> import java.util.Map;
> import java.util.List;
> global java.util.Set controlSet;
> global org.example.drools.service.DummyService dummyService;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> $m: Measurement( id == "color", $colorVal : val )
> String() from dummyService.dummy($m.getId(), $m.getVal())
> then
> controlSet.add($colorVal);
> end{code}
>
> Compiling the generated model throws:
> {code:java}
> [...]/drools-model-compiler/main/java/defaultpkg/Rules6348cbea36f646fc98d4712bf48686c6RuleMethods0.java:[25,111] no suitable method found for from(org.drools.model.Global<org.example.drools.service.DummyService>,org.drools.model.Variable<org.example.drools.model.Measurement>,org.drools.model.Variable<org.example.drools.model.Measurement>,defaultpkg.P6C.LambdaExtractor6C9C4CCEE9EF61AD2FF71F545BAC12C2)
> [ERROR] method org.drools.model.DSL.<T>from(T) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.functions.Function0<T>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>,org.drools.model.functions.Function1<T,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.functions.Function2<A,B,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B,C>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.functions.Function3<A,B,C,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,C
> [ERROR] (argument mismatch; defaultpkg.P6C.LambdaExtractor6C9C4CCEE9EF61AD2FF71F545BAC12C2 cannot be converted to org.drools.model.functions.Function3<A,B,C,?>))
> [ERROR] method org.drools.model.DSL.<A,B,C,D>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.Variable<D>,org.drools.model.functions.Function4<A,B,C,D,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,C,D
> [ERROR] (actual and formal argument lists differ in length)){code}
>
> This error occurs as well with drools version _7.43.0-SNAPSHOT_
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (DROOLS-5590) org.kie:kie-maven-plugin:7.43.0-SNAPSHOT:generateModel failed: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5590?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5590:
---------------------------------
Story Points: 1
> org.kie:kie-maven-plugin:7.43.0-SNAPSHOT:generateModel failed: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5590
> URL: https://issues.redhat.com/browse/DROOLS-5590
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final, 7.41.0.Final, 7.42.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> When compiling the rules, _org.kie:kie-maven-plugin::generateModel_ fails with _sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl_
> Given the rule below:
> {code:java}
> import java.util.Map;
> import java.util.List;
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> $measurement: Measurement( id == "color", $colorVal : val )
> $lst : List() from collect(Measurement())
> $selectedList: List() from accumulate(Measurement($m: this) from $lst, collectList(Map.entry($m, $measurement.getListOfCodes())))
> then
> controlSet.add($colorVal);
> end{code}
> Fails with the following stack exception:
> {code:java}
> Caused by: java.lang.ArrayStoreException: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
> at java.util.stream.Nodes$FixedNodeBuilder.accept (Nodes.java:1230)
> at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:195)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1654)
> at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:484)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:474)
> at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:550)
> at java.util.stream.AbstractPipeline.evaluateToArrayNode (AbstractPipeline.java:260)
> at java.util.stream.ReferencePipeline.toArray (ReferencePipeline.java:517)
> at org.drools.modelcompiler.builder.generator.DrlxParseUtil.returnTypeOfMethodCallExpr (DrlxParseUtil.java:186)
> at org.drools.modelcompiler.builder.generator.ToMethodCall.setCursorForMethodCall (ToMethodCall.java:128)
> at org.drools.modelcompiler.builder.generator.ToMethodCall.toMethodCallWithClassCheck (ToMethodCall.java:71)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.methodCallExprParameter (AccumulateVisitor.java:262)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.parseFirstParameter (AccumulateVisitor.java:206)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.visit (AccumulateVisitor.java:186)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.classicAccumulate (AccumulateVisitor.java:145)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.visit (AccumulateVisitor.java:128)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit (ModelGeneratorVisitor.java:139)
> at org.drools.compiler.lang.descr.PatternDescr.accept (PatternDescr.java:288)
> at org.drools.modelcompiler.builder.generator.visitor.AndVisitor.visit (AndVisitor.java:50)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit (ModelGeneratorVisitor.java:86)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule (ModelGenerator.java:186)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel (ModelGenerator.java:159)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages (ModelBuilderImpl.java:281)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules (ModelBuilderImpl.java:209)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.postBuild (ModelBuilderImpl.java:129)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:111)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:97)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages (AbstractKieProject.java:268)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages (AbstractKieProject.java:216)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify (AbstractKieProject.java:80)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject (KieBuilderImpl.java:279)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll (KieBuilderImpl.java:247)
> at org.kie.maven.plugin.GenerateModelMojo.generateModel (GenerateModelMojo.java:146)
> at org.kie.maven.plugin.GenerateModelMojo.execute (GenerateModelMojo.java:106)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137){code}
>
> As the title says, this error happens on the _7.43.0-SNAPSHOT_ version as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (DROOLS-5590) org.kie:kie-maven-plugin:7.43.0-SNAPSHOT:generateModel failed: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5590?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5590:
---------------------------------
Sprint: 2020 Week 34-36 (from Aug 17)
> org.kie:kie-maven-plugin:7.43.0-SNAPSHOT:generateModel failed: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5590
> URL: https://issues.redhat.com/browse/DROOLS-5590
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final, 7.41.0.Final, 7.42.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> When compiling the rules, _org.kie:kie-maven-plugin::generateModel_ fails with _sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl_
> Given the rule below:
> {code:java}
> import java.util.Map;
> import java.util.List;
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> $measurement: Measurement( id == "color", $colorVal : val )
> $lst : List() from collect(Measurement())
> $selectedList: List() from accumulate(Measurement($m: this) from $lst, collectList(Map.entry($m, $measurement.getListOfCodes())))
> then
> controlSet.add($colorVal);
> end{code}
> Fails with the following stack exception:
> {code:java}
> Caused by: java.lang.ArrayStoreException: sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl
> at java.util.stream.Nodes$FixedNodeBuilder.accept (Nodes.java:1230)
> at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:195)
> at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1654)
> at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:484)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:474)
> at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:550)
> at java.util.stream.AbstractPipeline.evaluateToArrayNode (AbstractPipeline.java:260)
> at java.util.stream.ReferencePipeline.toArray (ReferencePipeline.java:517)
> at org.drools.modelcompiler.builder.generator.DrlxParseUtil.returnTypeOfMethodCallExpr (DrlxParseUtil.java:186)
> at org.drools.modelcompiler.builder.generator.ToMethodCall.setCursorForMethodCall (ToMethodCall.java:128)
> at org.drools.modelcompiler.builder.generator.ToMethodCall.toMethodCallWithClassCheck (ToMethodCall.java:71)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.methodCallExprParameter (AccumulateVisitor.java:262)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.parseFirstParameter (AccumulateVisitor.java:206)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.visit (AccumulateVisitor.java:186)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.classicAccumulate (AccumulateVisitor.java:145)
> at org.drools.modelcompiler.builder.generator.visitor.accumulate.AccumulateVisitor.visit (AccumulateVisitor.java:128)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit (ModelGeneratorVisitor.java:139)
> at org.drools.compiler.lang.descr.PatternDescr.accept (PatternDescr.java:288)
> at org.drools.modelcompiler.builder.generator.visitor.AndVisitor.visit (AndVisitor.java:50)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit (ModelGeneratorVisitor.java:86)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule (ModelGenerator.java:186)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel (ModelGenerator.java:159)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages (ModelBuilderImpl.java:281)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules (ModelBuilderImpl.java:209)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.postBuild (ModelBuilderImpl.java:129)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:111)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build (CompositeKnowledgeBuilderImpl.java:97)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages (AbstractKieProject.java:268)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages (AbstractKieProject.java:216)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify (AbstractKieProject.java:80)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject (KieBuilderImpl.java:279)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll (KieBuilderImpl.java:247)
> at org.kie.maven.plugin.GenerateModelMojo.generateModel (GenerateModelMojo.java:146)
> at org.kie.maven.plugin.GenerateModelMojo.execute (GenerateModelMojo.java:106)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137){code}
>
> As the title says, this error happens on the _7.43.0-SNAPSHOT_ version as well.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (DROOLS-5591) Compilation fails on generated model
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5591?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5591:
---------------------------------
Story Points: 1
> Compilation fails on generated model
> ------------------------------------
>
> Key: DROOLS-5591
> URL: https://issues.redhat.com/browse/DROOLS-5591
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.38.0.Final, 7.39.0.Final, 7.40.0.Final, 7.41.0.Final, 7.42.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> Given the following rule:
> {code:java}
> import java.util.Map;
> import java.util.List;
> global java.util.Set controlSet;
> global org.example.drools.service.DummyService dummyService;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> $m: Measurement( id == "color", $colorVal : val )
> String() from dummyService.dummy($m.getId(), $m.getVal())
> then
> controlSet.add($colorVal);
> end{code}
>
> Compiling the generated model throws:
> {code:java}
> [...]/drools-model-compiler/main/java/defaultpkg/Rules6348cbea36f646fc98d4712bf48686c6RuleMethods0.java:[25,111] no suitable method found for from(org.drools.model.Global<org.example.drools.service.DummyService>,org.drools.model.Variable<org.example.drools.model.Measurement>,org.drools.model.Variable<org.example.drools.model.Measurement>,defaultpkg.P6C.LambdaExtractor6C9C4CCEE9EF61AD2FF71F545BAC12C2)
> [ERROR] method org.drools.model.DSL.<T>from(T) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.functions.Function0<T>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>,org.drools.model.functions.Function1<T,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.functions.Function2<A,B,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B,C>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.functions.Function3<A,B,C,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,C
> [ERROR] (argument mismatch; defaultpkg.P6C.LambdaExtractor6C9C4CCEE9EF61AD2FF71F545BAC12C2 cannot be converted to org.drools.model.functions.Function3<A,B,C,?>))
> [ERROR] method org.drools.model.DSL.<A,B,C,D>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.Variable<D>,org.drools.model.functions.Function4<A,B,C,D,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,C,D
> [ERROR] (actual and formal argument lists differ in length)){code}
>
> This error occurs as well with drools version _7.43.0-SNAPSHOT_
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13801) JWT Revoke Feature
by Paulo Cesar Silva Reis (Jira)
[ https://issues.redhat.com/browse/WFLY-13801?page=com.atlassian.jira.plugi... ]
Paulo Cesar Silva Reis commented on WFLY-13801:
-----------------------------------------------
Got it, so something like *Keycloak* is the way to go and I agree with you, token revocation would be nice to have :).
> JWT Revoke Feature
> ------------------
>
> Key: WFLY-13801
> URL: https://issues.redhat.com/browse/WFLY-13801
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 20.0.1.Final
> Reporter: Paulo Cesar Silva Reis
> Assignee: Darran Lofthouse
> Priority: Major
>
> Hi,
>
> We've been working with JWT using Elytron and we would like to know why there isn't a way to REVOKE tokens. Reading the documentation it seems elytron doesn't provide a way to double-check whether that valid JWT still has access to the application. If a class could be instantiate and a method called, the application could validate it, returning a boolean (indicating whether the user can proceed) or throwing an exception when permission is denied.
> If such feature isn't present, even though we blacklist the token (logging him out), the user already logged in and that can be a security breach.
>
> Something like this would be great:
> {code:java}
> /subsystem=elytron/token-realm=app-realm:add(jwt={issuer=["issuer"],audience=["app"],key-store=app.ks,certificate="alias", validator="com.validator.TokenValidator"},principal-claim="sub"){code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13801) JWT Revoke Feature
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13801?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13801:
-----------------------------------------
Thank you for the feature request, token revocation is certainly something we can consider further.
At the moment the alternative is to configure the token realm to use introspection, this will result in a call back to the authorization server to verify a token is still valid.
When using the offline verification of tokens it would generally be better to issue tokens with a small period of validity to minimise the window between invalidating a token and the token timing out.
> JWT Revoke Feature
> ------------------
>
> Key: WFLY-13801
> URL: https://issues.redhat.com/browse/WFLY-13801
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 20.0.1.Final
> Reporter: Paulo Cesar Silva Reis
> Assignee: Darran Lofthouse
> Priority: Major
>
> Hi,
>
> We've been working with JWT using Elytron and we would like to know why there isn't a way to REVOKE tokens. Reading the documentation it seems elytron doesn't provide a way to double-check whether that valid JWT still has access to the application. If a class could be instantiate and a method called, the application could validate it, returning a boolean (indicating whether the user can proceed) or throwing an exception when permission is denied.
> If such feature isn't present, even though we blacklist the token (logging him out), the user already logged in and that can be a security breach.
>
> Something like this would be great:
> {code:java}
> /subsystem=elytron/token-realm=app-realm:add(jwt={issuer=["issuer"],audience=["app"],key-store=app.ks,certificate="alias", validator="com.validator.TokenValidator"},principal-claim="sub"){code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month