[JBoss JIRA] (WFCORE-1801) DomainSlaveHostRegistrations should survive a reload
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1801:
----------------------------------------
Summary: DomainSlaveHostRegistrations should survive a reload
Key: WFCORE-1801
URL: https://issues.jboss.org/browse/WFCORE-1801
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Priority: Minor
DomainSlaveHostRegistrations is used by the master to record HC registration/unregistration events for display via the management API. The lifecycle of this data is tied to that of DomainModelControllerService, which gets gc'd and recreated on each reload. This data should have a longer lifespan than that.
It doesn't need to be persistent (survive HC restart) but surviving reload would be better.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1294) Root path of kjar module is incorrectly calculated under Windows for both spring and blueprint integration
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1294?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1294:
--------------------------------
Description: KModule post processor wherein createKieModule method implementation removes the drive name from the base directory url which causes the problem. So if we have base jetty temp dir path like C:\users\user\tem\jettytempfolder\webapp\web-inf\classes the below lines of code removes the "C:\" from the url which makes it invalid path and which in turn isnt recognized as classes file folder.
> Root path of kjar module is incorrectly calculated under Windows for both spring and blueprint integration
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1294
> URL: https://issues.jboss.org/browse/DROOLS-1294
> Project: Drools
> Issue Type: Bug
> Components: integration
> Reporter: Mario Fusco
> Assignee: Mario Fusco
>
> KModule post processor wherein createKieModule method implementation removes the drive name from the base directory url which causes the problem. So if we have base jetty temp dir path like C:\users\user\tem\jettytempfolder\webapp\web-inf\classes the below lines of code removes the "C:\" from the url which makes it invalid path and which in turn isnt recognized as classes file folder.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-298:
---------------------------------
Fix Version/s: 1.1.0.Beta10
(was: 1.1.0.Beta9)
> load-from/uri keystore xsd/parser mismatch
> ------------------------------------------
>
> Key: ELY-298
> URL: https://issues.jboss.org/browse/ELY-298
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: Kabir Khan
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta10
>
>
> The xsd has
> {code}
> <xsd:complexType name="key-store-type">
> <xsd:sequence minOccurs="1" maxOccurs="1">
> <!-- Access source type -->
> <xsd:choice minOccurs="1" maxOccurs="1">
> <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
> <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
> <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {code}
> The parser seems to look for 'uri' rather than 'load-from'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-212) Client-side SSL context configuration is subtly wrong
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-212?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-212:
---------------------------------
Fix Version/s: 1.1.0.Beta10
(was: 1.1.0.Beta9)
> Client-side SSL context configuration is subtly wrong
> -----------------------------------------------------
>
> Key: ELY-212
> URL: https://issues.jboss.org/browse/ELY-212
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta10
>
>
> SSL context client-side configuration is problematic in that the SSL context is not (and cannot be) cached. This means that we lose SSL session reuse and other benefits which may cause problems for users.
> However we also cannot just cache an SSL context on a configuration either - the client credentials may vary on each request, causing leakage between identities.
> What we need to do is have a separate SSL context client configuration mechanism, and use the generic client context configuration to reference this SSL context client configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months