Re: hivemind impressions/comments/rant (caching example)

[Knut Wannheden <kn...@gmail.com>]

Viktor,

(Moving this over to the dev list now...)

On 5/11/05, Viktor Szathmary <ph...@gmail.com> wrote:
> 
> Knut, that does look better. Ultimately, what I'd consider a
> simple/straightforward notation for defining things would be something
> like this:
> 
> <module>
>         <service-point id="StoreContent"
> interface="com.freshdirect.cms.application.ContentServiceI">
>                 <construct class="...">
>                         <propertyOne>foo</propertyOne>
>                         <propertyTwo>bar</propertyTwo>
>                         ...
>                 </construct>
>                 <interceptor>
>                         <construct class="com.freshdirect.cms.cache.ContentCacheInterceptor">
>                                 <cacheType>Hybrid</cacheType>
>                                 <multicastIP>${cms.cache.multicastIP}</multicastIP>
>                                 <lruCacheSize>10000</lruCacheSize>
>                         </construct>
>                 </interceptor>
>         </service-point>
> </module>
> 
> The key here is:
> 
>  - allow bean properties (and constructor params) to be easily bound,
> with using identically  named xml elements that are automatically
> mapped. Java type declarations provide a good enough schema
> declaration, one rarely has a desire to make the xml mapping
> different.
> 

I think I can see what you're getting at. I can see two problems with
this approach. First you can unfortunately not access a constructor
parameter's name using Java reflection. Thus you have to map them by
position and / or type. IMO this is one of the main disadvantages of
constructor based dependency injection. The second problem is a
restriction in HiveMind: HiveMind's schema language cannot express
that the elements can have any name (as for example RelaxNG's
<anyName>). But this is something we could look into.

There are also some other minor problems one would have to solve, but
I think this is a very interesting idea. I should also mention that it
has been proposed that the <construct> element could for simple cases
be made more succinct by encoding the nested elements into a string.
See http://issues.apache.org/jira/browse/HIVEMIND-121 and
http://thread.gmane.org/gmane.comp.jakarta.hivemind.devel/1417 if you
are interested.

>  - allow nesting declarations, so I don't have to flatten out simple
> hierarchical dependencies, which i found to be very common. (of course
> a good editor tool could alleviate this, but let's not fall into this
> trap, especially considering that there are no such tools yet).
> 

I can remember this being requested before. IMHO it can sometimes save
you a few lines of XML, but as soon as you want to reuse those nested
elements you will want to move them to the top level anyway. I suppose
this would be the case with your cache interceptor.

I can also see that you dropped the CacheI implementation (SwarmCache)
here. I assume this was unintentional since you mentioned the CacheI
implementation and the AOP interceptor as separate objects in your
original posting.

Thank you for your insightful comments and suggestions!

--knut

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org