[jboss-dev-forums] [Design of JBossCache] - Re: JBoss Cache 3.0 and JBoss AS 5

[bstansberry@jboss.com]

Two possible approaches:

ASServiceA --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3
ASServiceB --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3
ASServiceC --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3

or

ASServiceA --> ASServiceAJBCIntgAPI --> ASServiceAJBCIntgImpl3 --> JBC 3
ASServiceB --> ASServiceBJBCIntgAPI --> ASServiceBJBCIntgImpl3 --> JBC 3
ASServiceC --> ASServiceCJBCIntgAPI --> ASServiceCJBCIntgImpl3 --> JBC 3

I don't think I want to limit all AS usage of JBC to a single fixed API. I prefer to have the flexibility to use all features of a particular release for a particular service.

There are 6 JBoss AS usages of JBC:

1) Hibernate 2LC. The 2nd style approach is already implemented:

Hibernate --> RegionFactory --> cache-jbosscache2 --> JBC2

2) EJB3 SFSB. The 2nd style approach is already implemented in the next gen caching discussed at http://wiki.jboss.org/wiki/DevEJB3NewSFSBCache

3) Web sessions. JBC interaction already goes through a utility class; this needs conversion into a proper SPI, a factory for the implementation, and a separate jar for the implementation. Should be pretty simple, just needs doing.  JIRA is https://jira.jboss.org/jira/browse/JBAS-5820

4) Clustered SSO. There already is an SPI and a mechanism for specifying the class of the impl.

5) DistributedState. I would prefer reverting DS to no longer use JBC over making any attempt to abstract out an SPI. TBH, I think this is a good idea anyway, just haven't done it due to other priorities.

6) HA-JNDI. Same as DistributedState.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169670#4169670

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169670