[Design of JBossCache] - Thoughts on 2.0 API
by genman
Probably the boat has already left the dock, but here are some thoughts...
There's org.jboss.cache.factories and org.jboss.cache.pojo.factory, in addition to being inconsistent, I sort of don't like the "ies" look. I also don't like "factory" as a package in general, because I don't think it has enough weight (number of classes and scope of use) to warrant separation. Its use is integral to how a user builds a cache, so it should be immediately obvious where to get it.
I also doubt that having the Factory be an interface is better than an abstract base class. A simple "abstract Cache createCache(...)" that users can replace and a "static Cache createDefaultCache" would be far more useful.
import org.jboss.cache.Cache;
import org.jboss.cache.CacheFactory;
Cache c = CacheFactory.createDefaultCache();
c.put(Fqn.ROOT, "a", "b");
// versus
import org.jboss.cache.Cache;
import org.jboss.cache.factories.CacheFactory;
import org.jboss.cache.factories.DefaultCacheFactory;
CacheFactory cf = new DefaultCacheFactory();
Cache c = cf.createCache();
c.start();
c.put(Fqn.ROOT, "a", "b");
Having a start parameter, like "Factory { create(Config c, boolean start) }" is sort of hokey... In general, the 90% use case is to create a started cache, if you're going through Java. A "Configuration" could state if a cache should be in started state for the 10% of cases. Example:
Configuration c = ...
c.setStartOnCreate(false); // or something like that
Cache c = CacheFactory.createCache(c);
c.start();
CacheSPI () { } ... Having a List that can be changed seems better than two additional methods. A List is for adding and removing stuff, right?
CacheSPI spi = ...
spi.getInterceptorChain().add(new MyInterceptor());
// or
spi.getInterceptorChain().add(4, new MyInterceptor());
// or
spi.getInterceptorChain().addAll(4, List l);
I'm also thinking a JSR-77 sort of Statistics class would be in order. Having a grouped bunch means you can add new statistics without changing the CacheSPI interface itself.
Why does Region not have a "CacheListener"? There are 6 methods in CacheSPI for a listener, but none in Region.
I guess what'd be nice is a:
Fqn f;
CacheListener cl;
Region r = Cache.getRegion(f);
r.getCacheListeners().clear();
r.getCacheListeners().add(cl);
Cache.getRegion(Fqn.Root).clear();
// not sure how well defined this might be
I would probably move RegionImpl->Region.
Having interfaces sort of prevents you from extending your API (easily). Again, what's the benefit of an interface over a concrete class in this situation? Region sounds like something you'd want to extend in the future. One scenario is if you had different interceptor configs or cache loaders per region in the future.
The new API needs to justifiable, otherwise your users will simply do this:
TreeCache tc = ...
Cache c = tc.getCacheSPI();
and the hell to your factories ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975254#3975254
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975254
18 years
[Design of JBoss ESB] - Re: Smooks Transformation Integrated
by tfennelly
"mark.little(a)jboss.com" wrote : However, what's the service API look like?
Sorry about the delay.... I was busy fixing the build ;-)
Transformation Service API
SmooksTransformer implements the TransformationService interface.
"mark.little(a)jboss.com" wrote : How will someone go about replacing this transformation service with another one?
I suppose that depends on whether we're talking about the current or a future architecture... Currently, as far as the ESB is concerned, Transformation Service implementations need to be ActionProcessors same as any other ActionProcessor (terrible name ;-( ).
So, from a code perspective, replacing any ActionProcessor with another ActionProcessor is seemless because they all implement that interface. From a configuration perspective, it'd be a case of replacing the processor on the "Action" configuration to reference that "different" transformation service - thereby getting it to transform (process) the message instead. Of course, the "different" transformation service would need to work against the same action properties.
This should all become more decoupled in our future archs once we get all the "Action" configurations into the registry and get our normalised message structures + EPRs etc in there with the routing info (and other message metadata).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975192#3975192
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975192
18 years