[Design the new POJO MicroContainer] - Re: Automatic Scoped Kernels - A good idea
by adrian@jboss.org
"alesj" wrote :
| Or which part you think is really misunderstood?
|
It was something you said either last week or the previous week
about having duplicates and I responded that I didn't understand
the issue since it should be impossible to have duplicates in the same scope.
I'm also not sure whether you understood the issue with the classloader
creating a dependency on itself?
ClassLoader (as bean) -> scope annotations creates scope -> requires classloader (itself)
There's also some other subtle issues about how we expect to use the scopes.
e.g. A bean in a kernel deployment might have the full scope:
Application=myapp.ear
Deployment=mybeans.jar
Class=MyBean.class
Instance=BeanName
But you aren't going to create a ScopedKernel at the Intance level or class level.
The natural level for the scope would be at the Application/Deployment pair.
This latter issue is much easier to deal with from the deployers
(which understand deployment structure) than it is from the automatic scope generation
that we are prototyping.
I also think there will be use cases where people want to assign a scope
to a bean (or MBean) for the purposes of the MetaData overrides but don't
want a full scoped kernel for their deployment?
And we still need to address the issue I raised with "exporting" beans
into global scope (if that really is a use case ?).
Basically, like I said at the beginning, although we are building a mechanism
to do something called scoped kernel, we haven't gone through a requirements
gathering stage to see whether it meets the real need(s).
This makes me worried. :-)
I'm happy that the controller api should support scoped kernels (the implementation side)
but I'm not so sure on the "policy" side that the way we are creating
assigning contexts to scope is correct.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022440#4022440
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022440
17 years, 8 months
[Design the new POJO MicroContainer] - Re: Automatic Scoped Kernels - A good idea
by alesj
"adrian(a)jboss.org" wrote :
| For ease of use it probably is, but making it work is requiring too many hacks
|
Ok, moving Controller looks kind of hackih, but it is used transparently regarding previous code.
"adrian(a)jboss.org" wrote :
| 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).
|
My problems are mainly from missing API point of view - UID name, ScopeKey as param, AOP scoping domain, ...
Or which part you think is really misunderstood?
"adrian(a)jboss.org" wrote :
| 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.
We can probably support both.
Just need to work on the use cases of current impl - something we said before I went and hacked this initial code.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022431#4022431
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022431
17 years, 8 months
[Design the new POJO MicroContainer] - Re: Scoped Kernels
by adrian@jboss.org
"alesj" wrote : "adrian(a)jboss.org" wrote :
| | I think we mentioned this with aliases and inner un-named beans.
| | Any other place?
|
| I'm saying that even before then we (probably before you got involved)
| discussed not using ControllerContext.getName() as the key to store the state
| but use a ControllerContext.getId() which would be a system generated
| unique id. See UUID in the common module.
|
| It was discussed in the context of giving better error messages
| when two deployments have the same name for a context.
|
| Currently you get a failure upfront about trying to install a duplicate context
| when you should get a summary at the end saying one (or maybe both?) is not installed
| because it has a duplicate name.
|
| It also supports the "anonymous" bean concept better since the name becomes
| "optional". It is only used in the external api when somebody wants to do
| give me a context by name (e.g. an explicit dependency injection).
|
| But I think it is a bit too close to the JBoss5-beta2 release to do this
| refactoring at the moment.
| If you are going to do it, it would be better if it was on a branch in SVN.
| This is probably also true of the scoping development in general?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4022428#4022428
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4022428
17 years, 8 months