[JBoss JIRA] (WFCORE-3963) Fix of WFCORE-3826 breaks plain authentication for ejbs using legacy configuration
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3963?page=com.atlassian.jira.plugi... ]
Jiri Ondrusek edited comment on WFCORE-3963 at 8/9/18 7:09 AM:
---------------------------------------------------------------
[~dehort] I've tested following configuration (with JAAS)
{quote} <security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<jaas name="ima_jaas_sec_domain"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>{quote}
{quote}<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<properties>
<property name="SASL_MECHANISMS" value="ANONYMOUS,PLAIN"/>
<property name="SASL_POLICY_NOANONYMOUS" value="false"/>
</properties>
</http-connector>{quote}
As you can see, I've defined JAAS as you suggested. (Whole file is attached as standalone2.xml)
With this configuration, authentication *works*.
I've noticed only one possible problem during configuration. If password is hashed in *.properties file. You have to add appropriate hash algorithm into login module:
{quote}<security-domain name="ima_jaas_sec_domain" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file:///\${jboss.server.config.dir}/application-users.properties"/>
<module-option name="rolesProperties" value="file:///\${jboss.server.config.dir}/application-roles.properties"/>
<module-option name="hashAlgorithm" value="MD5"/>
</login-module>
</authentication>{quote}
was (Author: jondruse):
[~dehort] I've tested following configuration (with JAAS)
{quote} <security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<jaas name="ima_jaas_sec_domain"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>{quote}
{quote}<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<properties>
<property name="SASL_MECHANISMS" value="ANONYMOUS,PLAIN"/>
<property name="SASL_POLICY_NOANONYMOUS" value="false"/>
</properties>
</http-connector>{quote}
As you can see, I've defined JAAS as you suggested. (Whole file is attached as standalone2.xml)
With this configuration, authentication *works*.
I've noticed only one possible problem during configuration. If password is hashed in *.properties file. You have to add appropriate hash algorithm into login module:
{quote}<security-domain name="ima_jaas_sec_domain" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file:///${jboss.server.config.dir}/application-users.properties"/>
<module-option name="rolesProperties" value="file:///${jboss.server.config.dir}/application-roles.properties"/>
<module-option name="hashAlgorithm" value="MD5"/>
</login-module>
</authentication>{quote}
> Fix of WFCORE-3826 breaks plain authentication for ejbs using legacy configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3963
> URL: https://issues.jboss.org/browse/WFCORE-3963
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 6.0.0.Alpha3
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Labels: Regression
> Fix For: 6.0.0.Alpha5
>
> Attachments: standalone-for-node01.xml, standalone2.xml
>
>
> Fix https://issues.jboss.org/browse/WFCORE-3826 fixes anonymous authentication but breaks authenticated mode (for example PLAIN mode with username/password). See https://issues.jboss.org/browse/JBEAP-14647 for more details.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3963) Fix of WFCORE-3826 breaks plain authentication for ejbs using legacy configuration
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3963?page=com.atlassian.jira.plugi... ]
Jiri Ondrusek commented on WFCORE-3963:
---------------------------------------
[~dehort] I've tested following configuration (with JAAS)
{quote} <security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<jaas name="ima_jaas_sec_domain"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>{quote}
{quote}<http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
<properties>
<property name="SASL_MECHANISMS" value="ANONYMOUS,PLAIN"/>
<property name="SASL_POLICY_NOANONYMOUS" value="false"/>
</properties>
</http-connector>{quote}
As you can see, I've defined JAAS as you suggested. (Whole file is attached as standalone2.xml)
With this configuration, authentication *works*.
I've noticed only one possible problem during configuration. If password is hashed in *.properties file. You have to add appropriate hash algorithm into login module:
{quote}<security-domain name="ima_jaas_sec_domain" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file:///${jboss.server.config.dir}/application-users.properties"/>
<module-option name="rolesProperties" value="file:///${jboss.server.config.dir}/application-roles.properties"/>
<module-option name="hashAlgorithm" value="MD5"/>
</login-module>
</authentication>{quote}
> Fix of WFCORE-3826 breaks plain authentication for ejbs using legacy configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3963
> URL: https://issues.jboss.org/browse/WFCORE-3963
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 6.0.0.Alpha3
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Labels: Regression
> Fix For: 6.0.0.Alpha5
>
> Attachments: standalone-for-node01.xml
>
>
> Fix https://issues.jboss.org/browse/WFCORE-3826 fixes anonymous authentication but breaks authenticated mode (for example PLAIN mode with username/password). See https://issues.jboss.org/browse/JBEAP-14647 for more details.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2792) [DMN Designer] Data-types: Grid: LiteralExpression
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2792?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2792:
--------------------------------
Description:
*_Literal Expression_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
- (/) Update header when Output Data Type is changed via Properties panel
h3. Manual acceptance test
- Resizing (/)
- Ctrl+C, Ctrl+v (/)
- Default Data Type for literal expression (/)
- Selecting itemDefinition (/)
- Long name of data type (?)
-- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
-- [manstis] We could resize the column based on the Data Type name; feel free to open a (minor) JIRA and [~tirelli] can comment.
- Used in levels of context grid (/)
-- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
-- Should be the data type shown anytime or just if literal expression is top level context entry?
-- [manstis] For {{LiteralExpression}} only when top-level. {{ContextEntry}} will have a similar editor when https://issues.jboss.org/browse/DROOLS-2796 is complete.
- Changing data type in graph node (/)
- Changing data type in properties panel (/)
- Building project (?)
-- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
-- [manstis] Validation will be performed when saved/validated and errors appear in the Message Console. How validation is supported is, IIRC, a JIRA somewhere already.
- Undo / Redo (/)
was:
*_Literal Expression_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
- (/) Update header when Output Data Type is changed via Properties panel
h3. Manual acceptance test
- Resizing (/)
- Ctrl+C, Ctrl+v (/)
- Default Data Type for literal expression (/)
- Selecting itemDefinition (/)
- Long name of data type (?)
-- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
-- [manstis] We could resize the column based on the Data Type name; feel free to open a (minor) JIRA and [~tirelli] can comment.
- Used in levels of context grid (/)
-- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
-- Should be the data type shown anytime or just if literal expression is top level context entry?
-- [manstis] For {{LiteralExpression}} only when top-level. {{ContextEntry}} will have a similar editor when https://issues.jboss.org/browse/DROOLS-2796 is complete.
- Changing data type in graph node (/)
- Changing data type in properties panel (/)
- Building project (?)
-- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
-- [manstis] Validation will be performed when saved/validated and errors appear in the Message Console. How validation is supported is, IIRC, a JIRA somewhere already.
- Undo / Redo
> [DMN Designer] Data-types: Grid: LiteralExpression
> --------------------------------------------------
>
> Key: DROOLS-2792
> URL: https://issues.jboss.org/browse/DROOLS-2792
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Attachments: DROOLS-2792.odt, Screen Shot 2018-08-01 at 10.11.48 AM.png, Screen Shot 2018-08-01 at 10.20.35 AM.png, Screenshot from 2018-08-09 09-21-01.png
>
>
> *_Literal Expression_*
> - (/) Grid header _could_ show Output Data Type
> - (/) Editing Output Data Type is possible via Properties panel
> - (/) Update header when Output Data Type is changed via Properties panel
> h3. Manual acceptance test
> - Resizing (/)
> - Ctrl+C, Ctrl+v (/)
> - Default Data Type for literal expression (/)
> - Selecting itemDefinition (/)
> - Long name of data type (?)
> -- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
> -- [manstis] We could resize the column based on the Data Type name; feel free to open a (minor) JIRA and [~tirelli] can comment.
> - Used in levels of context grid (/)
> -- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
> -- Should be the data type shown anytime or just if literal expression is top level context entry?
> -- [manstis] For {{LiteralExpression}} only when top-level. {{ContextEntry}} will have a similar editor when https://issues.jboss.org/browse/DROOLS-2796 is complete.
> - Changing data type in graph node (/)
> - Changing data type in properties panel (/)
> - Building project (?)
> -- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
> -- [manstis] Validation will be performed when saved/validated and errors appear in the Message Console. How validation is supported is, IIRC, a JIRA somewhere already.
> - Undo / Redo (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SWSQE-374) When starting 40> more jenkins slaves some of them fail to start
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-374?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-374:
-------------------------------------
I updated the kubernetes plugin to the latest version to see if the issue disappears but I hit another issue, I filed plugin bug: https://issues.jenkins-ci.org/browse/JENKINS-52958
> When starting 40> more jenkins slaves some of them fail to start
> -----------------------------------------------------------------
>
> Key: SWSQE-374
> URL: https://issues.jboss.org/browse/SWSQE-374
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Minor
>
> Some slaves fail to start with following errors:
> from jenkins log:
> ARNING: Error in provisioning; agent=KubernetesSlave name: jenkins-slave-kiali-ui-tests-fcdsz, template=PodTemplate{inheritFrom='', name='jenkins-slave-kiali-ui-tests', namespace='jenkins-slaves', label='python kiali-ui-tests', nodeSelector='', nodeUsageMode=NORMAL, workspaceVolume=EmptyDirWorkspaceVolume [memory=false], containers=[ContainerTemplate{name='jnlp', image='docker-registry.default.svc:5000/jenkins-slaves/jenkins-slave-kiali-ui-tests', alwaysPullImage=true, workingDir='/home/jenkins', command='', args='${computer.jnlpmac} ${computer.name} ', resourceRequestCpu='', resourceRequestMemory='', resourceLimitCpu='', resourceLimitMemory='', livenessProbe=org.csanchez.jenkins.plugins.kubernetes.ContainerLivenessProbe@3106f760}], yaml=}
> java.lang.IllegalStateException: Node was deleted, computer is null
> at org.csanchez.jenkins.plugins.kubernetes.KubernetesLauncher.launch(KubernetesLauncher.java:177)
> at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:292)
> at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
> at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Aug 08, 2018 8:38:46 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesSlave _terminate
> INFO: Terminating Kubernetes instance for agent jenkins-slave-kiali-ui-tests-fcdsz
> Aug 08, 2018 8:38:46 AM org.csanchez.jenkins.plugins.kubernetes.KubernetesSlave _terminate
> SEVERE: Computer for agent is null: jenkins-slave-kiali-ui-tests-fcdsz
> WARNING: Unable to move atomically, falling back to non-atomic move.
> java.nio.file.NoSuchFileException: /var/lib/jenkins/nodes/jenkins-slave-kiali-ui-tests-fcdsz/atomic9143280938281774341tmp -> /var/lib/jenkins/nodes/jenkins-slave-kiali-ui-tests-fcdsz/config.xml
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:396)
> at sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> at java.nio.file.Files.move(Files.java:1395)
> at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:191)
> at hudson.XmlFile.write(XmlFile.java:198)
> at jenkins.model.Nodes.persistNode(Nodes.java:175)
> at jenkins.model.Nodes.addNode(Nodes.java:144)
> at jenkins.model.Jenkins.addNode(Jenkins.java:2058)
> at hudson.slaves.NodeProvisioner$2.run(NodeProvisioner.java:241)
> at hudson.model.Queue._withLock(Queue.java:1380)
> at hudson.model.Queue.withLock(Queue.java:1257)
> at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:207)
> at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:61)
> at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(No
> WARNING: Unable to move /var/lib/jenkins/nodes/jenkins-slave-kiali-ui-tests-fcdsz/atomic9143280938281774341tmp to /var/lib/jenkins/nodes/jenkins-slave-kiali-ui-tests-fcdsz/config.xml. Attempting to delete /var/lib/jenkins/nodes/jenkins-slave-kiali-ui-tests-fcdsz/atomic9143280938281774341tmp and abandoning.
> Aug 08, 2018 8:38:34 AM hudson.slaves.NodeProvisioner$2 run
> WARNING: Provisioned agent Kubernetes Pod Template failed to launch
> java.nio.file.NoSuchFileException: /var/lib/jenkins/nodes/jenkins-slave-kiali-ui-tests-fcdsz/atomic9143280938281774341tmp
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:409)
> at sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> at java.nio.file.Files.move(Files.java:1395)
> at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:206)
> at hudson.XmlFile.write(XmlFile.java:198)
> at jenkins.model.Nodes.persistNode(Nodes.java:175)
> at jenkins.model.Nodes.addNode(Nodes.java:144)
> at jenkins.model.Jenkins.addNode(Jenkins.java:2058)
> at hudson.slaves.NodeProvisioner$2.run(NodeProvisioner.java:241)
> From docker log:
> INFO: Handshaking
> Aug 08, 2018 12:38:43 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Connecting to jenkins2.bc.jonqe.lab.eng.bos.redhat.com:39765
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Trying protocol: JNLP4-connect
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Remote identity confirmed: b0:58:42:9c:19:76:a1:78:81:79:d9:fc:9a:e9:19:fd
> Aug 08, 2018 12:38:44 PM org.jenkinsci.remoting.protocol.impl.ConnectionHeadersFilterLayer onRecv
> INFO: [JNLP4-connect connection to jenkins2.bc.jonqe.lab.eng.bos.redhat.com/10.16.23.71:39765] Local headers refused by remote: Unknown client name: jenkins-slave-kiali-ui-tests-fcdsz
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Protocol JNLP4-connect encountered an unexpected exception
> java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Unknown client name: jenkins-slave-kiali-ui-tests-fcdsz
> at org.jenkinsci.remoting.util.SettableFuture.get(SettableFuture.java:223)
> at hudson.remoting.Engine.innerRun(Engine.java:609)
> at hudson.remoting.Engine.run(Engine.java:469)
> Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Unknown client name: jenkins-slave-kiali-ui-tests-fcdsz
> at org.jenkinsci.remoting.protocol.impl.ConnectionHeadersFilterLayer.newAbortCause(ConnectionHeadersFilterLayer.java:378)
> at org.jenkinsci.remoting.protocol.impl.ConnectionHeadersFilterLayer.onRecvClosed(ConnectionHeadersFilterLayer.java:433)
> at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:832)
> at org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed(FilterLayer.java:287)
> at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.java:172)
> at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:832)
> at org.jenkinsci.remoting.protocol.NetworkLayer.onRecvClosed(NetworkLayer.java:154)
> at org.jenkinsci.remoting.protocol.impl.BIONetworkLayer.access$1500(BIONetworkLayer.java:48)
> at org.jenkinsci.remoting.protocol.impl.BIONetworkLayer$Reader.run(BIONetworkLayer.java:247)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:93)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: java.nio.channels.ClosedChannelException
> ... 7 more
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Connecting to jenkins2.bc.jonqe.lab.eng.bos.redhat.com:39765
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Server reports protocol JNLP4-plaintext not supported, skipping
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Server reports protocol JNLP3-connect not supported, skipping
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Server reports protocol JNLP2-connect not supported, skipping
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener status
> INFO: Server reports protocol JNLP-connect not supported, skipping
> Aug 08, 2018 12:38:44 PM hudson.remoting.jnlp.Main$CuiListener error
> SEVERE: The server rejected the connection: None of the protocols were accepted
> java.lang.Exception: The server rejected the connection: None of the protocols were accepted
> at hudson.remoting.Engine.onConnectionRejected(Engine.java:670)
> at hudson.remoting.Engine.innerRun(Engine.java:634)
> at hudson.remoting.Engine.run(Engine.java:469)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2792) [DMN Designer] Data-types: Grid: LiteralExpression
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2792?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2792:
--------------------------------
Description:
*_Literal Expression_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
- (/) Update header when Output Data Type is changed via Properties panel
h3. Manual acceptance test
- Resizing (/)
- Ctrl+C, Ctrl+v (/)
- Default Data Type for literal expression (/)
- Selecting itemDefinition (/)
- Long name of data type (?)
-- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
-- [manstis] We could resize the column based on the Data Type name; feel free to open a (minor) JIRA and [~tirelli] can comment.
- Used in levels of context grid (/)
-- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
-- Should be the data type shown anytime or just if literal expression is top level context entry?
-- [manstis] For {{LiteralExpression}} only when top-level. {{ContextEntry}} will have a similar editor when https://issues.jboss.org/browse/DROOLS-2796 is complete.
- Changing data type in graph node (/)
- Changing data type in properties panel (/)
- Building project (?)
-- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
-- [manstis] Validation will be performed when saved/validated and errors appear in the Message Console. How validation is supported is, IIRC, a JIRA somewhere already.
- Undo / Redo
was:
*_Literal Expression_*
- (/) Grid header _could_ show Output Data Type
- (/) Editing Output Data Type is possible via Properties panel
- (/) Update header when Output Data Type is changed via Properties panel
h3. Manual acceptance test
- Resizing (/)
- Ctrl+C, Ctrl+v (/)
- Default Data Type for literal expression (/)
- Selecting itemDefinition (/)
- Long name of data type (?)
-- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
-- [manstis] We could resize the column based on the Data Type name; feel free to open a (minor) JIRA and [~tirelli] can comment.
- Used in levels of context grid (?)
-- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
-- Should be the data type shown anytime or just if literal expression is top level context entry?
-- [manstis] For {{LiteralExpression}} only when top-level. {{ContextEntry}} will have a similar editor when https://issues.jboss.org/browse/DROOLS-2796 is complete.
- Changing data type in graph node (/)
- Changing data type in properties panel (/)
- Building project (?)
-- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
-- [manstis] Validation will be performed when saved/validated and errors appear in the Message Console. How validation is supported is, IIRC, a JIRA somewhere already.
- Undo / Redo
> [DMN Designer] Data-types: Grid: LiteralExpression
> --------------------------------------------------
>
> Key: DROOLS-2792
> URL: https://issues.jboss.org/browse/DROOLS-2792
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Attachments: DROOLS-2792.odt, Screen Shot 2018-08-01 at 10.11.48 AM.png, Screen Shot 2018-08-01 at 10.20.35 AM.png, Screenshot from 2018-08-09 09-21-01.png
>
>
> *_Literal Expression_*
> - (/) Grid header _could_ show Output Data Type
> - (/) Editing Output Data Type is possible via Properties panel
> - (/) Update header when Output Data Type is changed via Properties panel
> h3. Manual acceptance test
> - Resizing (/)
> - Ctrl+C, Ctrl+v (/)
> - Default Data Type for literal expression (/)
> - Selecting itemDefinition (/)
> - Long name of data type (?)
> -- Column Width is not adapted automatically nor Data Type name is abbreviated, do we want to address somehow in future?
> -- [manstis] We could resize the column based on the Data Type name; feel free to open a (minor) JIRA and [~tirelli] can comment.
> - Used in levels of context grid (/)
> -- !Screenshot from 2018-08-09 09-21-01.png|thumbnail!
> -- Should be the data type shown anytime or just if literal expression is top level context entry?
> -- [manstis] For {{LiteralExpression}} only when top-level. {{ContextEntry}} will have a similar editor when https://issues.jboss.org/browse/DROOLS-2796 is complete.
> - Changing data type in graph node (/)
> - Changing data type in properties panel (/)
> - Building project (?)
> -- Should the deployment fail if I have literal expression of type number but inside string constant like: "string constant"?
> -- [manstis] Validation will be performed when saved/validated and errors appear in the Message Console. How validation is supported is, IIRC, a JIRA somewhere already.
> - Undo / Redo
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-83) [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-83?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on WFWIP-83:
-------------------------------------
[~gaohoward] The script in reproducer is necessary to run as {{source prepare.sh}} so all environment variables are exported in your shell. If you ctrlc-c when tests are already running then there should be AMQ7 and EAP7 running in background. Then when you move to directory with the test in the same shell and run something like:
{code}
ant -Dtest=verifyLookupWithRAElementSpecifiedTest -Dtest.client=Client.java all
{code}
then it will trigger the test ( you need to put name of test and client to -Dtest and -Dtest.client otherwise it will run all tests from given directory)
> [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-83
> URL: https://issues.jboss.org/browse/WFWIP-83
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> There is regression TCK 7 when running WF/EAP with Artemis 2.x resource adapter against AMQ 7.2.0.GA. WF/EAP with Artemis 2.x is last build from [2018-08-06]:
> https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-...
> There are approximately 200 failures with exception:
> {code}
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) 08-03-2018 09:55:10: SVR-ERROR: javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.validateClientID(ActiveMQConnection.java:266)
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:681)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:849)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXATopicConnection(ActiveMQConnectionFactory.java:387)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:745)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:161)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:151)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(Semaphor
> eConcurrentLinkedDequeManagedConnectionPool.java:1326)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinke
> dDequeManagedConnectionPool.java:499)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> [javatest.batch] ESC[0mESC[0m09:55:10,606 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:751)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:475)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createTopicConnection(ActiveMQRAConnectionFactoryImpl.java:217)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.testInitForT(TransactionTests.java:354)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.Test06(TransactionTests.java:634)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.EETest.run(EETest.java:550)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.tests.common.vehicle.ejb.EJBVehicle.runTest(EJBVehicle.java:70)
> {code}
> Note that TCK 7 is passing when trying with current Wildfly master (Artemis 1.5.5.012).
> Link to TCK 7 job:
> https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-third-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months