Hi Rupert Lets not try to put too much into this branch as otherwise it might stay there for too long.
For 1 and partially 3 we first have to actually provide a REST interface. I think that fostering RDFViewable is a big step in this direction. With this the HTML interface is ideally just a set of templates on top of the REST interface which can be left away. But for now the branch still supports Viewable. 2 seems to be largely independt. I would say the goal for this branch are: - Get rid of jersey dependencies in modules (that's mainl jersey-multipart) - Get rid of ServeltContext service access (which also means getting rid of classes which are both resource classes as well as model for the template if this implies having instance fields) - Update some dependencies, most notably upgarding to jax-rs 2.0 In oder to keep things as iterative as possible I wouldn't add more goals to this branch. Cheers, Reto On Mon, Jun 10, 2013 at 9:17 AM, Rupert Westenthaler < [email protected]> wrote: > 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 >
