1 2 Previous Next 24 Replies Latest reply on Feb 25, 2008 12:21 PM by Anil Saldanha

    ServiceMetaData has the most recent dependencies/attributes/

    Anil Saldanha Master

      The ServiceMetaData dependencies/attributes/annotations just store the most recent ones. So for example, if I have a service bean at the EAR level, then I would need to create dynamic dependencies to the individual web,ejb components within the Ear. So deployers working with the war,ejb-jar deployments would want to create a dependency for these components on to the parent service bean (at the ear level for example). I would like the service bean at the ear level to start only after all the sub service beans in the ear have started.

      I propose changes to be made such as:

      /**
       * Set the dependencies.
       *
       * @param dependencies the dependencies.
       */
       public void setDependencies(List<ServiceDependencyMetaData> dependencies)
       {
       if (dependencies == null)
       throw new IllegalArgumentException("Null dependencies");
       if(this.dependencies.size() == 0)
       this.dependencies = dependencies;
       else
       this.dependencies.addAll(dependencies);
       }
      


        • 1. Re: ServiceMetaData has the most recent dependencies/attribu
          Scott Stark Master

          Then there is no way to clear out or explicitly set the dependencies list. There should just be add/remove methods to support extending the dependencies.

          • 2. Re: ServiceMetaData has the most recent dependencies/attribu
            Anil Saldanha Master

            I was looking for something like addDependencies/addAttribute in the servicemetadata.

            • 4. Re: ServiceMetaData has the most recent dependencies/attribu
              Ales Justin Master

               

              "anil.saldhana@jboss.com" wrote:
              I was looking for something like addDependencies/addAttribute in the servicemetadata.

              I don't think you want to alter someone's metadata, if you cannot bring it back to original state as the user wanted.
              See all the MC posts about cloning the metadata after changing it to get some inner anonymous bean behavior.

              • 5. Re: ServiceMetaData has the most recent dependencies/attribu
                Scott Stark Master

                If you have multiple deployers producing an aggregate metadata view the metadata will have to change. The 'users' view is a function of where you start at in the deployer chain. If I'm passing in authoritative metadata and expect 'metadata' deployers to be bypassed, that is something we would need better support for. Essentially an isMetaDataComplete(Class) call.

                What's the bean example?

                • 6. Re: ServiceMetaData has the most recent dependencies/attribu
                  Scott Stark Master

                  Alternatively, we need to be making better use of the MetaDataRepository and scopes to create the layered views.

                  • 8. Re: ServiceMetaData has the most recent dependencies/attribu
                    Scott Stark Master

                    Its a similar discussion, and I'm not sure what the clone of the ClassLoaderMetaData is acomplishing. In the thread about unwrapping the bean fro the classloader element to add it as a dependency to the BeanMetaData is essentially what we are talking about here. One piece of metadata is introducing another dependency. In this case, to ServiceMetaData rather than a BeanMetaData.

                    The real issue is having deployers separated such that if we are running with a profile service that can override the metadata for a deployment with that from an admin tool (the open console), we don't overwrite that metadata. I can still see modifications being made to this for things like dependencies that are internal deployer details. These should not be showing up in the console as dependencies.

                    • 9. Re: ServiceMetaData has the most recent dependencies/attribu
                      Adrian Brock Master

                       

                      "scott.stark@jboss.org" wrote:
                      Its a similar discussion, and I'm not sure what the clone of the ClassLoaderMetaData is acomplishing.


                      It's not really the same thing.

                      EXPLANATION OF WHAT ALES IS TALKING ABOUT

                      In the BeanMetaData we play around with some things,

                      e.g. (using xml to illustrate)
                      <deployment>
                       <classloader/>
                       <bean1/>
                       <bean2/>
                      </deployment>
                      


                      effectively gets turned into

                       <bean1>
                       <classloader/>
                       <bean1>
                       <bean2>
                       <classloader/>
                       </bean2>
                      </deployment>
                      


                      There's a similar issue where a nested bean gets replaced with an inject:

                       <bean>
                       <property><bean name="A"/></property>
                       </bean>
                      


                      becomes

                       <bean name="A"/>
                       <bean>
                       <property><inject bean="A"/></property>
                       </bean>
                      


                      These changes end up being irreversable and so we don't really keep
                      what the user requested. They can't undeploy/modify/redeploy
                      because the metadata has changed in ways they probably didn't expect.

                      The ServiceMetaData doesn't really have the same problem
                      (although it might if we expand its features to be more like the POJO stuff).

                      SERVICEMETADATA AS IMPLEMENTATION DETAIL

                      What this thread is about is whether it is ok to modify the service metadata
                      created by other deployers to add dependencies.

                      This metadata is implementation detail and not seen by the user
                      who deals with the ejb or web metadata.

                      The obvious question is whether this use case is really an implementation detail
                      or something the user should manage.

                      If it is something the user should control (e.g. see the default clustering dependencies
                      deployer),
                      then the dependencies need adding to the ejb/web metadata along other explicit
                      dependencies from jboss{-web}.xml

                      If it is just an implementation that may change in the future then it is probably
                      better modifying the "hidden" ServiceMetaData.

                      TRANSITIVE DEPENDENCIES

                      In practice, this just shows that the EJB/WEB containers are not
                      creating their containers correctly and the respective service being
                      used is not exposed for IOC (or aspect dependency) properly.

                      If they were these kind of transitive dependencies;
                      ejb -> security -> security policy
                      ejb -> security aspect -> security policy injection into the aspect
                      would be would be automatic.

                      AFTERWORD

                      I've deliberately refrained from analysing/commenting on the
                      security deployers/integration (until now)
                      since they are fundamental wrong/broken
                      and need a complete rewrite which we don't have time to do before JBoss5. ;-(

                      I may find time to fix some bits when I sort out the ejb deployers,
                      e.g. one obvious one I saw somewhere was checking if it was an ejb/war
                      by looking for META-INF/ejb-jar.xml or WEB-INF/web.xml.

                      * These files aren't even mandatory anymore (annotations or programmatic deployment)

                      * Somebody could in principle turn another type of deployment into a war
                      by adding Web metadata to the attachments, e.g. exposing an ejb as a webservice
                      That's the whole point of the aspectised deployments.

                      There a few other brain deaths in there (which I saw in passing),
                      but like I said above I haven't seriously anaylzed it.

                      • 10. Re: ServiceMetaData has the most recent dependencies/attribu
                        Anil Saldanha Master

                        This week I have rewritten the Security Deployer (or more precisely to split into deployers based on the type of metadata). It is ready and I am checking it in tomorrow.

                        The classes look as follows:

                        public abstract class AbstractSecurityDeployer<T extends IdMetaData>
                        extends AbstractDeployer
                        {
                         public AbstractSecurityDeployer()
                         {
                         setStage(DeploymentStages.POST_CLASSLOADER);
                         ...
                         setOutput(ServiceMetaData.class);
                         ...
                         }
                        }
                        
                        public class EarSecurityDeployer extends AbstractSecurityDeployer<JBossAppMetaData>
                        {
                        }
                        
                        public class EjbSecurityDeployer
                        extends AbstractSecurityDeployer<JBossMetaData>
                        {}
                        
                        public class WarSecurityDeployer extends AbstractSecurityDeployer<JBossWebMetaData>
                        { }
                        


                        An issue that exists for addDependencies/addAttributes api addition to ServiceMetaData is that the internal data structures are Lists (rather than Sets) and hence there can be duplication of dependencies.

                        • 11. Re: ServiceMetaData has the most recent dependencies/attribu
                          Scott Stark Master

                           

                          "adrian@jboss.org" wrote:

                          In practice, this just shows that the EJB/WEB containers are not
                          creating their containers correctly and the respective service being
                          used is not exposed for IOC (or aspect dependency) properly.

                          If they were these kind of transitive dependencies;
                          ejb -> security -> security policy
                          ejb -> security aspect -> security policy injection into the aspect
                          would be would be automatic.

                          Creating a depends-with-optional-attribute is the equivalent ioc we supported with the mbean model. This requires adding a ServiceAttributeMetaData with a ServiceDependencyValueMetaData value. We still end up modifying the ServiceMetaData. The ServiceMetaData is an implementation detail of the ejb container as its the JBossMetaData that would have the management interface.


                          • 12. Re: ServiceMetaData has the most recent dependencies/attribu
                            Adrian Brock Master

                             

                            "anil.saldhana@jboss.com" wrote:

                            An issue that exists for addDependencies/addAttributes api addition to ServiceMetaData is that the internal data structures are Lists (rather than Sets) and hence there can be duplication of dependencies.


                            That is to preserve the legacy semantic that it always did the
                            "depends optional-attribute" and attribute processing directly from the
                            xml file in the order listed.
                            There could be some stupid mbean that expects the attributes in a particular order
                            rather than using create to handle the multiple attribute processing, e.g.

                            public void setAttribute1(String one) { this.one = one }
                            public void setAttribute2(String two)
                            {
                             doSomething(one, two);
                            }
                            


                            Anyway it's not difficult for a new addDepednency() method to check
                            whether the list already contains the value trying to be inserted.

                            • 13. Re: ServiceMetaData has the most recent dependencies/attribu
                              Adrian Brock Master

                               

                              "scott.stark@jboss.org" wrote:

                              Creating a depends-with-optional-attribute is the equivalent ioc we supported with the mbean model. This requires adding a ServiceAttributeMetaData with a ServiceDependencyValueMetaData value.


                              The "depends optional attribute" only exists in the xml, it doesn't exist
                              in the ServiceMetaData model, so it's not the same as the examples I listed
                              for the POJO stuff.

                              1 2 Previous Next