Ticket #277 (closed Enhancement: fixed)

Opened 8 years ago

Last modified 7 years ago

add an abstract JSON provider

Reported by: dgf Owned by:
Priority: Minor Milestone:
Component: DeepaMehta Standard Distribution Version: 4.0.11
Keywords: Cc:
Complexity: 1 Area: Application Framework / API
Module: deepamehta-webservice


the actual implementation of a provider looks very technical and should be abstracted.

a class like the following would be charming:

package de.deepamehta.plugins.example.provider;

import javax.ws.rs.ext.Provider;

import org.codehaus.jettison.json.JSONObject;

import de.deepamehta.plugins.example.AbstractProvider;
import de.deepamehta.plugins.example.Example;

public class ExampleProvider extends AbstractProvider<Example> {

    public ExampleProvider() {

    protected JSONObject getJsonData(Example example) {
        return example.toJSON();



AbstractProvider.java (1.8 KB) - added by dgf 8 years ago.
a strate forwoard implementation approach
AbstractJaxrsReader.java (1.3 KB) - added by dgf 8 years ago.
a abstract reader suggestion

Change History

Changed 8 years ago by dgf

a strate forwoard implementation approach

comment:1 Changed 8 years ago by jri

The Webservice module already provides generic JSON providers for writing (JSONEnabledProvider and JSONEnabledCollectionProvider). These are available to all modules automatically. Your domain object just needs to implement de.deepamehta.core.JSONEnabled. This makes it ready to be send over the wire.

comment:2 Changed 8 years ago by dgf

In the example plugin project i want to show a simple implementation of specific provider.

I couldn't find a usage of the JSONEnabled interface, but some similar implementations. All provider that enhance the core classes should swallow an abstraction:

  • AssociationProvider
  • AssociationTypeProvider
  • CommandResultProvider
  • DirectivesProvider
  • StringSetProvider
  • TopicTypeProvider

comment:3 Changed 8 years ago by dgf

i just looked down from web service module, now i found the general usage at DeepaMehtaObject

comment:4 Changed 8 years ago by jri

Yes, the JSONEnabled feature is not yet exploited by all provider implementations. JSONEnabled was introduced later. TopicProvider? as an example is already adapted: it is just a reader. AssociationProvider? on the other hand is not yet adapted: it is still a reader and a writer, in which the writer part is obsolete.

There is no need for proprietary message body writer providers as long as the object implements JSONEnabled. Every object that is about to be send over the wire is supposed to do so.
(A generic reader provider of course is a different story and does not yet exist).

I will cleanup the provider implementations soon.

In fact all the Core objects are JSONEnabled. Derived from the very top of the hierarchies:


For an external module example which makes use of JSONEnabled see Geomaps.


Its model classes (Geomap, GeomapTopic?) are JSONEnabled. (GeomapTopic? derives JSONEnabled from TopicModel?.) So, Geomaps doesn't need to provide any custom providers to be send over the wire. A Geomap consist of GeomapTopics? and is returned by the getGeomap() service call (= resource method). See GeomapsService? and GeomapsPlugin?.

So, for your example plugin project there should be no need to provide a writer provider. Just implement JSONEnabled.

comment:5 Changed 8 years ago by jri

This diagram of important core classes might be useful:


Last edited 8 years ago by jri (previous) (diff)

Changed 8 years ago by dgf

a abstract reader suggestion

comment:6 Changed 8 years ago by dgf

The plugin dev guide should not show such internal stuff, it uses the attached reader suggestion now.

comment:7 Changed 8 years ago by jri

Sorry, misunderstanding.
The diagram was not meant for the dev guide, just for your pleasure :)

comment:8 Changed 7 years ago by jri

  • Status changed from new to closed
  • Resolution set to fixed

The Webservice module now offers a generic MessageBodyReader? Provider for JSON reprensented entities (#277).
This means the application developer must no longer implement a custom provider class when she wants to deserialze an arbitrary JSON represented application object contained in the message body. She only must ensure the application object's class has a public constructor that takes a JSONObject as argument.
In other words: in your (REST) resource methods you can use an arbitrary class as the type of the entity parameter as long as the entity is represented in JSON and the class has a public JSON constructor. You are no longer required to implement a provider class.

Furthermore: the webservice's provider classes are generalized by exploting the fact that most DM core application objects implements the JSONEnabled interface. 6 provider classes are stripped from the webservice module (#278).



  • relatedTopicsToJson() deleted

See ticket 277.
See ticket 278.

Changeset: ea5ca8535f796a5ec083b68ef49fdae570470ded

Note: See TracTickets for help on using tickets.