What's wrong with a? Doesn't that solve the two problems with the others?
Just means you might get an UnsupportedOperationException, right?
On Tue, Jun 14, 2011 at 20:12, Pete Royle <howardmoon(a)screamingcoder.com>wrote:
Hi,
There are some things that I would like to make configurable for a Cron
provider (eg: threadpool size for the Quartz scheduling provider). So
for example, say there was a @ThreadPool(size=10) annotation, should I:
(a) Add that the API and ignore it for providers who don't use it
(b) Only add it to the provider which uses it, and the provider chooses
the package/class name
(c) Same as (b) but provider must use standardised package/class name
I like (c) the most followed by (b), but I think there's a chance for
conflict. Quartz is a provider for both scheduling and asynchronous.
Assuming both have configurable thread pools, there would be 2
@ThreadPool annotations on the classpath. If their package names differ
(b), developer confusion will likely ensue. If the package names are the
same (c), classloading confusion will ensue.
I will also support having these options in the cron.properties file,
but the same questions of naming and convention will apply there too.
Opinions appreciated.
Cheers,
Pete.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at:
keyserver.net,
pgp.mit.edu