March 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBJCA-16) Message Inflow targetting MBeans/POJOs

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-16?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen closed JBJCA-16. -------------------------------- > Message Inflow targetting MBeans/POJOs > -------------------------------------- > > Key: JBJCA-16 > URL: https://issues.jboss.org/browse/JBJCA-16 > Project: IronJacamar > 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=48674 > The JCA message inflow could target MBeans or POJOs rather than EJBs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBJCA-15) Improvements to Message Inflow

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-15?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen closed JBJCA-15. -------------------------------- > Improvements to Message Inflow > ------------------------------ > > Key: JBJCA-15 > URL: https://issues.jboss.org/browse/JBJCA-15 > Project: IronJacamar > 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=48675 > Need to determine what quality of service features should be provided > for message inflow. > The most obvious would be delivery side pooling where the RAR does not do this > or does this badly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBJCA-18) JCA Interceptors

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-18?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen resolved JBJCA-18. ---------------------------------- Resolution: Won't Fix > JCA Interceptors > ---------------- > > Key: JBJCA-18 > URL: https://issues.jboss.org/browse/JBJCA-18 > Project: IronJacamar > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBJCA-13) More Configurable Bootstrap Context

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-13?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen resolved JBJCA-13. ---------------------------------- Assignee: Jesper Pedersen Resolution: Out of Date > More Configurable Bootstrap Context > ----------------------------------- > > Key: JBJCA-13 > URL: https://issues.jboss.org/browse/JBJCA-13 > Project: IronJacamar > 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=48677 > Need a mechanism to make the Bootstrap context passed to rar more configurable. > Currently a single context is passed to all rars. > e.g. A rar may want its own WorkManager/ThreadPool -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBJCA-13) More Configurable Bootstrap Context

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-13?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen closed JBJCA-13. -------------------------------- > More Configurable Bootstrap Context > ----------------------------------- > > Key: JBJCA-13 > URL: https://issues.jboss.org/browse/JBJCA-13 > Project: IronJacamar > 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=48677 > Need a mechanism to make the Bootstrap context passed to rar more configurable. > Currently a single context is passed to all rars. > e.g. A rar may want its own WorkManager/ThreadPool -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBJCA-15) Improvements to Message Inflow

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-15?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen resolved JBJCA-15. ---------------------------------- Resolution: Out of Date Assignee: Jesper Pedersen > Improvements to Message Inflow > ------------------------------ > > Key: JBJCA-15 > URL: https://issues.jboss.org/browse/JBJCA-15 > Project: IronJacamar > 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=48675 > Need to determine what quality of service features should be provided > for message inflow. > The most obvious would be delivery side pooling where the RAR does not do this > or does this badly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBJCA-12) Programmatic Connection Definition Deployment

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-12?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen closed JBJCA-12. -------------------------------- > Programmatic Connection Definition Deployment > --------------------------------------------- > > Key: JBJCA-12 > URL: https://issues.jboss.org/browse/JBJCA-12 > Project: IronJacamar > 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=48673 > Provide a mechanism where ConnectionFactorys/DataSources (Connection Definitions) > can be deployed/undeployed programmatically. > The basic design is as follows: > 1) Provide a mechanism to instantiate MetaData for a connection factory. > This information is the same as the -ds.xml deployment format. > The MetaData can be logically divided into at least the following categories: > * RAR/ConnectionDefinition identification > * ManagedConnectionFactory > * Pool > * Security > * ConnectionManager > * Proxy/JNDI binding > 2) Write an optimized version of the MetaData for the DataSource deployments > which are really a simplified version of the ConnectionFactory deployments with some > hardwiring. > 3) Write a service that deploys the ConnectionFactory (creates MBeans) > from the MetaData and undeploys them based on their id (jndi binding). > 4) Convert the ConnectionFactory deployer to construct the MetaData from the -ds.xml > files and invoke the service new service. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBJCA-19) RAR MetaData Repository

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-19?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen resolved JBJCA-19. ---------------------------------- Resolution: Out of Date > RAR MetaData Repository > ----------------------- > > Key: JBJCA-19 > URL: https://issues.jboss.org/browse/JBJCA-19 > Project: IronJacamar > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBJCA-19) RAR MetaData Repository

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-19?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen closed JBJCA-19. -------------------------------- > RAR MetaData Repository > ----------------------- > > Key: JBJCA-19 > URL: https://issues.jboss.org/browse/JBJCA-19 > Project: IronJacamar > 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBJCA-12) Programmatic Connection Definition Deployment

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-12?page=com.atlassian.jira.plugin.s... ] Jesper Pedersen resolved JBJCA-12. ---------------------------------- Resolution: Out of Date > Programmatic Connection Definition Deployment > --------------------------------------------- > > Key: JBJCA-12 > URL: https://issues.jboss.org/browse/JBJCA-12 > Project: IronJacamar > 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=48673 > Provide a mechanism where ConnectionFactorys/DataSources (Connection Definitions) > can be deployed/undeployed programmatically. > The basic design is as follows: > 1) Provide a mechanism to instantiate MetaData for a connection factory. > This information is the same as the -ds.xml deployment format. > The MetaData can be logically divided into at least the following categories: > * RAR/ConnectionDefinition identification > * ManagedConnectionFactory > * Pool > * Security > * ConnectionManager > * Proxy/JNDI binding > 2) Write an optimized version of the MetaData for the DataSource deployments > which are really a simplified version of the ConnectionFactory deployments with some > hardwiring. > 3) Write a service that deploys the ConnectionFactory (creates MBeans) > from the MetaData and undeploys them based on their id (jndi binding). > 4) Convert the ConnectionFactory deployer to construct the MetaData from the -ds.xml > files and invoke the service new service. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2011