On 8/6/2010 11:42 AM, Cris J Holdorph wrote:
Now knowing that it is, why does there have to be multiple config files
involved. Can't SmartLdap register a task with the quartz system on
it's own?
You mean, like through a Java API?
I could see that. In this case SmartLdap could keep it's configuration
in one place, but nevertheless leverage the advantages Quartz may offer
under-the-hood.
Now, in case there's some reason you can't register out of context a new
job. And you must configure it separately. I think a counter point to
your logic though, is why should someone have to edit multiple places to
change all of the time based tasks?
That's a good counter point.
But I mostly expect to establish a sensible default behavior, and then
for schools that use SmartLdap to leave the default alone. (Setting
aside the idea above for a moment) *if* we configured the Quartz job in
schedulerContext.xml, it's less easy to provide a sensible,
pre-configured default setup since SmartLdap is an optional component.
I suppose we could ask the SmartLdap Quartz job to check (somehow) and
make sure SmartLdap is configured before doing any work. The pattern I
was trying to avoid was having a commented-out XML block in
schedulerContext.xml, with a note in the SmartLdap setup instructions to
go and uncomment it.
On 8/6/2010 10:59 AM, Eric Dalquist wrote:
> The change set for SmartLdap will leak the refresh thread when the
> portal webapp is reloaded.
Reflecting a bit more on this point... I still can't imagine leaking the
refresh thread "when the portal webapp is reloaded." And, FWIW I have
observed the new code joining the refresh thread -- and emerging from it
-- once and only once. In other words, when the portal starts up
SmartLdap joins (on the first time only) the refresh thread, and I have
observed SmartLdap resuming, successfully, from the thread that joined.
But I suppose there's a chance of a leak if -- after that first time
through -- the refresh thread(s) simply go off and never return...
somehow never finish nor error-out. There doesn't appear to be a
setTimeout() method on Thread.class, but establishing a maximum period
the thread is allowed to live could be done with a ThreadPoolExecutor or
(I presume) with Quartz as well.
drew
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
