HiveMind continues to come along nicely; I'm quite proud of it.
The latest addition was a revision to how parameters to service implementation factories work. A service implementation factory is a HiveMind service used to construct the implementation of some other HiveMind service. Down the rabbit hole yet? This is occasionally useful ... the example built into the HiveMind framework is creating a HiveMind service that fronts for a stateless service bean. The implementation that is generated (in this case, using JDK dynamic proxies) looks up the home interface in a naming service (a HiveMind service wrapping around JNDI), invokes the create() method (using reflection), and forwards all the remaining interface methods to it.
The factory needs to know the JNDI name. The new approach is that the factory will create a parameters object and the <parameters> element of the descriptor will configure the properties of the parameters object, which is then passed back to the factory so that it can construct the final service.
Why not just set properties on the factory service implementation itself? Because the factory service implementation is a HiveMind service, and therefore it is multi-threaded. Two different threads could be trying to create implementations for two different session EJBs at the same time.
It ends up looking something like:
<service id="SimpleRemote" interface="hivemind.test.services.SimpleRemote"> <service-factory service-id="org.apache.commons.hivemind.EJBProxyFactory"> <parameters> <set property="jndiName" value="hivemind.test.services.Simple"/> </parameters> </service-factory> </service>