Viktor,

I think there are a few things you could simplify in your HiveMind
configuration:

1. You should be able to use the MethodInterceptorFactory as is. This
would although require you to define your AOP interceptor as a service
into which you'd inject the StoreCache service. This would relieve you
from the burden of defining a interceptor factory service, schema, and
implementation.

2. I think you could get rid of the swarmCacheConfig configuration
(and the accompanying SwarmCacheConfiguration class). The way I
understand it you only use it to capture initialization data for the
StoreCache service. This is better declared directly in the
<construct> element for the StoreCache service implementation. What
leads me to this conclusion is that you only ever expect one
contribution to this configuration. But maybe you have other good
reasons for declaring a configuration...

You'd end up with something like:

<module>

  <service-point id="StoreCache" interface="com.freshdirect.cms.cache.CacheI">
    <invoke-factory>
      <construct class="com.freshdirect.cms.cache.SwarmCache">
        <service-id/>
        <set property="cacheType" value="Hybrid"/>
        <set property="multicastIP" value="${cms.cache.multicastIP}"/>
        <set property="lruCacheSize" value="10000"/>
        <!-- you could of course also define these as constructor
parameters... -->
      </construct>
    </invoke-factory>
  </service-point>

  <service-point id="CacheInterceptor"
interface="org.aopalliance.MethodInterceptor">
    <invoke-factory>
      <construct class="com.freshdirect.cms.cache.ContentCacheInterceptor"/>
      <!-- assuming StoreCache is autowired -->
    </invoke-factory>
  </service-point>

  <service-point id="StoreContent"
    interface="com.freshdirect.cms.application.ContentServiceI">
     ...
     ...
     <interceptor service-id="hivemind.lib.MethodInterceptorFactory">
       <impl object="service:CacheInterceptor"/>
      </interceptor>
  </service-point>

</module>

Does this look better?

--knut

On 5/11/05, Viktor Szathmary <[EMAIL PROTECTED]> wrote:
> So, the real-world example (which as I said, is hopefully a bad one :)
> 
> To provide some context (this part is non-hivemind specific) and the 
> objective:
> 
> - you have a domain-specific service interface (ContentServiceI in
> this case), that you will contribute the caching interceptor to.
> 
> - you have a defined a CacheI interface that provides the basic
> get/put/remove for a generic object cache (you would like to plug in
> things like hashmap/ehcache/swarmcache/your favorite).
> 
> - you have an AOP-alliance style interceptor that given a CacheI
> implementation, intercepts method calls to your domain-specific
> service and makes the appropriate cache get/puts around the method
> calls (it's called ContentCacheInterceptor)..
> 
> - you wrote the adapter for SwarmCache to implement CacheI.
> 
> Ok, that wasn't too bad or unusually mind-boggling :) Now on to the
> hivemind-specific tasks:
> 
> First, looks like you will need an interceptor factory to explain
> hivemind that your ContentCacheInterceptor instances need a CacheI as
> a dependency. The class is just a few lines, and extends
> MethodInterceptorFactory...
> 
> <service-point id="ContentCacheInterceptorFactory"
> parameters-occurs="1"
> interface="org.apache.hivemind.ServiceInterceptorFactory">
>         <invoke-factory>
>                 <construct 
> class="com.freshdirect.cms.cache.ContentCacheInterceptorFactory" />
>         </invoke-factory>
>         <parameters-schema>
>                 <element name="cache">
>                         <attribute name="object" required="true" 
> translator="object"/>
>                         <rules>
>                                 <push-attribute attribute="object" />
>                                 <invoke-parent method="addElement" />
>                         </rules>
>                 </element>
>         </parameters-schema>
> </service-point>
> 
> Ok fine.. Let's bind our configurations to SwarmCache... (Turns out,
> the default configuration object in SwarmCache had some warts so you
> wrote an adapter for that as well... No big deal, just a small
> distraction - but you shall blame that on SwarmCache). Let's define
> the schema for it in hivemind...
> 
> <schema id="SwarmCacheConfiguration">
>         <element name="cacheConfiguration">
>                 <attribute name="cacheType" required="true">
>                         <!-- LRU, Auto, Timer, Hybrid -->
>                 </attribute>
>                 <attribute name="multicastIP"/>
>                 <attribute name="lruCacheSize"/>
>                 <attribute name="timerCacheTimeout"/>
>                 <conversion 
> class="com.freshdirect.cms.cache.SwarmCacheConfiguration"/>
>         </element>
> </schema>
> 
> Ok, now you want to have a cache configuration, like so (details about
> the symbol source definitions omited for clarity, not everyone needs
> that anyway):
> 
> <configuration-point id="swarmCacheConfig" 
> schema-id="SwarmCacheConfiguration"/>
> <contribution configuration-id="swarmCacheConfig">
>         <cacheConfiguration multicastIP="${cms.cache.multicastIP}"
> cacheType="Hybrid" lruCacheSize="10000"/>
> </contribution>
> 
> And finally, you'll need a SwarmCache (implements CacheI) instance
> using this configuration. Since you have decided that cache
> configuration objects should be represented as a configuration in
> hivemind, not a service (after all its just a small data carrier, no
> biz logic, etc), you'll have to modify the constructor to take a List,
> and use the one-and-only element therein. Oops.. well, you're not
> gonna backtrack now, stuff needs to get done... :)
> 
> <service-point id="StoreCache" interface="com.freshdirect.cms.cache.CacheI">
>         <invoke-factory>
>                 <construct class="com.freshdirect.cms.cache.SwarmCache">
>                         <string>StoreCache</string>
>                         <configuration>swarmCacheConfig</configuration>
>                 </construct>
>         </invoke-factory>
> </service-point>
> 
> Finally (!), you can simply apply a caching interceptor on your
> service like this:
> 
> <service-point id="StoreContent"
> interface="com.freshdirect.cms.application.ContentServiceI">
>         ...
>         ...
>         <interceptor service-id="ContentCacheInterceptorFactory">
>                 <cache object="service:StoreCache"; />
>         </interceptor>
> </serivce-point>
> 
> So, perhaps I'm too lazy or perhaps missed some essential points in
> the hivemind docs, but I found this a bit more involved than I
> consider reasonable :) It works, no doubt, but was far from a "simple,
> consistent, crisp, etc" experience...
> 
> regards,
>   viktor
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to