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.
Cheers,
Reto
