[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
[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
[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
[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
[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
[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
[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
[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