1 2 Previous Next 16 Replies Latest reply on Jan 10, 2005 4:52 PM by Adrian Brock

    Configuring a container for POJOs

    Adrian Brock Master

      So I've committed the intial version of the POJO container.
      It is still a prototype (with some horrible hacky code in parts) but it does the job
      for the initial M1 release.

      You can now configure a set of *single* set interceptors for a POJO
      and it will put a proxy container in front of it. Obviously you need an interface
      to make this work (this constraint will disappear when we integrate JBoss/AOP).

      The key part is that the interceptors are configurable just like other beans
      so they can take part in the dependency/configuration mechanism.

      Here's an example from one of my tests. The key part here is that the interceptor
      has a constructor that must wait for another bean to be created so the bean
      it intercepts is also delayed.

      <?xml version="1.0" encoding="UTF-8"?>
      
      <deployment>
       <beans>
      
       <!-- The intercepted bean -->
      
       <bean name="SimpleBean1"
       bean="org.jboss.test.kernel.xml.support.SimpleBeanImpl">
       <interceptors>
       <interceptor bean="org.jboss.test.kernel.xml.support.ConstructorDependencyInterceptor">
       <constructorParams>
      
       <!-- Here I make the interceptor wait for SimpleBean2 -->
       <parameter type="org.jboss.test.kernel.xml.support.SimpleBean"><dependency value="SimpleBean2"/></parameter>
       </constructorParams>
       </interceptor>
       </interceptors>
       </bean>
      
       <!-- The bean the interceptor needs -->
      
       <bean name="SimpleBean2"
       bean="org.jboss.test.kernel.xml.support.SimpleBeanImpl">
       <constructorParams>
       <parameter type="java.lang.String"><value>ConstructorDependencyInterceptor</value></parameter>
       </constructorParams>
       </bean>
       </beans>
      </deployment>
      




        • 1. Re: DataSources Don't Belong in java:/ Space
          Adrian Brock Master

          The distinction made, as I understand it, is that the "java:/" is not available external to the JVM in which the JNDI schema is created, as opposed to "java:". That is; "java:/myObject" is not the same as "java:myObject". And there are security reasons for which you may not want objects accessible from an external JVM.

          The issue with regards to access to the datasource from an external JVM in JBoss is ultimately a physical restriction with connections rather than an arbitrary choice by the JBoss developers. The DataSource is just a connection factory.

          The physical connection is manifested between the JVM in which the DataSource is instantiated, and the actual datasource (database). Passing the connection handle (Connection) to an external environment would be of little use. Now the JBoss developers might produce a proxy implementation for connections manufactured from the DataSource but the cost benefits of a connection pool are diminished by the cost of establishing a separate connection between the external JVM and the JVM in which the real datasource connection resides.

          Secondly, were JBoss developers to develop a proxy implementation for the connection pool, there is no security restriction inherent in the Connection manufacture from a DataSource such that exposing the DataSource to external access opens the datasource to possible malicious attack from unauthorised parties.

          MHO.

          • 2. Re: Configuring a container for POJOs
            Adrian Brock Master

            The key feature is that you don't need to add dependencies to the bean itself.
            You can define the dependencies on the interceptor.

            When we have true aspects, you will be able to automagically get dependencies.

            e.g. If you add the transaction demarcation aspect it will *know* it needs to wait for the
            transaction manager to be deployed.

            Just to reiterate. The dependencies are associated with the aspect not the bean
            meaning you only define it once.

            • 3. Re: Configuring a container for POJOs
              Adrian Brock Master

              So the container construction code is a bit hacky.

              I'm actually thinking that this config should be more long winded and more
              explicit but giving you more control.
              i.e. you construct the whole container using the metadata.

              In more detail, currently we have the implicit container when you configure an
              interceptor:

               <bean name="SimpleBean1"
               bean="org.jboss.test.SimpleBeanImpl">
               <interceptors>
               <interceptor bean="org.jboss.test.AnInterceptor">
               </interceptor>
               </interceptors>
               </bean>
              


              But how much better would it be if you had more control...

              <bean name="SimpleBean1"
               bean="org.jboss.proxy.Proxy">
               <attribute name="interfaces">org.jboss.test.SimpleBean</attribute>
               <attribute name="handler">
               <bean bean="org.jboss.container.bean.BeanContainer">
               <attribute name="Interceptors">
               <bean bean="org.jboss.test.AnInterceptor"/>
               <bean bean="org.jboss.test.AnotherInterceptor"/>
               </attribute>
               <attribute name="Target">
               <bean bean="org.jboss.test.SimpleBeanImpl"/>
               </attribute>
               </bean>
               </attribute>
              </bean>
              


              This is great for internal work where you could set an attribute on the Target
              at deployment time, but not have the attribute exposed to the user
              at runtime via the interface.

              Of course there would need to a simpler xml exposed to the users
              for the most common use cases which would "transform" into this more long winded
              but more flexible form for internal use or if the user wants more control.

              • 4. Re: Configuring a container for POJOs
                Bill Burke Master

                A couple of things. I think there are 3 types of containers:

                1. The bean itself, with no proxy in front
                2. A container per bean-type. (i.e. EJB)
                3. A container per bean.

                JBoss AOP is currently a container per bean-type. I don't think it would be much work to have a container per bean.

                BTW, I think you are looking at this in the wrong way. Interceptors/Aspects should not be defined as part of the bean, but rather defined outside the bean, and bound in. (like in JBoss AOP). Your examples above are the wrong approach. THe reason being is that you want interceptors defined for different scopes. You may want an interceptor created as a singleton, per bean-type(per class), per instance, per joinpoint, per class per joinpoint, but have one configuration for it.

                JBoss AOP aspects/interceptors are created via a pluggable factory. This factory's api is createPerVM, createPerInstance, createPerClass, etc...

                Bill

                • 5. Re: Configuring a container for POJOs
                  Adrian Brock Master

                  We actually agree, but our definitions are different.

                  You will note in my example (it is pseudo code) the interceptors are external
                  to the bean (target).

                  What I want to get across is that the container (advisor) is also a bean
                  and should be constructed through dependency injection so it can take advantage
                  of microcontainer dependency processing.

                  • 6. Re: Configuring a container for POJOs
                    Adrian Brock Master

                    Let's take your three types of container (again this is pseudo code):

                    1) No container

                    <bean name="SimpleBean1" bean="org.jboss.test.SimpleBeanImpl"/>
                    


                    2) Container per bean type
                    <bean name="SimpleBeanInterceptors" bean="org.jboss.container.bean.BeanList">
                     <bean bean="org.jboss.test.AnInterceptor"/>
                     <bean bean="org.jboss.test.AnotherInterceptor"/>
                    </bean>
                    <bean name="SimpleBean1"
                     bean="org.jboss.proxy.Proxy">
                     <attribute name="interfaces">org.jboss.test.SimpleBean</attribute>
                     <attribute name="handler">
                     <bean bean="org.jboss.container.bean.BeanContainer">
                     <attribute name="Interceptors">
                     <depends name="SimpleBeanInterceptors"/>
                     </attribute>
                     <attribute name="Target">
                     <bean bean="org.jboss.test.SimpleBeanImpl"/>
                     </attribute>
                     </bean>
                     </attribute>
                    </bean>
                    


                    3) Container per bean
                    <bean name="SimpleBean1"
                     bean="org.jboss.proxy.Proxy">
                     <attribute name="interfaces">org.jboss.test.SimpleBean</attribute>
                     <attribute name="handler">
                     <bean bean="org.jboss.container.bean.BeanContainer">
                     <attribute name="Interceptors">
                     <bean bean="org.jboss.test.AnInterceptor"/>
                     <bean bean="org.jboss.test.AnotherInterceptor"/>
                     </attribute>
                     <attribute name="Target">
                     <bean bean="org.jboss.test.SimpleBeanImpl"/>
                     </attribute>
                     </bean>
                     </attribute>
                    </bean>
                    


                    • 7. Re: Configuring a container for POJOs
                      Adrian Brock Master

                      What I'm trying to get across is that the containers need to be constructed using
                      the microcontainer dependency process. There are dependencies like classloading
                      or jndi binding that a simple factory mechanism cannot hope to understand/implement.


                      • 8. Re: Configuring a container for POJOs
                        Adrian Brock Master

                        One thing that is on my roadmap to implement is that the

                        <bean/>

                        can specify a factory not just a constructor.

                        This is needed for more complex POJOs that don't follow the javabean pattern
                        and will also give more control on how objects are constructed.
                        Of course the same thing can also be achieved with constructor aspects
                        but this would class wide which might not be what you want.

                        • 9. Re: Configuring a container for POJOs
                          Bill Burke Master

                          I REALLY don't like the generic syntax, but understand it is needed to be able to snap on any type of handler, etc...

                          BTW, I think your example for per bean type is wrong. It should be:

                          <bean name="SimpleBean1"
                           bean="org.jboss.proxy.Proxy">
                           <attribute name="interfaces">org.jboss.test.SimpleBean</attribute>
                           <attribute name="handler">
                           <depends name="container:name=somecontainer"/>
                           </attribute>
                          </bean>
                          





                          • 10. Re: Configuring a container for POJOs
                            Adrian Brock Master

                             


                            BTW, I think your example for per bean type is wrong. It should be:


                            Yes if we are talking about something like an EJB container that has a pooling
                            interceptor or a JMX singleton container.

                            But, for POJO level you will need a different handler instance to identify the instance
                            to the outside world even though they share interceptors.
                            You will notice I have Target as an attribute of the handler rather than the proxy.

                            I believe exposing the full the definition of the container this way enables
                            more configuration choices for the "user".

                            • 11. Re: Configuring a container for POJOs
                              Scott Stark Master

                              Alexey has added support to the jbossxb layer so that you can specify the factory to use for a given namespace. See the following thread for an example:

                              http://www.jboss.org/index.html?module=bb&op=viewtopic&t=57871

                              We need to get the xml processing unified in the pojo server.

                              • 12. Re: Configuring a container for POJOs
                                Adrian Brock Master

                                Under no circumstances should the micro container require XML.

                                XML is one option for configuring the server. All the XML parsing should do
                                is construct kernel metadata objects. It should not be attempting to construct the
                                real objects as dependencies will not be satisfied at this stage, e.g. classloading
                                dependencies.

                                • 13. Re: Configuring a container for POJOs
                                  Scott Stark Master

                                  XML is not required, but where it shows up it should be processed consistently. The most flexible mechanism we have today is the jbossxb framework.

                                  • 14. Re: Configuring a container for POJOs
                                    Ivelin Ivanov Expert

                                    just nit-picking here on the syntax:

                                    <bean name="XYZ" bean="org.something.ClassName">
                                    


                                    1. What will be the naming convention for XYZ? Bill seems to be leaning towards JMX. Is each Bean going to show as an MBean if the JMX wrapper around the microcontainer is deployed?

                                    2. Is the attribute bean=".." always going to refer to a class name? If so, why not call it "class"? class="..."



                                    1 2 Previous Next