[JBoss JIRA] (JBJCA-1259) Tracer improvements
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1259:
--------------------------------------
Summary: Tracer improvements
Key: JBJCA-1259
URL: https://issues.jboss.org/browse/JBJCA-1259
Project: IronJacamar
Issue Type: Task
Components: Core
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.4.Final
Add the following events:
* PUSH_CCM_CONTEXT
* POP_CCM_CONTEXT
* REGISTER_CCM_CONNECTION
* UNREGISTER_CCM_CONNECTION
* CCM_USER_TRANSACTION
* UNKNOWN_CCM_CONNECTION
* CLOSE_CCM_CONNECTION
* VERSION
Add 2nd payload field
Create reports for CCM interaction
Add -ignore-tracking command line option
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (JGRP-1605) API changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1605?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1605:
---------------------------
Description:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
* {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
was:
API changes to be done in 4.0, which break code:
* MessageDispatcher: remove MessageListener
* Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
* Remove @Deprecated methods, properties or classes
* Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
* Make {{RspFilter}} --> {{RspFilter<T>}}
> API changes
> -----------
>
> Key: JGRP-1605
> URL: https://issues.jboss.org/browse/JGRP-1605
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> API changes to be done in 4.0, which break code:
> * MessageDispatcher: remove MessageListener
> * Merge AsyncRequestHandler and RequestHandler, OR make them 2 separate interfaces, ie. AsyncRH doesn't extend RH
> * Remove @Deprecated methods, properties or classes
> * Remove direct access to Message in JChannel.send() methods (to prevent passing in the same message more than once)
> * Make {{RspFilter}} --> {{RspFilter<T>}}
> * {{ProtocolStack.findProtocol(Class<?> clazz)}} should return generic type {{<T extends Protocol>>}}, so no casting is needed. Requires changes to a number of methods in the same class.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-372) Cache role mapping results for the span of the overall operation
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-372?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-372:
------------------------------------
Fix Version/s: 2.0.0.Alpha1
(was: 1.0.0.CR1)
> Cache role mapping results for the span of the overall operation
> ----------------------------------------------------------------
>
> Key: WFCORE-372
> URL: https://issues.jboss.org/browse/WFCORE-372
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Labels: access_control, management_security,
> Fix For: 2.0.0.Alpha1
>
>
> Look into caching role mapping results for the duration of an overall operation. This would be an impl detail of the RoleMapper. With our standard mappers, the mapping results should not be changing in the middle of an operation, so I believe they should be cacheable.
> Likely place to cache them is as an attachment in a context object that will be passed in to the Authorizer. It would have to be passed in to the RoleMapper as well.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-301:
------------------------------------
Fix Version/s: 2.0.0.Alpha1
(was: 1.0.0.CR1)
> Configuration of individual contexts for http management interface.
> -------------------------------------------------------------------
>
> Key: WFCORE-301
> URL: https://issues.jboss.org/browse/WFCORE-301
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 2.0.0.Alpha1
>
>
> At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console.
> The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context.
> We need to start to open up the handling of cross origin requests for a couple of reasons: -
> - Enabling Keycloak SSO support.
> - Alternative console distribution options
> The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default.
> A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months