Howard M. Lewis Ship wrote:
Please elaborate on some of these ideas.
I really, really, really don't want to sacrifice HiveDoc. I think applications will be using dozens
if not hundreds of configurations, services and contributions and without HiveDoc there will be no
way to make sense of it all.
I would absolutely not want to lose the hivedoc myself. I am simply
suggesting producing the hivedoc from the script module descriptors.
With scripting languages, you can document the descriptors in javadoc
format and access them from the AST. And then its simply a matter
spitting it out in the form of xml/html and formatting them for display.
This can be further simplified with Groovy 'cause it has native support
for markups!
AOP as in AspectJ is, I believe, orthogonal to HiveMind. What kinds of introductions do you want?
I would like to see simple mixin type introductions. For eg., with the
simple event producer/listener pattern I have to pollute my classes with
event handling code which can be avoided by isolating this code and
mixing it in as needed. May be this is orthogonal to HiveMind. May be we
just need a hook to allow dynamic weaving of services by proxy based aop
frameworks like dynaop.
Perhaps we need a more sophisticated way of defining the interceptors for a service; a mix of
*explicitly* contributed interceptors and some other system where interceptors are "drafted in" via
some other form of configuration. Regexp is a good idea ... though that ties us to ORO or JDK 1.4.
Yes, it introduces a dependency but I think it is justified in this
case. On a related note, I kinda like jakarta regexp package better than
oro. regexp is very compact and seems as performant as its couterpart.
-Harish
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
-----Original Message-----
From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 8:00 PM
To: [email protected]
Subject: Re: Status update
1. I want easier and more AOP! I think the interceptor-set
idea is good
but we need a way of applying these sets to services in one
fell swoop
using regexp or something. And we need atleast some simple
introductions.
2. Secondly, I want easier and more powerful configuration with
scripting especially with Howard's recent ideas on the wiki. I had
second thoughts on this before due to the line-precise error
reporting
and hivedoc that comes with the current xml descriptors, but
having done
some research it turns out that the scripting languages provide a
complete AST that simplifies things a whole lot. Really, all the
complexity in HiveMind is simply due to the xml descriptors.
I haven't
yet had a chance to take a look at plugging this into Hivemind. I am
guessing it should be simple.
-Harish
PS. Why don't the messages here not have the reply-to attribute set?
Howard M. Lewis Ship wrote:
So ... what are people doing with HiveMind? It's back, it's
free and I've been doing some work on
it. I've also been doing some planning for HiveMind on the Wiki.
I'm afraid that all the interruptions caused by the IP
problem, and then by the infrastructure
delay, have hurt HiveMind. The community is failing to
coalesce at the new home ... it's important
that the other HiveMind users and developers check in and
start communicating about their needs.
I have plans for HiveMind in the immediate future:
- Hook into J2EE for declarative security on services via an
interceptor
- Create a gateway into Spring, to allow managed Spring
beans to appear as HiveMind services
- Interface with JMX: map JMX MBean interfaces to HiveMind
services, and add a "performance"
interceptor that records method invocation data into other JMX beans
- Transaction interceptor
That's my immediate list ... what's your?
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
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]
---------------------------------------------------------------------
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]
