Redesign of Pool Configuration

[alrubinger]

Looking over @Pool and @Cache configurations, I'm not happy with the metamodel available and the implementation I'd put in place last year while resolving API leaks.

Starting this Thread to document the discussion so far.

"#ejb3 IRC" wrote:
(02:12:20 AM) ALR: Some things are bothering me with @Pool configs.
(02:12:24 AM) ALR: 1) 1/2 the stuff we don't have tests for
(02:12:32 AM) ALR: 2) I hate the Pool configuration now.
(02:13:29 AM) ALR: carlo: I really messed that up when working around the API leaks. I was new, and wasn't thinking of things I should have been. The whole PoolFactoryRegistry thing is an indirection that requires more configuration than necessary.
(02:13:46 AM) carlo: ALR: :-)
(02:13:53 AM) ALR: carlo: And there's no mechanism to define properties for each Pool impl. Everything should be an injected MC bean factory.
(02:14:03 AM) carlo: ALR: We still have to get a good blueprint for Pool annotations
(02:14:15 AM) ALR: carlo: So now I'm thinking on how to fix it while maintaining backwards-compatibility.
(02:14:27 AM) ALR: carlo: For AS6 we can get it right. Same for @Cache and @CacheConfig.
(02:14:55 AM) carlo: ALR: What I really want to have is that @Cache and @CacheConfig are no longer part of ext-api
(02:15:16 AM) ALR: carlo: Yes, I'd rather the whole thing be ejb3-cache-jboss-beans.xml
(02:15:19 AM) carlo: ALR: Each cache implementation should have it's own annotations, metadata and deployers.
(02:15:28 AM) ALR: carlo: And ejb3-pool-jboss-beans.xml
(02:15:42 AM) ALR: carlo: With some nice annotations/metadata overrides.
(02:15:45 AM) carlo: ALR: So you won't even get ejb3-pool-jboss-beans.xml
(02:16:04 AM) ALR: carlo: I like it as a mechanism to configure the factory defaults. :)
(02:16:04 AM) carlo: ALR: More like: ejb3-default-pool-jboss-beans.xml
(02:16:10 AM) ALR: carlo: Yes, that.

S,
ALR

[brian.stansberry]

(02:15:19 AM) carlo: ALR: Each cache implementation should have it's own annotations, metadata and deployers.

I like that as well.

An implemenation detail we should remember when we do this though is user-friendliness when people mismatch their configuration. E.g. there used to be two @CacheConfig variants in different packages, one meant for SimpleCache, other for StatefulTreeCache. People would use the wrong one, which would result in the cache just using defaults.

Of course, getting rid of @Cache and making the cache impl implicit based on the @CacheConfig would remove that problem.