click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <>
Subject Re: Click Services
Date Mon, 20 May 2013 03:49:11 GMT
I think there is some merit in this stuff for RPC JSON services.

I would like to see some form of API documenting feature, this is a problem
with existing services they are hard to program to because they are not
self describing like Web Services are. This could be tricky to implement
however, and you may want to disable this on production systems.

Interesting to think what the design should be:

1) single RPC method per class, with the service implementing some service
interface, e.g.



2) multiple RPC methods per class, using reflection to lookup the methods:




In terms of whether we should support singleton /prototype (Spring
terminology) services. I distrust stateful services and would prefer new
service instances to be created per request. If people what to cache stuff,
they can do this themselves in the servlet context.  If we take this
approach I don't think we need lifecycle methods onInit(), onDestroy() etc.
 This would also keep it simple, we dont need configuration or annoations
to describe the service lifecycle.

In terms of mapping requests to service, I think Bob's on demand approach
would be good where by we cache resolved look-ups. For implementation agree
the Filter would be the best approach as this would avoid impacting the
ClickServlet and the XML configuration stuff.  It would be good do have
some package automapping stuff like we do with Click pages. Maybe this
could be configure against the filter in the web.xml


On Wed, May 15, 2013 at 5:43 AM, Bob Schellink <> wrote:

> On 2013/05/14 15:45, Malcolm Edgar wrote:
>> I think this is an interesting discussion.  I am seeing existing Multiple
>> Page Applications (MPA),
>> which is Clicks forte, evolve into hybrid MPA / Single Page Applications
>> (SPA) using frameworks like
>> AngularJS.
>> For serving JSON/RPC we have been using both hand coded Servlets with
>> net.sf.json.JSONSerializer and
>> using services built with RESTEasy (**).
>>  The RESTEasy approach is
>> more idiomatic Java (lots of layers of abstraction) and works well 99% of
>> time.
>> I am not sure what the value Click could provide for services.
> Nods, we will be reinventing the wheel a bit.
>  While I agree Velocity templates
>> would be useful for rendering a JSON response, the main problem in this
>> space is marshalling JSON
>> request data into Java objects. Maybe Marco google library would be good
>> for this.
> I'm currently using GSON[1], mostly because their docs is straightforward.
>> How would you see the services being registered, e.g. XML definition or
>> auto-mapped some how ?
> Guess annotation based but it looks like a pain to discover the annotated
> classes. There are some libs to help with that part but EE environments are
> tricky eg. JBoss 7 has a custom file system implementation which is tricky
> to 'scan'. Preprocessor could also be used at compile time to discover
> annotated classes and build an index of classes.
> One could also use plain interfaces and build up a cache at runtime eg:
> each request that matches a valid class is placed in a map and cached for
> faster retrieval in the future.
> Kind regards
> Bob
> [1]:**google-gson/<>

View raw message