Designing Habanero - Configuration changes

[manik]

The last of my initial postings in this (exciting!) series of interface changes for JBoss Cache 2.0.0 (Habanero): configuration files.

See http://jira.jboss.com/jira/browse/JBCACHE-89

This will change the way JBoss Cache is configured, and among some suggestions I have received are doing away with properties lists as the contents of certain elements.

[ben.wang]

Can we take one step further by providing a SPI callback to provide the interceptor stack? For example, PojoCache would like to customize this interceptor stack, what would be the best way to do it?

Of course, obtaining the list and then iterating thru it is one way. But if we can provide a callback, it would be nice.

[manik]

Perhaps SPI methods to insert an Interceptor at a given position and another method to retrieve a (read-only) list of Interceptors?

void addInterceptor(Interceptor i, int position);

List getInterceptors();

void removeInterceptor(int position);

[manik]

Reviving this thread. Do we see any use in being able to add custom interceptors via XML? E.g., an XML element like:

<attribute name="CustomInterceptors">
 <config>
 <interceptor>
 <!-- your interceptor class -->
 <class>com.microsoft.SecurityLoopholeInterceptor</class>

 <!-- interceptor config -->
 <attribute name="Enabled">true</attribute>
 <attribute name="CustomSetting1">Blah</attribute>

 <!-- where do we attach this interceptor in the chain? -->
 <chainPosition>3</chainPosition>
 </interceptor>
 </config>
</attribute>

[manik]

Or is something like this more preferable/simpler to configure?

<attribute name="InterceptorChainCustomisation">
 <config>
 <!-- interceptors are ordered in the order they appear here -->
 <interceptor class="a.b.c.d" params="" />

 <!-- the 'generated' chain based on the rest of the config-->
 <generated-chain />

 <!-- params are "key=value, key=value ...", passed in as a String. Up
 to the custom interceptor to parse this. -->
 <interceptor class="a.b.c.f" params="" />
 </config>
</attribute>

[manik]

With both approaches, though, there is no way to remove or replace any of the default interceptors - just a way to add more.

Removing/replacing would have to be done via the CacheSPI interface. Can anyone think of a way to allow removing/replacing via XML as well, without bloating out to a full-blown expression language?

[ben.wang]

Is there a use case to provide the XML interceptor configuration that currently can't be done progrmatically?

I mean, I'd prefer to have the full interceptor stack configurable via XML if that is the case. But given the number of interceptors that we have now, I agree this is too bloated. So maybe we will just leave it to runtime configuration then?

[ben.wang]

One other thing to mention is currently PojoCache uses jboss-aop.xml to specify the full interceptor stack. It is little bloated but still manageable, IMO, becuase of JBoss Aop has provided the poincut language. Maybe this is the step for the Cache impl to go?

[galder.zamarreno]

JBoss AS shows a complete stack of interceptors and even though it might
look a bit bloated, it's quite simple to understand and modify. For
example, modification can be done in customer's jboss.xml

We could maybe give the customers an documentation oriented XML
containing the default interceptor stack and tell them that they can modify
it in the cache config, adding/removing new interceptors where needed
(like in jboss.xml).

On the other hand, specifying PojoCache and Cache interceptors in the
same way could be a good way forward and maybe some could be
reused? This option would make the gap understanding PojoCache v
Cache smaller.

How will the interceptors be defined in JBoss 5? Will it be in a similar way to
PojoCache?

[galder.zamarreno]

Manik, is there any reason why you'd want to only add/remove interceptors
and not change the core interceptor chain? Is it to avoid misusage?

[manik]

Is there a use case to provide the XML interceptor configuration that currently can't be done progrmatically?

User feature requests.

[manik]

One other thing to mention is currently PojoCache uses jboss-aop.xml to specify the full interceptor stack. It is little bloated but still manageable, IMO, becuase of JBoss Aop has provided the poincut language. Maybe this is the step for the Cache impl to go?

I agree, I think this is the way to go in future (eases up on a lot of the biolder-plate crap we have in TreeCache to pass calls up an interceptor stack) and we should be eating our own dog food, but it is way too big a change for now.

Maybe in 3.0.0? ;)

[manik]

Manik, is there any reason why you'd want to only add/remove interceptors
and not change the core interceptor chain? Is it to avoid misusage?

This is not out of choice. :-)

We have an XML config block that currently builds an interceptor chain based on config options. In the same XML config, adding more custom interceptors before/after this chain is easy, but to modify the chain is hard - imagine some XML element like:

<suppress-interceptor interceptor="org.jboss.cache.TxInterceptor" />

or

<replace-interceptor position="2" interceptor="my.custom.TxInterceptor" />

Very ungainly, and presumes that the user knows what sort of chain will be generated.

And, as you said, open to a lot of breakage. :-)

[galder.zamarreno]

That indeed looks quite complicated. What about JBoss AS style? If they
wanna make any modifications, repeat all the stack with the desired changes.

I think this would be a lot easier than replacing by position or by name.

[manik]

Isn't this unnecessarily complex?