Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.1.8
-
None
-
None
-
Operating System: other
Platform: Other
-
24964
Description
I'm not sure how far back in CVS this goes, but it would appear that the
SlideRepository component, when looked up from the component manager, is wrapped
in a ComponentProxy. The proxy exposes itself with the interfaces Component,
Repository which contain no methods.
SlideSource and SlidePrincipalProvider try "instanceof SlideRepository" and then
a cast to SlideRepository to be able to call the get*NamespaceAccessToken()
methods. Neither of these will work.
I found I needed to define these methods in the Repository interface, this
works, but I suspect it is not clean since the component role now contains slide
specific. I was considering trying to refactor this, but I cannot conceive what
actually has to be done here- if indeed the design is wrong in the first place.
I presume the reason the component proxy is generated is to further enforce
avalon ideals of interchangeable role implementations?
NB: Also broken appears to be the selector for the principal provider. I do not
know exactly why, but changing the class in the cocoon.xconf file from
DefaultServiceSelector to ExtendedComponentSelector seemed to fix this problem.
Perhaps something has gone wrong here somewhere in the change from Composables
-> Serviceables?
Werner Masik noted this problem on the users lists I believe.
SlideRepository component, when looked up from the component manager, is wrapped
in a ComponentProxy. The proxy exposes itself with the interfaces Component,
Repository which contain no methods.
SlideSource and SlidePrincipalProvider try "instanceof SlideRepository" and then
a cast to SlideRepository to be able to call the get*NamespaceAccessToken()
methods. Neither of these will work.
I found I needed to define these methods in the Repository interface, this
works, but I suspect it is not clean since the component role now contains slide
specific. I was considering trying to refactor this, but I cannot conceive what
actually has to be done here- if indeed the design is wrong in the first place.
I presume the reason the component proxy is generated is to further enforce
avalon ideals of interchangeable role implementations?
NB: Also broken appears to be the selector for the principal provider. I do not
know exactly why, but changing the class in the cocoon.xconf file from
DefaultServiceSelector to ExtendedComponentSelector seemed to fix this problem.
Perhaps something has gone wrong here somewhere in the change from Composables
-> Serviceables?
Werner Masik noted this problem on the users lists I believe.
Attachments
Attachments
Issue Links
- is depended upon by
-
COCOON-971 [Roadmap] General - NEXT release
-
- Closed
-