5 Replies Latest reply on Apr 1, 2008 6:07 PM by Scott Stark

    Resolver plugins

    Scott Stark Master

      Classes like DeploymentPersistenceUnitResolver, MessageDestinationResolver, EjbModuleEjbResolver need to be plugins that can be specified at the deployer level so the logic can be defined by the jbossas integration layer.

        • 2. Re: Resolver plugins
          Scott Stark Master

          I guess the spi should live in jboss-ejb3-ext-api under org.jboss.ejb3.resolver package.

          The Ejb3Deployment needs to be updated to allow injection of the spi for the EjbModuleEjbResolver, EjbModulePersistenceUnitResolver and MessageDestinationResolver.

          These will be the default implementations of the spis initialized in the ctor with the expectation that the integration code will override as needed.

          • 3. Re: Resolver plugins
            Carlo de Wolf Master

            jboss-ejb3-ext-api is the API extension for bean (/ EJB) developers, not for plugin developers. Can't the SPI be part of the injection component?

            Where does the injection code currently live? It should live in a component which is beneath EJB 3.

            I think a ctor with default implementations is a nice to have. If we make it, it also has to live very high, because it is dependent upon a couple of existing implementations.

            Shouldn't the actual integration be done somehow in beans.xml? A bit like the pool factory registry?

            • 4. Re: Resolver plugins
              Scott Stark Master

              in going through the ejb deployer resolver its really
              the existing DeploymentScope interface in core that just
              needs to have a couple of methods moved there for
              resolution. This is not to the injection layer yet, although
              some use of jndi names seems questionable

              • 5. Re: Resolver plugins
                Scott Stark Master

                Updating the DeploymentScope interface to the following looks like it allows the integration code to specifying the resolution logic:

                public interface DeploymentScope extends JavaEEApplication
                {
                 public Collection<Ejb3Deployment> getEjbDeployments();
                 void register(Ejb3Deployment deployment);
                 void unregister(Ejb3Deployment deployment);
                
                 /**
                 * Find a deployment based on its relative deployment name
                 *
                 * @param relativeName expects "../foo.jar" so expects the .. in front
                 * @return
                 */
                 Ejb3Deployment findRelativeDeployment(String relativeName);
                 /**
                 * Obtain the EJBContainer best matching the business interface
                 * @param businessIntf - the business interface to match
                 * @return the matching EJBContainer if found, null otherwise.
                 */
                 EJBContainer getEjbContainer(Class businessIntf);
                 /**
                 * Obtain the EJBContainer best matching the business interface
                 * @param ejbLink - the referencing ejb-link
                 * @param businessIntf - the business interface to match
                 * @return the matching EJBContainer if found, null otherwise.
                 */
                 EJBContainer getEjbContainer(String ejbLink, Class businessIntf);
                
                 String getShortName();
                 String getBaseName();
                }
                


                What to do with legacy implementations of DeploymentScope like JmxDeploymentScopeImpl? Are these being supported in this release?