Finally some time to answer ... been batteling VFS hell. :-) "obrien" wrote : | 1. search itself doesn't have any concept of precedence/relationship of two scopes and respective deployment, ie. possible to pick up wrong bean. | It somehow has the hierarchy, determined by the scope levels; see PreInstallAction. But you have to be strict, the mechanism is pretty dumb. So yes, you can easily pickup wrong bean. "obrien" wrote : | I'll solved that for now by provisioning custom LookupStrategy, but within the kernel structure there's not sense of the deployment structure. For example is there easy way how to pickup beans from particular deployment (from jboss-beans.xml for example)? | You could mock this by putting particular deployment into unique scope. "obrien" wrote : | 2. That leads to the <scope%gt> we've discussed and I think it doesn't make sense to create it in such a manner. | | To provide some generalized control of scoping to application developer I realized it would be better to have it on deployment level. Something like this: | | | | <deployment scoped="true" name="myApp" xmlns="urn:jboss:bean-deployer:3.0"> | | | | where scoping could be enabled by default. Then it would be just matter to create nested deployments and define visibility/relationship rules between them. | You can do this with deployment's annotations; they are then inherited by beans. "obrien" wrote : | 3. Rules are needed for merging of deployment scopes(along two different physical deployments). | Same scope key == same scoped controller. "obrien" wrote : | 4. In such a case Kernel/Controller reference handed over to the application (for example WAR file), would represent just its deployment scope, with resolving functionality by default to be upwards in the structure (as it's currently). | Might not be a bad idea. "obrien" wrote : | 5. Then concept of the ObjectName as it was used within JMX microkernel could be recreated to support something like maindeployment.subdepl:name=myBean to define cross-scope references. | This is just one way of determining scope. Should be more flexible. "obrien" wrote : | 6. And to get this to the extreme, it might be then possible to create RemoteDeployment where the given scope doesn't have to part of the same JVM. with clever mixing of VFS delegation to the other kernel, aspects and bit of dark magic that could work :) | MC runs of VFS, so if we're really FS agnostic, this should then run ootb - we don't care where VFS comes from. "obrien" wrote : | *. Which leads me to the question, if there is currently way how to 'include' other XML deployment descriptor? | Wildcards? "obrien" wrote : | To stay real, there's a small bit I can try to implement - AbstractKernelController to have support to return scope context, because I don't see other way than lookup strategy to get to the scoped beans. This is a huge overhaul of the system. And as such it's more of a feature than real requirement. I'll ping you here when we put this on the dev forum. Like I already mentioned, this spreads from MDR, unique naming, Deployers, ... Each of them should properly address possible scoping. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207396#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...