The messaging module has a task that runs every 5 seconds and generates a log message in the log file every time whenever it runs. Is there a way to suppress this type of logging messages in my log file? I have checked all my of modules's log4j.xml settings to ensure all of the log level to be WARN or above but that does not seem to help to suppress the logs from the LoggingAdvice.
INFO - LoggingAdvice.invoke(102) |2012-02-22 13:16:25,606| In method SchedulerService.saveTask. Arguments: TaskDefinition=[TaskDefinition id=12 name=Messaging Module Gateway Manager class=org.openmrs.module.messaging.schedulertask.DispatchMessagesTask startTime=null repeatInterval=5 secondsUntilNext=0], INFO - LoggingAdvice.invoke(127) |2012-02-22 13:16:25,607| Exiting method saveTask Any suggestions would be highly appreciated! Thanks, Hui Xiao From: [email protected] [mailto:[email protected]] On Behalf Of Ben Wolfe Sent: Tuesday, February 21, 2012 10:23 PM To: [email protected] Subject: Re: [OPENMRS-DEV] concept_reference_term and sync Perhaps this is why we originally had hardcoded the uuids to be some combination of the map name and source hl7 code? We undid that recently because it wasn't actually turning out to be unique. Dave, this is something that should be added to the Sync Upgrade Scripts jsp page. "The scripts here should be generated on the PARENT server AFTER upgrading and run on your CHILD databases BEFORE you upgrade them to the new version". Ben On Tue, Feb 21, 2012 at 8:36 PM, Dave Thomas <[email protected]<mailto:[email protected]>> wrote: Hi. Thanks for the explanations. sync works through the hibernate interceptor, so when you're running direct SQL updates, these aren't going to get logged. At least I don't think they will, because liquibase isn't using the openmrs services, right? And actually, if they do get logged, I would expect liquibase to fail spectacularly on the child servers, because many of its changes would have already been applied by sync. For sync, I think the rules around liquibase are that if you're adding a row to a table that has uuids, those uuids should be hard coded into the liquibase xml. I'm ok with hacking those tables manually after the upgrade, I just need to figure out the exact routine ahead of time. D On Feb 21, 2012 4:49 PM, "Wyclif Luyima" <[email protected]<mailto:[email protected]>> wrote: Hi Dave, I'm not sure how sync handles changes that are a result of running liquibase upgrade scripts. However, from my understanding there should be no conflict of any sort in uuids for reference terms since concept_reference_term and concept_map_type are new tables that were added in 1.9. What those liquibase changesets are doing is they generate concept reference terms from your existing concept_map table, they also insert new rows in the newly created table concept_map_type. An overview of the changes (You can visit additions in concept mapping attributes<https://wiki.openmrs.org/display/projects/Additional+Attributes+on+Concept+Map+%28Design+Page%29> for a some background info) Before 1.9 a concept map had minimal data about it and one of its properties was the sourcecode property which in the real world of concept dictionaries is not supposed to be looked at as a mere string but rather a more compound property that has attributes like name, version, description and a list of other terms that are related to it. Further more, when you create a mapping, you need to specify the map type which describes the relationship between it and the one you are mapping to in the other dictionary. Examples of my types are; replaced by, is broader, is narrower, interprets etc. This is the kind of design for concept mappings that folks that manage concept dictionaries desired OpenMRS to have and this is why the changes were made. I assumed sync has a mechanism to properly handle additions made by such upgrades scripts so that they get copied to the other servers. Wyclif On Tue, Feb 21, 2012 at 6:33 PM, Dave Thomas <[email protected]<mailto:[email protected]>> wrote: And it looks like the same issue is going to exist with concept_map_type? d On Tue, Feb 21, 2012 at 3:29 PM, Dave Thomas <[email protected]<mailto:[email protected]>> wrote: Hi. I could use some help wrapping my mind around what I think is an incompatibility between sync and the liquibase upgrade scripts. ConceptReferenceTerm is an OpenmrsObject, meaning that sync is going to pay attention to it. However, in the liquibase scripts, the concept_reference_term table is populated with the following SQL: INSERT INTO concept_reference_term (concept_reference_term_id, concept_source_id, code, description, creator, date_created, uuid) SELECT cm.concept_map_id, cm.source, cm.source_code, cm.comment, cm.creator, cm.date_created, UUID() FROM concept_reference_map cm, concept_reference_source crs WHERE cm.source = crs.concept_source_id This means that the 'same' ConceptReferenceTerms are going to have different UUIDs between the parent and child sync servers. So if on the parent i modify a ConceptReferenceTerm, that's going to cause a sync failure -- its not going to be able to find the object. I don't know exactly what ConceptReferenceTerms do -- does it look like upon upgrading all child servers, we're going to have to override the liquibase results for this table? d ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list ________________________________ Click here to unsubscribe<mailto:[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]
