1 2 Previous Next 16 Replies Latest reply on Jul 10, 2007 11:40 AM by Adrian Brock

    TODO: Interceptors

    Adrian Brock Master

      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.

        • 2. Re: TODO: Interceptors
          Weston M. Price Master

          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.

          • 3. Re: TODO: Interceptors
            Weston Price Newbie

            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 ;-)

            • 4. Re: TODO: Interceptors
              Weston M. Price Master

              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.

              • 5. Re: TODO: Interceptors
                Weston M. Price Master

                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.

                • 6. Re: TODO: Interceptors
                  Scott Stark Master

                  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.

                  • 7. Re: TODO: Interceptors
                    Scott Stark Master

                     

                    "weston.price@jboss.com" wrote:

                    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.


                    • 8. Re: TODO: Interceptors
                      Adrian Brock Master

                      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.

                      • 9. Re: TODO: Interceptors
                        Adrian Brock Master

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

                        • 10. Re: TODO: Interceptors
                          Weston M. Price Master

                          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.



                          • 11. Re: TODO: Interceptors
                            Vicky Kak Master

                            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 .



                            • 12. Re: TODO: Interceptors
                              Adrian Brock Master

                              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.

                              • 13. Re: TODO: Interceptors
                                Vicky Kak Master

                                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?

                                • 14. Re: TODO: Interceptors
                                  Adrian Brock Master

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

                                  1 2 Previous Next