Is there room for some refactorings? I'm thinking of reorganizing the package structure. The org.apache.hivemind.impl package and service.impl packages are rather "crowded" right now. Moreover placement of classes is sometimes not very obvious. Some examples for possible improvements:
- Utility classes like LoggingUtils, JavaTypeUtils or Defense should reside in the utils package. - BuilderFactory related classes (about 10) could be placed in their own package - SchemaProcessorImpl lies in hivemind.impl whereas the corresponding interface is defined in hivemind.schema.
Achim Huegen
Am Mon, 27 Dec 2004 16:37:08 -0500 schrieb Howard Lewis Ship <[EMAIL PROTECTED]>:
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?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
