[JBoss JIRA] Moved: (JBJCA-26) Making JCA security more pluggable
by Jesper Pedersen (JIRA)
[ https://jira.jboss.org/jira/browse/JBJCA-26?page=com.atlassian.jira.plugi... ]
Jesper Pedersen moved JBAS-2923 to JBJCA-26:
--------------------------------------------
Project: JBoss JCA (was: JBoss Application Server)
Key: JBJCA-26 (was: JBAS-2923)
Component/s: Core
(was: JCA service)
Security: (was: Public)
> Making JCA security more pluggable
> ----------------------------------
>
> Key: JBJCA-26
> URL: https://jira.jboss.org/jira/browse/JBJCA-26
> Project: JBoss JCA
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Moved: (JBJCA-21) Move the rars into a separate project that does not depend on the connection manager implementation
by Jesper Pedersen (JIRA)
[ https://jira.jboss.org/jira/browse/JBJCA-21?page=com.atlassian.jira.plugi... ]
Jesper Pedersen moved JBAS-1791 to JBJCA-21:
--------------------------------------------
Project: JBoss JCA (was: JBoss Application Server)
Key: JBJCA-21 (was: JBAS-1791)
Component/s: Core
(was: JCA service)
Security: (was: Public)
> Move the rars into a separate project that does not depend on the connection manager implementation
> ---------------------------------------------------------------------------------------------------
>
> Key: JBJCA-21
> URL: https://jira.jboss.org/jira/browse/JBJCA-21
> Project: JBoss JCA
> Issue Type: Task
> Components: Core
> Reporter: Adrian Brock
>
> The resource adapter implementations should NOT depend upon the connection manager
> implementation or transaction manager or any other jboss service.
> This is the wrong way around. It is like coding an EJB to use specifics of a JBoss EJB container.
> Related, each resource adapter should be useable in a standalone environment
> (with an internal dummy connection manager) through the alternate api
> See javax.resource.spi.ManagedConnectionFactory
> /**
> * Creates a connection factory instance. The connection manager is provided
> * by the resource adapter.
> *
> * STANDALONE USE
> *
> * @return the connection factory
> * @throws ResourceException for a generic error
> * @throws ResourceAdapterInternalException for an internal error in the
> * resource adapter
> */
> public Object createConnectionFactory() throws ResourceException;
> /**
> * Creates a connection factory instance. the connection manager is provided
> * by the application server
> *
> * APPLICATION SERVER/EXTERNAL CONNECTION MANAGER USE
> *
> * @param cxManager the connection manager
> * @return the connection factory
> * @throws ResourceException for a generic error
> * @throws ResourceAdapterInternalException for an internal error in the
> * resource adapter
> */
> public Object createConnectionFactory(ConnectionManager cxManager) throws ResourceException;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Moved: (JBJCA-19) RAR MetaData Repository
by Jesper Pedersen (JIRA)
[ https://jira.jboss.org/jira/browse/JBJCA-19?page=com.atlassian.jira.plugi... ]
Jesper Pedersen moved JBAS-1437 to JBJCA-19:
--------------------------------------------
Project: JBoss JCA (was: JBoss Application Server)
Key: JBJCA-19 (was: JBAS-1437)
Component/s: Core
(was: JCA service)
Security: (was: Public)
> RAR MetaData Repository
> -----------------------
>
> Key: JBJCA-19
> URL: https://jira.jboss.org/jira/browse/JBJCA-19
> Project: JBoss JCA
> Issue Type: Task
> Components: Core
> Reporter: Adrian Brock
> Assignee: Jesper Pedersen
> Priority: Minor
>
> Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48681
> Implement a RAR MetaData repository.
> There are two use cases of this object:
> * A tool wants to retrieve information about how to configure a RAR deployment
> either inbound/outbound or admin object
> * Avoiding the need to specify the rar-name in jboss.xml, -ds.xml or admin object deployments when
> only one rar implements the connection definition or message listener.
> Design:
> 1) When a RAR is deployed/undeployed update the repository with information about the RAR including
> cross references by
> * ConnectionDefinition
> * MessageListener
> * AdminObject
> 2) When an MDB is deployed without identifying the rar, use the repository to try to guess the RAR
> 3) When a ConnectionFactory is deployed without identifying the rar, use the repository to try to guess the RAR
> 4) When an AdminObject is deployed without identifying the rar, use the repository to try to guess the RAR
> The algorithm to guess the RAR is
> a) Is there only one RAR implementing the object
> b) If there is more than one RAR, is there a specific RAR in the same top level deployment (EAR)
> as the referencing deployment
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Moved: (JBJCA-20) JDBC RAR tests
by Jesper Pedersen (JIRA)
[ https://jira.jboss.org/jira/browse/JBJCA-20?page=com.atlassian.jira.plugi... ]
Jesper Pedersen moved JBAS-1587 to JBJCA-20:
--------------------------------------------
Project: JBoss JCA (was: JBoss Application Server)
Key: JBJCA-20 (was: JBAS-1587)
Component/s: JDBC
(was: JCA service)
Affects Version/s: (was: JBossAS-4.0.1 Final)
(was: JBossAS-4.0.2RC1)
(was: JBossAS-4.0.1 SP1)
Security: (was: Public)
> JDBC RAR tests
> --------------
>
> Key: JBJCA-20
> URL: https://jira.jboss.org/jira/browse/JBJCA-20
> Project: JBoss JCA
> Issue Type: Task
> Components: JDBC
> Reporter: Adrian Brock
> Priority: Minor
>
> Need to write some tests that tweaks the edge cases of the RAR configuration,
> in particular:
> no-tx vs local-tx vs xa
> PreparedStatement caching
> Resetting of Connection/Statement state variables
> auto-commit vs user setAutoCommit(false) vs Managed
> transaction isolation levels
> etc.
> This will probably have to wait until we integrate Derby
> so we actually have support for these usecases in a test database.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Moved: (JBJCA-18) JCA Interceptors
by Jesper Pedersen (JIRA)
[ https://jira.jboss.org/jira/browse/JBJCA-18?page=com.atlassian.jira.plugi... ]
Jesper Pedersen moved JBAS-1435 to JBJCA-18:
--------------------------------------------
Project: JBoss JCA (was: JBoss Application Server)
Key: JBJCA-18 (was: JBAS-1435)
Component/s: Core
(was: JCA service)
Fix Version/s: (was: JBossAS-5.1.0.Beta1)
Security: (was: Public)
> JCA Interceptors
> ----------------
>
> Key: JBJCA-18
> URL: https://jira.jboss.org/jira/browse/JBJCA-18
> Project: JBoss JCA
> Issue Type: Task
> Components: Core
> Reporter: Adrian Brock
> Priority: Minor
>
> Forums discussion thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48683
> This is really a major rewrite of the JCA implementation to be less monolithic
> so this will need some careful design and consideration and
> breaking up into more fine grained tasks.
> The idea is to provide containers/interceptors for the components within the JCA module
> such that these components can be more easily customised and developed according to
> the needs of each user.
> There are three main interceptor stacks that I can think of:
> 1) ConnectionManager (connection allocation)
> This provides an interceptor stack behind the ConnectionFactory/DataSource proxy
> to process the allocateConnection invocation.
> It will look something like:
> ConnectionFactory proxy -> ConnectionManager interceptor -> Pooling interceptor
> 2) ManagedConnection/ConnectionEventListener (connection management)
> This stack provides most of the features that are currently performed by the
> BaseManagerConnection2$ConnectionListener and their supporting methods,
> but as an interceptor stack.
> As now they will largely be driven by the events from the resource adapter,
> and it this object that is actually pooled.
> 3) Resource Adaptors
> The JDBC and JMS adaptors should be implemented as interceptor stacks
> to allow optional interceptors like statistics collection, custom behaviour
> and also to perform vendor specific processing/workarounds.
> Where AOP can be used, we could actually instrument the vendor classes so
> we can also expose vendor specific methods, not just the JDBC interfaces.
> This would remove the requirement to do things like getUnderlyingConection() by user code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[JBoss JIRA] Moved: (JBJCA-17) JMS Message Inflow
by Jesper Pedersen (JIRA)
[ https://jira.jboss.org/jira/browse/JBJCA-17?page=com.atlassian.jira.plugi... ]
Jesper Pedersen moved JBAS-1434 to JBJCA-17:
--------------------------------------------
Project: JBoss JCA (was: JBoss Application Server)
Key: JBJCA-17 (was: JBAS-1434)
Component/s: JMS
(was: JCA service)
Fix Version/s: (was: JBossAS-5.1.0.Beta1)
Affects Version/s: (was: JBossAS-4.0.2 Final)
Security: (was: Public)
> JMS Message Inflow
> ------------------
>
> Key: JBJCA-17
> URL: https://jira.jboss.org/jira/browse/JBJCA-17
> Project: JBoss JCA
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months