This content has been marked as final.
Show 4 replies
-
1. Re: using MC beanfactory for configuration
starksm64 Jul 8, 2006 3:56 PM (in response to bill.burke)As described, two bean factories with extension points in a jboss_5 xml schema makes sense. Shouldn't there be a general container framework in the unified aop/mc project that can be used of the basis of any context requiring a container with aspects and instance control?
-
2. Re: using MC beanfactory for configuration
wolfc Jul 10, 2006 8:09 AM (in response to bill.burke)If I see it correctly the micro kernel currently has no knowledge of aspects, it does lean and mean injection. While AOP does the aspects.
So why not:<bean name="StatelessBeanContainer" class="..."> <propery name="timerService"><factory bean="TimerServiceFactory"/></propery> <propery name="aspectDomain>Stateless Bean</property> ... </bean>
-
3. Re: using MC beanfactory for configuration
bill.burke Jul 10, 2006 8:45 AM (in response to bill.burke)"wolfc" wrote:
If I see it correctly the micro kernel currently has no knowledge of aspects, it does lean and mean injection. While AOP does the aspects.
So why not:<bean name="StatelessBeanContainer" class="..."> <propery name="timerService"><factory bean="TimerServiceFactory"/></propery> <propery name="aspectDomain>Stateless Bean</property> ... </bean>
MC does or will (it should now I believe) have knowledge of aspects. You should be able to define an aspect domain embedded within it. Maybe its best to keep the ideas separate and configured separately, maybe not. -
4. Re: using MC beanfactory for configuration
bill.burke Jul 10, 2006 8:49 AM (in response to bill.burke)"scott.stark@jboss.org" wrote:
As described, two bean factories with extension points in a jboss_5 xml schema makes sense. Shouldn't there be a general container framework in the unified aop/mc project that can be used of the basis of any context requiring a container with aspects and instance control?
The EJB Container extends an AOP Advisor to gain the ability for annotation overloading, interceptor stack building, etc... Any generic container there is will have to be extensively extended for EJB specific behavior.
I'm doing a bunch of abstraction to share behavior between Tomcat/EJB for JEE5, but it looks *REALLY* ugly so far.