This content has been marked as final.
Show 8 replies
-
1. Re: Status of annotation based configuration
anil.saldhana Nov 16, 2007 10:59 AM (in response to starksm64)Use reasonable defaults for annotations?
-
2. Re: Status of annotation based configuration
adrian.brock Nov 16, 2007 11:17 AM (in response to starksm64)"anil.saldhana@jboss.com" wrote:
Use reasonable defaults for annotations?
That doesn't make sense you have to specify the value if you use the annotation
directly.
Rather than the normal annotation, I'd guess the problem is the annotation
created from the xml.
No default here:public class PoolImpl implements Pool { public String value;
or here:private void addPoolAnnotations(EJBContainer container, JBossEnterpriseBeanMetaData enterpriseBean) throws Exception { if (enterpriseBean.getPoolConfig() != null) { PoolConfigMetaData config = enterpriseBean.getPoolConfig(); PoolImpl poolAnnotation = new PoolImpl(); if (config.getValue() != null && !config.getValue().trim().equals("")) poolAnnotation.setValue(config.getValue()); if (config.getMaxSize() != null) poolAnnotation.setMaxSize(config.getMaxSize()); if (config.getTimeout() != null) poolAnnotation.setTimeout(config.getTimeout()); addClassAnnotation(container, Pool.class, poolAnnotation); } }
-
3. Re: Status of annotation based configuration
alrubinger Nov 16, 2007 12:14 PM (in response to starksm64)There should be compile-time constraints to ensure that @Pool.value is specified; as Adrian notes, this is bypassed when using XML-based configuration.
http://jira.jboss.com/jira/browse/EJBTHREE-1119
S,
ALR -
4. Re: Status of annotation based configuration
alrubinger Nov 16, 2007 12:32 PM (in response to starksm64)In the case of missing "value" in XML, I'd prefer a Deployment Exception:
if (config.getValue() != null && !config.getValue().trim().equals("")) { poolAnnotation.setValue(config.getValue()); } else { throw new RuntimeException("detailed message"); }
...instead of a default; let the bean provider know they must specify a registered Pool implementation if they're going to perform an override in jboss.xml.
S,
ALR -
5. Re: Status of annotation based configuration
anil.saldhana Nov 16, 2007 12:43 PM (in response to starksm64)Think Adrian said he is going to/has an idea how to get this issue resolved. So verify with him, Andrew. :)
-
6. Re: Status of annotation based configuration
adrian.brock Nov 20, 2007 6:56 AM (in response to starksm64)"ALRubinger" wrote:
...instead of a default; let the bean provider know they must specify a registered Pool implementation if they're going to perform an override in jboss.xml.
Why do they have to specify a default pool implementation?
Most likely all they want to do is change the pool size?
We should define defaults somewhere and reference them
from the three places that use.
e.g.public interface PoolDefaults { String defaultPool = "ThreadLocalPool"; int defaultSize = 30; // etc. } public @interface Pool { String value() default PoolDefaults.defaultPool; int size() default PoolDefaults.defaultSize; // etc. } public class PoolImpl implements Pool { public String value = PoolDefaults.defaultPool; public int maxSize = PoolDefaults.defaultSize; // etc. }
-
7. Re: Status of annotation based configuration
alrubinger Nov 20, 2007 10:35 AM (in response to starksm64)"adrian@jboss.org" wrote:
Why do they have to specify a default pool implementation? Most likely all they want to do is change the pool size?
A much better point."adrian@jboss.org" wrote:
We should define defaults somewhere and reference them from the three places that use.
OK, but if we externalize the defaults into a "constants" class/interface, it'll have to go into ext-api for @Pool to get at it. I don't think this is too implementation-specific to be a problem, but worth noting.
S,
ALR -
8. Re: Status of annotation based configuration
adrian.brock Nov 20, 2007 10:45 AM (in response to starksm64)"ALRubinger" wrote:
OK, but if we externalize the defaults into a "constants" class/interface, it'll have to go into ext-api for @Pool to get at it. I don't think this is too implementation-specific to be a problem, but worth noting.
S,
ALR
If you don't like the default being in ext-api, make the defaultPool "##Default" or
"*Default" then bind that to a real runtime default in your PoolFactoryRegistry config.