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@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