DO NOT REPLY [Bug 24964] New: - broken SlideRepository <-> SlideSourceFactory / SlidePrincipalProvider

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24964>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24964

broken SlideRepository <-> SlideSourceFactory / SlidePrincipalProvider

           Summary: broken SlideRepository <-> SlideSourceFactory /
                    SlidePrincipalProvider
           Product: Cocoon 2
           Version: Current CVS 2.1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: general components
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: samc@atnet.net.au


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.