TODO: Interceptors

[adrian.brock]

Need to add interceptors to the implementation to allow behaviour to be more
easily introduced by users/integrators. This would also simply much of the
code which is fairly monolithic.

[adrian.brock]

JIRA Task: http://jira.jboss.com/jira/browse/JBJCA-5

[weston.price]

Yep, this is a biggie ;-)

I have some thoughts on this, been kicking it around in my head for awhile (lots of rattling in empty spaces).

My initial question/thought is one of trying to share as much with the JCA MC stuff as possible. Clearly we want to use AOP for the JCA rewrite, so some restructuring of projects is probably in order. I will come up with some broad strokes on this and post when finished.

[wmprice]

This one is bugging me. I was thinking how much we could get out of replacing the JCA core as it exists today with the MC stuff. Keep the basic MBean stuff, but just delegate to the MC internals.

More on this when I can get my head around it ;-)

[weston.price]

Does it make sense to integrate the jca MC project into the connector project as a first step? There is no reason why we couldn't generated seperate artifacts in the build process, however, it would seem to make sense that we want to house this stuff together since my plan is to use the jca MC code for the core of the new JCA implementation.

[weston.price]

This brings up another question I have, well a few of them ;-)

1.4 versus 1.5. I have always operated under the assumption that for the most part, in JCA, we stay away from 1.5 constructs (ie generics, static imports, annotations). Is this actually the case? In large part I naturally took this path because of our matrix build process. However, if this is not the case, please advise.

I would like to refactor the connector project in anticipation of breaking apart things to satisfy the JIRA task. I know we try to maintain backwards compatibility at all costs in the 4.0.x branch, and I can understand this, however, I would like to know how much freedom we have for JBoss 5.0.

Initial thoughts on what this task will required

Introduction of a jboss-ra.xml file to allow for invoker/proxy bindings for the new JCA 'container'

Refactor the connector code to integrate the MC work, basically constructing the 'core' or 'kernel' packages, basically an spi that would introduce pluggable aspects for the container:

connection management
pool policies
transaction management
etc

Sorry for the long post. If you want, I can split these up into different threads.

[starksm64]

In terms of the project structure, we need to be moving away from single projects that define multiple artifacts as this does not fit with the maven2 direction we want to head.

[starksm64]

1.4 versus 1.5. I have always operated under the assumption that for the most part, in JCA, we stay away from 1.5 constructs (ie generics, static imports, annotations). Is this actually the case? In large part I naturally took this path because of our matrix build process. However, if this is not the case, please advise.

jboss5 will require a Java5 runtime. The issue has always been how much of the codebase will have to run in jboss4 or another component like the ESB that required a Java1.4 runtime. For these, the main sticking point is whether there an existing jboss4 codebase that needs to be kept in synch with the jboss5 codebase.

Upto this point we have restricted the use of Java5 for such a codebase. With the introduction of the jbossretro tool to convert a Java5 codebase into a Java14 compatible runtime, this is less of an issue. The main problem is that this essentially requires that the component source be pulled out of jboss4 and integrated as a binary dependency. The jboss5 version would use the Java5 based artifacts, and the jboss4 version would use the jbossretro converted Java14 compatible artifacts. This is what was done with the jbossws stack.

[adrian.brock]

LIke I said before, don't do too much refactoring in the connector project.

This will be moving to "legacy" status once we have time to work
on the jca project.

What I don't want is an unstable/new codebase in jca
and an unstable codebase in connector.

Leave connector as the JBoss4 implementation of JCA.
If people want to use it in JBoss5 then fine, but we should
encourage people to move the aspectized jca container once
it is stable.

There must be a path for people that can't use the new aspectized
jca container because they've done their integration with
org.jboss.resource, even though we don't officially support
people that do that.

[adrian.brock]

On Java5 features. You are ok to use them.
If we need to backport the code to JDK1.4/JBoss4 we can
JBossRetro it.

[weston.price]

Ok, this answers exactly the question I had. As a result, the following seems to hold:

The connector module is being included in JBoss5 only for legacy compatiblity and will be frozen from active development beyond bug fixes and minor JIRA enhancements.

I understand about not wanting 'unstable' code bases in the connector, however, there are some things I think would benefit from a cleanup, just to make things clearer to read and understand. However, I will defer to your judgement on this one.

So, the JIRA task

http://jira.jboss.org/jira/browse/JBAS-1435

Concerns only the jca project. I had assumed that we were going to try and retrofit some interception in the legacy stuff but this doesn't appear to be in the vision. This is fine, make more sense in the larger context.

[vickyk]

I think this task should be broken in subtasks as this appears a major change to me . If no one has started working on this then I can continue with it , I would follow these checkpoints

1) Analyze and discuss about where to configure the interceptors in the configurations , weston has already pointed to have the invoker proxy binding configuration in the jboss-ra.xml . I can think of putting the interceptor flag in the ra.xml file as one of the config-properties . In the -ds.xml file we can have comma seperated interceptors as

<cminterceptors>com.foo.Inteceptor1,com.foo.Interceptor2</cminterceptor>

This was we can define the ConnectionManager Interceptors.
Same would be true with other type of Interceptors.

2) For the ConnectionManager Interceptor entry the the BaseConnectionManager2.allocateConnection(...) should detect if the interceptors are configured , if they are then the invocations should be passed through them.I am yet not sure what CM intercetors would do , yet trying to figure about the use cases.

3) Similar steps should be followed for other interceptor types .

[adrian.brock]

This work has already been started in the jboss-jca prototype project (using AOP).
There's another thread about it somewhere.
It's going to be done in the old code.

[vickyk]

Is some one still working on this ?

This work has already been started in the jboss-jca prototype project (using AOP).

Where can I get the jboss-jca project which contains this work?

[adrian.brock]

Not currently. The code is in old cvs along with a jboss-rars project that implements
rars using AOP as well.