<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><br></div><blockquote type="cite">What's wrong with a? Doesn't that solve the two problems with the others? Just means you might get an UnsupportedOperationException, right?<br></blockquote><div><br></div><div>My preference for (b) and (c) is because an unsupported configuration becomes apparent at compile-time, rather than on deployment.</div><div><br></div><div>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?</div><div><br></div><br><blockquote type="cite"><br><div class="gmail_quote">On Tue, Jun 14, 2011 at 20:12, Pete Royle <span dir="ltr"><<a href="mailto:howardmoon@screamingcoder.com">howardmoon@screamingcoder.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
There are some things that I would like to make configurable for a Cron<br>
provider (eg: threadpool size for the Quartz scheduling provider). So<br>
for example, say there was a @ThreadPool(size=10) annotation, should I:<br>
<br>
(a) Add that the API and ignore it for providers who don't use it<br>
(b) Only add it to the provider which uses it, and the provider chooses<br>
the package/class name<br>
(c) Same as (b) but provider must use standardised package/class name<br>
<br>
I like (c) the most followed by (b), but I think there's a chance for<br>
conflict. Quartz is a provider for both scheduling and asynchronous.<br>
Assuming both have configurable thread pools, there would be 2<br>
@ThreadPool annotations on the classpath. If their package names differ<br>
(b), developer confusion will likely ensue. If the package names are the<br>
same (c), classloading confusion will ensue.<br>
<br>
I will also support having these options in the cron.properties file,<br>
but the same questions of naming and convention will apply there too.<br>
<br>
Opinions appreciated.<br>
<br>
Cheers,<br>
<br>
Pete.<br>
<br>
<br>
<br>
_______________________________________________<br>
seam-dev mailing list<br>
<a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Jason Porter<br><a href="http://lightguard-jp.blogspot.com/" target="_blank">http://lightguard-jp.blogspot.com</a><br><a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>
<br>Software Engineer<br>Open Source Advocate<br>Author of Seam Catch - Next Generation Java Exception Handling<br><br>PGP key id: 926CCFF5<br>PGP key available at: <a href="http://keyserver.net/" target="_blank">keyserver.net</a>, <a href="http://pgp.mit.edu/" target="_blank">pgp.mit.edu</a><br>
</blockquote></div><br></body></html>