What's wrong with a? Doesn't that solve the two problems with the others? Just means you might get an UnsupportedOperationException, right?
My preference for (b) and (c) is because an unsupported configuration becomes apparent at compile-time, rather than on deployment.
OTOH, a deployment exception provides a chance to explain the error in more detail (compared to a squiggly red line). If we were to take this approach, should it be a fatal exception (drop-kicking the deployment) or just a warning?
On Tue, Jun 14, 2011 at 20:12, Pete Royle
<howardmoon@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@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