Hi Vincent, Vincent Massol wrote: see http://dev.xwiki.org/xwiki/bin/view/Design/AnnotationFeature (solution n°3) The prototype character filter only accept roman alphabet characters and numbers. Indeed this is bad because it hurts internationalization. I simply forget this aspect, so I propose that the DefaultCharacterFilter only refuse characters that has a special meaning for the wiki syntax concerned and separators characters. The prototype also uppercase all characters, I don't remember why I added this process, I can't justify this choice now, so I will remove it. First of all I precise that the marks are not inserted definitely in the document content. The wiki document content is not modified. Prototype insert marks in a copy of the document content string, and then trigger a rendering on obtained string. The marks aren't related to a wiki syntax they are symbolic and they only make sens inside annotation plugin ( so I don't use (% param=value %) ). The marks should not be interpreted by any parser because they allow us to retrieve the selection limit after the rendering has been processed. So it's important to retrieve them after the rendering exactly in the same state that we inserted them. So the system works independently of the synthax used. Almost in fact because we supposed that syntaxes use non alphanumeric characters for formatting information. Indeed a more elegant solution should be to use the XDOM by inserting the annotation in it, but this require to associate to offset and length of the selection in the wiki document content a couple of node (initial / final) and related offsets. According to me this is impossible (or hard to maintain) because current rendering system do not integrate offset concept, so we are not able to determine where a given character in the wiki document content is located in the XDOM (node + offset inside the node). By the way, it would be great to add this capability to XWiki Babel specs. :) In order to fix this problem I split the span if needed. <h1><span></h1><p></span></p> becomes <h1><span></span></h1><p><span></span></p> Symbolic marks are replaced by span markups. Theses span aims to highlight the selection range. This not done by a new renderer but simply by a pattern replacement on the rendering string result. Yes of course I explained it wrong, these 3 features are located in the same plugin. Moreover there is no need for a plugin, so I agree to make it a component. Ok, I will see that. Thank you for your support!

On May 18, 2009, at 2:32 PM, Fabio Mancinelli wrote: Hi everybody. I managed to implement what I was proposing. * Now every JAXRS entity (i.e., resource, provider or exception mapper) is declared as a component having the role defined by the XWikiRestComponent interface. * The component manager is used to lookup all the components implementing that role for registering them. * A custom factory is used for instantiating components when JAXRS requests them. Instantiation, of course, is a lookup using the component manager. * Component deallocation is done seamlessly. Now, in order to extend the REST Api you just need to write a @Component annotated class that Implements XWikiRestComponent (or extends XWikiResource in order to have for free all the relevant variables for interacting with the wiki). The only constraint is that the hint of the @Component must be the fully qualified name of the annotated class (this is needed because of the lookup logic). Of course a META-INF/components.txt listing all the @Component classes should also be packaged in the jar. Once you have such a jar, you just throw it in WEB-INF/lib and you have your resources published (no need to edit web.xml anymore) Cheers, Fabio P.S. : You can see the example here : http://pastebin.com/m2187c62a

On May 18, 2009, at 6:52 PM, Vincent Massol wrote: At registration time, I have to tell Restlet/JAXRS what are the java.lang.Classes that implement JAXRS entities. So, at startup, I basically do this for registering components once for all: List<XWikiRestComponent> components = componentManager.lookupList(XWikiRestComponent.class); for (XWikiRestComponent component : components) { jaxRsClassed.add(component.getClass()) } During normal operation, Restlet/JAXRS starts calling the object factory through the method public <T> T getInstance(Class<T> clazz) throws InstantiateException whenever it needs an instance of a given class. So, in order to lookup a component, I just have the class name to be used as a way for identifying it. What I do is: componentManager.lookup(XWikiRestComponent.class, clazz.getName()); That's the reason why the hint if the FQN of the class. If I don't use the FQN I would have to create a mapping class- Doable but more complicated, so I just delegated the responsibility to the programmer to declare things in the right way :) Cheers, Fabio

On May 18, 2009, at 7:39 PM, Vincent Massol wrote: Yes. The first lookup is only needed in order to retrieve class names and not the objects. In fact I release all the objects right after the lookup. Actual objects are allocated on demand later by using the factory. It's the restlet plumbing that does that (afaik, it's one object per request) -Fabio