Hey guys: Is there a reason we're doing stuff like: JBossEjb.lookupEjbReferenceResolver(controller).resolveEjb(topLevelDeploymentUnit, new EjbReference(beanName, beanInterface, mappedName)) ...instead of injecting the reference resolver? http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/ejb... There are a few other examples where this type of lookup is used. Given only one implementing class per interface, you can even rely upon MC to do the autowiring. S, ALR

I don't know the class names to use, tell me, or make the change :-)

Pete Muir wrote: > On 24 Jan 2009, at 09:07, Ales Justin wrote: >> Injecting it how? >> >> Currently the entry point is ServletContext, >> which holds MC's Kernel and DeploymentUnit as its attribute. >> >> The WB pieces that reside in WB app are not (yet) 'connected' to >> MC directly. >> Only the custom WB deployers are. >> See wb-int/jbossas/ and its vdf package for more details. >> >> WRT to autowiring, I agree, there is no need to do lookup by name, > I was just following ALR's example when I did this :-p My example had no lookup code; all was injected/installed via MC ;) For instance, I'd been expecting JBossEjbResolver to itself be an MC bean, where the EjbReferenceResolver would be an injected instance member. Like I do in ejb3-mc-int: ...declares the EjbReferenceResolver impl: <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> ...injects the EjbReferenceResolver into something that uses it. <bean name="org.jboss.ejb3.EjbReferenceAnnotationPlugin" class ="org.jboss.ejb3.mcint.metadata.plugins.EjbReferenceAnnotationPlugin"> <constructor> <parameter><inject bean="org.jboss.ejb3.EjbReferenceResolver" / ></parameter> </constructor> </bean>

I bring this up as a general point as I'd been looking things over. If you can get JBossEjbResolver from MC injected into ServletJBossEjbResolver, then you can avoid lookups altogether.

S, ALR >> a class would be enough - as long as there is only one matching >> instance. > I don't know the class names to use, tell me, or make the change :-) >> >> >> Andrew Lee Rubinger wrote: >>> Hey guys: >>> Is there a reason we're doing stuff like: >>> JBossEjb >>> .lookupEjbReferenceResolver >>> (controller).resolveEjb(topLevelDeploymentUnit, new >>> EjbReference(beanName, beanInterface, mappedName)) >>> ...instead of injecting the reference resolver? >>> http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/ejb... >>> There are a few other examples where this type of lookup is >>> used. Given only one implementing class per interface, you can >>> even rely upon MC to do the autowiring. >>> S, >>> ALR >> _______________________________________________ >> webbeans-dev mailing list >> webbeans-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/webbeans-dev -- Andrew Lee Rubinger Sr. Software Engineer JBoss, a division of Red Hat, Inc. http://exitcondition.alrubinger.com _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

>> I bring this up as a general point as I'd been looking things over. >> If you can get JBossEjbResolver from MC injected into >> ServletJBossEjbResolver, then you can avoid lookups altogether. > > I don't think so, but this would depend on Ales as he wrote the bridge > code. Sure, to some extent. We just have to move JBossEjbDiscovery into microcontainer part of the project, so it gets deployed in the same phase as WB deployers. Then we just do a vdf connector to JBossEjbDiscovery and use current underlying DeploymentUnit to do lookup. All other stuff will already be injected. ServletJBossEjbResolver is our bridge between MC and WB, hence conceptually cannot be part of MC.