-
1. Re: Indirect dependency names
adrian.brock Apr 10, 2008 4:23 AM (in response to starksm64)There's an outstanding task to do the opposite.
i.e. internally the MC will use GUIDs to identify contexts with the
setName() just being processed as an alias. You can add aliases dynamically
(which is I think what you are trying to achieve with the name/id?).
If you're generating the BeanMetaData programmatically,
there's no reason why couldn't do this yourself even before this change.
i.e.initially do
setName(new GUID().toString())
then later add the alias (your IdentityDependencyName)
to the context when you know what it is. -
2. Re: Indirect dependency names
starksm64 Apr 10, 2008 5:21 AM (in response to starksm64)Ok, that should work. I'll give it a try.
-
3. Re: Indirect dependency names
starksm64 Apr 10, 2008 5:25 AM (in response to starksm64)Actually that still does not work. The problem is that the name has to change everytime the factory creates a new instance. Unlike the GenericBeanFactory, the notion of the ComponenentFactory is that each instance created is an mcbean. So I need a GUID()+"."+compCount type of update to the name everytime createBeans() is called.
-
4. Re: Indirect dependency names
adrian.brock Apr 10, 2008 5:44 AM (in response to starksm64)I need to see something a bit more concrete to understand how this wired together.
The idea of the GenericBeanFactory is that the GBF is controlled by the MC,
which then creates beans that get injected from the MC components but
those beans aren't themselves managed by the MC
(that is unless you the GBF as a constructor factory for some other MC managed bean).
You're saying that your factory is actually creating MC contexts during createBeans().
Two questions:
1) Why can't the thing that creates the MC contexts do your logical name + next number
processing? i.e. you store next number within the factory.
2) What unregisters the MC contexts when they are no longer required?
i.e. what keeps track of this generated name to remove it? -
5. Re: Indirect dependency names
alesj Apr 10, 2008 5:57 AM (in response to starksm64)As I understand what Scott is trying to do is to have a pre-defined metadata, e.g. InstallMetaData that does 'mybean::addInterceptor'.
Where mybean would be determined in createBean method, mostly preprending 'baseName' and appending some number to existing meaningful name (e.g. BeanContext).
Reusing pre-defined metadata should be done by cloning, since when metadata moves through states, we set some member variables. Knowing where this is done is impl detail on which you should not rely - e.g. we might change the actual metadata impl.
Perhaps having a more open BeanMetaDataBuilder is the way to go - meaning you can provide what the actual metadata impls are we gonna use, e.g. when we do a LifecycleMetaData instantiation, one could override that with it's own impl, not using our default AbstractLifecycleMetaData. -
6. Re: Indirect dependency names
starksm64 Apr 10, 2008 6:09 AM (in response to starksm64)"adrian@jboss.org" wrote:
1) Why can't the thing that creates the MC contexts do your logical name + next number
processing? i.e. you store next number within the factory.
It can, and currently does. Its just needing to rebuild the bean metadata list for the components for each new instance even though all that changes are the underlying mc bean names. In terms of types of metadata and relationships between then, nothing changes once the factory is initialized. If there was a name indirection on the dependency values then only that piece would need to be updated.
Actually, back to the guid idea notion, if there was auto generated id notion with a scoped alias notion such that the dependencies names used the alias scoped to the list of beans used by the factory, and the bean guid was generated each time then that is something that would work."adrian@jboss.org" wrote:
2) What unregisters the MC contexts when they are no longer required?
i.e. what keeps track of this generated name to remove it?
I updated the "GenericBeanFactory and install methods" thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=133332
with the current ComponentFactory spi, it has a destroyBeans call to unregister the beans created during createBeans.
This code is checked in the jboss-kernel project tests under org.jboss.test.kernel.deployment.support.container.{spi,plugin}. -
7. Re: Indirect dependency names
adrian.brock Apr 10, 2008 6:18 AM (in response to starksm64)"alesj" wrote:
Perhaps having a more open BeanMetaDataBuilder is the way to go - meaning you can provide what the actual metadata impls are we gonna use,
You mean something like Builder::addInstallCallback(InstallCallback ic);
Where ic can be your own implementation. Ok.
But I don't think that is the issue here is it?
For this case (as I understand it),
the thing that is building the BeanMetaData just needs to do:
builder.addInstallCallback(method, someGeneratedName);
The part I don't understand is why it has to get more complicated?
Why do we need lots of new interfaces or methods when the thing creating
the BeanMetaData is the one that knows what the generated names are?
Like I said above, if you don't know what the generated name is
how are you going to uninstall it when it is no longer required? -
8. Re: Indirect dependency names
adrian.brock Apr 10, 2008 6:24 AM (in response to starksm64)"scott.stark@jboss.org" wrote:
It can, and currently does. Its just needing to rebuild the bean metadata list for the components for each new instance even though all that changes are the underlying mc bean names. In terms of types of metadata and relationships between then, nothing changes once the factory is initialized. If there was a name indirection on the dependency values then only that piece would need to be updated.
You can't install the BeanMetaData twice (i.e. use it as template)
until Ales has finished the clone() stuff."adrian@jboss.org" wrote:
This code is checked in the jboss-kernel project tests under org.jboss.test.kernel.deployment.support.container.{spi,plugin}.
Ok, I'll look at it once I've finished what I'm currently working on.
Does it have a test that shows what it is supposed to do but doesn't currently? -
9. Re: Indirect dependency names
starksm64 Apr 10, 2008 6:30 AM (in response to starksm64)"adrian@jboss.org" wrote:
Ok, I'll look at it once I've finished what I'm currently working on.
Does it have a test that shows what it is supposed to do but doesn't currently?
Yes, org.jboss.test.kernel.deployment.test.BeanContainerUsageMDTestCase.testComponentBeanFactory which calls the org.jboss.test.kernel.deployment.test.BeanContainerUsageMDTestCase.getDeploymentForComponentBeanFactory to build the programatic deployment is what is testing this. I'm updating it for the current changes to get the names correct. Right not its building the BeanMetaData list a new for each create call so I don't think the clone issue applies yet. -
10. Re: Indirect dependency names
alesj Apr 10, 2008 6:35 AM (in response to starksm64)Perhaps we can create a new child Controller for every ComponentFactory?
Meaning we could have beans with the 'same' name living side by side, e.g. multiple BeanContext beans.
Annotating initial ComponentFactory instance with @ScopeFactoryLookup, and then applying the same annotation for all created beans.
PreInstallAction is gonna handle them, and create child Controllers accordingly.
I'll fix the caching of ScopeFactory in PreInstallAction. -
11. Re: Indirect dependency names
adrian.brock Apr 10, 2008 8:39 AM (in response to starksm64)Scott, if you commit a test that is failing can you also update the config
to ignore failing tests otherwise other people's builds are broken.
e..g--- kernel/pom.xml (revision 71907) +++ kernel/pom.xml (working copy) <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> + <configuration> + <testFailureIgnore>true</testFailureIgnore> + </configuration> </plugin>
-
12. Re: Indirect dependency names
starksm64 Apr 10, 2008 8:49 AM (in response to starksm64)Ok, will do. The tests are passing again as of now.
-
13. Re: Indirect dependency names
adrian.brock Apr 10, 2008 9:12 AM (in response to starksm64)So is this something I still need to look at or you've done a workaround?
-
14. Re: Indirect dependency names
starksm64 Apr 10, 2008 9:27 AM (in response to starksm64)I have a workaround, and Ales has another approach as well so I'm good for now.