Hi Reto, all
Three other things we should take care about in this branch are:
1. Separate RESTful interface and the default UI: I would like to have
the (optional) ability to deploy the RESTful services of a Stanbol
component without the default UI (e.g. the Enahncer without the
possibility to submit text via the HTTP UI). I am not sure if this
requires anything in commons. Most likely this needs only some
refactoring in the JAX-RS resources of the components.
2. Exception Handling: I would like to have our own JAX-RS writer for
Exceptions (overwriting the default one) that
a. detects permission related Exceptions and reports with 401
instead of the generic 500
b. supports responding Exceptions as RDF data if the Accept header
is any RDF serialization
c. supports responding Exceptions as JSON. Actually JSON-LD, but
with a nicer context.
d. optionally also nicer messages for HTML and text pain
3. making the Stanbol default UI skinable. At least taking care that
the static resources and the css templates are in an module that does
not contain any code, so that people that want to use a different code
do only need to replace this bundle with an other one. I would also
like to add the ability to use some kind of "ranking" mechanism to the
resource loading service(s). This would allow users to deploy both
their own skin as well as the default one to have fall-back support
for things they have not modified in their skin.
best
Rupert
best
Rupert
On Sat, Jun 8, 2013 at 12:54 PM, Reto Bachmann-Gmür <[email protected]> wrote:
> On Sat, Jun 8, 2013 at 10:08 AM, Rupert Westenthaler <
> [email protected]> wrote:
>
>> On Fri, Jun 7, 2013 at 12:38 PM, Reto Bachmann-Gmür <[email protected]>
>> wrote:
>> > Hello,
>> >
>> > I wanted to give you a quick update on the status of the commons-ng
>> branch.
>> >
>> >
>> > - The updated dependency with the biggest impact is jersey which is
>> now
>> > in version 2.0 which is a jax-rs 2.0 implementation. I've found no
>> > incompatibilities between jax-rs 2.0 and 1.1 so I've broadened the
>> import
>> > range for the dependency.
>>
>> So you plan to still stick with jersey as default jax-rs
>> implementation? But I guess Stanbol will only use standard APIs so we
>> can easily switch the implementation, right?
>>
>
> Exactly. No module (except web.base.jersey) shall depend on anything jersey
> specific.
>
>>
>> > - I've also updated the scr plugin to allow dependency injections in
>> > superclasses
>> > - WebFragement will still be there as a deprecated class
>> > - Accessing services and properties via ServletContext is no longer
>> > supported (but BaseStanbolResource is still there and provide the
>> legacy
>> > global script/css support)
>> > - There is an issue with the new jersey version when security is
>> enabled
>> > - CORS has not yet been ported, the respective classes are disabled#
>>
>> I would like to change CORS support in a way that developers do not
>> need to handle this within JAX-RS resources. Maybe via a ServletFilter
>> or something similar.
>>
>
> That's good news!
>
>>
>> > - The job manager is not yet working (missing service, probably since
>> > scr update)
>> > - A mini launcher shall provide the common bundle and minimum support
>> > classes to test new modules
>> >
>> > To summarize what is there: You can launch the mini-launcher and access
>> the
>> > start page which is now powered by a jax-rs 2.0 implementation.
>>
>> I hope I will find some time to look into this on Sunday. Otherwise I
>> will not have time until later next week.
>
>
> Great, thanks. For an example template-compatible removable of
> Viewabe(this) see the job service resource. JobsResource used to set
> instance variables to itself which where then accessed by the template. Now
> it's passing a data objects which provided the same method as the
> BaseStanbolResource.
>
> Cheers,
> Reto
--
| Rupert Westenthaler [email protected]
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
