Thanks Saptarshi. So its thrown by spring, not openmrs. Thats unfortunate. Is this because the controller has @Controller on it? Or is it our @Handler annotation on the Resource?
I really want to try to keep all code in the rest module. Perhaps building specifically for different versions is the solution? 1) If building against 1.8 don't include certain resources and controllers. Annotate classes somehow to know what to exclude? 2) Hide certain bits of code using maven variables? 3) Add 1.9 specific resources/controllers at compile/runtime to avoid these classpath scanning errors? Any maven experts out there know if this is possible? Maven can do a lot, but I don't know if it can do this much. Ben On Thu, May 17, 2012 at 2:22 PM, Saptarshi Purkayastha <sun...@gmail.com>wrote: > Ben, > Yes, it was not discussed since you were missing and we wanted you to be > part of the decision... also time was short and it seemed like a decision > on the list could be reached. > > Yes, I can confirm that it doesn't work, if we've built the module using > 1.9.0-RC3 and then say require version to be 1.8.1 and have the > LocationAttributeResource that uses the LocationAttribute class. Spring > doesn't like it and throws the following exception: > http://pastebin.com/GBy9bRyW > > I think resource versioning is fairly trivial. If the resource changes in > its representation (or params it takes), we should make it v2 (or v1.1) and > then only that resource has a v2 in its URL while others have v1. This is > how many services exist where resources have different versions in the same > release. > > --- > Regards, > Saptarshi PURKAYASTHA > > My Tech Blog: http://sunnytalkstech.blogspot.com > You Live by CHOICE, Not by CHANCE > > > On 17 May 2012 03:35, Ben Wolfe <b...@openmrs.org> wrote: > >> I don't see this in the notes for the design call today, so I assume it >> wasn't discussed. >> http://notes.openmrs.org/Design-Forum-2012-05-16 >> >> I do NOT want branches for the module. I also would prefer to not have >> the -ext modules. Can someone confirm that the rest module def does not >> start up if the provider classes are just on the path? If it fails, I >> assume it is because of classpath scanning by us or by spring. The former >> could be caught and handled gracefully. >> >> Adding a v2 of a resource would come at any point, I think. I don't the >> the v1/v2/v3 versions match the rest module version which doesn't match the >> openmrs version. (We will need to document each rest method and keep it >> updated on the wiki to make alleviate developer version matchings) >> >> Ben >> >> >> On Wed, May 16, 2012 at 5:59 PM, Darius Jazayeri <djazayeri+...@gmail.com >> > wrote: >> >>> Yes, my suggestion is that we'll have to manage up to a couple of -ext >>> modules, for supported versions of OpenMRS. At some (way future) point we >>> might decide to stop supporting 1.8 in active web service development, and >>> we could fold -19ext into the main webservice module, and increase the >>> required version to 1.9. >>> >>> I think Ben prefers to branch the module instead (so we'd have a >>> 1.8-compatible branch, a 1.9-compatible branch, etc). >>> >>> Let's discuss this (in a time-boxed way!) on the design call today, as >>> neither Ben or I are experts on this. >>> >>> Another question: what happens when we introduce an incompatible >>> variation of a resource (e.g. in 1.9 concept.mappings changes >>> significantly)? Would we make that v2 of the concept resource only? Or does >>> introducing v2 imply incrementing the version of the whole API? (And thus >>> we might try to hide the new concept map structure under the hood.) >>> >>> -Darius >>> >>> >>> On Wed, May 16, 2012 at 7:41 AM, Saptarshi Purkayastha <sun...@gmail.com >>> > wrote: >>> >>>> So is the plan that with every new data model change in the core, there >>>> will another web service extension module?? >>>> That means to get web services in 1.10, I'd have to install the >>>> webservices.rest, the webservices.rest-19ext and then >>>> webservices.rest-110ext (or the new webservices-110.ozip) >>>> >>>> So, Spencer Kathol's work on the Provider should be in the >>>> webservices.rest-19ext module and not in 1.1 >>>> >>>> --- >>>> Regards, >>>> Saptarshi PURKAYASTHA >>>> >>>> My Tech Blog: http://sunnytalkstech.blogspot.com >>>> You Live by CHOICE, Not by CHANCE >>>> >>>> >>>> On 16 May 2012 19:55, Darius Jazayeri <djazayeri+...@gmail.com> wrote: >>>> >>>>> Saptarshi, >>>>> >>>>> I think that for the foreseeable future, all versions of the restws >>>>> module (1.0, 1.1, 1.2, etc) will require OpenMRS 1.8.1. >>>>> >>>>> So, webservices.rest 1.1 will still require OpenMRS 1.8.1. In addition >>>>> we'll have a webservices.rest-19ext that requires 1.9 and provides the >>>>> additional 1.9 resources. >>>>> >>>>> Roger, >>>>> >>>>> I actually think there's a benefit to having our REST API change more >>>>> slowly than our java API. (It would be wonderful to be able to build a >>>>> future version of sync based on having 1.8, 1.9, and 1.10 children all >>>>> synching over web services.) >>>>> >>>>> -Darius >>>>> >>>>> >>>>> >>>>> On Wed, May 16, 2012 at 4:58 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) >>>>> <r...@cdc.gov> wrote: >>>>> >>>>>> On further review, it seems to me that while there are certain >>>>>> types of changes to the data model that can be made without breaking >>>>>> RESTWS, others cannot. For example, adding a new nullable field to a >>>>>> table >>>>>> requires a change to the creatable and updatable field lists and to the >>>>>> could-be-missing field list within the resource (as well as corresponding >>>>>> changes in the .hbm and pojo), but existing calls to the resource will >>>>>> still work correctly, so it doesn't break anything. But adding providers >>>>>> and using them as a mapped collection in encounters instead of a user >>>>>> reference does break things, you can no longer create an encounter with a >>>>>> user.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> I am beginning to think that we should roll RESTWS into core so that >>>>>> it moves with its version-appropriate data model. So 1.9.1 should >>>>>> include >>>>>> a RESTWS appropriate to its data model. That would leave the "v1.0" >>>>>> portion of the URL to handle changes in the semantics of the calls, >>>>>> should >>>>>> that ever happen. And 1.8 would be the only version to use the RESTWS >>>>>> module (or we could roll it into 1.8.4 or whatever is next).**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> *From:* dev@openmrs.org [mailto:dev@openmrs.org] *On Behalf Of *Darius >>>>>> Jazayeri >>>>>> *Sent:* Tuesday, May 15, 2012 7:57 PM >>>>>> *To:* openmrs-deve...@listserv.iupui.edu >>>>>> *Subject:* Re: [OPENMRS-DEV] RESTWS release timing/content**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Roger,**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> To clarify, I do *not* think we should have branches of the >>>>>> webservices.rest module for OpenMRS 1.8.x, 1.9.x, 1.10.x, etc. I assume >>>>>> that we will release webservices.rest v1.0, and this will work with >>>>>> OpenMRS >>>>>> 1.8.2+. However if you're using OpenMRS 1.9 with webservices.rest v1.0 >>>>>> you >>>>>> will not have access to anything that wasn't available in OpenMRS 1.8 >>>>>> (e.g. >>>>>> Visits, Location Attributes) I think we should do a >>>>>> "webservices.rest-19ext" module that adds support for all the new 1.9 >>>>>> features.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> My initial thought is that adding new fields to existing resources >>>>>> (e.g. adding attributes to Location) should not increment the version >>>>>> number of the REST API. (But this is not well-thought out.)**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Regarding whether to release 1.0 or not. I feel very strongly that we >>>>>> should release 1.0 ASAP, with the current functionality.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Almost a year ago we set out a limited set of functional >>>>>> requirements: we wanted to satisfy a few key user stories that were >>>>>> suggested by interested people. (See this wiki >>>>>> page<https://wiki.openmrs.org/x/94IHAQ>.) >>>>>> We added to that the strategic requirement that whatever we release as >>>>>> "1.0" should be an API that we want to support going forwards.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> As a result of that requirement we delayed doing a 1.0 release to >>>>>> make some fundamental design changes. (The bulk of these were spurred by >>>>>> you, Roger, because you insisted we deal with the issue of subclasses. I >>>>>> think you were absolutely right to do that, and I think it led to us >>>>>> doing >>>>>> some very-necessary refactoring of the code. So, a non-sarcastic "Thanks" >>>>>> for that.)**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> At this point I really think we need release our current code (just >>>>>> missing a couple of reviews) as 1.0, and commit to supporting it. Work >>>>>> can >>>>>> and should continue to happen on the module. It is straightforward to add >>>>>> some missing resources and release 1.1, 1.2, etc. (For the record those >>>>>> would be *module* versions, *not* API versions.)**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> -Darius**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> PS- Regarding competition of resources between finishing off the 1.8 >>>>>> API and doing the 1.9 API...I'd say "patches are welcome". Whatever >>>>>> tickets >>>>>> people create and vote on, and whatever tickets people claim and submit >>>>>> patches to, is what will get released first. :-)**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> On Tue, May 15, 2012 at 3:21 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) >>>>>> <r...@cdc.gov> wrote:**** >>>>>> >>>>>> We have not had an up-to-date version of RESTWS in the module >>>>>> repo for quite a while, and there have been a lot of important changes. >>>>>> Darius would like to get something into the repo, and I agree, but I >>>>>> don't >>>>>> think the current version is sufficiently complete and correct to just >>>>>> move >>>>>> on. I have four reasons for this: (1) we don't have all the 1.8 data >>>>>> model >>>>>> in REST; (2) we have some known anomalies to fix; (3) we haven't had much >>>>>> experience with the subclass model; and (4) there will be a competition >>>>>> for >>>>>> resources due to the need for a version that supports the 1.9 data model. >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> If I understand Darius correctly, he never thought version 1.0 >>>>>> would be a complete exposure of the data model, but only a sufficient >>>>>> proof >>>>>> of concept to assure that the interface would not change drastically. >>>>>> But >>>>>> I believe everyone who has tried to use RESTWS has found a data object >>>>>> they >>>>>> needed which was not exposed. If a needed object is not exposed, then >>>>>> the >>>>>> user can't really put RESTWS to the test. I don't really care what the >>>>>> 1.8-compatible and the 1.9-compatible releases are called, I just want a >>>>>> clear path to a fully capable 1.8-compatible version. I don't want >>>>>> issues >>>>>> (1)-(3) to be lost as we pursue 1.9.**** >>>>>> >>>>>> **** >>>>>> >>>>>> It is not clear how we are going to revise RESTWS as the data >>>>>> model changes. If I understand Darius correctly, the "v1.0" portion of >>>>>> the >>>>>> URL will indicate that the module supports 1.8, and will be changed to >>>>>> another value (most likely "v2.0") when the module supports 1.9. There >>>>>> will probably not be much backporting (maybe additional queries or custom >>>>>> reps or a resource-specific catalog call) because most of the changes >>>>>> will >>>>>> depend on the data model (in the case of 1.8-1.9, location attributes, >>>>>> providers, provider attributes, visits, multiple providers per encounter, >>>>>> concept mapping, complex concepts). It seems to make sense to make a new >>>>>> 2.0 head and keep a 1.0 branch, but I don't think we've ever worked on >>>>>> both >>>>>> a branch and the head at the same time. So I think it would be better to >>>>>> get 1.0 to a more complete, correct state before we start work on 2.0. >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> Maybe the sprint schedule needs to be revised to have an RESTWS >>>>>> 1.1 (or whatever) sprint sooner, and tickets that address 1.9 issues >>>>>> should >>>>>> be given a new future release fix 2.0 (or whatever). Maybe we can have >>>>>> simultaneous 1.1 and 2.0 sprints.**** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> ------------------------------ >>>>>> >>>>>> Click here to >>>>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>>>> OpenMRS Developers' mailing list >>>>>> **** >>>>>> >>>>>> ** ** >>>>>> ------------------------------ >>>>>> >>>>>> Click here to >>>>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>>>> OpenMRS Developers' mailing list >>>>>> **** >>>>>> ------------------------------ >>>>>> Click here to >>>>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>>>> OpenMRS Developers' mailing list >>>>>> >>>>> >>>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
