hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hivemind-...@jakarta.apache.org
Subject [Jakarta HiveMind Wiki] New: PojoServices
Date Sun, 01 Aug 2004 21:23:17 GMT
   Date: 2004-08-01T14:23:17
   Editor: AchimHuegen <ahuegen@gmx-topmail.de>
   Wiki: Jakarta HiveMind Wiki
   Page: PojoServices
   URL: http://wiki.apache.org/jakarta-hivemind/PojoServices

   no comment

New Page:

= Problem Description =

AchimHuegen, July 6 2004, 1.0beta

Services must be interfaces. Plain java objects are not supported.
  * Maintenance of interfaces is extra work (two units, linked javadoc)
  * Prototyping is more difficult
  * Adoption of HiveMind for new developers is more difficult

= Proposed Solution =

Allow the use of java classes in the interface attribute of a service-point.

Example:
{{{   <service-point id="POJO" interface="java.text.SimpleDateFormat">
		<invoke-factory service-id="hivemind.BuilderFactory" model="primitive">			
			<construct class="java.text.SimpleDateFormat">
				<string>MM/yy</string>
			</construct>
		</invoke-factory>
   </service-point>
}}}

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.

Interceptor support should be extended to support both POJOs (without final methods) and interfaces.
This can be achieved by switching from inheritance to composition. 
For example a LoggingInterceptor shouldn't specialize AbstractLoggingInterceptor but hold
a reference to a LoggingInterceptor (non abstract counterpart of AbstractLoggingInterceptor)
and delegate all the work to this instance. 


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org


Mime
View raw message