Does it work worse now than it did pre-mavenization? -Darius
On Mon, Nov 7, 2011 at 1:09 AM, Rowan Seymour <[email protected]>wrote: > I've switched htmlformentry to depend on org.openmrs.module.logic 0.4 > which has been put in maven now. The test-hibernate.cfg.xml file now looks > like: > > <hibernate-configuration> > <session-factory> > ${hbmConfig} > <!--<mapping resource="TokenRegistration.hbm.xml" />--> > <mapping resource="LogicRuleToken.hbm.xml" /> > </session-factory> > </hibernate-configuration> > > So all the unit tests pass, but this module currently doesn't work > completely with OpenMRS 1.8 because of the differences between Logic 0.4 > and 0.5. Does this mean we need a "pre1.8-compatibility" branch? > > Can we do the git migration today and sort out these issues afterwards? > > Thanks > On 4 November 2011 16:39, Darius Jazayeri <[email protected]> wrote: > >> To clarify, modules ought to have two application context xml files. >> Spring combines all those plus the core ones into a single >> ApplicationContext. >> >> -Darius >> >> >> On Fri, Nov 4, 2011 at 7:13 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < >> [email protected]> wrote: >> >>> So what happens when a module has a dependency on another module, or >>> when multiple modules are loaded? Do we end up with 3, 4, 5 application >>> contexts?**** >>> >>> ** ** >>> >>> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Michael >>> Seaton >>> *Sent:* Friday, November 04, 2011 9:33 AM >>> >>> *To:* [email protected] >>> *Subject:* Re: [OPENMRS-DEV] FW: HTML form entry changes**** >>> >>> ** ** >>> >>> Hey Rowan, >>> >>> >>> I think we should encourage (or require) 2 application context's per >>> module. It is already supported (moduleApplicationContext.xml and >>> webModuleApplicationContext.xml) - you can see how we did this in the >>> reporting module here: >>> http://svn.openmrs.org/openmrs-modules/reporting/trunk/metadata/ >>> >>> I would say yes about going ahead and checking in htmlformentry with >>> those failing unit tests, as we work on getting the external dependencies >>> sorted out for fixing them. >>> >>> Mike >>> >>> >>> On 11/04/2011 04:17 AM, Rowan Seymour wrote: **** >>> >>> 1. So we'd have two application context's per module? One in the API for >>> services etc and one in the OMOD for controllers etc? **** >>> >>> 2. Can someone put logic 0.4 into the OpenMRS maven repos**** >>> >>> 3. Can I check htmlformentry into SVN now that we're down to a mere 3 >>> failing tests? **** >>> >>> ** ** >>> >>> On 3 November 2011 21:36, Darius Jazayeri <[email protected]> >>> wrote:**** >>> >>> +2. **** >>> >>> ** ** >>> >>> Ben, Matt, etc, is there a reason we did things the way we did? (I.e. >>> did something force us to put things in the omod project that don't really >>> belong there?)**** >>> >>> ** ** >>> >>> -Darius**** >>> >>> ** ** >>> >>> On Thu, Nov 3, 2011 at 12:15 PM, Burke Mamlin <[email protected]> >>> wrote: >>> >>> **** >>> >>> +1 **** >>> >>> >>> >>> On Thursday, November 3, 2011, Nyoman Ribeka <[email protected]> wrote: >>> > Hi, >>> > >>> > I think the workaround Rowan did by adding the mapping manually reveal >>> > a problem with the way we package the module. Right now what we have >>> > in the API layer for a mavenized module is just the class file only >>> > and the output from the API layer for a module is just the java class >>> > file for that module. With the current approach, we won't be able to >>> > do unit testing on the API layer because there's no configuration to >>> > wire the DAO and Service layer. And if we want to include the API >>> > layer of another module, we will end up with the same situation as >>> > above (maybe adding the omod as dependency, instead of the api would >>> > fix the above problem!) >>> > >>> > I think the better way to package the module is putting the class >>> > files and hbm and spring configuration in the api layer. With this >>> > approach we will have a better separation between the API and the web >>> > layer for the module itself. API will contains all the beans for that >>> > module and omod will contains the API jar file and the web layer for >>> > the module. >>> > >>> > Somewhat related question from me in the answers website: >>> > >>> https://answers.openmrs.org/questions/85/how-does-maven-replace-hbm-filenames-in-test-hibernatecfgxml >>> > >>> > On Thu, Nov 3, 2011 at 12:04 PM, Rowan Seymour <[email protected]> >>> wrote: >>> >> I edited test-hibernate.cfg.xml to explicitly include >>> the TokenRegistration >>> >> mapping file and that seems to fix the unknown entity exception, i.e. >>> >> >>> >> <hibernate-configuration> >>> >> <session-factory> >>> >> ${hbmConfig} >>> >> <mapping resource="TokenRegistration.hbm.xml" /> >>> >> </session-factory> >>> >> </hibernate-configuration> >>> >> >>> >> But now those 3 unit tests are failing with another exception... >>> >> java.lang.NoSuchMethodError: >>> >> >>> org.openmrs.logic.LogicContext.eval(Ljava/lang/Integer;Lorg/openmrs/logic/LogicCriteria;Ljava/util/Map;)Lorg/openmrs/logic/result/Result; >>> >> I've looked at the source for LogicContext and it appears that between >>> >> OpenMRS 1.7 and 1.8 it's eval methods switched from using Patient >>> objects as >>> >> parameters, to using integers. The same switch occurred >>> in LogicContextImpl >>> >> in the logic module between 0.4 and 0.5 >>> >> So I need to depend on version 0.4 of the logic module which isn't in >>> the >>> >> maven repository. Can someone who knows more about this module put it >>> in >>> >> maven? Does html form entry work with OpenMRS 1.8? >>> >> On 3 November 2011 15:50, Rowan Seymour <[email protected]> >>> wrote: >>> >>> >>> >>> It's using logic 0.5 same as Mark just showed. The 3 failing tests >>> are: >>> >>> >>> >>> >>> applyExcludes_shouldReturnCorrectXmlAfterApplyExcludeIfTag(org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest): >>> >>> Unknown entity: org.openmrs.logic.token.TokenRegistration >>> >>> >>> >>> >>> applyIncludes_shouldReturnCorrectXmlAfterApplyIncludeTag(org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest): >>> >>> Unknown entity: org.openmrs.logic.token.TokenRegistration >>> >>> >>> >>> >>> processIncludeLogic_shouldReturnACorrectBooleanValueForLogicTestString(org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest): >>> >>> Unknown entity: org.openmrs.logic.token.TokenRegistration >>> >>> Stack trace just shows that it didn't recognize TokenRegistration as >>> an >>> >>> entity.... >>> >>> >>> >>> >>> applyExcludes_shouldReturnCorrectXmlAfterApplyExcludeIfTag(org.openmrs.module.htmlformentry.HtmlFormEntryGeneratorTest) >>> >>> Time elapsed: 0.255 sec <<< ERROR! >>> >>> org.hibernate.MappingException: Unknown entity: >>> >>> org.openmrs.logic.token.TokenRegistration >>> >>> at >>> >>> >>> org.hibernate.impl.SessionFactoryImpl.getEntityPersister(SessionFactoryImpl.java:550) >>> >>> at >>> >>> >>> org.hibernate.impl.SessionImpl.getEntityPersister(SessionImpl.java:1338) >>> >>> at org.hibernate.engine.ForeignKeys.isTransient(ForeignKeys.java:180) >>> >>> at >>> >>> >>> org.hibernate.event.def.AbstractSaveEventListener.getEntityState(AbstractSaveEventListener.java:512) >>> >>> at >>> >>> >>> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:80) >>> >>> at >>> >>> >>> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70) >>> >>> at >>> org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:507) >>> >>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:499) >>> >>> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:495) >>> >>> at >>> >>> >>> org.openmrs.logic.token.db.hibernate.HibernateTokenDAO.saveTokenRegistration(HibernateTokenDAO.java:118) >>> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> >>> at >>> >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>> >>> at >>> >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>> >>> at java.lang.reflect.Method.invoke(Method.java:597) >>> >>> at >>> >>> >>> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) >>> >>> at**** >>> >>> >>> org.springframework.aop.framework.ReflectiveMethodIn-- ** ** >>> >>> >>> > Thanks, >>> > >>> > Nyoman Ribeka >>> > >>> > _________________________________________ >>> > >>> > 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] >>> > >>> > **** >>> ------------------------------ >>> >>> 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 >>> **** >>> >>> >>> >>> **** >>> >>> ** ** >>> >>> -- >>> *Rowan Seymour* >>> tel: +250 783835665 >>> http://twitter.com/rowanseymour**** >>> ------------------------------ >>> >>> 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 >> > > > > -- > *Rowan Seymour* > tel: +250 783835665 > http://twitter.com/rowanseymour > > ------------------------------ > 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]
