[JBoss JIRA] (DROOLS-3249) [DMN Designer] Add support for optional typeRefs
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3249?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3249:
-----------------------------------
Tester: Jozef Marko
Labels: drools-tools (was: )
> [DMN Designer] Add support for optional typeRefs
> ------------------------------------------------
>
> Key: DROOLS-3249
> URL: https://issues.jboss.org/browse/DROOLS-3249
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Critical
> Labels: drools-tools
>
> At the moment {{TypeRef}} is a mandatory field within the editor.
> This is a hard limitation of use of the Properties Panel bean-binding (it cannot bind to {{null}} values). However the DMN Specification states that {{TypeRef}} are optional (and we are working around by changing the _default_ to {{Any}} - see [DROOLS-3248|https://issues.jboss.org/browse/DROOLS-3248]).
> We need to change the UI and marshaller to be able to support _optional_ {{TypeRef}}. This would (probably) require adding a _magic_ value to {{BuiltInType}} representing a "null" selection. It would need to:
> - Appear at the top of the "Data Type selector" widget (with label "<None>" or similar)
> - Be the _selected_ option when the {{TypeRef}} is the new _magic_ value (this should happen automatically, but worth checking!)
> - The marshaller should set the {{TypeRef}} to the _magic_ {{BuiltInType}} if the DMN model (coming from XML->{{kie-dmn-model}}->workbench model) has a {{null}} {{TypeRef}} - the _magic_ value is only to be used _client-side_.
> - The marshaller should set the {{TypeRef}} to {{null}} when converting from the workbench model to {{kie-dmn-model}} and the workbench model {{TypeRef}} is the _magic_ value - again, the _magic_ value is only to be used _client-side_.
> - Check that creating new data-types does not show the _magic_ value (it uses a different widget, but population of the widget probably iterates all {{BuiltInType}}.
> [~tari_manga] [~karreiro] seem reasonable to you?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3249) [DMN Designer] Add support for optional typeRefs
by Michael Anstis (Jira)
Michael Anstis created DROOLS-3249:
--------------------------------------
Summary: [DMN Designer] Add support for optional typeRefs
Key: DROOLS-3249
URL: https://issues.jboss.org/browse/DROOLS-3249
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.14.0.Final
Reporter: Michael Anstis
Assignee: Daniel José dos Santos
At the moment {{TypeRef}} is a mandatory field within the editor.
This is a hard limitation of use of the Properties Panel bean-binding (it cannot bind to {{null}} values). However the DMN Specification states that {{TypeRef}} are optional (and we are working around by changing the _default_ to {{Any}} - see [DROOLS-3248|https://issues.jboss.org/browse/DROOLS-3248]).
We need to change the UI and marshaller to be able to support _optional_ {{TypeRef}}. This would (probably) require adding a _magic_ value to {{BuiltInType}} representing a "null" selection. It would need to:
- Appear at the top of the "Data Type selector" widget (with label "<None>" or similar)
- Be the _selected_ option when the {{TypeRef}} is the new _magic_ value (this should happen automatically, but worth checking!)
- The marshaller should set the {{TypeRef}} to the _magic_ {{BuiltInType}} if the DMN model (coming from XML->{{kie-dmn-model}}->workbench model) has a {{null}} {{TypeRef}} - the _magic_ value is only to be used _client-side_.
- The marshaller should set the {{TypeRef}} to {{null}} when converting from the workbench model to {{kie-dmn-model}} and the workbench model {{TypeRef}} is the _magic_ value - again, the _magic_ value is only to be used _client-side_.
- Check that creating new data-types does not show the _magic_ value (it uses a different widget, but population of the widget probably iterates all {{BuiltInType}}.
[~tari_manga] [~karreiro] seem reasonable to you?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11285) [IBM JDK] JBoss Modules are unable to load default JAXP implementation into deployment when SchemaFactory provider is set to implementation unavailable to deployment
by Michal Jurc (Jira)
Michal Jurc created WFLY-11285:
----------------------------------
Summary: [IBM JDK] JBoss Modules are unable to load default JAXP implementation into deployment when SchemaFactory provider is set to implementation unavailable to deployment
Key: WFLY-11285
URL: https://issues.jboss.org/browse/WFLY-11285
Project: WildFly
Issue Type: Bug
Components: MSC
Affects Versions: 14.0.0.Final
Reporter: Michal Jurc
Assignee: Alessio Soldano
As discovered during investigation in WFLY-10336, we are now getting test failures in WSTrustTestCase when IBM JDK is used. The relevant part of the exception is:
{code:java}
Caused by: java.lang.IllegalArgumentException: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found
at javax.xml.validation.SchemaFactory.newInstance(Unknown Source)
at org.opensaml.core.xml.config.XMLConfigurator.<init>(XMLConfigurator.java:94)
at org.apache.wss4j.common.saml.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:85)
at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:91)
at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:75)
at org.apache.wss4j.common.saml.SamlAssertionWrapper.<init>(SamlAssertionWrapper.java:184)
at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:308)
at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:120)
... 102 more
{code}
It turned out the issue is in wildfly for some time, the breaking change was identified as https://github.com/wildfly/wildfly-core/pull/3201/
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (SWSQE-485) Test ingress gateway with 2 or more independent meshes
by viet nguyen (Jira)
viet nguyen created SWSQE-485:
---------------------------------
Summary: Test ingress gateway with 2 or more independent meshes
Key: SWSQE-485
URL: https://issues.jboss.org/browse/SWSQE-485
Project: Kiali QE
Issue Type: QE Task
Reporter: viet nguyen
Assignee: Michael Foley
test case:
# - Create two or more independent meshes. Bookinfo1, Bookinfo2, Bookinfo3
# - Create ingress gateway for each of the mesh
# - Verify traffics are going through gateways (not Unknown in Kiali)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFWIP-132) MP Metrics - capabilities names - prefix unification
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-132?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFWIP-132:
-----------------------------------
[~rsvoboda] I removed the JmxRegistrarService. I now have only 1 service (with the capability org.wildlfy.extension.microprofile.metrics.wildfly-registrar to register all vendor and base metrics)
> MP Metrics - capabilities names - prefix unification
> ----------------------------------------------------
>
> Key: WFWIP-132
> URL: https://issues.jboss.org/browse/WFWIP-132
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Metrics
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Major
>
> MP Metrics - capabilities names - prefix unification
> {{/subsystem=microprofile-metrics-smallrye:read-resource-description}} returns details about capabilities:
> {code}
> "capabilities" => [
> {
> "name" => "org.wildfly.extension.microprofile.metrics.smallrye",
> "dynamic" => false
> },
> {
> "name" => "org.wildlfy.microprofile.metrics.jmx-registrar",
> "dynamic" => false
> },
> {
> "name" => "org.wildlfy.microprofile.metrics.wildfly-registrar",
> "dynamic" => false
> }
> ],
> {code}
> Prefix {{org.wildfly.extension.microprofile.metrics}} is used one time, prefix {{org.wildlfy.microprofile.metrics}} is used two times.
> I think the same prefix could be used for all of them.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3216) Async dependencies resolution or add loading indicator during scesim creation
by Klara Kufova (Jira)
[ https://issues.jboss.org/browse/DROOLS-3216?page=com.atlassian.jira.plugi... ]
Klara Kufova updated DROOLS-3216:
---------------------------------
Tester: Klara Kufova
> Async dependencies resolution or add loading indicator during scesim creation
> -----------------------------------------------------------------------------
>
> Key: DROOLS-3216
> URL: https://issues.jboss.org/browse/DROOLS-3216
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Daniele Zonca
> Priority: Major
> Labels: ScenarioSimulation
>
> When user create the first scesim file in the project, the system creates the JUnit activator file and it adds the needed dependencies.
> After that the system takes several seconds (5-6) to retrieve all the dependencies.
> During this time the editor still blank without any indicator or information to the user about what is going on.
> This happens only for the first scesim creation in the project
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFWIP-132) MP Metrics - capabilities names - prefix unification
by Rostislav Svoboda (Jira)
[ https://issues.jboss.org/browse/WFWIP-132?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda commented on WFWIP-132:
-----------------------------------------
Prefixes are the same now
BUT I don't see {{jmx-registrar}}
{code}
"capabilities" => [
{
"name" => "org.wildfly.extension.microprofile.metrics.smallrye",
"dynamic" => false
},
{
"name" => "org.wildlfy.extension.microprofile.metrics.wildfly-registrar",
"dynamic" => false
}
],
{code}
> MP Metrics - capabilities names - prefix unification
> ----------------------------------------------------
>
> Key: WFWIP-132
> URL: https://issues.jboss.org/browse/WFWIP-132
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Metrics
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Major
>
> MP Metrics - capabilities names - prefix unification
> {{/subsystem=microprofile-metrics-smallrye:read-resource-description}} returns details about capabilities:
> {code}
> "capabilities" => [
> {
> "name" => "org.wildfly.extension.microprofile.metrics.smallrye",
> "dynamic" => false
> },
> {
> "name" => "org.wildlfy.microprofile.metrics.jmx-registrar",
> "dynamic" => false
> },
> {
> "name" => "org.wildlfy.microprofile.metrics.wildfly-registrar",
> "dynamic" => false
> }
> ],
> {code}
> Prefix {{org.wildfly.extension.microprofile.metrics}} is used one time, prefix {{org.wildlfy.microprofile.metrics}} is used two times.
> I think the same prefix could be used for all of them.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months