Hi, For the ongoing discussion about SLING-2192 it would be great if I could get some feedback on the patch I propose for WINK-351 as to be able to estimate if and when this could become part of wink. The patch would greatly simplify the task of integrating wink into Sling or Clerezza.
Cheers, Reto On Sat, Sep 17, 2011 at 1:38 PM, Reto Bachmann-Gmür <[email protected]> wrote: > 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 > > >
