I have sent him a fix for this.. -- Morten
On Mon, Oct 29, 2012 at 11:43 AM, Lars Helge Øverland <[email protected]>wrote: > Hi Bob, it should be possible to define a more specific mapping in the > concrete controller class. To see the stack trace in the log you can > start any single web-module with mvn clean jetty:run . Your build > cycle is then to run mvn install on the dhis-web-api module, then mvn > clean jetty:run on e.g. dhis-web-reporting module. > > Lars > > On Sun, Oct 28, 2012 at 10:43 PM, Bob Jolliffe <[email protected]> > wrote: > > Hi Morten > > > > On 28 October 2012 13:18, Morten Olav Hansen <[email protected]> wrote: > >> Hi Bob > >> > >> This should be as easy as adding another method.. we already have > >> getObjectList (I think thats the name.. ) in our ABC. What you will > need to > >> do, is to add another method in DataSetController, maybe call it > >> getDataSetsDSD (or something similar). And have a request-mapping that > >> points to both dataSets and dataSets.dsd, this together with the > consumed = > >> mimetype option, should give you a unique combination (spring mvc will > >> complain if two requestmappings point to the same method) > > > > This is all what I figured. Estimated 2 hours work and 2 days later > > :-) So I have a method in DataSetController with a signature like: > > > > @RequestMapping( value = DataSetController.RESOURCE_PATH + ".dsd", > > produces = "application/dsd+xml" ) > > public void getStructure( @RequestParam Map<String, String> > > parameters, HttpServletResponse response ) > > > > Which is I think like you say (other than produces rather than > > consumes). But all I get is the "Aw snap" page with nothing in the > > logs whatsoever which makes this really difficult to debug. (I don't > > know if you have any tips for efficient debugging, but currently my > > edit-compile-test cycle is also very unfriendly, going into many > > minutes). > > > > I *think* (and I feel I am no expert on this), that the getObjectList > > in abstract controller is catching ALL get requests to dataSets. I > > had originally thought that providing a more precise match to the > > request in the dataSets class would trump the more general match in > > the abstract controller (you will recognize xslt as having dominated > > my thinking on this matching business). Anyway it looks like it > > doesn't work like this. If two controller methods are an ambiguous > > match, spring seems to just go pop. > > > > Thats ok, but if it is the case, then either we would have to make > > specific exclusions to the abstract controller match (which could get > > ugly as it is used for much more than datasets), or move back away > > from /api/dataSets to something like /api/dsd. > > > > Can you confirm that I am reading this correctly. > > > > Bob > > > > > > > >> > >> Try it... if its not working, I will try and add it for you > >> > >> -- > >> Morten > >> > >> > >> > >> On Sat, Oct 27, 2012 at 6:54 PM, Bob Jolliffe <[email protected]> > wrote: > >>> > >>> Hi Morten > >>> > >>> I am struggling to grasp something (well actually to do something) > >>> which I thought would be fairly simple, and probably even is if only I > >>> knew how ... > >>> > >>> It has to do with where you have been clever with the > >>> AbstractCrudController in the web api. > >>> > >>> Something like DataSetController extends this. > >>> > >>> Currently /api/dataSets returns you the full list of datasets > >>> formatted in html. And using either the extension (.xml or .json) or > >>> accept headers we can get xml or json renditions of the same. > >>> > >>> But I want to return an alternative xml description of the structure > >>> of the datasets (lets call it as data structure definition or DSD). > >>> Is there any way to map a request which uses either an extension (eg > >>> dataSets.dsd) or accept header (eg application/dsd+xml) which DOES NOT > >>> get routed through the getObjectList method of AbstractCrudController? > >>> > >>> Bob > >> > >> > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~dhis2-devs > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~dhis2-devs > > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
