This would be valuable discussion for the coming hivemind mailing lists and wiki.
> > 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". > > - 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 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. > > - 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. > > - 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]
