9 Replies Latest reply on Aug 31, 2007 3:10 PM by flavia.rainone

    dynamic cflow double call

    system.out

      Athough the dynamic cflow in tutorial is working fine, when I deploy it in appserver, the SimpleDynamicCFlow is being called twice.
      here is the scenario:
      module-one.ear (including aop-one.aop)
      module-two.ear(including aop-one.aop)
      the application is working fine without dynamic cflow in jboss-aop.xml, but upon adding dynamic cflow, shouldExecute() method is being called twice, before interception.

      Any idea?

        • 1. Re: dynamic cflow double call
          flavia.rainone

          Are you deploying two instances of the same binding that uses the DynamicCFlow component?

          If yes, this deployment should take place in a scoped way. Otherwise, both bindings will apply globally, so, they will affect both applications (module-one.ear and module-two.ear). Hence, each joinpoint will be intercepted twice, which will trigger two calls to SimpleDynamicCFlow.

          • 2. Re: dynamic cflow double call
            system.out

            Flavia,
            You are right on the money! Yes, both have the same bindings, however, the module-two.ear is in 'deploy-hasingleton', while the other in 'deploy' folder.

            Although there are two instances of 'aop-one.aop', I set the scope of aspects to be 'PER_VM', which doesn't work on DynamicCflow?!

            Any idea to avoid this double call to DynamicCflow? maybe by packaging them differently!

            Thanks,
            Mike

            • 3. Re: dynamic cflow double call
              flavia.rainone

              You have to scope your .ear files.

              In each one of the.ear files, add this to the META-INF/jboss-app.xml file:

              <jboss-app>
              .....
              <loader-repository>yourApp:loader=yourApp.ear</loader-repository>
              </jboss-app>


              This way, each .ear will be loaded in a separate scope, and the same will apply to the .aop file inside of them.

              Alternatively, you can change the "Isolated" attribute value of ear-deployer.xml file instead of adding the loader-repository tag above to each ear (this will scope all ear deployed files of your server).

              Notice that isolating each ear in a scope will forbid classes of one ear file to see classes of the other. If this is not what you want, I think that deploying a single .aop file would also work.

              • 4. Re: dynamic cflow double call
                system.out

                How can I deploy single aop file, while instrumenting both ears, one in 'deploy' another in 'deploy-hasingleton'?
                I assume if I remove aop file from ears, they won't be instrumented at load-time?
                I like to know how I can have single aop file in the above scenario !! That is a clean solution if possible !

                • 5. Re: dynamic cflow double call
                  system.out

                  by single aop file, I am referring to aop-one.aop package !

                  • 6. Re: dynamic cflow double call
                    flavia.rainone

                    Given that the aop file of module-one.ear is affecting module-two.ear and vice-versa, you just need this aop file in one of the modules. I would choose the .ear file that is in the deploy directory.

                    AFAIK, putting the .aop file directly in the deploy dir should also work. This way, your packaging structure would be cleaner, since the .aop file affects not only module-one.ear, but also module-two.ear.

                    Let me know if this works. :)

                    • 7. Re: dynamic cflow double call
                      kabirkhan

                      A standalone .aop file is the way forward. The URLDeploymentScanner will deploy .aop files before .ear files

                      • 8. Re: dynamic cflow double call
                        system.out

                        2 questions:

                        1 - As per section 10.4, by default the aop bindings are global to whole VM. What happens if aop is deployed after the deployments of ear? Would all aspectized ear be instrumented? If not, can it be enfoced to do so!

                        2 - Should section 10.4 (below) include 'deploy-hasingleton' folder beside 'deploy' folder?

                        10.4. Scoping aop to the classloader
                        By default all deployments in JBoss are global to the whole application server. That means that any ear, sar, jar etc. that is put in the deploy directory can see the classes from any other deployed archive. Similarly, aop bindings are global to the whole virtual machine. This "global" visibility can be turned off per top-level deployment.



                        • 9. Re: dynamic cflow double call
                          flavia.rainone

                           

                          1 - As per section 10.4, by default the aop bindings are global to whole VM. What happens if aop is deployed after the deployments of ear? Would all aspectized ear be instrumented?

                          When using load-time weaving, if aop is deployed after the deployements of ear, it won't work. Since the weaving takes place during load-time, deploying aop before the ear file is the only way to ensure that the application will be loaded after the deployment of your aop file.

                          If not, can it be enfoced to do so!

                          I think that deploying a jboss-aop.xml to the deploy dir with prepare pointcut expressions should work. But I haven't tried it.

                          Should section 10.4 (below) include 'deploy-hasingleton' folder beside 'deploy' folder?

                          I think you are right, we will fix this.