Two possible approaches:
ASServiceA --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3
ASServiceB --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3
ASServiceC --> JBCIntgAPI --> JBCIntgImpl3 --> JBC 3
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.
For ClusteredSSO, if we created an alternate impl of the web session SPI, any needed new ClusteredSSO impl would be packaged with it. It's only one class.
Ok, this is good to know. Would these be in AS5 at some point (if not 5.0, a point release afterwards)? And I guess more importantly EAP 5?
Having it for EAP 5 is my goal, yes. And that means also in a community AS release around the same time. The hibernate and ejb3 sfsb ones will come out of those projects.
Great - so getting JBC 3 in EAP 5 is a possibility then?