Hi devs, As suggested by Vincent, it would be cool not to have a distinct API for usage from velocity scripts, but pseudo-wrap the Java classes into a scriptable API using some uberspectors/introspectors. I like this idea a lot, as it is a bit hard to maintain two APIs (as the internal core is an API, just that it isn't directly scriptable), and with the new component architecture, the scriptable API would be completely unneeded. To remind, introspectors are used for finding the right methods to be called, given the target object, the method name, and the parameters; uberspectors must use introspector's results to construct velocity-specific objects for direct method calls ($something.methodCall()), getters (#set something = $object.getter), setters (#set $object.setter = something) and iterators (#foreach $iterator in something). During the last few days I wrote a chaining uberspector, that allows chaining several uberspectors, and a introspector chaining uberspector, that allows chaining several introspectors (not committed yet). The idea would be to have something like: [(introspector <- ... <- introspector)>- IntrospectorChainingUberspector <- Uberspector <- ... <- uberspector]>- ChainingUberspector Introspectors are chained in order to find or to filter out requested methods, then uberspectors use these methods to further enhance or restrict the method retrieving & calling process. So, a possible chain would be: BaseIntropector - finds methods using reflection. SecureIntrospector - filters out restricted objects/methods, like reflection, classloaders, threads/synchronization and the System class. ScriptableCheckIntrospector - blocks all direct calls to methods in the org.xwiki package that don't have an @Scriptable annotation. Note that it is possible to have calls to non-scriptable methods inside scriptable methods, as that is java code already, outside scripting. RightsCheckingIntrospector - uses the @Authorisation("accessright") annotations placed on our methods to perform rights checking. ProgrammingWrapIntrospector - not sure about this one, as I don't know how it could be implemented, but it would be nice to mimic all *WithProgrammingRights methods (like saveWithProgrammingRights), instead of literally having them in the java classes. ContextInjectionIntrospector - if no method was found, tries to find a method with an extra XWikiContext parameter. I must find a way to pass the request-specific XWikiContext (Vincent, any ideas?). This one is needed because all current API methods hide a non-scriptable method with almost the same signature, just an extra XWikiContext parameter at the end. This might not be needed if we completely get rid of the XWikiContext from the code before starting to use this chain. DeprecatedCheckIntrospector - logs deprecated method calls. IntrospectorChainingUberspector - calls the introspector chain and wraps the resulting methods into velocity objects (VelMethod, VelPropertyGet, VelPropertySet). ExceptionCatchingUberspector - catches all exceptions and puts them in the context (and logs them, too). ChainingUberspector - just allows having the uberspectors chain. I'm not sure if all those should be introspectors, or would be better as uberspectors instead. I didn't include the SecureUberspector in the chain, as besides the filtering done by the SecureIntrospector, it only checks if the returned iterator is restricted or not, and I don't think the iterators should ever be restricted. I don't know if the rights check should be left only to the introspector or not. Currently, this check is done mostly in the API classes only, suggesting that anything that happens in the java world is safe to execute, regardless of the access rights. Groovy doesn't need access rights check, as it requires programming rights from the start. XmlRpc should be a little more secure, but right now it doesn't use rights checks from the core classes anyway. So, any method we would like to be callable from Velocity should have an @Scriptable annotation. Rights checking could be performed entirely from an introspector. Any thoughts on this? -- Sergiu Dumitriu http://purl.org/net/sergiu/