It is annoying that the reply-to does not go to the list ...
-------- Original Message --------
Subject: Re: Status update
Date: Thu, 15 Apr 2004 10:27:29 -0400
From: Harish Krishnaswamy <[EMAIL PROTECTED]>
To: Christian Essl <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Honestly, I am not concerned about the possibility of making the module descriptors intentionally complex but rather the ability to make it simpler ;)
-Harish
Christian Essl wrote:
I'm biased towards scripting. On one side it is impressive how fast and what you can do with it on the other hand scripts can turn out to be monsters quite soon. Hivemind in it's current static way makes things just easy - most important to read the source, but I guess also for tools.
I agree that compile-time or classloading-time aop frameworks are orthogonal to HiveMind. But in terms of intercepting proxies frameworks like dynaop are way ahead of what we have at the moment. Maybe a decorating service-factory which applies dynaop to a service-impl would help. Exlplicit interceptors are given as parameters drafted-in interceptors are specified in a config-point. The factory could be in the lib module and therefore add no further dependencies to the core. Such an explicit factory aproach would also prevent some nasty circularity problems with drafted-in interceptors.
I guess this would also be quite easy to implement when there are recursive-schemas or a way to specify that elements can be gotten under a certain schema-element.
On Thu, 15 Apr 2004 00:16:41 -0400, Harish Krishnaswamy <[EMAIL PROTECTED]> wrote:
Howard M. Lewis Ship wrote:
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!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.
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 ofYes, 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.
*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.
-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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
