[Design the new POJO MicroContainer] - Automatic Scoped Kernels - A good idea
by adrian@jboss.org
Given Ales's latest issue/hack,
I'm beginning to wonder whether the automatic construction of scoped
kernels is really such a good idea.
For ease of use it probably is, but making it work is requiring too many hacks
and I have a feeling that Ales is doing it wrong anyway or has at least
misunderstood part of it (Given some of the problems he is reporting).
The alternate approach would be to move the scoping of kernels to the deployers.
i.e. The MC can support scoped kernels but you have to use an api
to configure them.
The deployment chain would then look something like:
1) Parsing as now (for POJOs - BeanDeployer)
2) ClassLoading deployer (as now or replaced with OSGi style)
3) Component Deployer (for POJOs KernelDeploymentDeployer)
4) Scoping Deployer (NEW looks at BeanMetaData and creates ScopedKernel)
5) Real Deployer (as now BeanMetaDataDeployer - but deploys into ScopedKernel)
This gives a cleaner api and probably makes it easier to override scoping rules.
The downside is that you don't get scoping out of the box, you either
have to use the deployers or write your own scoping config code.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022413#4022413
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022413
18 years, 10 months
[Design the new POJO MicroContainer] - Re: Scoped Kernels
by adrian@jboss.org
"alesj" wrote : "alesj" wrote :
| | From previous problem (duplicate 'context') temp fix, I currently have Context's hashCode under WORK level to diff the contexts. What's the appropriate fix?
| |
|
|
| | public ScopeKey getFullScope(KernelControllerContext context)
| | {
| | ScopeKey scope = ScopeKey.DEFAULT_SCOPE.clone();
| | scope.addScope(CommonLevels.INSTANCE, context.getName().toString());
| | BeanMetaData beanMetaData = context.getBeanMetaData();
| | if (beanMetaData != null)
| | {
| | String bean = beanMetaData.getBean();
| | if (bean != null)
| | scope.addScope(CommonLevels.CLASS, bean);
| | }
| | // todo - some other level
| | scope.addScope(CommonLevels.WORK, String.valueOf(context.hashCode()));
| | return scope;
| | }
| |
|
| Otherwise I cannot differentiate between these two beans:
|
| | <bean name="simple" class="org.jboss.test.kernel.deployment.support.SimpleBeanImpl">
| | <annotation>@org.jboss.metadata.plugins.scope.ApplicationScope("testApp")</annotation>
| | <annotation>@org.jboss.metadata.plugins.scope.DeploymentScope("deployment1")</annotation>
| | <constructor>
| | <parameter>deployment1</parameter>
| | </constructor>
| | </bean>
| |
| | <bean name="simple" class="org.jboss.test.kernel.deployment.support.SimpleBeanImpl">
| | <annotation>@org.jboss.metadata.plugins.scope.ApplicationScope("testApp")</annotation>
| | <annotation>@org.jboss.metadata.plugins.scope.DeploymentScope("deployment2")</annotation>
| | <constructor>
| | <parameter>deployment2</parameter>
| | </constructor>
| | </bean>
| |
That looks like a very dirty hack to me.
I'm beginning to think that if we are going to add one hack
(pretending mutating the name to avoid clashes) because
of another hack (moving the controller) then we are on the wrong
track.
In fact, what is really required to fix this problem is something we discussed a while ago
where the bean is given a UID (unique identifier) to store its internal state.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022406#4022406
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022406
18 years, 10 months