4 Replies Latest reply on Mar 2, 2004 5:51 PM by essington

    Excluding classes from AOP munging.

    essington

      I am trying to add a JCE provider at runtime. This provider is supplied as a signed jar file. When I have this jar file within my sar file, AOP appears to rewrite (modify the bytecode of?) the classes causing them to no longer be valid as signed.

      The net effect of this is I am able to load the JCE provider, but I am not able to actually use it, as the java security manager whines "The provider may not be signed by a trusted party."

      If I comment out the AspectManagerService from the conf/jboss-service.xml file the provider can be loaded and used successfully.

      Is there a way to tell the AspectManager to not touch any of the classes found in this signed jar? Is it possible to do this from within the sar I am trying to deploy?

      Any help would be appreciated

      -jason

        • 1. Re: Excluding classes from AOP munging.
          bill.burke

          COOL! Actually this is a good thing as I had not tested to make sure that signed jars could not be modified.

          But, to solve your problem, with JBoss DR2, I think if you modify jboss-service.xml where AspectManagerService is defined you can do

          You have to make sure that any pointcuts you have defined to not target any classes within your JCE provider. I think you can do this in DR2:

          [mbean code="org.jboss.aop.deployment.AspectManagerService"
           name="jboss.aop:service=AspectManager"]
           [attribute name="ConvertAll"]false[/attribute]
          [/mbean]
          


          DR3 does not have this switch. In DR3 (CVS HEAD now to be released mid March), JBoss will not modify any classes at loadtime if you do not declare a pointcut on it. In DR3 you can also decide to do precompilation of Class files rather than doing class-loadtime AOP. In other words, you can turn class-loadtime instrumentation.

          Let me know if this helps.

          bill

          • 2. Re: Excluding classes from AOP munging.
            essington

            I am using a version of jboss-head from a couple weeks ago (it still claims to be DR3, but it isn't completely courrent).

            I edited the AspectManagerService to look like so:

            <mbean code="org.jboss.aop.deployment.AspectManagerService"
             name="jboss.aop:service=AspectManager">
             <!--attribute name="MethodFilter">ALL</attribute>
             <attribute name="FieldFilter">ALL</attribute>
             <attribute name="ConstructorFilter">ALL</attribute-->
             <attribute name="ConvertAll">false</attribute>
             </mbean>
            


            and still when I try to access my provider I get a stack trace that begins:

            java.lang.SecurityException: The provider BC may not be signed by a trusted party
             at javax.crypto.SunJCE_b.a(DashoA6275)
             at javax.crypto.Cipher.a(DashoA6275)
             at javax.crypto.Cipher.getInstance(DashoA6275)
             at org.jboss.net.axis.security.plugins.WSSecurityDomain.loadProvider(WSSecurityDomain.java:353)
             at org.jboss.net.axis.security.plugins.WSSecurityDomain.create(WSSecurityDomain.java:240)
            


            I guess I should update my tree and try it again.
            In the mean time, any other ideas?

            -jason

            • 3. Re: Excluding classes from AOP munging.
              bill.burke

              well, what is currently in head is very different from 3 weeks ago. the XML expressions have been totally changed. You would have to look at the testsuite xml testsuite/src/resources/aop/META-INF/jboss-aop.xml for examples as I haven't written any doco yet. But HEAD should work as you can shut off load-time transformations.

              Bill

              • 4. Re: Excluding classes from AOP munging.
                essington

                 

                "Bill Burke" wrote:
                But HEAD should work as you can shut off load-time transformations.


                Well, I finally found the time to upgrade my test environment to the latest code found in HEAD (3/2) and sure enough, AOP no longer causes the classes in the signed jar to fail to load properly.

                progress is a "good thing"

                thanks Bill

                -jason