-
15. Re: Generalizing dependency injection
"wolfc" wrote:
"adrian@jboss.org" wrote:
What you are describing is called "flow control". You can do it outside an EJB
with an aspect, e.g. a semaphore controlling access to a singleton.
If the semaphore/pool uses priority queuing the admin request
can "jump the queue" based on a higher privilege.
A pool beats a semaphored singleton anytime.
Obviously wrong. ;-)
It makes no difference whether the semaphore is on the pool or the object,
and the rest of the code is the same. -
16. Re: Generalizing dependency injection
So what is the benefit to BeanFactory over an instance factory on the bean ctor metadata?
-
17. Re: Generalizing dependency injection
"scott.stark@jboss.org" wrote:
So what is the benefit to BeanFactory over an instance factory on the bean ctor metadata?
I wouldn't describe it as a benefit, its a different semantic.
Factory construction is just an alternate way to construct a singleton<bean> <constructor factroyClass="x.y.z.A" factoryMethod="create"/>
A bean factory creates an object that implements BeanFactory
on which you can call create() to create as many instances as you like:<beanfactory name="MyFactory"> ... public class MyClass { @Inject("MyFactory") public void setFactory(BeanFactory factory) {} public void doStuff() { Object one = factory.create(); Object two = factory.create(); } }
The main usecase of beanfactory so far has been to do dependency injection
into aop's advices.
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontainer/trunk/aop-mc-int/src/main/org/jboss/aop/microcontainer/beans/GenericBeanAspectFactory.java?revision=61978&view=markup -
18. Re: Generalizing dependency injection
Where I'm at right now is:
- The MappedReferenceMetaDataResolverDeployer creates a mapping of the endpoint ids (ejb/vfspath/ejbName, etc) to a ContainerDependencyMetaData. There still is a layer of mapping with alternative keys as has been talked about here for resolving references, but the output is the unique set of ContainerDependencyMetaData for referenced endpoints.
- The ContainerDependencyMetaData has the set of ResourceInjectionTargetMetaData for references that need the endpoint injected.
- The ContainerDependencyMetaData has the jndi names that references have declared they will lookup rather than inject.
- The ContainerDependencyMetaData has the container name and bean factory which have to be setup by the associated endpoint deployer. The associated container bean also has aliases for the jndi names associated with the endpoint. There can be more than one due to different invokers (ejb2). I assume there is something similar for ejb3, but I'm not that far yet.
Getting this wired up to validate it works in the ejb2/3 deployers is something I'm still working on.