[JBoss JIRA] (WFCORE-3484) Variables can't be set and used inside if/try blocks
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugi... ]
Erich Duda updated WFCORE-3484:
-------------------------------
Summary: Variables can't be set and used inside if/try blocks (was: Nonintuitive error message when for loop is used inside of if/try/batch constructs)
> Variables can't be set and used inside if/try blocks
> ----------------------------------------------------
>
> Key: WFCORE-3484
> URL: https://issues.jboss.org/browse/WFCORE-3484
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha5
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work.
> Let's see on real examples.
> {code:title=Using for inside if}
> [standalone@embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone@embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone@embedded /] echo $propName
> Unrecognized variable propName
> {code}
> As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if".
> {code:title=Using for inside try}
> [standalone@embedded /] try
> [standalone@embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone@embedded /] echo $propName
> Unrecognized variable propName
> {code}
> The same applies here as for "if" case.
> {code:title=Using for inside batch}
> [standalone@embedded /] batch
> [standalone@embedded / #] for propName in :read-children-names(child-type=system-property)
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> {code}
> In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available.
> {code:title=Using for inside for}
> [standalone@embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone@embedded /] for propName in :read-children-names(child-type=system-property)
> for is not allowed while in for block
> {code}
> Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ELY-85) Support GSS-Proxy
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.sys... ]
Jan Kalina edited comment on ELY-85 at 1/3/18 5:42 AM:
-------------------------------------------------------
Native Kerberos is supported, there are just following issues:
* properties like *sun.security.jgss.lib* needs to be set during JVM initialization - in standalone.xml it is too late - need to set using JAVA_OPTS
* SASL mechanims GS2 will not work until JDK will be fixed - problem with null address in channel binding cannot be workarounded
* mechanisms SASL GSSAPI and HTTP SPNEGO needs workaround of JDK-8194073 - implemented in PR of ELY-85
Complete setup instructions at https://hkalina.github.io/2018/01/02/gssproxy/
was (Author: honza889):
Native Kerberos is supported, there are just following issues:
* properties like *sun.security.jgss.lib* needs to be set during JVM initialization - in standalone.xml it is too late - need to set using JAVA_OPTS
* SASL mechanims GS2 will work until JDK will be fixed - problem with null address in channel binding cannot be workarounded
* mechanisms SASL GSSAPI and HTTP SPNEGO needs workaround of JDK-8194073 - implemented in PR of ELY-85
Complete setup instructions at https://hkalina.github.io/2018/01/02/gssproxy/
> Support GSS-Proxy
> -----------------
>
> Key: ELY-85
> URL: https://issues.jboss.org/browse/ELY-85
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 1.2.0.Beta13
>
>
> GSS Proxy is something we should consider being able to support when running on an OS that supports it: -
> -https://fedorahosted.org/gss-proxy/-
> https://pagure.io/gssproxy
> The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ELY-85) Support GSS-Proxy
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.sys... ]
Jan Kalina commented on ELY-85:
-------------------------------
Native Kerberos is supported, there are just following issues:
* properties like *sun.security.jgss.lib* needs to be set during JVM initialization - in standalone.xml it is too late - need to set using JAVA_OPTS
* SASL mechanims GS2 will work until JDK will be fixed - problem with null address in channel binding cannot be workarounded
* mechanisms SASL GSSAPI and HTTP SPNEGO needs workaround of JDK-8194073 - implemented in PR of ELY-85
Complete setup instructions at https://hkalina.github.io/2018/01/02/gssproxy/
> Support GSS-Proxy
> -----------------
>
> Key: ELY-85
> URL: https://issues.jboss.org/browse/ELY-85
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 1.2.0.Beta13
>
>
> GSS Proxy is something we should consider being able to support when running on an OS that supports it: -
> -https://fedorahosted.org/gss-proxy/-
> https://pagure.io/gssproxy
> The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2205) Issues in KIE WB
by Senthil Kumar Kamaraj (JIRA)
Senthil Kumar Kamaraj created DROOLS-2205:
---------------------------------------------
Summary: Issues in KIE WB
Key: DROOLS-2205
URL: https://issues.jboss.org/browse/DROOLS-2205
Project: Drools
Issue Type: Bug
Affects Versions: 7.4.1.Final
Reporter: Senthil Kumar Kamaraj
Assignee: Edson Tirelli
There are some issues in KIE workbench 7.4.1 release
1. Creating group on KIE WB on tomcat throws exception sometimes, but the group is created.
2. When trying to delete the user from KIE WB, the user is not getting deleted.
3. Language support other than English is not complete: partial support
4. Sometimes, when I am trying to perform operation on "newly created project" in KIE Workbench, URL is redirected to other existing project.
5. KIE WB user creation: Unable to create new user gracefully from the GUI: error: Cannot read property 'p8b' of null.
6. The new user creation is failing if it is assigned to Groups and Roles.
Received Error : Group not found.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-1383) Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1383?page=com.atlassian.jira.plugi... ]
Lin Gao reassigned WFCORE-1383:
-------------------------------
Assignee: Lin Gao
> Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1383
> URL: https://issues.jboss.org/browse/WFCORE-1383
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.0.0.CR1
> Environment: Linux/Debian
> Reporter: Thorsten Moeller
> Assignee: Lin Gao
>
> If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded.
> Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same.
> I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-278) ProtobufMarshaller throws ClassCastException when marshalling CDI proxied KieSession.
by Duncan Doyle (JIRA)
[ https://issues.jboss.org/browse/DROOLS-278?page=com.atlassian.jira.plugin... ]
Duncan Doyle reassigned DROOLS-278:
-----------------------------------
Assignee: Duncan Doyle
> ProtobufMarshaller throws ClassCastException when marshalling CDI proxied KieSession.
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-278
> URL: https://issues.jboss.org/browse/DROOLS-278
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.0.0.CR3
> Environment: Mac OS-X 1.0.8.5, Hotspot 1.7.0_40
> Reporter: Duncan Doyle
> Assignee: Duncan Doyle
>
> I have a CDI (Weld) @Producer which produces a KieSession. The KieSession is therefore proxied by a CDI/Weld proxy. When I try to marshall such a KieSession object, the ProtobufMarshaller throws the following ClassCastException:
> 01:21:07.505 [main] ERROR o.j.d.b.c.CdiSessionPersistenceTest - Error saving KieSession.
> java.lang.ClassCastException: org.jboss.weld.proxies.CommandExecutor$EntryPoint$KieRuntime$KieRuntimeEventManager$KieSession$ProcessEventManager$ProcessRuntime$RuleRuntime$StatefulProcessSession$StatefulRuleSession$WorkingMemoryEventManager$761192450$Proxy$_$$_WeldClientProxy cannot be cast to org.drools.core.impl.StatefulKnowledgeSessionImpl
> at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:157) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1]
> at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:148) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1]
> at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:67) ~[classes/:na]
> at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:37) ~[classes/:na]
> at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager.saveKieSession(SessionManager.java:27) ~[classes/:na]
> at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager$Proxy$_$$_WeldClientProxy.saveKieSession(SessionManager$Proxy$_$$_WeldClientProxy.java) ~[classes/:na]
> at org.jboss.ddoyle.brms.cdi.CdiSessionPersistenceTest.testCdiSessionPersistence(CdiSessionPersistenceTest.java:43) ~[test-classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40]
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) [junit-4.11.jar:na]
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [junit-4.11.jar:na]
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) [junit-4.11.jar:na]
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) [junit-4.11.jar:na]
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [junit-4.11.jar:na]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [junit-4.11.jar:na]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.11.jar:na]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:na]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:na]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:na]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:na]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:na]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:na]
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) [surefire-junit4-2.10.jar:2.10]
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) [surefire-junit4-2.10.jar:2.10]
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) [surefire-junit4-2.10.jar:2.10]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40]
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) [surefire-api-2.10.jar:2.10]
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) [surefire-booter-2.10.jar:2.10]
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) [surefire-booter-2.10.jar:2.10]
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) [surefire-booter-2.10.jar:2.10]
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) [surefire-booter-2.10.jar:2.10]
> I've created a reproducer which shows the behaviour: https://github.com/DuncanDoyle/DroolsSessionCdiClassCastException
> Just run 'mvn clean test' in the project.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2204) DMN QName regex problem and assimilated for function drools:kind
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-2204:
--------------------------------------
Summary: DMN QName regex problem and assimilated for function drools:kind
Key: DROOLS-2204
URL: https://issues.jboss.org/browse/DROOLS-2204
Project: Drools
Issue Type: Bug
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
DMN QName regex does not match with serialization strategy.
A qname string serialization as
{code:java}
{http://namespace}localPart
{code}
would fail the regex of MarshallingUtils.
Additionally FunctionDefinition could now rely on the additionalAttributes generally available at the level of DMNModelInstrumentedBase (which would also serialize any other type of additional attributes, preserving from any original .dmn file).
Finally, it was noted calling getDecisionResultByName on DMNResultImpl by passing a wrong name would have thrown the stacktrace for wrong use of Optional.get(), instead of returning null as per getDecisionResultById() of the same class.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFCORE-3484) Nonintuitive error message when for loop is used inside of if/try/batch constructs
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise edited comment on WFCORE-3484 at 1/2/18 11:39 AM:
-----------------------------------------------------------------------
You have revealed multiple issues there:
1) Variables can't be set and used inside if/try/for.
For example:
if (outcome != success) of /system-property=test:read-resource
set foo=bar
echo $foo
==> You will get an exception. This is the same exception that you are getting when echoing propName
2) There is no check when a redirection is already active and a new redirection is used:e.g.: if followed by if, ... The CLI accepts the new redirection silently.
Finally, having an If inside a for is supported. Nesting of the same redirection is not supported, but you can mix redirections. I will update the analysis document, it was not clear.
was (Author: jdenise):
You have revealed multiple issues there:
1) Variables can't be set and used inside if/try/for.
For example:
if (outcome != success) of /system-property=test:read-resource
set foo=bar
echo $foo
==> You will get an exception. This is the same exception that you are getting when echoing propName
2) There is no check when a redirection is already active and a new redirection is used:e.g.: try followed by if, if followed by if, ... The CLI accepts the new redirection silently.
3) Command name completion is not helpful, although a redirection is active (eg: if), other redirections are proposed (try, for).
> Nonintuitive error message when for loop is used inside of if/try/batch constructs
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3484
> URL: https://issues.jboss.org/browse/WFCORE-3484
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha5
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work.
> Let's see on real examples.
> {code:title=Using for inside if}
> [standalone@embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone@embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone@embedded /] echo $propName
> Unrecognized variable propName
> {code}
> As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if".
> {code:title=Using for inside try}
> [standalone@embedded /] try
> [standalone@embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone@embedded /] echo $propName
> Unrecognized variable propName
> {code}
> The same applies here as for "if" case.
> {code:title=Using for inside batch}
> [standalone@embedded /] batch
> [standalone@embedded / #] for propName in :read-children-names(child-type=system-property)
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> {code}
> In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available.
> {code:title=Using for inside for}
> [standalone@embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone@embedded /] for propName in :read-children-names(child-type=system-property)
> for is not allowed while in for block
> {code}
> Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months