Burke, FYI, the Reporting and Logic modules both are written against OpenMRS 1.6, whereas Daemon wasn't introduced until 1.7.
Logic already has some ugly reflection code to try using the Daemon to run its scheduled task, and otherwise falls back to proxy privileges, or something like that. I think Reporting needs something similar. Once we actually stop supporting OpenMRS 1.6, writing modules will get easier, with respect to this, and also the improved activator interface. -Darius On Tue, Apr 10, 2012 at 6:34 PM, Burke Mamlin <[email protected]>wrote: > Reporting should not be able to run something as Daemon; in fact, it > should be impossible to authenticate as the daemon user. Rather, daemon > threads can only be created by Daemon and it will only start those things > that it knows about. Logic was known by Daemon because it was part of > core. As logic moves out of core, we'll need to come up with another > mechanism for Daemon to know about it (and reporting). > > One such mechanism is schedule tasks. We trust that only admins (e.g., > admins installing a module) can add a scheduled task; therefore, one of the > things Daemon knows how to do is to start an existing scheduled task. > > If you don't want to be limited to scheduled tasks, we could do something > similar for modules – e.g., define a method for OpenMRS modules (within the > module interface) that Daemon would know about and could invoke on a daemon > thread. Alternatively, you could start your processes during module > startup by spawning another daemon thread (daemon threads, like the thread > used for module startup, should be able to ask Daemon to spawn another > daemon thread). > > -Burke > > > On Tue, Apr 10, 2012 at 8:40 PM, Michael Seaton <[email protected]> wrote: > >> ** >> I think we probably need to fix reporting to do what Ben said Logic is >> doing. However, if the OpenMRS scheduler benefits from use of the Daemon >> user "for free" in 1.7+, we'll likely need to explicitly tell reporting to >> use the Daemon user for the Spring-managed scheduled tasks. Unfortunately, >> we're in a reporting sprint right now, so we're not in the ideal position >> to patch reporting to work with 1.9... >> >> Mike >> >> >> >> On 04/10/2012 08:14 PM, Darius Jazayeri wrote: >> >> So what's the implication for what we should do with 1.9? >> >> Is it a fix to 1.9.x to include the right reporting version? >> Is it a fix to reporting to avoid running the tasks if it doesn't have a >> username/password? >> >> -Darius >> >> On Tue, Apr 10, 2012 at 4:36 PM, Michael Seaton <[email protected]> wrote: >> >>> One wrinkle is that we (I) moved these tasks in 1.7.1 such that they >>> are no longer scheduled tasks executed by the OpenMRS scheduler, but rather >>> tasks managed directly by Spring's built-in scheduling mechanism. The main >>> reason for making this change was that I didn't like how the OpenMRS >>> scheduler-based Scheduled Tasks hung around after the module was >>> un-installed and also because I was running into some Classloading issues. >>> With Spring-managed scheduled tasks, these issues disappear - the tasks are >>> run if the module is installed, and not run if it isn't. The main drawback >>> is that the end user can't start / stop / delete these tasks from within >>> the management pages, but these are not meant to be optional or >>> configurable - they are things the reporting module relies on working in a >>> specific way, so shouldn't be end-user modifiable. >>> >>> >>> On 04/10/2012 06:37 PM, Ben Wolfe wrote: >>> >>> The gps should not be set by openmrs after 1.7 the daemon user is used >>> instead. The reporting module should work like the logic module and only >>> authenticate if pre 1.7. >>> >>> I like the idea of clearing the scheduler gp, but that might mess up >>> modules like reporting that haven't updated to not use the authenticated >>> user. >>> >>> Isnt there an authenticate() method that should be called? Is that still >>> looking fur the scheduler username/pw in gps? >>> >>> Ben >>> On Apr 10, 2012 6:24 PM, "Darius Jazayeri" <[email protected]> >>> wrote: >>> >>>> Wyclif, >>>> >>>> That won't solve it--when you go through the setup wizard, you are >>>> required to enter a strong admin password ("test" is not allowed), so what >>>> Mark is describing is the issue that as soon as you've set up OpenMRS for >>>> the first time, you are guaranteed to have incorrect GP values for >>>> scheduler.username and scheduler.password. As a result, your admin account >>>> will soon be locked out, and it will stay that way forever due to the >>>> scheduled task. >>>> >>>> Options: >>>> >>>> 1. clear the scheduler.password property, and make sure that >>>> scheduled tasks don't try to run as admin if that isn't set >>>> >>>> 2. the setup wizard could set scheduler.password to the new admin >>>> password (but this is insecure) >>>> >>>> 3. change the reporting module to *not* use those GPs, but rather to >>>> use an anonymous user, but grant proxy privileges... >>>> >>>> -Darius >>>> >>>> On Tue, Apr 10, 2012 at 2:29 PM, Wyclif Luyima <[email protected]>wrote: >>>> >>>>> Are you running the standalone or are you using the 1.9 demo data from >>>>> the demo data downloads page? >>>>> >>>>> If yes to any of the above, I ran into this and i think the password >>>>> for admin was changed from *test*, try *Admin123*, we need to change >>>>> it back to *test* >>>>> >>>>> Wyclif >>>>> >>>>> >>>>> On Tue, Apr 10, 2012 at 4:55 PM, Mark Goodrich <[email protected]>wrote: >>>>> >>>>>> I’m having problems logging in to OpenMRS 1.9 after doing a clean >>>>>> install (as opposed to an update of an existing database). Has anyone >>>>>> else >>>>>> run into this issue? This is what I think might be happening: >>>>>> >>>>>> >>>>>> >>>>>> https://tickets.openmrs.org/browse/TRUNK-3272 >>>>>> ------------------------------ >>>>>> Click here to >>>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>>>> OpenMRS Developers' mailing list >>>>> >>>>> >>>>> ------------------------------ >>>>> Click here to >>>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>>> OpenMRS Developers' mailing list >>>>> >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
