1 2 Previous Next 21 Replies Latest reply on Jun 22, 2006 11:01 AM by Adrian Brock

    Repository prototype discussion

    Scott Stark Master

      The current prototype source and class diagram has been placed here:
      http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5RepositoryClasses

      until there is a location for the source in cvs.


      Issues/questions.

      - The basic MetaDataCombiner implementations only deal with existence of a metadata value at their level. They don't know enough to actually be able to combine metadata from levels as in the case of an aspect providing a partial override to
      - Querying across dimensions is not implemented. Need to figure how what types of queries are needed along with how to index/store the data to allow for this query case.
      - The MetaDataLoader notion needs to be fleshed out. It could be used to lazily load data at the various levels including admin metadata from persistent stores.
      - Integration into the MC. The metadata repository fits into the current kernel spis as an implementation detail (plugin) of the bean/dependency layer. Its also an independent service that can be used for exchange of metadata independent of the kernel concerns. I don't really see that the metadata repository need be a low level service/spi of the kernel. Are there other views on this?

        • 1. Re: Repository prototype discussion
          Adrian Brock Master

           

          "scott.stark@jboss.org" wrote:

          - The MetaDataLoader notion needs to be fleshed out. It could be used to lazily load data at the various levels including admin metadata from persistent stores.


          I only see this as useful for other environments? I prefer push to pull.
          Obviously outside JBossAS we will need an adapter to get at any of the host's
          native config. But the adapter itself can be pushed and do the details lazy?


          - Integration into the MC. The metadata repository fits into the current kernel spis as an implementation detail (plugin) of the bean/dependency layer. Its also an independent service that can be used for exchange of metadata independent of the kernel concerns. I don't really see that the metadata repository need be a low level service/spi of the kernel. Are there other views on this?


          I agree. It is not something that needs to be in the core kernel, at least from my point of view.
          I only *need* it for the "decorators" which can be implemented outside
          the basic bootstrap and dependency mechanism.

          Bill may disagree since this fits more into the invocation layer and AOP.

          We still need to finalize how that plugs into the MC.
          aspect manager(domain) <- class adapter/bean info -> kernel controller
          was our original solution in Boston.

          • 2. Re: Repository prototype discussion
            Adrian Brock Master

             

            "scott.stark@jboss.org" wrote:

            Issues/questions.

            - The basic MetaDataCombiner implementations only deal with existence of a metadata value at their level. They don't know enough to actually be able to combine metadata from levels as in the case of an aspect providing a partial override to



            I think there are some previous threads will Bill discussing these issues
            in the AOP forum. You'll probably have to go back about 18 months to 2 years? :-)


            • 3. Re: Repository prototype discussion
              Scott Stark Master

               

              "adrian@jboss.org" wrote:

              I think there are some previous threads will Bill discussing these issues
              in the AOP forum. You'll probably have to go back about 18 months to 2 years? :-)


              Ok, I'll review that. I did remove the Invocation as the main entry point into the metadata layer, but it will be one of the main users.

              • 4. Re: Repository prototype discussion
                Adrian Brock Master

                Hi Scott,

                What is the status of this? This was the one part of my discussions
                with Kabir where I couldn't give him clear answers.

                I envision add the following to InvocationBase.
                Which will delegate to something set up by the advisor to access the metadata
                in the current context.

                public class InvocationBase
                {
                 private MetaDataContext context;
                
                 public <A extends Annotation> getAnnotation(Class<A> annotationClass)
                 {
                 // Pass the context (instance), joinpoint and the requested metadata type
                 return getMetaDataRepository().getAnnotation(context, this, annotationClass);
                 }
                }
                


                This differentiates this typed configuration from untyped attachments
                in the SimpleMetaData like transaction, user, credential, etc.

                • 5. Re: Repository prototype discussion
                  Adrian Brock Master

                  We also discussed whether the MetaData repository context
                  should be linked to different AOP Domains to separate the configuration.

                  Kabir was unclear on this because Domains are being used for lots of different
                  things at the moment in AOP.

                  • 6. Re: Repository prototype discussion
                    Scott Stark Master

                    The status is that the prototype is still sitting in my workspace because we never decided on where to put it. Let's just define its cvs module so I can check it in.

                    What you show is how I envisioned this fitting into the call stack as well.

                    • 7. Re: Repository prototype discussion
                      Adrian Brock Master

                      I think, you can put it in the "container" module for now.

                      It should tie into the ClassInfo repository of annotations when we make the
                      version that uses javassist for java1.4/5 compatibilty.

                      • 8. Re: Repository prototype discussion
                        Scott Stark Master

                        Its been added to the container module under the org.jboss.repository package.

                        • 10. Re: Repository prototype discussion
                          Viet Master

                          we intend to base the future JBoss Portal 3.0 on this framework (and microcontainer of course). I'll attend the webinar of next wed.

                          • 11. Re: Repository prototype discussion
                            Scott Stark Master

                            Consider how the repository fits into this example deployment.

                            <deployment>
                             <bean name=?BeanCache? class=?com.titan.MyCache?>
                             <depends>TransactionManager</depends>
                             <create method=?create?>
                             <inject bean=?DefaultPartition?/>
                             </property
                             </bean>
                            
                             <bean name=?DefaultPartition? class=?org.jboss.clustering.ClusterPartition>
                             <property name=?MulticastAddress?>${jboss.server.udp.address}</property>
                             </bean>
                            </deployment>
                            


                            The jboss.server.udp.address reference could be viewed as a reference to the repository starting with the SERVER_LEVEL metadata. At one point I think the jbossxb layer was replacing these values, but it probably should not, or at least be a pluggable aspect taken over the by repository when avaialble.

                            Does this make sense as a starting point for integrating the repository?


                            • 12. Re: Repository prototype discussion
                              Adrian Brock Master

                              I'd rather see these in separate "policy" deployments.
                              Whether the policy icomes from a
                              * javabean
                              * system property
                              * a reference into the repository
                              will be an implementation detail.
                              But the main point is that we are not mixing user configurable
                              options with the implementation details of the service.

                              <!-- What the developer codes -->
                              <deployment>
                              ...
                              <bean name="DefaultPartition" class="org.jboss.clustering.ClusterPartition">
                               <property name="MulticastAddress"><policy name="Clustering" item="udp.address"/></property>
                              </bean>
                              
                              <!-- WHAT THE USER SEES -->
                              <deployment>
                               <policy name="Clustering">
                              
                               // Plain value (1)
                               <item name="udp.address">228.1.2.3</item>
                              
                               // Plain value with system property override (2)
                               <item name="udp.address">{228.1.2.3:jboss.server.udp.address}</item>
                              
                               // Some other POJO (3)
                               <item name="udp.address"><inject bean="MyConfig" property="udpAddress"/></item>
                              
                               // The repository (4)
                               <item name="udp.address"><repository level="Server" name="jboss.server.udp.address"/></item>
                               </policy>
                              </deployment>
                              


                              (1) and (2) are really the same thing
                              (3) and (4) are also really the same thing if you think of it as
                               <item name="udp.address"><inject bean="ServerLevelRepository" property="jboss.server.udp.address"/></item>
                              


                              This is basically just the same as the MC's bean handling.
                              The reason for having a different name "policy" is because I would like to be
                              able to layer them (like the ejb container config):

                              <policy name="Clustering" extends="ClusteringFactorySettings">
                               <!-- Place your overrides here -->
                              </policy>
                              


                              Such that a user doesn't need to touch our default config.

                              • 13. Re: Repository prototype discussion
                                Adrian Brock Master

                                 

                                "adrian@jboss.org" wrote:

                                This is basically just the same as the MC's bean handling.
                                The reason for having a different name "policy" is because I would like to be
                                able to layer them (like the ejb container config):


                                And except in the plain value case, the policy item doesn't store anything
                                except the strategy to get the value.

                                • 14. Re: Repository prototype discussion
                                  Scott Stark Master

                                  my next question was going to be how does the profile service fit into this picture? In the current mc examples we are still mixing bean declaration and configuration. The policy seems like an indirection layer that could be used:

                                  <deployment>
                                   // Externalized profile (0)
                                   <policy name="Clustering" profile="theProfileID">
                                  
                                   // Plain value (1)
                                   <item name="udp.address">228.1.2.3</item>
                                  
                                   // Plain value with system property override (2)
                                   <item name="udp.address">{228.1.2.3:jboss.server.udp.address}</item>
                                  
                                   // Some other POJO (3)
                                   <item name="udp.address"><inject bean="MyConfig" property="udpAddress"/></item>
                                  
                                   // The repository (4)
                                   <item name="udp.address"><repository level="Server" name="jboss.server.udp.address"/></item>
                                   </policy>
                                  



                                  1 2 Previous Next