-
1. Re: Dependency State Machine
adrian.brock May 20, 2005 5:28 PM (in response to adrian.brock)In more concrete terms, the Controller should have a
ControllerContext install(MetaData)
The MetaData gives a stateless callback for the lifecycle actions that are
currently hardwired towards BeanMetaData at the momentpublic interface ControllerAction { void install(ControllerState state, ControllerContext context) throws Throwable; void uninstall(ControllerState state, ControllerContext context); }
The BeanMetaData would just provide a callback that are the actions that
are currently in AbstractController. -
2. Re: Dependency State Machine
adrian.brock May 20, 2005 5:32 PM (in response to adrian.brock)This has one major advantage in terms of backwards compatiblity.
Which is that it will work equally as well with the current JMX kernel ServiceContext,
where the ServiceContext can provide callbacks that just do what the
ServiceCreator/Configurator/Controller do now.
In other words, running older JMX code with new POJO code won't require
complicated JMX introductions/AOP proxies that Bill is reluctant to support.
The JMX introduction will of course still be required to actually manage POJOs,
but it would mean I can make a start on the JBoss5 integration without waiting for it. -
3. Re: Dependency State Machine
adrian.brock May 20, 2005 5:36 PM (in response to adrian.brock)It can also be used to support other models, e.g. where Bill is dragging his heels
deploying AOP metadata as BeanMetaData and instead using the POJO MC
as a ServiceLocator.
By removing the BeanMetaData requirement, this pattern can be more easily incorported
without the cruft of wrapping things in BeanMetaData just to get the dependencies to work. -
4. Re: Dependency State Machine
adrian.brock May 20, 2005 5:36 PM (in response to adrian.brock)Thoughts?
-
5. Re: Dependency State Machine
bill.burke May 23, 2005 11:06 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
In other words, running older JMX code with new POJO code won't require
complicated JMX introductions/AOP proxies that Bill is reluctant to support.
Please expand on what I'm reluctant to support here...I have proxy support implemented and tested. These proxies also support introductions. -
6. Re: Dependency State Machine
bill.burke May 23, 2005 11:17 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
It can also be used to support other models, e.g. where Bill is dragging his heels
deploying AOP metadata as BeanMetaData and instead using the POJO MC
as a ServiceLocator.
Please expand what you want explicitly and what exactly is missing instead of just insulting me. -
7. Re: Dependency State Machine
adrian.brock May 23, 2005 11:25 AM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
Please expand on what I'm reluctant to support here...I have proxy support implemented and tested. These proxies also support introductions.
You were (are?) reluctant to support a proxy that does not require any form of
bytecode manipulation, i.e. no use of aopc, runtime manipulation or javassist proxy
construction.
I couldn't get your tests to run, I "fixed" a few obvious things but then gave up.
Did you forget to commit something? :-)
http://sourceforge.net/mailarchive/message.php?msg_id=11771381
http://sourceforge.net/mailarchive/message.php?msg_id=11771375
+ some others -
8. Re: Dependency State Machine
adrian.brock May 23, 2005 11:36 AM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
"adrian@jboss.org" wrote:
It can also be used to support other models, e.g. where Bill is dragging his heels
deploying AOP metadata as BeanMetaData and instead using the POJO MC
as a ServiceLocator.
Please expand what you want explicitly and what exactly is missing instead of just insulting me.
I am not insulting you, at least that was not my intension.
I'm sorry if you interpreted it that way.
I am actually agreeing with you. If you want to take it incrementally and use
the dependencies as a ServiceLocator we should support that as a first class notion.
You shouldn't have to do unnatural things to make this work.
The "Dragging Heels" comment refers to originally we agreed that the aspect
factories would be deployed as beans through the kernel, but this isn't what you are
doing now.
Somewhere down the road, the aspect manager will support DI and be integrated
with the full dependency model. In the meantime we need the ability to query
dependencies and use the service locator pattern.
To fully clarify before you misinterpet :-).
By the "aspect manager will support DI", I mean the aspect metadata will be injected
into the aspect manager as the aspect's dependencies are satisfied.
Currently the aspect is placed in the aspect manager's "holding area" where
anybody could activate "by reference" before the dependencies are satisfied. -
9. Re: Dependency State Machine
bill.burke May 23, 2005 11:50 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
"bill.burke@jboss.com" wrote:
Please expand on what I'm reluctant to support here...I have proxy support implemented and tested. These proxies also support introductions.
You were (are?) reluctant to support a proxy that does not require any form of
bytecode manipulation, i.e. no use of aopc, runtime manipulation or javassist proxy
construction.
I'm pretty sure Javassist proxy construction would work inside of an Applet as Chiba has some RMI proxy generation stuff and demos where it runs inside an applet, not sure about J2ME though. I don't understand why you just cannot use the Javassist Proxy construction stuff that's there now and then use the java.lang.reflect.Proxy implementation when it is complete. It should just be a method change.
BTW, I don't understand why you even need AOP/proxies anyways to support older JMX stuff within the new Kernel. -
10. Re: Dependency State Machine
adrian.brock May 23, 2005 11:53 AM (in response to adrian.brock)What I'm suggesting on this thread, is that is shortsighted to expect
only "beans" to take part in the dependency mechanism.
Instead, the dependency mechanism should be generalized
depending upon the model being used.
Beans: instantiate/configure -> kernel registry
MBeans: instantiate/configure -> MBeanServer
Aspects: instantiate/configure -> AspectManager
etc.
Each model is responsible for determining what the lifecycle operations
describe, instantiate, configure. create, start, install
means in its context.
The other advantage is that this gives the old MBean style deployments
a DESCRIBE state which means they are enhanced with the extra classloading
dependencies. -
11. Re: Dependency State Machine
adrian.brock May 23, 2005 11:58 AM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
BTW, I don't understand why you even need AOP/proxies anyways to support older JMX stuff within the new Kernel.
I know, that is why we keep arguing about it :-)
Fundamentally, I don't want to use the old JMX container with its own invocation model.
I want a new JMX container that uses the AOP invocation model (but not its bytecode manipulation). If bytecode manipulation has already been done on the MBean
then we should use it (it potentially allows extra functionality like MBean Attributes
based directly on private fields, i.e. without get/set), but this should not be a requirement - it is a "value add". -
12. Re: Dependency State Machine
bill.burke May 23, 2005 2:25 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
"bill.burke@jboss.com" wrote:
"adrian@jboss.org" wrote:
It can also be used to support other models, e.g. where Bill is dragging his heels
deploying AOP metadata as BeanMetaData and instead using the POJO MC
as a ServiceLocator.
Please expand what you want explicitly and what exactly is missing instead of just insulting me.
I am not insulting you, at least that was not my intension.
I'm sorry if you interpreted it that way.
I am actually agreeing with you. If you want to take it incrementally and use
the dependencies as a ServiceLocator we should support that as a first class notion.
You shouldn't have to do unnatural things to make this work.
I'm not understanding you.
The "Dragging Heels" comment refers to originally we agreed that the aspect
factories would be deployed as beans through the kernel, but this isn't what you are
doing now.
This is exactly what I am doing now. Take a look at the AspectSchemaFactory.
Somewhere down the road, the aspect manager will support DI and be integrated
with the full dependency model. In the meantime we need the ability to query
dependencies and use the service locator pattern.
To fully clarify before you misinterpet :-).
By the "aspect manager will support DI", I mean the aspect metadata will be injected
into the aspect manager as the aspect's dependencies are satisfied.
Currently the aspect is placed in the aspect manager's "holding area" where
anybody could activate "by reference" before the dependencies are satisfied.
Not true. A delegator is placed in the aspect manager's "holding area". This delegator looks up the actual factory within the Kernel when needed. If the factory does not have all dependencies satisfied, it will not be in the Kernel registry and the delegator will fail to create the aspect and throw an exception.
There has to be some locator pattern used somewhere as aspectized classes can be created with the new() operator. Either you locate the factory within the AspectManager or the kernel. -
13. Re: Dependency State Machine
adrian.brock May 23, 2005 2:48 PM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
There has to be some locator pattern used somewhere as aspectized classes can be created with the new() operator. Either you locate the factory within the AspectManager or the kernel.
Agreed. I am saying eventually it will be in the DI, I'm not asking you to do this now. -
14. Re: Dependency State Machine
adrian.brock May 23, 2005 3:29 PM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
"adrian@jboss.org" wrote:
"bill.burke@jboss.com" wrote:
"adrian@jboss.org" wrote:
It can also be used to support other models, e.g. where Bill is dragging his heels
deploying AOP metadata as BeanMetaData and instead using the POJO MC
as a ServiceLocator.
Please expand what you want explicitly and what exactly is missing instead of just insulting me.
I am not insulting you, at least that was not my intension.
I'm sorry if you interpreted it that way.
I am actually agreeing with you. If you want to take it incrementally and use
the dependencies as a ServiceLocator we should support that as a first class notion.
You shouldn't have to do unnatural things to make this work.
I'm not understanding you.
The "Dragging Heels" comment refers to originally we agreed that the aspect
factories would be deployed as beans through the kernel, but this isn't what you are
doing now.
This is exactly what I am doing now. Take a look at the AspectSchemaFactory.
Somewhere down the road, the aspect manager will support DI and be integrated
with the full dependency model. In the meantime we need the ability to query
dependencies and use the service locator pattern.
To fully clarify before you misinterpet :-).
By the "aspect manager will support DI", I mean the aspect metadata will be injected
into the aspect manager as the aspect's dependencies are satisfied.
Currently the aspect is placed in the aspect manager's "holding area" where
anybody could activate "by reference" before the dependencies are satisfied.
Not true. A delegator is placed in the aspect manager's "holding area". This delegator looks up the actual factory within the Kernel when needed. If the factory does not have all dependencies satisfied, it will not be in the Kernel registry and the delegator will fail to create the aspect and throw an exception.
I don't conceed these other points, because you haven't understood what I am talking about. As usual, I suspect the problem is we talking about different things. :-)