June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1591) Problems in serialization/deserialization of KnowledgePackages

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1591?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1591: -------------------------------- Sprint: Sprint 5 > Problems in serialization/deserialization of KnowledgePackages > -------------------------------------------------------------- > > Key: DROOLS-1591 > URL: https://issues.jboss.org/browse/DROOLS-1591 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final, 7.0.0.Beta3 > Reporter: Vítor Moreira > Assignee: Mario Fusco > Attachments: jboss_issue.tar.gz > > > Using {{DroolsStreamUtils}}, created an unit-test to serialize and deserialize a DRL file. In version "6.0.1.Final", the unit-test runs flawlessly. In other versions, deserialization gives an ClassNotFoundException for the declared event. > I've checked StackOverflow and Drools' JIRA for similar problems and found nothing. > I've also attached a junit. Please change property {{drools.version}} to test with different Drools versions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1590: -------------------------------- Sprint: Sprint 5 > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output sequence was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2898) Unable to define realm-mapping for TrustManager based auth

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2898?page=com.atlassian.jira.plugi... ] Jan Kalina moved JBEAP-11285 to WFCORE-2898: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2898 (was: JBEAP-11285) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta23 (was: 7.1.0.DR19) > Unable to define realm-mapping for TrustManager based auth > ---------------------------------------------------------- > > Key: WFCORE-2898 > URL: https://issues.jboss.org/browse/WFCORE-2898 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta23 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > > For SASL and HTTP mechanisms it is possible to define *realm-mapping* as part of **-authentication-factory*. But this cannot be used for EXTERNAL/CLIENT_CERT mechanism, because *ServerAuthenticationContext* is not constructed by mechanism but by *SecurityDomainTrustManager* - without relation to any **-authentication-factory*. > It can be misleading for user, that *EXTERNAL* mechanism is present in *sasl-authentication-factory*, but if *realm-mapper* is defined here, it is ignored: (because SSL authentication finish before any SASL is initiated) > {code:xml} > <sasl-authentication-factory name="client-cert-digest" sasl-server-factory="configured" security-domain="client-cert-domain"> > <mechanism-configuration> > <mechanism mechanism-name="EXTERNAL" realm-mapper="key-store-realm"/> > </mechanism-configuration> > </sasl-authentication-factory> > {code} > Should be considered adding way how to pass *realm-mapper* into SSL authentication - maybe add *realm-mapper* attribute into *server-ssl-context* definition? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1217) Unable to define realm-mapping for TrustManager based auth

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1217?page=com.atlassian.jira.plugin.s... ] Jan Kalina moved JBEAP-11284 to ELY-1217: ----------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1217 (was: JBEAP-11284) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: SSL (was: Security) Affects Version/s: 1.1.0.Beta48 (was: 7.1.0.DR19) > Unable to define realm-mapping for TrustManager based auth > ---------------------------------------------------------- > > Key: ELY-1217 > URL: https://issues.jboss.org/browse/ELY-1217 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta48 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > > For SASL and HTTP mechanisms it is possible to define *realm-mapping* as part of **-authentication-factory*. But this cannot be used for EXTERNAL/CLIENT_CERT mechanism, because *ServerAuthenticationContext* is not constructed by mechanism but by *SecurityDomainTrustManager* - without relation to any **-authentication-factory*. > It can be misleading for user, that *EXTERNAL* mechanism is present in *sasl-authentication-factory*, but if *realm-mapper* is defined here, it is ignored: (because SSL authentication finish before any SASL is initiated) > {code:xml} > <sasl-authentication-factory name="client-cert-digest" sasl-server-factory="configured" security-domain="client-cert-domain"> > <mechanism-configuration> > <mechanism mechanism-name="EXTERNAL" realm-mapper="key-store-realm"/> > </mechanism-configuration> > </sasl-authentication-factory> > {code} > Should be considered adding way how to pass *realm-mapper* into SSL authentication - maybe add *realm-mapper* attribute into *server-ssl-context* definition? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2796) CLI - module add - handle symlinks for directories and files

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2796?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-2796: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2412, https://github.com/wildfly/wildfly-core/pull/2491 (was: https://github.com/wildfly/wildfly-core/pull/2412) > CLI - module add - handle symlinks for directories and files > ------------------------------------------------------------ > > Key: WFCORE-2796 > URL: https://issues.jboss.org/browse/WFCORE-2796 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Rostislav Svoboda > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Beta22 > > > With WFCORE-2765 changes one can copy directories using CLI operation {{module add}} > I tried few non-empty directory cases > a) non-empty directory + subdirectories > b) non-empty directory + subdirectories + symlink (ln -s) to file (pom.xml -> /home/rsvoboda/tmp/wildfly-core/pom.xml) > c) non-empty directory + subdirectories + symlink (ln -s) to directory (jdk -> /opt/jdk1.8.0_91) > a) worked without problem > b) modules contain file (pom.xml) with copied content of sym-linked file, symlink not preserved > c) modules contain empty file jdk, content of sym-linked directory is not copied, symlink not preserved > Symlinks must be also handled, I would prefer to copy all the linked content to be consistent on different machines. > This can be complex as symlinks to files and directories can be nested in the directories structure. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2895?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2895: ------------------------------------------ A note for the record: we'll probably do some more on this basic topic. Even with this I'm still seeing more ServiceName creations than I like, and I expect it's related to capabilities but I'm not sure quite how. I see stuff to improve but not how those things would equate to the "excess" number of names. For example, even with this fix, a heap comparison of a standalone-full-ha.xml server vs EAP 7.0 shows 31 more ServiceControllerImpl instances but 2,433 more ServiceName instances. Places to improve: CapabilityServiceSupportImpl.getCapabilityServiceName and OperationContextImpl.getCapabilityServiceName. The latter expect to have little impact as it should only be creating a new ServiceName in an edge case scenario. > Save memory in RuntimeCapability ServiceName creation > ----------------------------------------------------- > > Key: WFCORE-2895 > URL: https://issues.jboss.org/browse/WFCORE-2895 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta24 > > > RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates its ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. > Also RuntimeCapability should not create a ServiceName if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2897) Remove match-purpose from Elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2897?page=com.atlassian.jira.plugi... ] Jan Kalina moved JBEAP-11279 to WFCORE-2897: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2897 (was: JBEAP-11279) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta23 (was: 7.1.0.DR19) > Remove match-purpose from Elytron > --------------------------------- > > Key: WFCORE-2897 > URL: https://issues.jboss.org/browse/WFCORE-2897 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta23 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > > Match purpose should be entirely removed from authentication-context, see [1]. It means it should be removed from API, Elytron subsystem and Elytron client configuration file. > We request blocker flag to avoid situation where match-purpose occurs in GA. > [1] https://issues.jboss.org/browse/JBEAP-11144?focusedCommentId=13413867&pag... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-112) Installation of MM and MM storage (cassadnra) on OS

