Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Can you elaborate on "looks like"? If we load the roles files from the classpath, this means we define a naming contract for these files, e.g. either org/apache/cocoon/cocoon.roles as of today or META-INF/services/org.apache.cocoon.core.RoleManager.
So files that "look like" roles file are very likely to be actual role files and nothing else :-)
Yepp, that's true - hmm, hmm, ahh,
:-D
what if I just want to drop
a particular jar into cocoon as it contains some nice classes.
And of course this jar contains such a roles file, but I don't
want to get the components added to cocoon; i just want to
use the classes. :)
A component isn't added to Cocoon unless it is explicitely declared in the xconf file. Ah yes, there's also the implicit declaration when a role has a default-class. But this implicit declaration only happens when the code looks up the component, meaning it does more that just using the classes ;-)
Ok, I admit this is very rare - hmm, let me see what other arguments might be against your approach...hmm
Ah, if we scan for all role files contained in the jar, all
of these roles are added to the root service manager. But
perhaps I want to restrict the access to those components
by adding them somewhere down in the hierarchy. This
only works by explicitly declaring them, e.g. in the sitemap.
Mmmh... what does "restrict the access" mean? If the class exists in the jar, anyone can use the component by adding an inline role in their xconf (<component-instance role="..."/>).
The only way we can really restrict access, is by having a per-sitemap classloader or... real blocks!
Try again ;-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
