[JBoss JIRA] Resolved: (JBJCA-26) Making JCA security more pluggable
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-26?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen resolved JBJCA-26.
----------------------------------
Resolution: Out of Date
> Making JCA security more pluggable
> ----------------------------------
>
> Key: JBJCA-26
> URL: https://issues.jboss.org/browse/JBJCA-26
> Project: IronJacamar
> Issue Type: Feature Request
> Components: Core
> Reporter: Adrian Brock
> Assignee: Jesper Pedersen
>
> We need a mechanism to make JCA security more pluggable.
> This is to cater for use cases where some extra context needs to be used.
> The connection manager only understands a subject.
> The connection factory (e.g. DataSource) only understands the CRI (method parameters).
> The pooling uses both without needing to understand what they are in detail.
> This change would provide a "wrapper" connection manager that can do things
> more associated to context, e.g. it could be connection factory specific,
> i.e. it understands the CRI and can do things that the connection factory doesn't do
> or it can do things based on information.
> An example of other information would allowing a per deployment
> security domain such that you have different pre-configured user/password per ejb.
> With something like the following in META-INF/jboss-[web].xml
> <jboss>
> <enterprise-beans>
> <session>
> <ejb-name>Whatever</ejb-name>
> ...
> <resource-ref>
> <res-ref-name>jdbc/DataSource</res-ref-name>
> <jndi-name>java:/MySQLDS</jndi-name>
> <security-domain>FooBar</security-domain>
> </resource-ref>
> </session>
> </enterprise-beans>
> </jboss>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Closed: (JBJCA-26) Making JCA security more pluggable
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-26?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen closed JBJCA-26.
--------------------------------
> Making JCA security more pluggable
> ----------------------------------
>
> Key: JBJCA-26
> URL: https://issues.jboss.org/browse/JBJCA-26
> Project: IronJacamar
> Issue Type: Feature Request
> Components: Core
> Reporter: Adrian Brock
> Assignee: Jesper Pedersen
>
> We need a mechanism to make JCA security more pluggable.
> This is to cater for use cases where some extra context needs to be used.
> The connection manager only understands a subject.
> The connection factory (e.g. DataSource) only understands the CRI (method parameters).
> The pooling uses both without needing to understand what they are in detail.
> This change would provide a "wrapper" connection manager that can do things
> more associated to context, e.g. it could be connection factory specific,
> i.e. it understands the CRI and can do things that the connection factory doesn't do
> or it can do things based on information.
> An example of other information would allowing a per deployment
> security domain such that you have different pre-configured user/password per ejb.
> With something like the following in META-INF/jboss-[web].xml
> <jboss>
> <enterprise-beans>
> <session>
> <ejb-name>Whatever</ejb-name>
> ...
> <resource-ref>
> <res-ref-name>jdbc/DataSource</res-ref-name>
> <jndi-name>java:/MySQLDS</jndi-name>
> <security-domain>FooBar</security-domain>
> </resource-ref>
> </session>
> </enterprise-beans>
> </jboss>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Closed: (JBJCA-17) JMS Message Inflow
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-17?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen closed JBJCA-17.
--------------------------------
> JMS Message Inflow
> ------------------
>
> Key: JBJCA-17
> URL: https://issues.jboss.org/browse/JBJCA-17
> Project: IronJacamar
> Issue Type: Task
> Components: JMS
> Reporter: Adrian Brock
> Assignee: Jesper Pedersen
>
> Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48672
> The JMS message inflow in the JMS resource adapter needs properly testing.
> There are basic tests, but the following are missing:
> 1) Complete tests of edge cases for each configuration parameter in the activation spec
> 2) Failure tests to confirm the implementation handles error gracefully
> 3) Stress tests to make sure there the implementation is stable
> 4) Performance tests to optimize the implementation
> Additionally, we need to confirm that it is possible to use this implementation for EJB2.0
> style deployments and hence as the default configuration.
> This should be possible provided the user has not created their own
> container configuration that uses the old JMSContainerInvoker explicitly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Resolved: (JBJCA-17) JMS Message Inflow
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-17?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen resolved JBJCA-17.
----------------------------------
Resolution: Won't Fix
HornetQ has their own resource adapter
> JMS Message Inflow
> ------------------
>
> Key: JBJCA-17
> URL: https://issues.jboss.org/browse/JBJCA-17
> Project: IronJacamar
> Issue Type: Task
> Components: JMS
> Reporter: Adrian Brock
> Assignee: Jesper Pedersen
>
> Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48672
> The JMS message inflow in the JMS resource adapter needs properly testing.
> There are basic tests, but the following are missing:
> 1) Complete tests of edge cases for each configuration parameter in the activation spec
> 2) Failure tests to confirm the implementation handles error gracefully
> 3) Stress tests to make sure there the implementation is stable
> 4) Performance tests to optimize the implementation
> Additionally, we need to confirm that it is possible to use this implementation for EJB2.0
> style deployments and hence as the default configuration.
> This should be possible provided the user has not created their own
> container configuration that uses the old JMSContainerInvoker explicitly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month