-
15. Re: using the registry/ClassAdapter.getDependencies()
adrian.brock Mar 23, 2005 7:03 PM (in response to bill.burke)"bill.burke@jboss.com" wrote:
This @Dependency annotation only tells the MC about the dependency. The MC doesn't know how/where this dependency should be injected. The @SecurityDomain is on the bean class and it is the aspect that needs this information to lookup and set the dependency within the aspect. A distinct, non-GenericBeanFactory implementation of an AspectFactory would be needed here. It would work the same way the Security aspect works now in the current impl except that they MC would be able to hold up bean creation because the SecurityDomain dependency would be published to it via the @Dependency annotation.
Correct, the @SecurityDomain tells the MC the correct order for instantiation.
The advice does not change its implementation. I think this is a major requirement.
i.e. none of our changes should affect user code already in existance.
What we are changing (hopefully improving) is the way and the possiblities
they are configured/managed.
In the security domain case, it will still use jndi as now, though as Scott pointed
out in a different thread, the implementation could be improved to avoid the dependency on jndi. -
16. Re: using the registry/ClassAdapter.getDependencies()
adrian.brock Mar 23, 2005 7:08 PM (in response to bill.burke)"adrian@jboss.org" wrote:
In the security domain case, it will still use jndi as now, though as Scott pointed
out in a different thread, the implementation could be improved to avoid the dependency on jndi.
In the same vain, the TX aspect can be improved to avoid the
TxManager.getInstance() and use dependency injection instead.
This is an especially important requirement when the aspects are being used
as an integration layer across different app servers by our services.
The MC or some trivial factory controlled by the MC
knows the TM instance or how to map a security domain/realm
to the platform's native notion. -
17. Re: using the registry/ClassAdapter.getDependencies()
bill.burke Mar 23, 2005 7:10 PM (in response to bill.burke)phew cool...I was scared from your previous post that we had to have the same argument all over again.. :) *blush*
So, what I need to do is:
1) make ClassAdapterFactory configurable
2) Implement ClassAdapter. I will reuse the ReflectionClassAdapter since I currently think reflection is sufficient.
3) hook in ClassAdaptor.getDependencies()
4) Refactor AOP weaving/binding to be able to use MC registry to find AspectFactories and as a side effect abort weaving/binding if the factory isn't ready.
I'll do this all programmitcally. I cannot write an AspectDeployer until the XML parsing is done. I'll need an XML parser that can handle XML fragments since AspectFactory implementations are pluggable (and must remain pluggable for things like SecurityAspect).
So, second iteration will be:
1) Write AspectDeployer
3rd iteration will be:
1) Morph GenericBeanFactory so that I can add additional injections like Advisor, InstanceAdvisor, TargetObject, etc.. Things only AOP can resolve.
4th iteration:
1) Rewrite DynamicAOP to be able to handle more fine-grain aspects.
2) Refactor annotation overrides and maybe move it into the kernel or a separately shared module.
3) Hook in per-instance annotation overrides with DynamicAOP (the getInstanceAdapter implementation
I think maybe you need to handle the @Dependency stuff as it seems this may be something specific to MC and not soley an AOP thing. Is that correct? -
18. Re: using the registry/ClassAdapter.getDependencies()
bill.burke Mar 23, 2005 7:14 PM (in response to bill.burke)Oh, most definately. I was assumingn that TM would be injected. In the case of security where the aspect needs to get what domain from the bean class, the domain would be looked up through the KernelRegistry.
-
19. Re: using the registry/ClassAdapter.getDependencies()
adrian.brock Mar 23, 2005 7:19 PM (in response to bill.burke)"bill.burke@jboss.com" wrote:
I think maybe you need to handle the @Dependency stuff as it seems this may be something specific to MC and not soley an AOP thing. Is that correct?
Ok. We originally had this in the ClassAdapter because the jboss-aop.xml
can add extra annotations/introductions. If you are saying this does
not require any special processing in AOP land I am OK with doing this in the MC. -
20. Re: using the registry/ClassAdapter.getDependencies()
adrian.brock Mar 23, 2005 7:27 PM (in response to bill.burke)"bill.burke@jboss.com" wrote:
1) Morph GenericBeanFactory so that I can add additional injections like Advisor, InstanceAdvisor, TargetObject, etc.. Things only AOP can resolve.
Isn't that the purpose of wrapping the generic bean factory in the aspect factory?
The GBF constructs and configures the advice object then the aspect factory
tells it the interesting stuff. -
21. Re: using the registry/ClassAdapter.getDependencies()
bill.burke Mar 23, 2005 7:29 PM (in response to bill.burke)Ok, shit, now I remember why AOP needed to create ClassInfos. Because of annotation overrides at the class level by the AOP container.
Yeah, I think MC should handle @Dependency, but ClassAdaptor will provide the ClassInfos (with overrides). Really I think the annotation override facility in JBoss AOP should be extracted into its own module so that MC can reuse it. It would be silly to map between ObjectModels that are doing the same thing.
Anyways. let's iterate. I need to iterate because I can't focus on this stuff continuously because of other responsibilities (i.e. EJB3). -
22. Re: using the registry/ClassAdapter.getDependencies()
bill.burke Mar 23, 2005 7:30 PM (in response to bill.burke)"adrian@jboss.org" wrote:
"bill.burke@jboss.com" wrote:
1) Morph GenericBeanFactory so that I can add additional injections like Advisor, InstanceAdvisor, TargetObject, etc.. Things only AOP can resolve.
Isn't that the purpose of wrapping the generic bean factory in the aspect factory?
The GBF constructs and configures the advice object then the aspect factory
tells it the interesting stuff.
Yeah, this is what I'm talking about.