by Filip Brychta (JIRA)

Filip Brychta created HAWKULARQE-112: ---------------------------------------- Summary: Installation of MM and MM storage (cassadnra) on OS Key: HAWKULARQE-112 URL: https://issues.jboss.org/browse/HAWKULARQE-112 Project: Hawkular QE Issue Type: Task Reporter: Filip Brychta Assignee: Michael Foley Priority: Critical We need to add test cases covering installation of MM and MM storage on plain docker host. This task should cover: basic positive and negative test cases datastore cluster (adding, removing) SSL configuration and agent installation are covered by HAWKULARQE-105 and other tasks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-111) Installation of MM and MM storage (cassadnra) on plain docker host

by Filip Brychta (JIRA)

Filip Brychta created HAWKULARQE-111: ---------------------------------------- Summary: Installation of MM and MM storage (cassadnra) on plain docker host Key: HAWKULARQE-111 URL: https://issues.jboss.org/browse/HAWKULARQE-111 Project: Hawkular QE Issue Type: Task Reporter: Filip Brychta Assignee: Michael Foley Priority: Critical We need to add test cases covering installation of MM and MM storage on plain docker host. Documentation: https://doc-stage.usersys.redhat.com/documentation/en-us/red_hat_middlewa... This task should cover: * basic positive and negative test cases * datastore cluster (adding, removing) SSL configuration and agent installation are covered by HAWKULARQE-105 and other tasks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2796) CLI - module add - handle symlinks for directories and files

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2796?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reopened WFCORE-2796: ------------------------------------------ Cases of recursive symlink not handled. > CLI - module add - handle symlinks for directories and files > ------------------------------------------------------------ > > Key: WFCORE-2796 > URL: https://issues.jboss.org/browse/WFCORE-2796 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Rostislav Svoboda > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Beta22 > > > With WFCORE-2765 changes one can copy directories using CLI operation {{module add}} > I tried few non-empty directory cases > a) non-empty directory + subdirectories > b) non-empty directory + subdirectories + symlink (ln -s) to file (pom.xml -> /home/rsvoboda/tmp/wildfly-core/pom.xml) > c) non-empty directory + subdirectories + symlink (ln -s) to directory (jdk -> /opt/jdk1.8.0_91) > a) worked without problem > b) modules contain file (pom.xml) with copied content of sym-linked file, symlink not preserved > c) modules contain empty file jdk, content of sym-linked directory is not copied, symlink not preserved > Symlinks must be also handled, I would prefer to copy all the linked content to be consistent on different machines. > This can be complex as symlinks to files and directories can be nested in the directories structure. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2017