8 Replies Latest reply on Jan 27, 2005 1:27 PM by adrian.brock

    Container abstraction

      I have factored out the container implementation from kernel into a new
      subproject "container" in jboss-head.

      This is basically the prototype container I was using in the kernel module
      with the joinpoint abstraction that uses the BeanInfo/ConstructorInfo/etc.

        • 1. Container

          Roadmap for the Container:

          We want to define/agree the spi

          The implementation/plugins are just what I had for for my prototype and are
          included for reference.

          1) Replace the container abstraction with the jboss-aop abstraction
          which is more feature rich.
          This is not the aop implementation which will remain in the jboss-aop.
          2) Keep the BeanInfo abstraction as this is used by the microcontainer
          (remember not all beans will have a container)
          3) Decide how much of my current prototype of a join point model is relevent
          and whether it is correct
          4) Produce JIRA tasks once it is agreed or JFDI

          Keep in mind that the abstraction should be flexible enough to be
          implemented a proxy container, if the aop container cannot be run in a certain environment.
          So actually the requirement is that a container should be available in all environments,
          J2ME, applet, A.N.Other app server etc.
          Running with the more limited proxy container may mean some features cannot be
          implemented, e.g. field interception.

          • 2. Re: Container abstraction
            bill.burke

            FYI, JBoss AOP can be a proxy-container. I do this with EJB3.

            • 3. Bean Info

              Roadmap for Bean Info:

              The purpose of the BeanInfo is to provide the same features as the java.beans
              package, except for the same reason that JMX introduced its own metadata
              java.beans has a fundamental problem with its dependency on AWT in some places.

              Hence it is not available in all environments.

              1) Agree the BeanInfo abstraction
              2) Decide whether javassist would be a better/alternate implementation (does it work
              in all environments)
              3) Agree missing features like the ability to define java.beans has to describe a
              bean from a descriptor class
              4) WRT (3), annotations would seam to me to be a better mechanism
              5) Include annotations in the BeanInfo abstraction
              6) Should we add support for redefining requests like constructor -> factory,
              e.g. the microcontainer thinks it is doing new Bean() but it is actually doing
              BeanFactory.createBean() or as these better left as container aspects?

              Current Known Issues:
              1) The introspection implementation is very agressive in that it will traverse the
              all the class references when asked for information. A more lazy implementation
              is required.
              2) How to avoid this information using too much memory - e.g. are descriptions
              necessary, if so can they be lazy loaded using I18N when required?

              • 4. Re: Container abstraction

                 

                "bill.burke@jboss.com" wrote:
                FYI, JBoss AOP can be a proxy-container. I do this with EJB3.


                Yes, but does it work in all environments and what is the footprint with
                jboss-aop using javassist, trove, etc.

                If you can show me jboss-aop's proxy container working inside
                1) j2me,
                2) inside an ejb/web container of another appserver with a security manager installed
                3) inside an applet
                then we have no need to write an old fashioned proxy container like the prototype
                BeanContainer

                • 5. Re: Container abstraction
                  bill.burke

                  We're supposed to be unifying things here. To do proxies, you need dynamic class creation. period. If you're just using java.lang.reflect.Proxy, you also need reflection as well.

                  Please state your concerns with:

                  1) footprint. I only use a few classes from jboss-common. Trove can be removed. Oswego cannot unless we switch to JDK5 as a base. QDox is just for the annotation compiler. Javassist cannot be removed as it is used to dynamically create classes. If classes cannot be dynamically created, then java reflection is needed. You'll have the same issue

                  2) security managers. Do you mean a security manager that disallows reflection or setAccessible(true)?

                  Please, let's not put any effort into writing a competing Interceptor model. We have enough to do as it is.

                  • 6. Re: Container abstraction

                    We are unifying the spi not the implementation. An interceptor doesn't care wether
                    it woven in through byte code manipulation or behind a proxy.

                    1a) My question was what is the footprint. My concern is that the size of the jars
                    if we are going to run on a system with limited space.
                    Most of jboss-common and concurrent are not used. These jars could
                    be very easily trimmed for a limited environment.

                    1b) java.lang.reflect.Proxy works in those environments. Yes you have to use
                    reflection (which means some features will not be available as I said).

                    2) I mean where you don't have control of the security policy.

                    These environments limit you to performing operations like classloading and reflection on
                    co-deployed classes (same classloader - or a child classloader if you are allowed to
                    create such a thing).
                    Certainly things like modifying accessibility or byte code manipulation won't be allowed.

                    • 7. Re: Container abstraction

                      My real concern is the unification.

                      The argument about the proxy is best resolved through the "suck it and see" approach.

                      • 8. Re: Container abstraction

                        I've refactored the core part of the bean configurator into the container module
                        so you can see how the microcontainer is using the BeanInfo/JoinPoint model.

                        See org.jboss.beans.info.config