1 2 Previous Next 24 Replies Latest reply on Feb 25, 2008 12:21 PM by anil.saldhana

    ServiceMetaData has the most recent dependencies/attributes/

    anil.saldhana

      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
          starksm64

          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.saldhana

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

            • 3. Re: ServiceMetaData has the most recent dependencies/attribu
              starksm64

              Yes, let's add those.

              • 4. Re: ServiceMetaData has the most recent dependencies/attribu
                alesj

                 

                "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
                  starksm64

                  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
                    starksm64

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

                    • 7. Re: ServiceMetaData has the most recent dependencies/attribu
                      alesj
                      • 8. Re: ServiceMetaData has the most recent dependencies/attribu
                        starksm64

                        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

                           

                          "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.saldhana

                            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
                              starksm64

                               

                              "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

                                 

                                "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

                                   

                                  "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.

                                  • 14. Re: ServiceMetaData has the most recent dependencies/attribu
                                    anil.saldhana
                                    1 2 Previous Next