Howard M. Lewis Ship wrote:
This would be valuable discussion for the coming hivemind mailing lists and wiki.The primary reason for order is because of the distributed nature of the contributions. To me, the before/after does not seem to serve any special purpose. If you knew all the interceptors for the service point, you will very well know their ordering too. As long as we have the HiveDoc document the modules in a combined fashion, I am fine.
Hi Howard,
I've been looking pretty closely at HiveMind for the past few days --
glad the IP issues have been squared away -- and I have to say, it looks
terrific. I have a couple of minor comments and questions:
- The use of integers for ordering makes me squeamish. Have you looked
at Perl 6 at all? Larry Wall's insight for operator precedence ordering
might apply here as well. In Perl 6, you define an operator's
precedence relative to another operator (see Apocalypse 6,
http://dev.perl.org/perl6/apocalypse/A06.html). I think this would
apply to the things that need ordering in HiveMind too, and would be
easier to manage than integers.
I have thought about putting in before and after attributes to replace order, i.e.
<interceptor service-id="PerformanceInterceptor" before="hivemind.LoggingInterceptor"
after="SecurityInterceptor,othermodule.FooInterceptor"/>
It's a question of correctness vs. utility. I think a dependency based solution is more correct, but the benefits of implementing and documenting it may not be worth the effort for the rare case where a service has lots of interceptors.
In fact, another option, potentially a better one, was to define groups of interceptors
(with a particular ordering) to apply to a service, instead of "a la cart".
I am yet to explore Javassist, but would certainly like to see some comments comparing it to Cglib2. I have seen some great reviews for it and not to mention its widespread use in other products.
- Why use Javassist instead of dynamic proxies? Poking around your
blogs a little I see that the transition to Javassist happened sometime
last summer, but I don't see any discussion of why. Just performance? Or are you manufacturing classes in ways that dynamic proxies just
wouldn't work for?
I no longer have a valid comparison. With Javassist, you don't have the object creation expense of
creating wrappers around primitive types, or any of the other reflection type overhead. In
addition, given the order of creation (core interceptor, then each interceptor in turn), the
interceptors will know the specific class (not the service interface) of the object they wrap, so
they can use the more efficient virtual invocations, not interface invocations. Sort of buying back
a little performance. I found it more straight forward to do some other things, such as properly
override toString() in a proxy or interceptor (through this can be done using dynamic proxies, but
it's less graceful).
I agree with Howard, to me, it is certainly an implementation aspect.
- I believe your placeholder for version checking is at the wrong level.
I think versioning should be at the service interface level, not the
module level. Isn't that how Eclipse does it? What are your thoughts here?
I'm pretty sure module level makes sense. Eclipse does it that way.
- I remember reading on your blog (I think?) a few days ago that you
were thinking of moving the definition of model from the service point
to the implementation. This sounds right to me -- or at least, it
should be possible to do this at the implementation level instead of the
interface level, though for some interfaces I guess the interface itself
might need to dictate the model of any implementation. Any further
thoughts on that?
I think it does belong on the implementation, not the <service-point>. I don't think any interface
mandates a particular service model. Certainly, with collaboration, the service may appear stateful,
but in fact, be stateless ... but be a facade, collaborating with a mix of stateless and stateful services.
I am a little confused here. If it is simply a question of setting up test services and production services, why not have two different modules with the appropriate services? The hivemodule.properties can help there too. But if it is a truly runtime requirement, then will the registry.getService() choose an appropriate service everytime its called? Meaning you will have multiple implementations for the service?
- One of the things we need to be able to do is to choose particular
service implementations at startup time, based on property or preference
settings. In particular, I'd like to be able to swap out all remote
services in favor of local (dummy) services based on a single property
value; or choose local over remote on a service-by-service basis. The
only way I can think of to do this sort of thing in a general way would
be to have some kind of boolean expression associated with a service
implementation that tells HiveMind whether to use that implementation or
to go on to the next available implementation. (I guess I'm thinking
OGNL or something equivalent.) Any thoughts on how I could accomplish
this within the current HiveMind implementation?
I've thought about this as well. The approach I'm going to explore is a "broker" core service implementatation factory. It will be provided with descriptions of other services and can dynamically select one.
So, you might have module.PublicService by the service id referenced in your code (or injected into other services). Its builder will select either module.StandardService or module.DebugService at runtime.
Another option would be to add an attribute to <create-instance> and <invoke-factory> to allow
HiveMind to help with the selection, and enabled attribute as you alluded to, might be a reasonable
shortcut.
-Harish
- I think you should lose the phrase "HiveMind doesn't have any
particular purpose" on your front page. Seems to me it has a very
particular purpose, which is to manage services within a JVM.
Good point.
Anyway, thanks for this codebase. It looks very cool!
I'm looking forward to using HiveMind in virtually everything I do.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components 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]
