-
1. Re: Scoped beans deployment
adrian.brock Jan 31, 2007 12:45 PM (in response to alesj)The idea is to be able define a sub-kernel in the scoped metadata.
Kernel kernel = MetaData.getMetaData(Kernel.class);
Then it needs two changes:
1) Either modifying the KernelController or create a subclass
that understands delegation from sub-kernel to parent kernels
A bean in a sub-kernel can depend upon a bean in a parent kernel
but not the other way around!
2) Adding something to the kernel deployment that says you want your
own private kernel for this deployment.
Something like:<deployment kernel="private"> <bean ....> </deployment>
Although I think a more general notion would come out of the work
we need to do to define scoped metadata, probably by annotating the
deployment or bean?
e.g. define these beans in the jca subsystem scope<deployment> <annotation>@org.jboss.metadata.scope.Subsystem("jca")</annotation> <bean ....> </deployment>
For the metadata there already is a thread local to get the current context:MetaData metaData = MetaDataStack.peek();
-
2. Re: Scoped beans deployment
bill.burke Jan 31, 2007 1:07 PM (in response to alesj)I was looking at Seam and their concepts of scopes. He has differently deployed components that are deployed statically, but are created as part of a particular scope: i.e. A Session or a Conversation. So, when a particular Scope is created (i.e. a Session) the component is instantiated and configured based on the component.xml file.
In MC land, this would translate to describing each bean deployed to a particular scope and this meta cloned to a new kernel that finally installs the beans.
It would be cool to get the things that make sense that are duplicated in Seam into MC so we can unify things. -
3. Re: Scoped beans deployment
bill.burke Jan 31, 2007 1:08 PM (in response to alesj)Here's some notes I jotted down when looking at SEam:
* Context/scope aware kernel
- ability to define components and attach them to a scope
- metadata would set in scope definition and not execute to expliclity created.
- can inject between scopes. One scope can override another scope with bean definition.
- almost "federated" but a little different as you can declare beans of different scopes in the same file.
- maybe starting off with federation is the correct way. With a kernel having a parent and children kernels.
- scope/context is a bit different than federation. You'd want the base template of the scope/context defined in bean.xml and you want to ask the kernel to create you a specific scope/context. So scope/context may be implemented via federation, but the kernel would have to know about the scope. -
4. Re: Scoped beans deployment
adrian.brock Jan 31, 2007 1:26 PM (in response to alesj)"bill.burke@jboss.com" wrote:
In MC land, this would translate to describing each bean deployed to a particular scope and this meta cloned to a new kernel that finally installs the beans.
The same feature has also been requested by jbpm.
Although there it is more related to scoped factory references that pass under the wire.
And there are multiple runtime scopes e.g. a process is long running
but can have subtasks that override the process with different factories.
The basic code would then look something like:// Get the current metadata MetaData metaData = MetaDataStack.peek(); // Get the controller KernelController controller = metaData.getMetaData(Kernel.class).getController(); // Get the factories and create the objects SomeFactory factory1 = controller.getInstance("SomeFactory").getTarget(); MyObject1 object = factory1.create(); AnotherFactory factory2 = controller.getInstance("AnotherFactory").getTarget(); MyObject2 object = factory2.create();
Incidently, it would look much nicer if the scope included a MetaDataLoader
that just delegated to the local kernel, i.e. it did the wiring above inside the
MetaDataLoader.// Get the current metadata MetaData metaData = MetaDataStack.peek(); // Get the factories and create the objects SomeFactory factory1 = metaData.getMetaData(SomeFactory.class); MyObject1 object = factory1.create(); AnotherFactory factory1 = metaData.getMetaData(AnotherFactory.class); MyObject2 object = factory2.create();
-
5. Re: Scoped beans deployment
adrian.brock Jan 31, 2007 1:28 PM (in response to alesj)"adrian@jboss.org" wrote:
Although there it is more related to scoped factory references
The advantages of using factories is that you get late binding of injections
during the "create()" not when you define the beans in the kernel. -
6. Re: Scoped beans deployment
adrian.brock Jan 31, 2007 1:38 PM (in response to alesj)The other piece is linking in the AOP domain concept into the scope.
i.e. so you can do the same thing with aspect definitions.
e.g. Being able to define advices for jdbc objects that only apply when
the jdbc object is used inside JCA.
User's jdbc objects would be unadvised. -
7. Re: Scoped beans deployment
bill.burke Jan 31, 2007 1:46 PM (in response to alesj)Adrian, I'm not grokking here...
I was thinking more of:<deploymen> <scope name="application"> <bean name="Foo"/> <scope name="session"> <bean name="bar/> </scope> </scope </deployment> Kernel app= kernel.createScope("Application"); Kernel session = app.createScope("session");
Or something like that. I hope you get the idea.
All scoped beans would just be described and their metadata deployed into a new kernel when the scope is created. Child scopes would not be created, but instead registered with the parent scope. -
8. Re: Scoped beans deployment
adrian.brock Jan 31, 2007 2:13 PM (in response to alesj)"bill.burke@jboss.com" wrote:
Adrian, I'm not grokking here...
See the scoped metadata in org.jboss.metadata in the container project
and its integration with the MC which was discussed/done within the last
couple of months.<deploymen> <scope name="application"> <bean name="Foo"/> <scope name="session"> <bean name="bar/> </scope> </scope </deployment>
That won't work because you define the scopes hierarchically
but also somewhat randomly (even without introducing session/thread/transaction/converstation/etc. :-)
e.g. You can have a bean scope
myapplication/mydeployment1/mybean1
myapplication/mydeployment1/mybean2
myapplication/mydeployment2/mybean1
But you also want to be able to define it in code, e.g. adding beans
to a subsystem scope which isn't part of a deployment but deployments
can be in that subsystem.
e.g. I know this part of the jca code goes in the jboss-jca subsystem scope@org.jboss.metadata.scope.Subsystem("jboss-jca") public class MyJCAImplementationObject {}
So it needs to be abitrary scope annotations against the bean
(and the deployment for convenience).
Kernel app= kernel.createScope("Application");
Kernel session = app.createScope("session");
Yes, you need to be able to create a child kernel
see my point (1) in the first response,
but you also need to add it to the MetaData scope
otherwise how does somebody which kernel to use in an abitrary context.
That is the purpose of the MetaData/MetaDataStack.
NOTE: This is all very speculative since besides maintaining the
MetaDataRepository yourself in some code none of this exists.
i.e. there is nothing that says I want to deploy this metadata into this scope.
That is what I meant before when I said:
"Although I think a more general notion would come out of the work
we need to do to define scoped metadata".
The repository exists with all the plumbing, but there is nothing to fill it! :-) -
9. Re: Scoped beans deployment
alesj Jan 31, 2007 5:47 PM (in response to alesj)"adrian@jboss.org" wrote:
Although I think a more general notion would come out of the work
we need to do to define scoped metadata, probably by annotating the
deployment or bean?
I think it's better if we go from the start into the direction of annotation support."adrian@jboss.org" wrote:
That is what I meant before when I said:
"Although I think a more general notion would come out of the work
we need to do to define scoped metadata".
The repository exists with all the plumbing, but there is nothing to fill it! :-)
If we/you can get some (semi) clear picture where and how we want this plumbing to happen, I can go and code some initial ideas - so that we can see what fits us best. And I can test this with our OSGi project (as previously mentioned requirement). -
10. Re: Scoped beans deployment
adrian.brock Feb 1, 2007 9:20 AM (in response to alesj)"alesj" wrote:
If we/you can get some (semi) clear picture where and how we want this plumbing to happen, I can go and code some initial ideas - so that we can see what fits us best. And I can test this with our OSGi project (as previously mentioned requirement).
We discussed it a while ago (I think some of the major discussions were on
the jboss-dev mailing list). I called it "policy" configuration at that time.
If search worked I could find it for you. ;-)
The basic idea is that you can deploy contextual metadata to scopes,
underneath it would be something like:<bean name="JCAPolicy" ...> <annotation>scope definition</annotation> <property name="binding"> <map> bindings into the metadata scope go here </property> </bean>
But I wanted some easier xml than this, similar to the use case xml for AOP.<policy> <scope/> <annotations/> <bindings/> </policy>
This then populates the MetaDataRepository for that scope.
Something that is only done currently at the instance level for annotations
against the bean. -
11. Re: Scoped beans deployment
alesj Feb 1, 2007 9:33 AM (in response to alesj)"adrian@jboss.org" wrote:
bindings into the metadata scope go here
...<bindings/>
What is meant here by bindings? -
12. Re: Scoped beans deployment
alesj Feb 1, 2007 10:04 AM (in response to alesj)Probably here is where a lot of things should / must be added:
- BasicKernelMetaDataRepository.initMetaDataRetrieval(KernelControllerContext context)
for this kind of bean scoping? -
13. Re: Scoped beans deployment
adrian.brock Feb 1, 2007 10:08 AM (in response to alesj)What is meant here by bindings?
Name->Object
e.g. This would map to the implementation (remove for undeploy)// Get a link to the scoped metadata KernelMetaDataRepository kmdr = kernel.getMetaDataRepository(); MutableMetaDataRepository mmdr = kmdr.getMutableMetaDataRepository(); ScopeKey scope = from the <scope/>; MutableMetaData mmd = (MutableMetaData) mmdr.getMetaDataRetrieval(scope); // Not found create it if (mmd != null) { mmd = ...; mmdr.addMetaDataRetrieval(mmd); } for (iterate) mmd.addMetaData(name, object, object.getClass());
If the scope wants to define its own kernel then you would also have something like:// Get our scope KernelMetaDataRepository kmdr = kernel.getMetaDataRepository(); MutableMetaDataRepository mmdr = kmdr.getMutableMetaDataRepository(); ScopeKey scope = from the <scope/>; MutalbeMetaData mmd = (MutableMetaData) mmdr.getMetaDataRetrieval(scope); // Get the parent scope ScopeKey parent = scope.getParent(); MutalbeMetaData pmmd = (MutableMetaData) mmdr.getMetaDataRetrieval(parent); MetaDataItem<Kernel> item = pmmd.retrieveMetaData(Kernel.class); Kernel kernel = null; if (item != null) kernel = item.getValue(); else kernel = // use default - or more probably this current kernel? // Create a scoped kernel Kernel scopedKernel = new ScopedKernel(kernel); mmd.addMetaData(scopedKernel);
There is also work to do on how ScopeKeys get constructed
This is very environment specific.
See my comments on the metadata integration thread in the last couple of months.
Also note that there are two notions of scope (configuration time and runtime).
This is important in the code above where the parent kernel needs to come
from the parent runtime scope, but it is added to local configuration time scope.
Again, this difference is explained in the metadata integration thread. -
14. Re: Scoped beans deployment
bill.burke Feb 1, 2007 10:32 AM (in response to alesj)"adrian@jboss.org" wrote:
"bill.burke@jboss.com" wrote:
Adrian, I'm not grokking here...
See the scoped metadata in org.jboss.metadata in the container project
and its integration with the MC which was discussed/done within the last
couple of months.<deploymen> <scope name="application"> <bean name="Foo"/> <scope name="session"> <bean name="bar/> </scope> </scope </deployment>
That won't work because you define the scopes hierarchically
but also somewhat randomly (even without introducing session/thread/transaction/converstation/etc. :-)
I think I see what you mean. Thread scope would want to obtain metadata from both its transaction and conversation. Is that what you're talking about?