POJOs as services

[Achim Huegen]

I must admit I'm lazy, sometimes. Whenever I complete a new service 
implementation I think 'oh no, now I have to split my service into 
interface and implementation, just to be able to use it in hivemind. 
Dealing with two units which both contain the same methods and use linked 
javadoc is extra work. Some service interfaces are not very stable in the 
beginning of development and some services will never require the use of 
interceptors or benefit from multiple implementations.

So, why don't we support POJO (interface free) services?
- It would ease adoption of hivemind for new users, by reducing some of 
the overhead of using hivemind.
- Integration of existing classes would be able without adapters or 
wrappers. For example you can setup a global SimpleDateFormat instance 
without problem.

Of course it would not be possible to use interceptors or any service 
model besides primitive.

In fact it is very easy to implement, just remove the interface check from 
ServicePointImpl.lookupServiceInterface and hivemind is ready for POJOs.
Better: Let the serviceModel decide whether it want to support 
non-interface classes.

Achim Huegen

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]