1 2 Previous Next 22 Replies Latest reply on Aug 18, 2008 5:54 AM by Ales Justin

    JBMICROCONT-330 - Preconfigured MDR and scopes

    Adrian Brock Master

      I've got this working.

      I had to do some refactoring since the initialisation of the hierarchical
      metadata was in the wrong place. It was in BasicKernelMetaDataRepository
      while the removal was in AbstractScopeInfo.

      I've moved it AbstractScopeInfo so it is symmetrical and we know whether
      we created it.

      It's brought up two issues which I'll raise bug reports for.

      1) ScopingOverridingTestCase

      This is failing because of the problem I suspected when taling to Kabir
      about the issue that led to finding JBMICROCONT-330
      i.e. a scoped controller context is sharing the same metadata
      as one that should not be scoped.

      2) We are not removing annotations from the mutable metadata when
      we undeploy. I'm going to leave this failing in MutableMetaDataTestCase

      Once these have been fixed, the kernel pom needs reverting so it
      fails when there is a testfailure.

        • 1. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
          Adrian Brock Master

          I also fixed up the api where it was assuming MemoryMetaDataLoader
          when populating the annotations from the BeanMetaData.

          It now uses the more correct MutableMetaDataLoader and ComponentMetaDataLoader
          where relevant.

          • 3. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
            Ales Justin Master

             

            "adrian@jboss.org" wrote:

            1) ScopingOverridingTestCase

            This is failing because of the problem I suspected when taling to Kabir
            about the issue that led to finding JBMICROCONT-330
            i.e. a scoped controller context is sharing the same metadata
            as one that should not be scoped.

            This is passing for me in IDE.
            Due to luck/random behavior?

            • 4. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
              Ales Justin Master

              This move

              projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java
              ===================================================================
              --- projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java 2008-08-08 14:37:38 UTC (rev 76832)
              +++ projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java 2008-08-08 15:11:04 UTC (rev 76833)
              @@ -21,20 +21,13 @@
               */
              ...
              
              -
              - /**
              - * Create metadata context.
              - *
              - * @param retrievals the retrievals
              - * @return new metadata context instance
              - */
              - protected MetaDataContext createMetaDataContext(List<MetaDataRetrieval> retrievals)
              - {
              - return new AbstractMetaDataContext(null, retrievals);
              - }
               }
              

              made the following classes:
              - CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
              - PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
              - LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
              - TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
              useless, since they don't serve the caching override function anymore.

              What's the best way to port this?
              Overriding this in some ControllerContext impl doesn't seem like a good fit.

              • 5. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                Ales Justin Master

                 

                "alesj" wrote:

                Overriding this in some ControllerContext impl doesn't seem like a good fit.

                e.g.
                 protected void initKernelScopeInfo()
                 {
                 String className = null;
                 Object target = getTarget();
                 if (target != null)
                 className = target.getClass().getName();
                 BeanMetaData bmd = getBeanMetaData();
                 if (bmd != null)
                 {
                 String bean = bmd.getBean();
                 if (bean != null)
                 className = bean;
                 }
                 setScopeInfo(createScopeInfo(className, bmd));
                 }
                
                 protected ScopeInfo createScopeInfo(String className, BeanMetaData bmd)
                 {
                 return new KernelScopeInfo(getName(), className, bmd);
                 }
                

                Where you could push in your ControllerContext impl,
                which would override this createScopeInfo method,
                providing ScopeInfo that again has overridden createMetaDataContext method.

                Yuck. :-)

                • 6. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                  Ales Justin Master

                   

                  "alesj" wrote:
                  This is passing for me in IDE.
                  Due to luck/random behavior?

                  OK, got the failure:
                  *** DEPLOYMENTS IN ERROR: Name -> Error
                  simple -> java.lang.IllegalStateException: Unable to register context name=simple state=Not Installed, name already exists: simple
                  

                  Should be able to fix it now. ;-)

                  • 7. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                    Adrian Brock Master

                     

                    "alesj" wrote:
                    This move
                    - protected MetaDataContext createMetaDataContext(List<MetaDataRetrieval> retrievals)
                    made the following classes:
                    - CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
                    - PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
                    - LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
                    - TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
                    useless, since they don't serve the caching override function anymore.


                    You should add @Override so it doesn't compile if somebody refactors
                    the callback.

                    Why didn't I see any failing tests? I must be blind?


                    What's the best way to port this?
                    Overriding this in some ControllerContext impl doesn't seem like a good fit.


                    I don't think there is a one best way. The simplest would be to allow
                    a setMetaDataContextFactory() on the ScopeInfo, it could be set
                    by the BasicKernelMDR if you want.

                    If you wanted to be "clever", you could make it a piece of metadata itself. :-)
                    i.e. which MetaDataContextFactory to use by looking through the retrievals
                    before you construct it. That would allow application and system wide construction,
                    but how it gets populated is a different question.

                    NOTE: The deployers also do this, see DefaultScopeBuilder,
                    although there you can override it by adding a ScopeBuilder attachment
                    to your deployment.

                    • 8. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                      Adrian Brock Master

                       

                      "adrian@jboss.org" wrote:

                      What's the best way to port this?
                      Overriding this in some ControllerContext impl doesn't seem like a good fit.


                      A simple way to make it backwards compatible would be to make KernelScopeInfo
                      delegate back to the BasicKernelMDR.

                      i.e. change AbstractScopeInfo::createMetaDataContext to pass in the ControllerContext
                      then in KernelScopeInfo do
                      context -> controller -> kernel -> BasicKernelMDR::createMetaDataContext

                      Phew! :-)

                      • 9. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                        Adrian Brock Master

                         

                        "adrian@jboss.org" wrote:
                        "adrian@jboss.org" wrote:

                        What's the best way to port this?
                        Overriding this in some ControllerContext impl doesn't seem like a good fit.


                        A simple way to make it backwards compatible would be to make KernelScopeInfo
                        delegate back to the BasicKernelMDR.

                        i.e. change AbstractScopeInfo::createMetaDataContext to pass in the ControllerContext
                        then in KernelScopeInfo do
                        context -> controller -> kernel -> BasicKernelMDR::createMetaDataContext

                        Phew! :-)


                        I've done that boss. ;-)

                        • 10. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                          Ales Justin Master

                           

                          "adrian@jboss.org" wrote:

                          I've done that boss. ;-)

                          Nice work, my apprentice. :-)

                          I only added a small change,
                          by the API in AbstractScopeInfo::initMetaDataRetrieval,
                          it's enough to get MetaDataRetrieval, no need for full MetaDataContext.

                          So, I've changed the methods involved
                          to return/use just MetaDataRetrieval.

                          The actual impl will still be our AbstractMetaDataContext,
                          but I'm always in favor for minimal interface when applicable.

                          • 11. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                            Emanuel Muckenhuber Master

                            This is really Adrian...

                            With reference to your apprentice, in Yoda speak:

                            interface BasicKernelMDR isn't, therefore bloat it is not :-)

                            • 12. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                              Ales Justin Master

                               

                              "adrian@jboss.org" wrote:

                              1) ScopingOverridingTestCase

                              This is failing because of the problem I suspected when taling to Kabir
                              about the issue that led to finding JBMICROCONT-330
                              i.e. a scoped controller context is sharing the same metadata
                              as one that should not be scoped.

                              How did this ever worked? :-)
                              Or what changed that 'broke' this?

                              I remember adding WORK scope to handle this duplicate issue.
                              Looking at the code, I don't see how that helped,
                              since it's the other two scopes that are 'interesting'; CLASS and INSTANCE,
                              which were always the same.

                              I don't see a good way to solve this,
                              since although scoped, beans should still share the same metadata,
                              if the key matches, e.g. CLASS scope on the same class.

                              Perhaps we should change what value we keep at INSTANCE scope.
                              e.g. the stuff we already discussed, adding ID to ControllerContext,
                              which is unique, and pass that as INSTANCE value.

                              • 13. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                                Ales Justin Master

                                 

                                "alesj" wrote:

                                Perhaps we should change what value we keep at INSTANCE scope.
                                e.g. the stuff we already discussed, adding ID to ControllerContext,
                                which is unique, and pass that as INSTANCE value.

                                Changing INSTANCE value to
                                 scopeKey.addScope(CommonLevels.INSTANCE, name.toString() + hashCode());
                                 if (className != null)
                                 scopeKey.addScope(CommonLevels.CLASS, className);
                                 setScope(scopeKey);
                                 setMutableScope(new ScopeKey(CommonLevels.INSTANCE, name.toString() + hashCode()));
                                

                                Only breaks tests that explicitly set MetaData to repository via bean name.
                                All other tests pass.

                                Perhaps completely random/unique INSTANCE value isn't good solution,
                                since then you cannot do what we do in MutableMetaDataTestCase,
                                setting predetermined metadata to an instance.

                                But then again, getting some ID in advance, applying predetermined metadata,
                                and the somehow passing this ID to ControllerContext,
                                is again the same problem as we already have - how to uniquely map ID to class and bean name.

                                • 14. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
                                  Adrian Brock Master

                                  You need to change the name of the INSTANCE scope for scoped beans
                                  to include something that identifies the scoped controller, e.g.

                                  new ScopeKey(CommonLevels.INSTANCE, scopedController.getScopeID() + "/" name.toString());
                                  


                                  It should be something predictable - not hashCode().

                                  You also need to be able to do this ahead of time in the deployers
                                  so people can populate the instance scope before controller context exists.

                                  1 2 Previous Next