Partially through a Java API, partially through xml configuration, in
the configuration beans of smart ldap. You could simply define the
Trigger bean, similar to how the current ones are defined, but do it in
the SmartLdap configuration files. Then inside of smart ldap, you get a
hold of the "uPortalTaskScheduler" and just add the smart ldap trigger
to the uPortalTaskScheduler's list of triggers.
You could also do it through XML configuration if the SmartLDAP beans
and uportal task scheduler beans are in the same Spring bean container.
I'd have to play with this a bit, but I think there would be a way
with just XML. However, if the SmartLDAP and uPortalTask Scheduler's
are in two different bean containers, then I'd think you'd have to dip
into java code to feed one object from one bean container to another
object in another bean container.
I also think your option of coding a special trigger that is on all the
time, but checks to see if SmartLDAP is actually turned on, before
running, is reasonable. The performance of it would be extremely quick
and it would be low overhead.
I guess the main point, is I feel very strongly that if quartz is
available, it should be used for periodic things like this. That's what
quartz does REALLY REALLY well. And it's going to do it much better and
most likely with fewer bugs then a hand-coded solution.
Keep in mind even if the code is correct today, it doesn't take much for
the next person in the code to make some change that screws up that
thread code.
---- Cris J H
On 08/06/2010 01:59 PM, Drew Wills wrote:
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 [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
