You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stanbol.apache.org by Olivier Grisel <ol...@ensta.org> on 2011/04/04 15:28:05 UTC
STANBOL-120: HTTP refactoring finally merged to trunk!
Hi all,
I have finally managed to merge the HTTP endpoint refactoring branch to trunk.
I plan to write a hands on developer guide on the stanbol site to help
other developers use this modular JAX-RS services + webapp but won't
have time before the IKS review meeting this week. In the mean time
here is a quick overview of the system:
https://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/web/README.txt
As I know people are lazy and won't click on my link, here is a copy
and paste of the content of this file:
Stanbol HTTP Endpoints
======================
The following bundles provide the base infrastructure for building a
consistent set JAX-RS based HTTP endpoints (RESTful webservices) to
publish services implemented by the various OSGi bundles of a Stanbol
distribution.
The general convention is to make each endpoint self-documented by
implementing a @GET annotated method that "Accept: text/html" and return
an HTML page that explains how the endpoint works and give usage examples
with the `curl` commandline tool and HTML forms to quickly test the
service from inside the browser.
- `stanbol/commons/web/base` provides the java interface and OSGi /
JAX-RS context
bridging tooling but not actual JAX-RS resources
- `stanbol/commons/web/home` provides a simple resource for the home page and
default CSS / icons and base freemarker template to be reused by other Stanbol
JAX-RS resources for consistent look and feel accross the all documentation.
- `stanbol/commons/web/sparql` provides a sample JAX-RS resource to publish
access to the registered clerezza triple stores using the standardized SPARQL
HTTP endpoint API.
TODO: write the documentation to contribute new endpoints that reuse the styling
and menu navigation of the default components.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Olivier Grisel <ol...@ensta.org>.
2011/4/5 Alessandro Adamou <ad...@cs.unibo.it>:
>
>> You don't need to merge rules related UI into the commons. Just
>> rewrite you endpoint to use the new infrastructure. Have a look at
>> stanbol/enhancer/jersey for an example.
>
> Okay.
>
>> There is indeed a new top-level "launchers" folder that include a
>> "mini" launcher (that was useful for quick launch / test during
>> development: it just contains the basic infra and http endpoints
>> without any enhancer what so ever). We should probably get rid of it
>> and move the lite and full launchers to the top-level instead.
>
> Ok. In the meantime I moved the commons build in the Stanbol reactor right
> before enhancer and entityhub. This should fix the issue that made Jenkins
> go berserk.
Ah alright, thanks for the fix.
>> We can do this together this week during the Saarbrücken workshops.
>
> I am following from Amsterdam, so I figure we can work this out remotely,
> also with my CNR mates attending the hackathon. Are you using the #iks
> channel for hackathon discussions?
I think stanbol related discussions will rather go to the #stanbol
room but I am also connected to the #iks room.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
> You don't need to merge rules related UI into the commons. Just
> rewrite you endpoint to use the new infrastructure. Have a look at
> stanbol/enhancer/jersey for an example.
Okay.
> There is indeed a new top-level "launchers" folder that include a
> "mini" launcher (that was useful for quick launch / test during
> development: it just contains the basic infra and http endpoints
> without any enhancer what so ever). We should probably get rid of it
> and move the lite and full launchers to the top-level instead.
Ok. In the meantime I moved the commons build in the Stanbol reactor
right before enhancer and entityhub. This should fix the issue that made
Jenkins go berserk.
> We can do this together this week during the Saarbrücken workshops.
I am following from Amsterdam, so I figure we can work this out
remotely, also with my CNR mates attending the hackathon. Are you using
the #iks channel for hackathon discussions?
Alessandro
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Olivier Grisel <ol...@ensta.org>.
2011/4/4 Alessandro Adamou <ad...@cs.unibo.it>:
> Thanks Olivier! Updating now and looking forward to merging the remaining
> kres/jersey classes in there.
You don't need to merge rules related UI into the commons. Just
rewrite you endpoint to use the new infrastructure. Have a look at
stanbol/enhancer/jersey for an example.
> Does this checkin also include the toplevel launchers you mentioned in
> STANBOL-135 yet?
There is indeed a new top-level "launchers" folder that include a
"mini" launcher (that was useful for quick launch / test during
development: it just contains the basic infra and http endpoints
without any enhancer what so ever). We should probably get rid of it
and move the lite and full launchers to the top-level instead.
We can do this together this week during the Saarbrücken workshops.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Thanks Olivier! Updating now and looking forward to merging the
remaining kres/jersey classes in there.
Does this checkin also include the toplevel launchers you mentioned in
STANBOL-135 yet?
Alessandro
On 4/4/11 3:28 PM, Olivier Grisel wrote:
> Hi all,
>
> I have finally managed to merge the HTTP endpoint refactoring branch to trunk.
>
> I plan to write a hands on developer guide on the stanbol site to help
> other developers use this modular JAX-RS services + webapp but won't
> have time before the IKS review meeting this week. In the mean time
> here is a quick overview of the system:
>
> https://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/web/README.txt
>
> As I know people are lazy and won't click on my link, here is a copy
> and paste of the content of this file:
>
> Stanbol HTTP Endpoints
> ======================
>
> The following bundles provide the base infrastructure for building a
> consistent set JAX-RS based HTTP endpoints (RESTful webservices) to
> publish services implemented by the various OSGi bundles of a Stanbol
> distribution.
>
> The general convention is to make each endpoint self-documented by
> implementing a @GET annotated method that "Accept: text/html" and return
> an HTML page that explains how the endpoint works and give usage examples
> with the `curl` commandline tool and HTML forms to quickly test the
> service from inside the browser.
>
> - `stanbol/commons/web/base` provides the java interface and OSGi /
> JAX-RS context
> bridging tooling but not actual JAX-RS resources
>
> - `stanbol/commons/web/home` provides a simple resource for the home page and
> default CSS / icons and base freemarker template to be reused by other Stanbol
> JAX-RS resources for consistent look and feel accross the all documentation.
>
> - `stanbol/commons/web/sparql` provides a sample JAX-RS resource to publish
> access to the registered clerezza triple stores using the standardized SPARQL
> HTTP endpoint API.
>
> TODO: write the documentation to contribute new endpoints that reuse the styling
> and menu navigation of the default components.
>
>
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Apr 4, 2011 at 3:28 PM, Olivier Grisel <ol...@ensta.org> wrote:
> I have finally managed to merge the HTTP endpoint refactoring branch to trunk...
Note that startup doesn't work, or not reliably for me since those
changes, see STANBOL-142
-Bertrand
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
Hi,
>>> ** JenaModelWriter : serializes a Jena Model into {"application/rdf+xml",
>>> "application/xml", "text/xml"}
>>> ** JSONJenaWriter, perhaps we could use JsonLdSerializerProvider from
>>> commons.web.home instead?
>> You can contribute your own serializers. Have a look at
>> entityhub/jersey which also contributes some serializers. And of
>> course you should re-use serializer where appropriate.
We already have custom serializers in web modules, but the
JenaModelWriter is used by three of them altogether. Since it serializes
a Jena Model it could be useful, so I eventually put it in
commons.web.base whereas JSONJenawriter has been dropped altogether.
> To be more precise, now the bundle context is forward into the
> servletcontext and you can fetch any OSGi service using the following
> snippet:
>
> jobManager =
> ContextHelper.getServiceFromContext(EnhancementJobManager.class,
> context);
> tcManager =
> ContextHelper.getServiceFromContext(TcManager.class, context);
> serializer =
> ContextHelper.getServiceFromContext(Serializer.class, context);
>
> I plan to extend the context lookup of the jersey resources to be able
> to inject singleton OSGi services using the @Context annotation
> instead but this is not implemented yet.
Ok good. Temporarily I am registering the two classes in the commons.web
jersey endpoint, but will switch to this method as soon as I get the
hang of it.
>> So these are non-standard mime-types not defined by any class yet? I
>> think yes - such things should be moved to commons/base.
> Yes we should centralize all those mimetypes in commons/web/base,
> while not duplicating what's already provided by Clerezza
Done that, there's an extension of MediaType in commons.web.base now.
Alessandro
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Olivier Grisel <ol...@ensta.org>.
2011/4/6 Fabian Christ <ch...@googlemail.com>:
> Hi,
>
> 2011/4/6 Alessandro Adamou <ad...@cs.unibo.it>:
>> I would like to ask for some opinion/advice on classes that should be moved
>> out of kres.jersey :
>>
>> * Writers: there are some in commons.base that we had as ducplicates and
>> will gladly drop in favor of common ones. There are a few more in
>> kres.jersey, though:
>> ** JenaModelWriter : serializes a Jena Model into {"application/rdf+xml",
>> "application/xml", "text/xml"}
>> ** JSONJenaWriter, perhaps we could use JsonLdSerializerProvider from
>> commons.web.home instead?
>
> You can contribute your own serializers. Have a look at
> entityhub/jersey which also contributes some serializers. And of
> course you should re-use serializer where appropriate.
Yes, and +1 for using JSON-LD every where as the default JSON
serialization of RDF Graphs.
>> * JerseyEndpoint : we register Clerezza TcManager and Serializer with the
>> servlet context. Perhaps this could be done in the commons.web jersey
>> endpoint?
>
> Have a look at entityhub/jersey and see how this is done there.
To be more precise, now the bundle context is forward into the
servletcontext and you can fetch any OSGi service using the following
snippet:
jobManager =
ContextHelper.getServiceFromContext(EnhancementJobManager.class,
context);
tcManager =
ContextHelper.getServiceFromContext(TcManager.class, context);
serializer =
ContextHelper.getServiceFromContext(Serializer.class, context);
I plan to extend the context lookup of the jersey resources to be able
to inject singleton OSGi services using the @Context annotation
instead but this is not implemented yet.
>> * KRFormat: we have this class with MIME constants for formats such as
>> RDF/XML, OWL/XML, manchester OWL, Turtle, RDF/JSON, OWL functional syntax
>> etc. We use it extensively in former Kres webservices, would it make sense
>> to move to commons.web?
>
> So these are non-standard mime-types not defined by any class yet? I
> think yes - such things should be moved to commons/base.
Yes we should centralize all those mimetypes in commons/web/base,
while not duplicating what's already provided by Clerezza.
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Fabian Christ <ch...@googlemail.com>.
Hi,
2011/4/6 Alessandro Adamou <ad...@cs.unibo.it>:
> I would like to ask for some opinion/advice on classes that should be moved
> out of kres.jersey :
>
> * Writers: there are some in commons.base that we had as ducplicates and
> will gladly drop in favor of common ones. There are a few more in
> kres.jersey, though:
> ** JenaModelWriter : serializes a Jena Model into {"application/rdf+xml",
> "application/xml", "text/xml"}
> ** JSONJenaWriter, perhaps we could use JsonLdSerializerProvider from
> commons.web.home instead?
You can contribute your own serializers. Have a look at
entityhub/jersey which also contributes some serializers. And of
course you should re-use serializer where appropriate.
> * JerseyEndpoint : we register Clerezza TcManager and Serializer with the
> servlet context. Perhaps this could be done in the commons.web jersey
> endpoint?
Have a look at entityhub/jersey and see how this is done there.
> * KRFormat: we have this class with MIME constants for formats such as
> RDF/XML, OWL/XML, manchester OWL, Turtle, RDF/JSON, OWL functional syntax
> etc. We use it extensively in former Kres webservices, would it make sense
> to move to commons.web?
So these are non-standard mime-types not defined by any class yet? I
think yes - such things should be moved to commons/base.
- Fabian
> Thanks
>
> Alessandro
>
>
> On 4/4/11 3:28 PM, Olivier Grisel wrote:
>>
>> Hi all,
>>
>> I have finally managed to merge the HTTP endpoint refactoring branch to
>> trunk.
>>
>> I plan to write a hands on developer guide on the stanbol site to help
>> other developers use this modular JAX-RS services + webapp but won't
>> have time before the IKS review meeting this week. In the mean time
>> here is a quick overview of the system:
>>
>>
>> https://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/web/README.txt
>>
>> As I know people are lazy and won't click on my link, here is a copy
>> and paste of the content of this file:
>>
>> Stanbol HTTP Endpoints
>> ======================
>>
>> The following bundles provide the base infrastructure for building a
>> consistent set JAX-RS based HTTP endpoints (RESTful webservices) to
>> publish services implemented by the various OSGi bundles of a Stanbol
>> distribution.
>>
>> The general convention is to make each endpoint self-documented by
>> implementing a @GET annotated method that "Accept: text/html" and return
>> an HTML page that explains how the endpoint works and give usage examples
>> with the `curl` commandline tool and HTML forms to quickly test the
>> service from inside the browser.
>>
>> - `stanbol/commons/web/base` provides the java interface and OSGi /
>> JAX-RS context
>> bridging tooling but not actual JAX-RS resources
>>
>> - `stanbol/commons/web/home` provides a simple resource for the home page
>> and
>> default CSS / icons and base freemarker template to be reused by other
>> Stanbol
>> JAX-RS resources for consistent look and feel accross the all
>> documentation.
>>
>> - `stanbol/commons/web/sparql` provides a sample JAX-RS resource to
>> publish
>> access to the registered clerezza triple stores using the standardized
>> SPARQL
>> HTTP endpoint API.
>>
>> TODO: write the documentation to contribute new endpoints that reuse the
>> styling
>> and menu navigation of the default components.
>>
>>
>
>
--
Fabian
Re: STANBOL-120: HTTP refactoring finally merged to trunk!
Posted by Alessandro Adamou <ad...@cs.unibo.it>.
I would like to ask for some opinion/advice on classes that should be
moved out of kres.jersey :
* Writers: there are some in commons.base that we had as ducplicates and
will gladly drop in favor of common ones. There are a few more in
kres.jersey, though:
** JenaModelWriter : serializes a Jena Model into
{"application/rdf+xml", "application/xml", "text/xml"}
** JSONJenaWriter, perhaps we could use JsonLdSerializerProvider from
commons.web.home instead?
* JerseyEndpoint : we register Clerezza TcManager and Serializer with
the servlet context. Perhaps this could be done in the commons.web
jersey endpoint?
* KRFormat: we have this class with MIME constants for formats such as
RDF/XML, OWL/XML, manchester OWL, Turtle, RDF/JSON, OWL functional
syntax etc. We use it extensively in former Kres webservices, would it
make sense to move to commons.web?
Thanks
Alessandro
On 4/4/11 3:28 PM, Olivier Grisel wrote:
> Hi all,
>
> I have finally managed to merge the HTTP endpoint refactoring branch to trunk.
>
> I plan to write a hands on developer guide on the stanbol site to help
> other developers use this modular JAX-RS services + webapp but won't
> have time before the IKS review meeting this week. In the mean time
> here is a quick overview of the system:
>
> https://svn.apache.org/repos/asf/incubator/stanbol/trunk/commons/web/README.txt
>
> As I know people are lazy and won't click on my link, here is a copy
> and paste of the content of this file:
>
> Stanbol HTTP Endpoints
> ======================
>
> The following bundles provide the base infrastructure for building a
> consistent set JAX-RS based HTTP endpoints (RESTful webservices) to
> publish services implemented by the various OSGi bundles of a Stanbol
> distribution.
>
> The general convention is to make each endpoint self-documented by
> implementing a @GET annotated method that "Accept: text/html" and return
> an HTML page that explains how the endpoint works and give usage examples
> with the `curl` commandline tool and HTML forms to quickly test the
> service from inside the browser.
>
> - `stanbol/commons/web/base` provides the java interface and OSGi /
> JAX-RS context
> bridging tooling but not actual JAX-RS resources
>
> - `stanbol/commons/web/home` provides a simple resource for the home page and
> default CSS / icons and base freemarker template to be reused by other Stanbol
> JAX-RS resources for consistent look and feel accross the all documentation.
>
> - `stanbol/commons/web/sparql` provides a sample JAX-RS resource to publish
> access to the registered clerezza triple stores using the standardized SPARQL
> HTTP endpoint API.
>
> TODO: write the documentation to contribute new endpoints that reuse the styling
> and menu navigation of the default components.
>
>