Howard, All - here are my two cents (and votes)
interceptor-set: +1 - would at the least save a lot of typing to cover all services with logging interceptors ;)
prototype service model: +1
enumerate services: +1 : I may be misusing the power of HiveMind, but we have quite a few cases where we have many service implementations of the same interface and the choice of the actual service being used is done at runtime (and may be different for each invokation). Being able to lookup all services for an interface would be a great start - meta-data support for looking up the service would be even better :) I can start having a look at this if deemed useful.
hivedoc: +1 As part of this, how about adding the possibility to build the registry docs at runtime?
hydra: 0
conditional contribs: +1
serializable: 0
Dynamic locale: 0
Also, I read on the list a while ago that there was talk about providing auto-wiring support for POJOs being created outside of hivemind - is this still on the list? If so, any thoughts about providing the same for static methods?
Cheers,
Johan
On Mon, 27 Dec 2004 16:37:08 -0500, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
Time, I think, to start closing down new features and get ready for a beta. Again, the point of a beta is to close of the development of new functionality and focus on stability, documentation and bug fixing.
Here's my list of thinks I'd like to see in HiveMind 1.1:
<interceptor-set> - apply a set of interceptors to a wide range of HiveMind services.
prototype service model (create a new instance for each method invocation)
Enumerate services. Ability to list the full ids of all HiveMind services. Rod (Johnson) thinks this is necessary to properly integrate with Spring.
Improve/fix HiveDoc. HiveDoc is now really ugly (sorry), need someone to really take ownership of this ... someone who understands XSLT and can do some decent design (not my forte!).
Hydra - allow a single service implementation to be shared by multiple service points. Not sure what this would look like! It's just that, occasionally, it would be nice for one piece of logic to have more than one "face". This may get deferred out to 1.2.
Conditional contributions -- I've already started on this.
Serializable Services --- the service proxy should be Serializable/Externalizable. A placeholder object should be written out. On de-serialize, the placeholder should locate a Registry (inside a well known ThreadLocal) and replace itself. This isn't for serializaing services, per-se, but to allow data objects that contain references to services to be serialized. This comes up a lot in web applications, where objects end up in the HttpSession.
Dynamic locale. Should be possible to change the Locale (on a thread-specific basis) and have messages automatically change over to the selected Locale. Currently, Locale is fixed at Registry build time ... it should be maleable at runtime.
Votes? Discussions? Other ideas?
-- you too?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
