[JBoss JIRA] (DROOLS-2578) [DMN Designer] Add use of 'DMNModelInstrumentedBase.setParent(..)' to marshaller
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2578?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-2578:
----------------------------------------
yep, thanks for your confirmation! Same behavior as for DMN v1.1 on the engine for resolving prefix:, will need to check in the parent chain of xml element the nearest where the prefix namespace alias is defined.
> [DMN Designer] Add use of 'DMNModelInstrumentedBase.setParent(..)' to marshaller
> --------------------------------------------------------------------------------
>
> Key: DROOLS-2578
> URL: https://issues.jboss.org/browse/DROOLS-2578
> Project: Drools
> Issue Type: Sub-task
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Matteo Mortari
> Priority: Critical
>
> In order to correctly handle QName prefix resolution I have added {{DMNModelInstrumentedBase.getPrefixForNamespaceURI(..)}} to the UI model. I will add support for setting it appropriately as the User authors a DMN model in the UI (i.e. to new elements as and when created) however the marshaller will need to set it accordingly when going from KIE-DMN-model to UI-DMN-model too; so existing diagrams have the parental hierarchy correctly set.
> This depends on https://github.com/kiegroup/kie-wb-common/pull/1818 being merged.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2874) Select a data type, inline, from DMN decision tables.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2874?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2874:
-------------------------------------
[~manstis] gotcha. Couple of little questions:
* the name "Decision 1" is the name of the Decision node? And uses a logic type of a literal expression, that will be using an (output?) data type of "number?"
* are we using [live search|https://codepen.io/Rio517/pen/NPLbpP] for all dropdowns or more specifically this one?
> Select a data type, inline, from DMN decision tables.
> -----------------------------------------------------
>
> Key: DROOLS-2874
> URL: https://issues.jboss.org/browse/DROOLS-2874
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, select.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to *select* a data type inline from a decision table.
> *
> Functional considerations/ pre conditions:
> * Actions will be offered or spawned inline within the cells of decision tables.
> * Design needs to be consistent with Stunner and PF components.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2578) [DMN Designer] Add use of 'DMNModelInstrumentedBase.setParent(..)' to marshaller
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2578?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-2578:
----------------------------------------
My current default is that [my assumption is] this work is going to take 1 day, 2 days max, hence still worth doing not to block/jeopardise ongoing work on the editor. We will sync separately for v1.2 support.
> [DMN Designer] Add use of 'DMNModelInstrumentedBase.setParent(..)' to marshaller
> --------------------------------------------------------------------------------
>
> Key: DROOLS-2578
> URL: https://issues.jboss.org/browse/DROOLS-2578
> Project: Drools
> Issue Type: Sub-task
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Matteo Mortari
> Priority: Critical
>
> In order to correctly handle QName prefix resolution I have added {{DMNModelInstrumentedBase.getPrefixForNamespaceURI(..)}} to the UI model. I will add support for setting it appropriately as the User authors a DMN model in the UI (i.e. to new elements as and when created) however the marshaller will need to set it accordingly when going from KIE-DMN-model to UI-DMN-model too; so existing diagrams have the parental hierarchy correctly set.
> This depends on https://github.com/kiegroup/kie-wb-common/pull/1818 being merged.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2578) [DMN Designer] Add use of 'DMNModelInstrumentedBase.setParent(..)' to marshaller
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2578?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2578:
----------------------------------------
[~tari_manga] Yes, that is correct (and not just the top-level conversion, but also for example an Expression in a ContextEntry in a Context needs the parent chain established) - so not just setting the parent in the Context etc but also any children that are created as part of the conversion. I use the parent information to resolve QNames for data-types on, for example, InformationItems. The XML (v1.1) has, for example feel:String and I need to verify "feel" is indeed the FEEL NameSpace (i.e. URL) in case a User has either used something different for FEEL NameSpace alias (so, for example the data-type might be mynamespace:String where mynamespace is the prefix for FEEL URL). Does this make sense? I'd be interested to know/understand how this is handled in v1.2.
[~tari_manga] IF the editor is to support v1.2 on launch then the work for this JIRA may become obsolete very quickly and hence not worth doing.. feel (ha!) free to check with [~tirelli] as to whether we need worry about it too much (at the moment if I cannot resolve the prefix on the DMN node - e.g. Decision, ContextEntry, InformationItem etc - I simply look in the Definitions. It surely must be an edge case to think a User has (re-)defined a NameSpace prefix within the DMN object hierachy (e.g. prefix "feel" is FEEL URL in Definitions, but FEEL URL is redefined as mynamespace within an intermediate object - between Definitions and for example an Expression on a ContextEntry in a Context in a Decision.
> [DMN Designer] Add use of 'DMNModelInstrumentedBase.setParent(..)' to marshaller
> --------------------------------------------------------------------------------
>
> Key: DROOLS-2578
> URL: https://issues.jboss.org/browse/DROOLS-2578
> Project: Drools
> Issue Type: Sub-task
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Matteo Mortari
> Priority: Critical
>
> In order to correctly handle QName prefix resolution I have added {{DMNModelInstrumentedBase.getPrefixForNamespaceURI(..)}} to the UI model. I will add support for setting it appropriately as the User authors a DMN model in the UI (i.e. to new elements as and when created) however the marshaller will need to set it accordingly when going from KIE-DMN-model to UI-DMN-model too; so existing diagrams have the parental hierarchy correctly set.
> This depends on https://github.com/kiegroup/kie-wb-common/pull/1818 being merged.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10784) WeldStartCompletionService failed when optional components not installed
by Alexander Kudrevatykh (JIRA)
[ https://issues.jboss.org/browse/WFLY-10784?page=com.atlassian.jira.plugin... ]
Alexander Kudrevatykh commented on WFLY-10784:
----------------------------------------------
added project that shows problem (test succesfully run in wildfy 11, but fails in 12 or later)
> WeldStartCompletionService failed when optional components not installed
> ------------------------------------------------------------------------
>
> Key: WFLY-10784
> URL: https://issues.jboss.org/browse/WFLY-10784
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 12.0.0.Final, 13.0.0.Final
> Reporter: Alexander Kudrevatykh
> Assignee: Matej Novotny
> Attachments: arq-test.tar.xz
>
>
> WebComponents are optional and fail in initialising it not causes fail of deployment, but when starting EAR application with included WAR fail in deployment since Wildfly 12 because WeldStartCompletionService depends on all components regardless of their type
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4060) Ensure the correct account URL gets used when using the certificate authority operations with both staging and non-staging endpoints with the same certificate-authority-account
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4060?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFCORE-4060:
-------------------------------
Description:
We need to make sure that when the {{obtain-certificate}} operation is used to obtain a certificate from Let's Encrypt staging server and then used again to obtain a certificate from Let's Encrypt's non-staging server that the appropriate account URL is used (i.e., the account URL should start with the staging endpoint in the first case and it should start with the production endpoint in the second case). For example, the following scenario should work properly:
{code}
# Try to obtain a certificate first using the staging endpoint and then again using the non-staging endpoint with the same certificate-authority-account
/subsystem=elytron/key-store=key-store3:add(credential-reference={clear-text=password},type=JKS,path=keystore3.jks)
/subsystem=elytron/certificate-authority-account=ca_letsenc3:add(alias=server,key-store=key-store3)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=true)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=false)
{code}
Other certificate authority management operations should also be able to handle switching between staging and non-staging using the same {{certificate-authority-account}}.
was:
We need to make sure that when the {{obtain-certificate}} operation is used to obtain a certificate from Let's Encrypt staging server and then used again to obtain a certificate from Let's Encrypt's production server that the appropriate account URL is used (i.e., the account URL should start with the staging endpoint in the first case and it should start with the production endpoint in the second case). For example, the following scenario should work properly:
{code}
# Try to obtain a certificate first using the staging endpoint and then again using the non-staging endpoint with the same certificate-authority-account
/subsystem=elytron/key-store=key-store3:add(credential-reference={clear-text=password},type=JKS,path=keystore3.jks)
/subsystem=elytron/certificate-authority-account=ca_letsenc3:add(alias=server,key-store=key-store3)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=true)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=false)
{code}
Other certificate authority management operations should also be able to handle switching between staging and non-staging using the same {{certificate-authority-account}}.
> Ensure the correct account URL gets used when using the certificate authority operations with both staging and non-staging endpoints with the same certificate-authority-account
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4060
> URL: https://issues.jboss.org/browse/WFCORE-4060
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> We need to make sure that when the {{obtain-certificate}} operation is used to obtain a certificate from Let's Encrypt staging server and then used again to obtain a certificate from Let's Encrypt's non-staging server that the appropriate account URL is used (i.e., the account URL should start with the staging endpoint in the first case and it should start with the production endpoint in the second case). For example, the following scenario should work properly:
> {code}
> # Try to obtain a certificate first using the staging endpoint and then again using the non-staging endpoint with the same certificate-authority-account
> /subsystem=elytron/key-store=key-store3:add(credential-reference={clear-text=password},type=JKS,path=keystore3.jks)
> /subsystem=elytron/certificate-authority-account=ca_letsenc3:add(alias=server,key-store=key-store3)
> /subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=true)
> /subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=false)
> {code}
> Other certificate authority management operations should also be able to handle switching between staging and non-staging using the same {{certificate-authority-account}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4060) Ensure the correct account URL gets used when using the certificate authority operations with both staging and non-staging endpoints with the same certificate-authority-account
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-4060?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFCORE-4060:
-------------------------------
Description:
We need to make sure that when the {{obtain-certificate}} operation is used to obtain a certificate from Let's Encrypt staging server and then used again to obtain a certificate from Let's Encrypt's non-staging server that the appropriate account URL is used (i.e., the account URL should start with the staging endpoint in the first case and it should start with the non-staging endpoint in the second case). For example, the following scenario should work properly:
{code}
# Try to obtain a certificate first using the staging endpoint and then again using the non-staging endpoint with the same certificate-authority-account
/subsystem=elytron/key-store=key-store3:add(credential-reference={clear-text=password},type=JKS,path=keystore3.jks)
/subsystem=elytron/certificate-authority-account=ca_letsenc3:add(alias=server,key-store=key-store3)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=true)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=false)
{code}
Other certificate authority management operations should also be able to handle switching between staging and non-staging using the same {{certificate-authority-account}}.
was:
We need to make sure that when the {{obtain-certificate}} operation is used to obtain a certificate from Let's Encrypt staging server and then used again to obtain a certificate from Let's Encrypt's non-staging server that the appropriate account URL is used (i.e., the account URL should start with the staging endpoint in the first case and it should start with the production endpoint in the second case). For example, the following scenario should work properly:
{code}
# Try to obtain a certificate first using the staging endpoint and then again using the non-staging endpoint with the same certificate-authority-account
/subsystem=elytron/key-store=key-store3:add(credential-reference={clear-text=password},type=JKS,path=keystore3.jks)
/subsystem=elytron/certificate-authority-account=ca_letsenc3:add(alias=server,key-store=key-store3)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=true)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=false)
{code}
Other certificate authority management operations should also be able to handle switching between staging and non-staging using the same {{certificate-authority-account}}.
> Ensure the correct account URL gets used when using the certificate authority operations with both staging and non-staging endpoints with the same certificate-authority-account
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4060
> URL: https://issues.jboss.org/browse/WFCORE-4060
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> We need to make sure that when the {{obtain-certificate}} operation is used to obtain a certificate from Let's Encrypt staging server and then used again to obtain a certificate from Let's Encrypt's non-staging server that the appropriate account URL is used (i.e., the account URL should start with the staging endpoint in the first case and it should start with the non-staging endpoint in the second case). For example, the following scenario should work properly:
> {code}
> # Try to obtain a certificate first using the staging endpoint and then again using the non-staging endpoint with the same certificate-authority-account
> /subsystem=elytron/key-store=key-store3:add(credential-reference={clear-text=password},type=JKS,path=keystore3.jks)
> /subsystem=elytron/certificate-authority-account=ca_letsenc3:add(alias=server,key-store=key-store3)
> /subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=true)
> /subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=false)
> {code}
> Other certificate authority management operations should also be able to handle switching between staging and non-staging using the same {{certificate-authority-account}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-4060) Ensure the correct account URL gets used when using the certificate authority operations with both staging and non-staging endpoints with the same certificate-authority-account
by Farah Juma (JIRA)
Farah Juma created WFCORE-4060:
----------------------------------
Summary: Ensure the correct account URL gets used when using the certificate authority operations with both staging and non-staging endpoints with the same certificate-authority-account
Key: WFCORE-4060
URL: https://issues.jboss.org/browse/WFCORE-4060
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Farah Juma
Assignee: Farah Juma
We need to make sure that when the {{obtain-certificate}} operation is used to obtain a certificate from Let's Encrypt staging server and then used again to obtain a certificate from Let's Encrypt's production server that the appropriate account URL is used (i.e., the account URL should start with the staging endpoint in the first case and it should start with the production endpoint in the second case). For example, the following scenario should work properly:
{code}
# Try to obtain a certificate first using the staging endpoint and then again using the non-staging endpoint with the same certificate-authority-account
/subsystem=elytron/key-store=key-store3:add(credential-reference={clear-text=password},type=JKS,path=keystore3.jks)
/subsystem=elytron/certificate-authority-account=ca_letsenc3:add(alias=server,key-store=key-store3)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=true)
/subsystem=elytron/key-store=key-store3:obtain-certificate(alias=app3,certificate-authority-account=ca_letsenc3,domain-names=["mydomain.com"],agree-to-terms-of-service,algorithm=RSA,staging=false)
{code}
Other certificate authority management operations should also be able to handle switching between staging and non-staging using the same {{certificate-authority-account}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months