Howard, do you have some plan of early release for HiveMind-1.1? At which
time? This might well condition our votes ;-)
Anyway, here are my votes:
<interceptor-set> +1
prototype service model +1
Enumerate services. 0 (don't care)
Improve/fix HiveDoc. +1
Hydra -1 (I think this requires too much reflection beforehand and I am
afraid it might break a lot of things)
Conditional contributions 0
Serializable Services -1 (important feature but may also require a lot of
refactoring no?)
Dynamic locale. +1 (although I cannot figure out how the Locale will be set
and by whom, possibly automatically: HiveMindFilter?)
In addition, I'd like to add the following:
Schema extensibility +1 (JIRA HIVEMIND-70)
AOP alliance interceptor support +1 (JIRA HIVEMIND-45)
Cheers
Jean-Francois
-----Original Message-----
From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 28, 2004 4:37 AM
To: hivemind-dev@jakarta.apache.org
Subject: [DISCUSS] HiveMind 1.1 Beta
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?
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
