-
15. Re: How to hide a bean from other deployments?
Not really. :-)
You already figured it out. ;-) It's just the AbstractInjectionDependencyMetaData.
You just need to properly fix its DependencyItem and getValue lookup.
Well, easier to figure out, but not so much to finish it. I've started with the added attribute search for the element and know that the DependencyItem I need is instantiated within AbstractDependencyValueMetaData.initialVisit(). What I'm not sure is how to propagate the Search object to the dependency item and don't mess up design constraints elsewhere.
Obvious solution would be to call setSearch() and then use it within AbstractDependencyItem.resolve() to call appropriate lookup strategy, default if it's null;
Does it make sense? Because, to be honest, your comment to change getValue is not ringing any bells here.
Also, is every controller instance a GraphController? -
16. Re: How to hide a bean from other deployments?
wrong HTML formatting
I'm using currently following notation<inject name="holder1" search="top"/>
-
17. Re: How to hide a bean from other deployments?
"obrien" wrote:
Well, easier to figure out, but not so much to finish it. I've started with the added attribute search for the element <inject/> and know that the DependencyItem I need is instantiated within AbstractDependencyValueMetaData.initialVisit(). What I'm not sure is how to propagate the Search object to the dependency item and don't mess up design constraints elsewhere.
We need a new dependency item.
Or actually moving/copying the existing SearchDependencyItem to AbstractDependencyValueMetaData."obrien" wrote:
Obvious solution would be to call setSearch() and then use it within AbstractDependencyItem.resolve() to call appropriate lookup strategy, default if it's null;
Yes.
Or perhaps instead of null use default LookupStrategy,
this way you don't need to write a null check."obrien" wrote:
Also, is every controller instance a GraphController?
Currently yes.
But if it's not, simply throw an exception saying it must be in order to use search notion. -
18. Re: How to hide a bean from other deployments?
"obrien" wrote:
wrong HTML formatting
I'm using currently following notation<inject name="holder1" search="top"/>
Yeah, that fine. -
19. Re: How to hide a bean from other deployments?
Now it makes sense. I got the piece before but couldn't the whole picture.
Will finish it tonight and send you diff. -
20. Re: How to hide a bean from other deployments?
"obrien" wrote:
Will finish it tonight and send you diff.
Great!
I'll then make sure we optimize on the code usage.
e.g. single SearchDependencyItem -
21. Re: How to hide a bean from other deployments?
Here it is
http://www2.laststation.net/temp/scrap/7d/inject_search.patch
patch (not svn diff). It really was dead simple after all. I would try to check existing unit tests, but after few failures realized it's probably related to other development.
Have edited original (2.0) XSD (as I don't know what plans you have with the versioning)
Thanks for showing me around, I do appreciated it - good to play with something really interesting for a change. -
22. Re: How to hide a bean from other deployments?
attribute use should be of course optional, not required
<xsd:attribute name="type" type="searchTypeType" use="required" default="DEFAULT"/>
-
23. Re: How to hide a bean from other deployments?
"obrien" wrote:
Thanks for showing me around, I do appreciated it
NP, thank you for doing it. ;-)
There is more if you like it. :-)
Check JIRA if you find something that would interest you,
and we can discus it the same way as we did this."obrien" wrote:
- good to play with something really interesting for a change.
:-) -
24. Re: How to hide a bean from other deployments?
"obrien" wrote:
attribute use should be of course optional, not required<xsd:attribute name="type" type="searchTypeType" use="required" default="DEFAULT"/>
Nah, np, I'll fix that.
I'll check it out tomorrow in details,
just about to finally fix VFS's temp handling. :-) -
25. Re: How to hide a bean from other deployments?
Will do, but now I need to write integration for RESTEasy (that's why I got into the scoping originally).
-
26. Re: How to hide a bean from other deployments?
This is now done.
- https://jira.jboss.org/jira/browse/JBMICROCONT-406
It took a bit more than just that patch. :-)
And, DML, I also updated BMDB to be able to use
search in inject or add annotation metadata to property. -
27. Re: How to hide a bean from other deployments?
"alesj" wrote:
This is now done.
- https://jira.jboss.org/jira/browse/JBMICROCONT-406
It took a bit more than just that patch. :-)
And, DML, I also updated BMDB to be able to use
search in inject or add annotation metadata to property.
proper integration :). Thanks for that.
I spend some time last night designing the integration with RESTEasy and realized scoping really needs significantly more work. This is total science fiction and terminology is most likely mixed, but :
1. search itself doesn't have any concept of precedence/relationship of two scopes and respective deployment, ie. possible to pick up wrong bean.
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)?
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.
3. Rules are needed for merging of deployment scopes(along two different physical deployments).
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).
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.
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 :)
*. Which leads me to the question, if there is currently way how to 'include' other XML deployment descriptor?
--
And don't ask me what I'm trying to implement :) now it's time to see my shrink.
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. -
28. Re: How to hide a bean from other deployments?
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.