April 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Indirect dependency names

by adrian＠jboss.org

"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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143114#4143114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143114

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Indirect dependency names

by scott.stark＠jboss.org

"adrian(a)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(a)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}. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143108#4143108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143108

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Indirect dependency names

by alesj

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143105#4143105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143105

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Indirect dependency names

by adrian＠jboss.org

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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143101#4143101 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143101

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Indirect dependency names

by scott.stark＠jboss.org

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143094#4143094 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143094

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Indirect dependency names

by scott.stark＠jboss.org

Ok, that should work. I'll give it a try. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143092#4143092 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143092

17 years, 12 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Excluding MC docs by default

by alesj

Can we set that docs are completely ignored when doing install/release/...? Probably this just requires inverting 'maven.skip.docs'? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143085#4143085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143085

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JAXB in cxf/metro

by thomas.diesler＠jboss.com

good, I'll do that View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143083#4143083 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143083

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Indirect dependency names

by adrian＠jboss.org

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143079#4143079 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143079

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: JAXB in cxf/metro

by heiko.braun＠jboss.com

Agreed, We should align them across stacks and make sure the AS uses the most recent one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143074#4143074 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143074

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2008