7 Replies Latest reply on Apr 18, 2005 12:10 PM by Adrian Brock

    Integration of aop/aspects into JBAS and other projects

    Scott Stark Master

      Ben Wang has created a web container aspect for fine-grained replication of session data. This brings up a previous issue of where aspects live and how they are deployed in non-trivial environments like JBAS.

      Currently there are aspects like security living in the aspects module which do not belong in a standalone aspects library as evidenced by the module dependencies:

       <path id="dependentmodule.classpath">
       <path refid="jboss.common.classpath"/>
       <path refid="jboss.j2ee.classpath"/>
       <path refid="jboss.j2se.classpath"/>
       <path refid="jboss.jmx.classpath"/>
       <path refid="jboss.system.classpath"/>
       <path refid="jboss.security.classpath"/>
       <path refid="jboss.j2se.classpath"/>
       <path refid="jboss.system.classpath"/>
       <path refid="jboss.remoting.classpath"/>
       <path refid="jboss.cluster.classpath"/>
       <path refid="jboss.transaction.classpath"/>
       <path refid="jboss.aop.classpath"/>
       <path refid="jboss.server.classpath"/>
       <path refid="jboss.container.classpath"/>
       </path>
      


      The aspects I am most familar with that do not belong here are the security aspects, which depend on implementation details of jbosssx as it is bundled into JBAS.

      Throw in deployment ordering, hot deployment, class loader scoping, alignment of aspects with their sevices for ease of installation packaging, etc. and the current monolithic aspect is not managable.

      So this thread is a starting point to discuss how we are going to manage the aop aspects.


        • 1. Re: Integration of aop/aspects into JBAS and other projects
          Ben Wang Master

          Well, this is not exactly as an Aspect. But rather an switch inside Tomcat.

          Still, I have a tc5-clutster.aop jar that needs to deploy under all/deploy. In addition, I need to access it from testsuite so my POJO can precompile with annotationc and aopc.

          What's the best practice?

          • 2. Re: Integration of aop/aspects into JBAS and other projects
            Ben Wang Master

            I am going ahead to create a tomcat module so I can reference it from testsuite. In addition, I am deploying tc5-cluster.aop (has jboss-aop.xml) under all/deploy. This is needed for http session fine-grained replication using aop.

            I can modify the setup later on if there is a need.

            • 3. Re: Integration of aop/aspects into JBAS and other projects
              Adrian Brock Master

              I believe the aspects belong in the module that implements them.

              This is the only approach that will allow the aspect to evolve across versions
              rather than trying to maintain a monolithic single integration package
              jboss-aspects.

              The aspect requires the rest of the implementation anyway, e.g. the
              authentication/authorization advices require jbosssx.

              • 4. Re: Integration of aop/aspects into JBAS and other projects
                Bill Burke Master

                It has actually been much easier to package it as this "monolithic" aspect library over the past few years. If there is a bug or feature addition in any of the aspects in the library, I can easily patch any version of JBoss. It would actually be more "monolithic" if the code was part of Branch_4_0 as I would not be able to do a new release of the aspect library (and EJB 3.0 for instance) without a complete rev of the entire application server. This is quite unacceptable to most users.

                So, in summary, although I think it might be asthetically appropriate, I don't see how this change you suggest will make anybody's life easier. It sure will make the EJB3/AOP team's life much harder to do new releases.

                • 5. Re: Integration of aop/aspects into JBAS and other projects
                  Scott Stark Master

                  A standalone release of aop which includes a security aspect depending on the implementation details of jboss-4.0.x makes no sense.

                  • 6. Re: Integration of aop/aspects into JBAS and other projects
                    Adrian Brock Master

                     

                    "bill.burke@jboss.com" wrote:
                    It has actually been much easier to package it as this "monolithic" aspect library over the past few years.


                    Ok, one contra example is code to integrate the deployer/classloader across versions:
                    http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-aspects/src/main/org/jboss/aop/deployment/

                    If there is a bug or feature addition in any of the aspects in the library, I can easily patch any version of JBoss.


                    How so, are you going to keep up and supply different versions of these advices
                    as the internal api changes?


                    It would actually be more "monolithic" if the code was part of Branch_4_0 as I would not be able to do a new release of the aspect library (and EJB 3.0 for instance) without a complete rev of the entire application server.


                    You need the implementation library anyway for the aspect to work. And the
                    implementation details (non-published api like SecurityAssociation) is going to
                    evolve independently across versions.


                    So, in summary, although I think it might be asthetically appropriate, I don't see how this change you suggest will make anybody's life easier.


                    Aesthetics are not an issue, it is about each module being responsible for
                    its own implementation.


                    It sure will make the EJB3/AOP team's


                    The EJB3/AOP team should concentrate on delivering containers and the invocation
                    model, not how to integrate security.
                    And see above about needing jbosssx.jar anyway.

                    This is the same mentality that led to the JBossCache project becoming bloated.

                    • 7. Re: Integration of aop/aspects into JBAS and other projects
                      Adrian Brock Master

                      The integration point is the annotation (which also belongs in JBossSX)
                      and that needs to be consistent with the features provided by each version.

                      @SecurityDomain("other")
                      @NewSecurityFeatureNotAvailableInJBoss32 // Shouldn't compile under 3.2.x
                      public void doSomething()
                      {
                      }