+1 one for a jdk 1.5 dependency in hivemind 1.2.
I regard annotations as much too useful to prevent extensive use
for the sake of downward compatibility.
Achim Huegen
Am Mon, 06 Feb 2006 03:51:54 +0100 schrieb Howard Lewis Ship
<[EMAIL PROTECTED]>:
Well, there hasn't been much, we've been focusing on 1.1.1.
I'm not satisified with my attempt to convert to Maven2 (in my branch).
But the experiment is useful, I'm going to take another crack at it,
on the trunk. I'm going to remerge 1.1.1 changes into the trunk, then
convert to Maven2 (but leave all the source folder locations as is,
for the meantime).
On the other hand, I'm getting into crunch mode with a client, so I
won't be able to do a lot with HiveMind for the next few weeks.
I do have a number of ideas I want to pursue for 1.2:
- <module> attribute to control the default builder factory
- A streamlined, smarter injection factory
- <interceptor-sets> ... a way to apply a set of interceptors to many
services (potentially, across many modules)
- Some kind of negotiation between the service extention point,
service lifecycle model, and service implementation builder to handle
negoation on the lifecycle model (i.e., to allow it to be determined
via an annotation on the implementation class), and to handle the
intracacies of event notification support for non-singleton models.
In addition, I want to start introducing an alternate approach to
creating services, one that invokes Java code to build the service
implementation. This may be based on annoations and/or naming
conventions. I see this ultimately as a way to reduce the amount of
XML in the system, make HiveMind more refactoring friendly, and
improve startup time for complex environments like Tapestry.
I want to seriously considering bumping the minimum release for
HiveMind 1.2 up to JDK 1.5, so that we can embrace annotations.
I've been doing some research on using annotations (on service
interfaces and service interface methods), rather than XML, to drive
interceptor factory behavior. I'm quite liking it; I've been taking
my own crack at Hibernate integration, using an @Transactional method
interceptor rather than XML to indicate how transactions are managed
for a service method. I'm finding this to be a good template to move
forward.
Yes, I know I should document these ideas on the wiki. I'm in a hotel
room right now, not at home.
--
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]
