Automatic Scoped Kernels - A good idea

[adrian.brock]

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.

[alesj]

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.

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?

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.

[adrian.brock]

"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.

[starksm64]

I would like to see the scoped kernel notion overviewed in the context of the existing architecture as it seems its too much of a piecewise prototype at this point. The main sticking points are namespaces, cross kernel dependencies, and relation to type systems/class loaders.

[adrian.brock]

I would like to see the scoped kernel notion overviewed in the context of the existing architecture as it seems its too much of a piecewise prototype at this point. The main sticking points are namespaces, cross kernel dependencies, and relation to type systems/class loaders.

And AOP Domains (scoped AOP metadata/aspect manager).