Have you tried to change the value of the global property 'log.level.openmrs' to warn, i think it is set to info by default.
Wyclif On Wed, Feb 22, 2012 at 1:28 PM, Hui Xiao <[email protected]> wrote: > 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]> 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]> 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]> 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]> 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<[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]
