9 Replies Latest reply on Dec 8, 2008 5:45 PM by alrubinger

    Pluggable @EJB Resolvers

    alrubinger
    alrubinger Oct 24, 2008 12:02 PM

      This is something I've had in mind for a couple weeks now.

      We presently do our resolving based on mappedName, interface type, etc in the AS server module's MappedReferenceMetaDataResolverDeployer.

      For Integration/Injection into MC Beans, this needs to be extracted into A more Pluggable resolver (as I think Carlo's already done similarly w/ JPA).

      Carlo mentioned we need to get something like this done for WS Support anyway, so that'll be the perfect opportunity for me to piggyback on this for MC Integration. :)

      Would like to use this Thread to discuss what the design will look like.

      S,
      ALR

      • 7039 Views
      • Tags:
        • 1. Re: Pluggable @EJB Resolvers
          wolfc
          wolfc Oct 27, 2008 4:55 AM (in response to alrubinger)

          I'm contemplating whether to change the supply/demand chain as well. It can work with only JNDI names. In which case we would get:

          interface EJBDependencyResolver {
 /** @return JNDI name */
 String resolveEJBReference(DeploymentUnit deploymentUnit, String beanName, Class<?> beanInterface, String mappedName);
}

          At least 1 argument must be specified. mappedName is for unforeseens, because now it's the JNDI name.

          For WS it's a bit different, because they can invoke any public method on a bean. So they can't invoke through the current proxies.

            • Actions
          • 2. Re: Pluggable @EJB Resolvers
            alrubinger
            alrubinger Oct 28, 2008 1:39 AM (in response to alrubinger)

            What do we need the deployment unit for? A ClassLoader and JBoss50MetaData could suffice?

            S,
            ALR

              • Actions
            • 3. Re: Pluggable @EJB Resolvers
              wolfc
              wolfc Oct 28, 2008 3:37 AM (in response to alrubinger)

              Deployment unit is the deployment containing the reference. Despite previous statement, it must be specified.

              For example suppose A.jar has BeanA with @EJB BeanB b; then the deployment unit will point to A.jar. If that doesn't contain BeanB, then we go to the top level deployment unit (hopefully X.ear) and start looking there. For each deployment unit the JBossMetaData attachment is queried.

              I don't see how a class loader works into play here.

                • Actions
              • 4. Re: Pluggable @EJB Resolvers
                alrubinger
                alrubinger Oct 30, 2008 2:54 AM (in response to alrubinger)

                I hadn't considered nested deployments, which is why we need DeploymentUnit. If JBossMetaData had a parent reference this might be a different story, but the reason I asked was to avoid the dependency on the Deployers SPI.

                I mentioned ClassLoader for the case that we'd need to construct Class objects from metadata in order to check assignability/equality of bean interfaces.

                S,
                ALR

                  • Actions
                • 5. Re: Pluggable @EJB Resolvers
                  wolfc
                  wolfc Oct 30, 2008 4:42 AM (in response to alrubinger)

                  You don't want to go into class loader details. The beanInterface name is used for comparisons. It's actually a view identifier and not a Java interface as such.

                    • Actions
                  • 6. Re: Pluggable @EJB Resolvers
                    alrubinger
                    alrubinger Dec 8, 2008 4:30 AM (in response to alrubinger)

                    https://jira.jboss.org/jira/browse/EJBTHREE-1616.

                    I've committed a jumping-off point in r82106.

                    The idea is that a EJB Reference resolver adheres to the SPI, and its implementation is defined by an MC deployment:

                    <!-- EJB Reference Resolver -->
 <bean name="org.jboss.ejb3.EjbReferenceResolver" class="org.jboss.ejb3.common.resolvers.spi.EjbReferenceResolver">
 <constructor factoryClass="org.jboss.ejb3.common.resolvers.spi.EjbReferenceResolverFactory"
 factoryMethod="newInstance">
 <parameter>org.jboss.ejb3.common.resolvers.plugins.FirstMatchEjbReferenceResolver</parameter>
 </constructor>
 </bean>


                    Other components (ie. WebBeans integration layer) would then consult this MC Bean.

                    S,
                    ALR

                      • Actions
                    • 7. Re: Pluggable @EJB Resolvers
                      alrubinger
                      alrubinger Dec 8, 2008 5:14 PM (in response to alrubinger)

                       

                      "wolfc" wrote:
                      You don't want to go into class loader details. The beanInterface name is used for comparisons. It's actually a view identifier and not a Java interface as such.


                      Then how do you resolve: 

                      @Local
interface MyBusinessLocal extends MyCommon


                      @EJB
MyCommon myBean;


                      For this you need to load the class in order to get all superclasses as well.

                      S,
                      ALR

                        • Actions
                      • 8. Re: Pluggable @EJB Resolvers
                        wolfc
                        wolfc Dec 8, 2008 5:43 PM (in response to alrubinger)

                        That does not resolve.

                        @Remote interface MyBusinessRemote extends MyCommon

                        Now what? You've undefined semantics.

                          • Actions
                        • 9. Re: Pluggable @EJB Resolvers
                          alrubinger
                          alrubinger Dec 8, 2008 5:45 PM (in response to alrubinger)

                           

                          "wolfc" wrote:
                          That does not resolve.
                          @Remote interface MyBusinessRemote extends MyCommon

                          Now what? You've undefined semantics.


                          In that case you've got to override @EJB(beanInterface) to something worthwhile, else you get NonDeterministicInterfaceException

                          S,
                          ALR

                            • Actions