Tuesday, September 1, 2015, 10:01:31 AM, Pradeep Murugesan wrote: > Sure Daniel, > I will change the initialization @ method level. > I have a couple of questions. Please reply when you find time. Sorry If its > too naive. > 1. I tried to check whether jersey's resource methods are singleton > but found in the doc that they spawn a thread for each request. And > we may turn on the singleton thing if required through some explicit > settings.
It's Spring bean (@Component), and those are singletons by default. Even if wasn't a singleton, I see no reason for a response object to be recycled between requests. It can be the source for hideous bugs, as you start with a dirty object, etc. > I browsed our code to see if we have some setting but > couldn't find anything. The easiest is just trying it with some log messages. > In 3.4 of > https://jersey.java.net/nonav/documentation/latest/user-guide.html#d0e2586 > we can see they mentioning the above. > 2. In the mean time I am trying to get hold of how freemarker > template engine works by trying to fix some low hanging bugs so that > I can understand the architecture better. I am browsing for issues > here http://sourceforge.net/p/freemarker/bugs/. Kindly let me know a > good place or a minor bug to start with. Most bugs will be stuff that isn't fixed because it's tricky to fix them, often because of backward compatibility requirements... But for example here's this new one: http://sourceforge.net/p/freemarker/bugs/434/ Could be checked if it's true, and why it happens. But of course deal what we feel like with. (It's also a good idea to polishing what you have started, like writing the JUnit tests, etc.) > Pradeep. > >> Date: Mon, 31 Aug 2015 20:49:34 +0200 >> From: [email protected] >> To: [email protected] >> Subject: Re: Rest Service for FreeMarkerOnline >> >> OK, thanks! I will be rather busy for a few days, so it might will >> take a while until I check this out in detail. But I assume you know >> of things that you wanted to finish/polish anyway. >> >> Something I have spotted with this quick look now is that >> executeResponse shouldn't be a field in >> FreeMarkerOnlineExecuteResource, as I suppose the resource object is a >> singleton used by multiple threads. >> >> >> Monday, August 31, 2015, 3:21:09 PM, Pradeep Murugesan wrote: >> >> > Hi Daniel, >> > >> > https://github.com/pradeepmurugesan/freemarker-online/commit/71e70d6caf9bead735ca0f2b6eb4f81c708a1922 >> > I have fixed the code review comments and integrated the same with UI. >> > Please let me know your reviews. >> > >> > Pradeep. >> > >> >> Date: Mon, 31 Aug 2015 12:22:17 +0200 >> >> From: [email protected] >> >> To: [email protected] >> >> Subject: Re: Rest Service for FreeMarkerOnline >> >> >> >> Certainly it's good enough to go ahead with the UI. >> >> >> >> Some random stuff I have noticed: >> >> >> >> - In "problems", the field names by convention should start with lower >> >> case, and they will have to be extracted to enums (or to static >> >> final String-s). >> >> >> >> - Class names will need some cleanup. Like FreeMarkerPayload and >> >> FreeMarkerResponse are in fact for the "execute" resource only, not >> >> for FM-Online in general, so I guess they should be ExecutreRequest >> >> and ExecuteResponse. FreeMarkerErrorReponse is for the FM *online* >> >> service, but that's already told by the package so... maybe just >> >> ErrorResponse. Anyway, these are just Alt+Shift+R things. >> >> >> >> -- >> >> Thanks, >> >> Daniel Dekany >> >> >> >> >> >> Sunday, August 30, 2015, 4:47:55 PM, Pradeep Murugesan wrote: >> >> >> >> > Hi Daniel, >> >> > https://github.com/pradeepmurugesan/freemarker-online/commit/80c984af1e810d69db2894146d67b52e2449a584 >> >> > >> >> > I have made the changes as per your comments below. Please review >> >> > and let me know if any corrections. >> >> > Still I didn't do the UI for this new Response structure. Thought >> >> > we will finalize the API Responses then we will get into the UI. >> >> > Pradeep. >> >> > >> >> >> Date: Sat, 29 Aug 2015 18:30:33 +0200 >> >> >> From: [email protected] >> >> >> To: [email protected] >> >> >> Subject: Re: Rest Service for FreeMarkerOnline >> >> >> >> >> >> Saturday, August 29, 2015, 4:12:16 PM, Pradeep Murugesan wrote: >> >> >> >> >> >> > okay.. >> >> >> > So almost all the errors we handle should go under Success right. >> >> >> > Having a structure like this would help I believe. >> >> >> > { error: true/false, outputTruncated: true/false, failureReason: >> >> >> > String output: String} >> >> >> >> >> >> That's for the HTTP 200 answers only, I assume. We miss the >> >> >> information about which field the failureReason applies to. So, I >> >> >> think, the cleanest and most flexible would be if we remove "error" >> >> >> (it's confusing and redundant anyway) and "failureReason", and instead >> >> >> add a "problems" JSON Object, in which the keys are the field names, >> >> >> and the value are the error descriptions. It's like some simple form >> >> >> processing answer. >> >> >> >> >> >> And then there are the HTTP 5xx errors. There I think we can get away >> >> >> with an "errorCode" and an "errorDescription" for now. >> >> >> >> >> >> -- >> >> >> Thanks, >> >> >> Daniel Dekany >> >> >> >> >> >> > Based on the error flag we can decide what to display. Sorry If I >> >> >> > am taking a longer time to get hold of things. >> >> >> > Pradeep. >> >> >> >> Date: Sat, 29 Aug 2015 14:34:58 +0200 >> >> >> >> From: [email protected] >> >> >> >> To: [email protected] >> >> >> >> Subject: Re: Rest Service for FreeMarkerOnline >> >> >> >> >> >> >> >> There are some cases whose distinction can be interesting for a UI >> >> >> >> (without much research, so it might not be accurate): >> >> >> >> - Successful Web service call results: >> >> >> >> - Template output, no template or data-model errors >> >> >> >> - Template output that's cut at a point as it was too long >> >> >> >> - Failed data model building >> >> >> >> - Failed template execution (position can be interesting here on >> >> >> >> the >> >> >> >> long run) >> >> >> >> - Service errors: I guess we just need the error message here. >> >> >> >> - A bit of both: Long running template timeout. Usually it's the >> >> >> >> user's mistake... usually. >> >> >> >> >> >> >> >> The *template* used by the current UI doesn't care about such >> >> >> >> details, >> >> >> >> but what it displays was already assembled by code that also belongs >> >> >> >> to the UI (i.e., to the JavaScript that processes the JSON >> >> >> >> response). >> >> >> >> That logic is certainly simplistic currently, but then, UI-s can >> >> >> >> change any time (and multiple different UI-s can co-exist), while >> >> >> >> Web >> >> >> >> service API-s less so. >> >> >> >> >> >> >> >> >> >> >> >> Saturday, August 29, 2015, 1:19:41 PM, Pradeep Murugesan wrote: >> >> >> >> >> >> >> >> > Hi Daniel, >> >> >> >> > The thing I am trying to understand here is the need for all the >> >> >> >> > 3 >> >> >> >> > fields of FreeMarkerServiceResponse for the UI. >> >> >> >> > FreeMarkerOnline view while rendering the template just uses the >> >> >> >> > 2 parameters. >> >> >> >> > 1. Is there an error in the result 2. what is the error message >> >> >> >> > <#if hasResult> <div class="resultContainer"> <label >> >> >> >> > for="result">Result</label> <textarea id="result" >> >> >> >> > class="pure-input-1 source-code <#if errorResult> error</#if>" >> >> >> >> > readonly>${result}</textarea> </div></#if> >> >> >> >> > >> >> >> >> > So assuming we too need the same from Ajax requests >> >> >> >> > I am returning the result & the error is found based on the >> >> >> >> > status code of the response. >> >> >> >> > Kindly let me know your thoughts. >> >> >> >> > Pradeep. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> >> Date: Fri, 28 Aug 2015 22:51:52 +0200 >> >> >> >> >> From: [email protected] >> >> >> >> >> To: [email protected] >> >> >> >> >> Subject: Re: Rest Service for FreeMarkerOnline >> >> >> >> >> >> >> >> >> >> The response should be JSON because we will need a few separate >> >> >> >> >> fields >> >> >> >> >> there. If you look at FreeMarkerServiceResponse, you will see 3 >> >> >> >> >> candidates, but then you will find more, as the thrown >> >> >> >> >> exceptions also >> >> >> >> >> carries information that's needed for the UI, as you can see in >> >> >> >> >> FreeMarkerService.calculateTemplateOutput. >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> Thanks, >> >> >> >> >> Daniel Dekany >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Friday, August 28, 2015, 9:57:58 PM, Pradeep Murugesan wrote: >> >> >> >> >> >> >> >> >> >> > Sure Daniel, >> >> >> >> >> > I will change as per your comments. >> >> >> >> >> > A quick clarification regarding the json response can be like >> >> >> >> >> > following ? >> >> >> >> >> > { result: <output> } >> >> >> >> >> > Pradeep. >> >> >> >> >> > >> >> >> >> >> >> Date: Fri, 28 Aug 2015 21:26:58 +0200 >> >> >> >> >> >> From: [email protected] >> >> >> >> >> >> To: [email protected] >> >> >> >> >> >> Subject: Re: Rest Service for FreeMarkerOnline >> >> >> >> >> >> >> >> >> >> >> >> Friday, August 28, 2015, 7:53:45 PM, Pradeep Murugesan wrote: >> >> >> >> >> >> >> >> >> >> >> >> > Hi Daniel, >> >> >> >> >> >> > I have made the rest service up @ a new path /compile >> >> >> >> >> >> > The service takes the following json as input >> >> >> >> >> >> > { "template": "Hello ${user}", "dataModel": >> >> >> >> >> >> > "user=pradeep"} >> >> >> >> >> >> > and then compiles the template and dataModel and returns >> >> >> >> >> >> > the output. >> >> >> >> >> >> > https://github.com/pradeepmurugesan/freemarker-online/commit/10de59ac0db0bf0f79ab28214f50c851a5610e20 >> >> >> >> >> >> > >> >> >> >> >> >> > Please review the above commit and let me know if its ok. >> >> >> >> >> >> >> >> >> >> >> >> The response will have to be JSON as well (not TEXT_PLAIN), >> >> >> >> >> >> but I >> >> >> >> >> >> guess that was planned later. >> >> >> >> >> >> >> >> >> >> >> >> The usage of the "compile" term is confusing here, as you >> >> >> >> >> >> actually >> >> >> >> >> >> parse (aka. compile) and then "process" (aka. execute) here. >> >> >> >> >> >> The last >> >> >> >> >> >> naturally implies the first. So I guess it should be, like, >> >> >> >> >> >> "run" or >> >> >> >> >> >> "execute". >> >> >> >> >> >> >> >> >> >> >> >> Also, all the web service operations should go under /api/, >> >> >> >> >> >> and the UI >> >> >> >> >> >> outside it. >> >> >> >> >> >> >> >> >> >> >> >> > Will >> >> >> >> >> >> > Integrate with the UI. I have a questions though >> >> >> >> >> >> > 1. Should I modify in the same path as "/" or keeping it >> >> >> >> >> >> > in a >> >> >> >> >> >> > separate path like "/compile" is fine ? >> >> >> >> >> >> >> >> >> >> >> >> The UI addresses should remain /, and the current web service >> >> >> >> >> >> should >> >> >> >> >> >> be under /api/run or something, I think. >> >> >> >> >> >> >> >> >> >> >> >> > Also I will write unit tests once we finalize the path. >> >> >> >> >> >> > Pradeep. >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Daniel Dekany >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> >> >> Thanks, >> >> >> >> Daniel Dekany >> >> >> > >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
