June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1802) Ensure OpenSSL Registration is first.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1802: ------------------------------------------ Reopening as we are now seeing a failure in the test case 'org.jboss.as.test.integration.web.security.tg.TransportGuaranteeTestCase' and are temporarily reverting under the following PR https://github.com/wildfly/wildfly-core/pull/2492. > Ensure OpenSSL Registration is first. > ------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta24 > > > The following in SecurityRealmResourceDefinition registers the provider: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > It would be good to remove this however for now we can't guarantee Elytron is enabled so register it globally. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Ensure OpenSSL Registration is first.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse reopened WFCORE-1802: -------------------------------------- > Ensure OpenSSL Registration is first. > ------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta24 > > > The following in SecurityRealmResourceDefinition registers the provider: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > It would be good to remove this however for now we can't guarantee Elytron is enabled so register it globally. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[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 resolved DROOLS-1591. --------------------------------- Resolution: Rejected In this case you'll have to pass the ClassLoader when the stream is deserialized like in {code} ClassLoader cl = ( (KnowledgeBuilderImpl) kbuilder ).getBuilderConfiguration().getClassLoader(); streamKnowledgePackages = (Collection<KnowledgePackage>) DroolsStreamUtils.streamIn(byteArray, cl); {code} However be aware that you're using internal drools classes that don't belong to our public API and then could change with every minor release. This is strongly discouraged. > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1592) Deleted facts retained in memory, but removed after (de)serialization

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1592?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1592: -------------------------------- Sprint: Sprint 5 > Deleted facts retained in memory, but removed after (de)serialization > --------------------------------------------------------------------- > > Key: DROOLS-1592 > URL: https://issues.jboss.org/browse/DROOLS-1592 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Nikolay Plekhanov > Assignee: Mario Fusco > Fix For: 7.1.0.Beta3 > > Attachments: drools-memleak.zip > > > Given: > two agenda groups: A1 and A2. > Rule R1 in agenda group A1 and rule R2 in agenda group A2. > R1 matches facts of type T1, deletes them and creates facts of type T2. > R2 matches facts of type T2 and does soemthing with them (it doesn't matter, because issue happens even if R2 never fired). > Scenario: > * Create session, add R1 and R2 rules > * add some facts of T1 type > * set focus on A1 agenda group > * invoke "fireAllRules" method > * Invoke "getObjects" and assure that session contains only T2 facts > * analyze objects in memory (by jmap + memory analyzing tool or just traversing references by reflection) and assure that T1 facts are still reachable via session object. > * serialize session using marshaller and deserialize in again > * analyze deserialized session and see that it doesn't contain T1 fact references anymore. > Thoughts: > I assumed that T1 references storing is feature, because they can be necessary in some cases (like reverse of their deletion due to logical inversion of truth - not sure, but maybe), but T1 deletion after (de)serialization points out the opposite. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[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, 11 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, 11 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, 11 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, 11 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, 11 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, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2017