11 Replies Latest reply on Feb 14, 2005 6:35 PM by adrian.brock

    INFO api - a critique

      Here are my problems with the Info api as it currently stands.

      1) Need support for ParameterInfo, mainly for parameter annotations
      2) Ideally, I'd like to share the reflection objects (field, method, etc) with
      the reflection join point factory rather than having to re-resolve them.
      I couldn't see any easy way to achieve this.
      3) Need to properly define the TypoInfoFactory that will be exposed through
      the ClassAdapter and how somebody (e.g. the MicroContainer) goes about
      overriding the annotations. Clone and update?
      4) The use of arrays (although efficient when everything needs retrieving)
      is inefficient for (at least) the reflection based approach, where we only want
      to retrieve some information and leave markers about what can be retrieved
      later if required. Otherwise it is going to have create a reflection model of the
      entire class model upfront.
      5) All info classes should be serializable with serialVersionUIDs defined
      and implementation details like the cached hashCode transient.
      They should work even in circumstances where the class is not available
      by the remote user (which is why I'm not convinced my reflection based
      versions are correct)? This also speaks towards lazy loading rather
      than serializng a big tree of metadata.
      6) Need to implement toString() so we can see what is happening in
      TRACE logging.

        • 1. Re: INFO api - a critique
          bill.burke

          Caching INFO's is problematic(but solvable) because of hot-deployment. I've been through this exercise a few times with JBoss AOP's caching of Javassist structures.

          We should probably go back to a interface-based because of #4 as we me be lazy-loading typeinfo's with either reflect or javassist structures.

          • 2. Re: INFO api - a critique

            If they are cached against their associated classloader there should not be a problem.
            By this I mean the ClassLoader of the Class not the application (thread context classloader).
            e.g.

            WeakHashMap<ClassLoader, Map<className, WeakReference<ClassInfo>>
            


            The WeakReference is only required if the ClassInfo contains references back
            to the Class.
            It could also be a SoftReference if you are prepared to put up with
            recalculating this information if the GC discards it.

            • 3. Re: INFO api - a critique
              bill.burke

              This won't work. I tried it. ClassLoaders never seem to be garbage collected. This may be the fault of JBoss AOP as the Advisor holds a reference to the class which holds a reference to the ClassLoader. The Advisor is a static field on the Class.

              • 4. Re: INFO api - a critique
                bill.burke

                I also don't trust SoftReferences

                • 5. Re: INFO api - a critique

                  If you have:

                  public class MyClass
                  {
                  public static Class myClass = MyClass.class; // or the same thing indirectly
                  }

                  The GC should detect this is no longer referenceable
                  when you lose all references to the ClassLoader.

                  The only thing that would stop it getting gced would be if the advisor
                  is held elsewhere, e.g. inside the AspectManager.

                  More likely, something else is holding a reference to
                  the class,
                  an instance of the class,
                  a subsidary object that holds a reference to the class (method, field, etc)
                  something holding a reference to another static constant of the class
                  that is not getting undeployed/dereferenced.

                  • 6. Re: INFO api - a critique
                    bill.burke

                    Yeah, I tried going the WeakReference route at one time and it just didn't work. I may not have found all the reference leaks.

                    • 7. Re: INFO api - a critique

                      So do you want I should refactor it into
                      interfaces and an
                      abstraction implementation == what you have now
                      or are you going to do this?

                      We can do the other stuff later.

                      Don't lose my javadoc if you do it :-)

                      • 8. Re: INFO api - a critique
                        bill.burke

                        i'm not getting to it for awhile. I'm going to do some aspects for the aspect library.

                        • 9. Re: INFO api - a critique

                          Don't forget I need the ClassAdapter api otherwise I'm going to get
                          stuck very soon in terms of what I can implement/test.

                          I'm already stuck on the XML deployer with Alex changing the parser api on me,
                          although I can test the metadata changes without an XML version.

                          Have you seen this thread?
                          http://www.jboss.org/index.html?module=bb&op=viewtopic&t=60080

                          • 10. Re: INFO api - a critique
                            starksm64

                            The priority is supposed to be the framework the aspects plug into.

                            • 11. Re: INFO api - a critique

                              I'm doing the interface stuff.