Hi Luciano, I've created WINK-351 and attached the patch to it.
After wink has been compiled with the patch you can: cd wink-examples/ext/OSGi/ mvn pax:run This should start an OSGi environment with the needed bundles, if all goes well you will be greeted at http://localhost:8080/demo/jaxrs/greeting?name=Luciano Cheers, Reto On Thu, Sep 8, 2011 at 6:49 PM, Reto Bachmann-Gmür <[email protected]> wrote: > > On Sep 8, 2011 6:39 PM, "Luciano Resende" <[email protected]> wrote: >> >> On Fri, Sep 2, 2011 at 1:06 PM, Reto Bachmann-Gmür <[email protected]> >> wrote: >> > On Fri, Sep 2, 2011 at 6:22 PM, Luciano Resende <[email protected]> >> > wrote: >> > ... >> >>> The second requirements might need a bit more explanation. In sling >> >>> servlets are typically bound to a type of JCR-resources even though >> >>> this goes beyond the jax-rs spec it would be nice to bind jax-rs style >> >>> classes to such a JCR-resource type, the patch I attached to >> >>> SLING-2192 allows this, see my blog post [2] for an example usage. >> >>> Similarly in Clerezza jax-rs style resource can be bound to an >> >>> RDF-Type [3]. >> >>> >> >> >> >> As for your second example, maybe a simple way would be to have >> >> JCR-resource types defined as specific media types, in this way, you >> >> could envision having a single endpoint for CRUD operations in your >> >> JCR repository to work based on the media type being requested. WDYT ? >> > >> > Hi Luciano, >> > >> > I must admit that I don't know as much of jcr and sling as I know >> > about clerezza. Not sure if I understand you correctly, but the >> > jcr:type of resource (which can be an arbitrary string) seems >> > orthogonal to the media type: on one hand we have the selection of the >> > root-resource on the other the production of an appropriate >> > representation. >> > >> > Sling has a mechanism that has shown to work well that associates code >> > handling the request to a specific URI, without changing this >> > mechanism I'd like support for jax-rs root resource like classes >> > ("like" because the @Path-Annotation are missing or ignored) as an >> > alternative to servlets or scripts. I think Wink should not directly >> > support other ways to bind resource-classes to URI than @Path, but it >> > should provide an easy way for frameworks integrating wink (like sling >> > or clerezza) to support other mechanisms. >> > >> > To avoid osgi-dependencies in wink-server I suggest providing an >> > wink-osgi-service bundle that provides a service with the following >> > methods >> > >> > //handles a request using previously bound root resources >> > void handleRequest(HttpServletRequest request, HttpServletResponse >> > response) >> > >> > //that's the method that allows easy integration with Sling or Clerezza >> > void handleRequest(HttpServletRequest request, HttpServletResponse >> > response, Object rootResource) >> > >> > //bind root resource or provider, binding classes seems against OSGi >> > architecture >> > void bindComponent(Object component) >> > >> > void unbindComponent(Object component) >> > >> > //framework supporting other request processing mechanism can use this >> > method to check if Wink can handle a request (with the currently bound >> > root resources) >> > boolean hasRootResourceForUriPath(String uriPath) >> > >> > Do you think a new module providing such a bundle and service would >> > fit into Wink? If so I'll open an issue and attach a patch to it. It >> > can be implemented without modifying other code, even though in future >> > the existing RequestProcessor might be adapted for a more seamless >> > integration. >> >> Is this new module have any Sling or Clerezza dependencies ? >> > No. > > Reto >
