Sorry, I miss-read the code and thought there was essentially a
while(true) loop in the refresh code that stayed resident as a
background thread.
-Eric
On 8/6/10 11:34 AM, Drew Wills wrote:
On 8/6/2010 11:10 AM, Cris J Holdorph wrote:
What do you mean it will leak the refresh thread? Won't
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
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 conf
> Does each SmartLdap item have "SmartLdap" in its name?
> Does each Quartz configuration item have "Quartz" in its name?
And the extension of the theme:
Quartz.SmartLdap.UseBacon=true
--
Bruce Tong
Software Engineer
Office of Information Technology
Ohio University
--
You are currently subscr
As a relatively new adopter, I already feel like I face something like
50 configuration files scattered over a tree of uPortal core and
portlets, plus a mirrored tree of overlays, plus issues related to
desiring different overlay trees for each of 4 environments so that
configurations can propogate
You imply to use Quartz you'd have to modify multiple config files.
Until this email thread I didn't even know quartz was available. 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? It doesn'
On 8/6/2010 11:10 AM, Cris J Holdorph wrote:
What do you mean it will leak the refresh thread? Won't the thread
complete and then die? I didn't think the thread lived on forever, but
only for as long as it took to refresh the group tree one time.
This is my understanding as well -- the thread
What do you mean it will leak the refresh thread? Won't the thread
complete and then die? I didn't think the thread lived on forever, but
only for as long as it took to refresh the group tree one time.
But I agree, if quartz is available, that's what quartz is good at and
I'd strongly advoca
The change set for SmartLdap will leak the refresh thread when the
portal webapp is reloaded.
If possible this refresh process should be a periodic trigger managed by
the quartz scheduler that already exists in 3.x. Using the schedule
guarantees correct thread handling and configuration level
