Generalizing supply/demand

[starksm64]

The current problem with using the ejb3 client deployer as a general client deployer is that its container bean is looking for suppliers of things like a jndi name binding. The problem is that supply/demand is a kernel bean specific notion. It does not show up in the Controller api. It shows up in the KernelController. The problem with this is that the jmx mbean service controller cannot express that its contexts supply the demands of an MC bean context. So when you have a legacy client application deployment that does not involve ejb3 components, there ends up being nothing to supply the demands of the client container bean.

Either supply/demand should just be a type of dependency where a demand maps onto a DependencyItem and supply maps to an alias, or we need the supply/demand notion to show up at the more general ControllerContext/Controller level to allow supply/demand to span different context implementations.

[alesj]

Can't we/they simply re-write those mbean to MC beans?
I'm in favor of encouraging people to use MC beans where ever possible, even if that means rewriting some code.

Demand already is a simple DependencyItem.
And I just extended it with some 'matching' notion.

[starksm64]

"alesj" wrote:
Can't we/they simply re-write those mbean to MC beans?

No.

'ales' wrote:

Demand already is a simple DependencyItem.
And I just extended it with some 'matching' notion.

I don't see how an mbean can satisfy the demand of an mc bean with the current spi because the matching of demand to supply does not use the mc bean independent apis.

[alesj]

"alesj" wrote:
Can't we/they simply re-write those mbean to MC beans?

No.

Uf. :-)
btw: why not?

'ales' wrote:

Demand already is a simple DependencyItem.
And I just extended it with some 'matching' notion.

I don't see how an mbean can satisfy the demand of an mc bean with the current spi because the matching of demand to supply does not use the mc bean independent apis.

It can't. :-)
It can only demand whatever with legacy 'demand' element.
I have no objections with moving demand/supply notion to our dependency module. Although this bloats simple 'state machine' impl in dependency.

[starksm64]

"alesj" wrote:

Uf. :-)
btw: why not?

Because its unnecessary busy work. What's the point of a multi-container kernel if you don't use multiple container types?

'ales' wrote:

It can't. :-)
It can only demand whatever with legacy 'demand' element.
I have no objections with moving demand/supply notion to our dependency module. Although this bloats simple 'state machine' impl in dependency.

If supply/demand are to be mc bean specific it simply cannot be used as a cross-container mechanism. It seems like this can be replaced with a dependency on an alias, in which case, that is how the mc supply/demand should be implemented.

[alesj]

Because its unnecessary busy work. What's the point of a multi-container kernel if you don't use multiple container types?

That's why I was asking if there is a tool to do this for you. :-)
Not all container shoes fit all container feet. ;-)
You don't want to push all features to all impls/legacy.

If supply/demand are to be mc bean specific it simply cannot be used as a cross-container mechanism. It seems like this can be replaced with a dependency on an alias, in which case, that is how the mc supply/demand should be implemented.

Yes, this is a legit/current workaround.
You can add an alias to mbean, which will work as a supply for any MC bean.

[adrian.brock]

It can only demand whatever with legacy 'demand' element.
I have no objections with moving demand/supply notion to our dependency module. Although this bloats simple 'state machine' impl in dependency.
If supply/demand are to be mc bean specific it simply cannot be used as a cross-container mechanism. It seems like this can be replaced with a dependency on an alias, in which case, that is how the mc supply/demand should be implemented.

There already is an abitrary alias mechanism in the ControllerContext.

The Demand/Supply mechanism predates this and is probably obsolete
now with the full alias dependency mechanism that Ales did a couple of months ago.

i.e. you can change supply -> alias and demand -> depends

On the cross controller issue, that's just an implementation detail.

It's only implemented in the KernelController because I'm lazy
I didn't want to create another object in the kernel bootstrap e.g. SupplyRegistry
to hold the registrations.

It has nothing to do with the controller, it is just a registry that is integrated
into the dependency mechanism by being a KernelRegistryPlugin.
i.e. The KernelController just happens to implement KernelRegistryPlugin
so it can say when Supplies are there.