[JBoss JIRA] (DROOLS-2870) [DMN Designer] Can not build project with multiple models
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2870?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2870:
--------------------------------
Description:
If the project contains multiple dmn models, it can not be built.
h3. Manual acceptance test
- Prepare three models
-- Empty
-- Just graph nodes
-- Login inside graph nodes
- Check Deployment successful
was:If the project contains multiple dmn models, it can not be built.
> [DMN Designer] Can not build project with multiple models
> ---------------------------------------------------------
>
> Key: DROOLS-2870
> URL: https://issues.jboss.org/browse/DROOLS-2870
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.10.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Blocker
> Labels: drools-tools
> Attachments: Screenshot from 2018-08-09 10-20-16.png
>
>
> If the project contains multiple dmn models, it can not be built.
> h3. Manual acceptance test
> - Prepare three models
> -- Empty
> -- Just graph nodes
> -- Login inside graph nodes
> - Check Deployment successful
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (ELY-1630) Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1630?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1630:
----------------------------
Description:
Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error:
{code}
org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260)
Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984)
... 3 more
{code}
The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK when {{CertificateFactory.generateCertificates()}} is called. To fix this, we can just ignore any blank lines in the chain.
was:
Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error:
{code}
org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260)
Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984)
... 3 more
{code}
The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK. To fix this, we can just ignore any blank lines in the chain.
> Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1630
> URL: https://issues.jboss.org/browse/ELY-1630
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error:
> {code}
> org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260)
> Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
> at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
> at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984)
> ... 3 more
> {code}
> The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK when {{CertificateFactory.generateCertificates()}} is called. To fix this, we can just ignore any blank lines in the chain.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (ELY-1630) Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK
by Farah Juma (JIRA)
Farah Juma created ELY-1630:
-------------------------------
Summary: Ignore any blank lines in between the certificates in the certificate chain returned by an ACME server to avoid parsing issues on IBM JDK
Key: ELY-1630
URL: https://issues.jboss.org/browse/ELY-1630
Project: WildFly Elytron
Issue Type: Bug
Components: API / SPI
Reporter: Farah Juma
Assignee: Farah Juma
Currently, {{AcmeClientSpiTest#testObtainCertificateChainWithKeySize}} and {{AcmeClientSpiTest#testObtainCertificateChainWithECPublicKey}} fail when run with IBM JDK with the following error:
{code}
org.wildfly.security.x500.cert.acme.AcmeException: ELY10049: Unable to download certificate chain from ACME server
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:988)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.obtainCertificateChain(AcmeClientSpi.java:519)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.obtainCertificateChain(AcmeClientSpiTest.java:284)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testObtainCertificateChainWithKeySize(AcmeClientSpiTest.java:260)
Caused by: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: insufficient data
at com.ibm.security.x509.X509CertImpl.<init>(X509CertImpl.java:268)
at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:448)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getPemCertificateChain(AcmeClientSpi.java:984)
... 3 more
{code}
The underlying issue is that the PEM certificate chain returned by the ACME server has a blank line in between the two certificates in the chain. This causes parsing issues on IBM JDK. To fix this, we can just ignore any blank lines in the chain.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (WFLY-10822) Provision core as a transitive dependency explicitly
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFLY-10822:
----------------------------------------
Summary: Provision core as a transitive dependency explicitly
Key: WFLY-10822
URL: https://issues.jboss.org/browse/WFLY-10822
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Currently core is installed implicitly as a dependency of wildfly and servlet. We use resolve-local elements in provision goal config for core and servlet feature-packs. Those are shortcuts to avoid the universe-based feature-pack resolver.
If instead of resolve-local elements we use feature-pack/transitive elements we will achieve the same effect avoiding the universe-based resolver and it will also allow us to specify the version of core using a system property.
The only difference will show up in .galleon/provisioning.xml, which will change from (based on build module)
{code:java}
<installation xmlns="urn:jboss:galleon:provisioning:2.0">
<feature-pack location="wildfly@maven(org.jboss.universe:community-universe):current#14.0.0.Beta2-SNAPSHOT">
<packages>
<include name="docs.examples.configs"/>
</packages>
</feature-pack>
</installation>
{code}
to
{code:java}
<installation xmlns="urn:jboss:galleon:provisioning:2.0">
<transitive>
<feature-pack location="wildfly-core@maven(org.jboss.universe:community-universe):current#6.0.0.Alpha5"/>
<feature-pack location="wildfly-servlet@maven(org.jboss.universe:community-universe):current#14.0.0.Beta2-SNAPSHOT"/>
</transitive>
<feature-pack location="wildfly@maven(org.jboss.universe:community-universe):current#14.0.0.Beta2-SNAPSHOT">
<packages>
<include name="docs.examples.configs"/>
</packages>
</feature-pack>
</installation>
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Liz Clayton resolved DROOLS-2787.
---------------------------------
Resolution: Done
marking as Resolved, verified with PO.
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Manage1.png, Manage2.png, Screen Shot 2018-07-24 at 3.51.03 PM.png, Screen Shot 2018-07-27 at 11.48.34 AM.png, Screen Shot 2018-07-27 at 12.24.49 PM.png, Screen Shot 2018-07-27 at 12.27.13 PM.png, Screen Shot 2018-08-09 at 2.09.21 PM.png, add_basic.png, treegrid.png, type_definitions.pdf
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 5 months