8 Replies Latest reply on Sep 18, 2007 12:49 PM by starksm64

    Handling component references

    starksm64

      Its seems to me that we need an EjbResolverDeployer that consumes the nested EjbRefMetaData/EjbLocalRefMetaData/EjbRef/EjbLocalRef from the parsing deployers. This should replace the existing EjbUtil50/EjbUtil logic. It should be the source of the DependencyPolicy component used by the ejb3 Container abstraction. For that it would need to be a generic ResolverDeployer that handled all of the intra/inter deployment references.

        • 1. Re: Handling component references
          anil.saldhana

          http://jira.jboss.com/jira/browse/JBAS-4706

          Can this deployer incorporate it or make this issue generic enough?

          • 2. Re: Handling component references
            starksm64

            No, we need an EarIntegrationDeployer that has as inputs the various container metadata that needs ear level metadata merging into it.

            • 3. Re: Handling component references
              wolfc
              • 4. Re: Handling component references
                wolfc

                Andrew Lee Rubinger (new EJB 3 dev) wants to build a service locator. This depends on an interface registry. So he's going to create one in projects/ejb3 ejb3-registrar. I think the deployers also need such a registry to resolve interface dependencies. Do you concur with that dependency?
                Should we put it in projects/ejb3? Or in integration?

                I want to limit the functionality of the component to (scoped) interface resolution only. Not ejb-links. So you'll get something like:

                interface Registry {
                 JavaEEComponent getComponentByBusinessInterface(Class<?> businessInterface);
                }


                Currently for ejb-links I've taken an approach where a JavaEEComponent asks it's JavaEEModule to resolve an ejb-link (in a weird way, via createObjectName). This should become: getComponent.

                • 5. Re: Handling component references
                  starksm64

                  Its not clear to me that the JavaEEComponent is what the resolving deployer needs. It needs to transform the metadata for the references into dependecy metadata for the component metadata so that when the mc creates the component from the component metadata, its dependencies are injected, or bound into jndi, or whatever, as appropriate.

                  The JavaEEComponent is too close to the mc component as far as I can see. I think the general mistake we continue to make is thinking of wiring beans/components together when we need to be describing the wiring (metadata) and letting the mc do the wiring.

                  • 6. Re: Handling component references
                    starksm64

                    The first issue for a component registry is how to build the keys that describe a component. The most obvious starting point is that you have a structured name and indices based on the different types of references. For ejb-link style references, you have a name based on the deployment structure and ejb-name. For @EJB with a class, you have a name based on the deployment structure and business interface class.

                    A source based on an ejb-name:
                    {vfs-url-base}/{root-deployment-name}/{ejb-deployment-name}/ejb-name - points to the component metadata for the ejb-name component.

                    A source based on a business interface:
                    {vfs-url-base}/{root-deployment-name}/{ejb-deployment-name}/business-interface-class - points to the component metadata for the component providing the business-interface-class implementation.

                    Resolution of a reference then consists of trying various structured keys based on the referencing component structure and type of reference.

                    • 7. Re: Handling component references
                      wolfc

                      We need to figure out a way how we are going to process annotations.

                      In EJB 3 it works by parsing xml and then putting annotations on classes (though not consitent yet). This annotation meta data is in the JavaEEComponent (EJBContainer / InjectionContainer / JavaEEComponent -> ClassContainer). So we only know the full set of meta data once the container is initialized. And thus the container has become part of our meta data model.

                      Notes:
                      - aop.xml is used on meta data (this must remain)
                      - ejb3-interceptors-aop.xml is used both to augment and process meta data, which is a potential problem (might need a split)

                      • 8. Re: Handling component references
                        starksm64

                        The annotations have to be part of the metadata, either as attachments or merged into it.