86 2018-12-05 22:53:41 +0100 OperationIDs with . in it preclude server generation 2019-01-21 16:28:51 +0100 1 1 1 Unclassified MEC GS 011 Release 1 PC Linux RESOLVED FIXED Normal enhancement --- 1 michele.carignani walter.featherstone fabio.giust michele.carignani sebastian.mueller walter.featherstone Any --- oldest_to_newest 153 0 michele.carignani 2018-12-05 22:53:41 +0100 The operationIds defined in the Swagger file will prevent the generation of a server stub, because the dot is a reserved token in several languages. Please change them to include an underscore (_) instead of the dot (.) 154 1 walter.featherstone 2018-12-06 01:24:24 +0100 For clarification, which languages? I've not come across this problem before. 155 2 michele.carignani 2018-12-06 14:20:23 +0100 I have seen the issue with the nodejs-server generation (Javascript). The tool uses the operationId as the name of a function called to handle the request. When the program is loaded, functions with dots inside will trigger a syntax error. 171 3 walter.featherstone 2019-01-11 17:31:05 +0100 I'm still struggling with this one, since I've not has this problem with nodejs. https://editor.swagger.io/ -> Generate Server -> nodejs-server works fine, e.g. DefaultService.js: exports.applicationsDnsRule.GET = function(appInstanceId,dnsRuleId) { return new Promise(function(resolve, reject) { var examples = {}; examples['application/json'] = { "DnsRule" : { "dnsRuleId" : "DnsRule1", "domainName" : "www.example.com", "ipAddressType" : "IP_V4", "ipAddress" : "146.241.7.3", "ttl" : 300, "state" : "ACTIVE" } }; if (Object.keys(examples).length > 0) { resolve(examples[Object.keys(examples)[0]]); } else { resolve(); } }); } And Default.js: module.exports.applicationsDnsRule.GET = function applicationsDnsRule.GET (req, res, next) { var appInstanceId = req.swagger.params['appInstanceId'].value; var dnsRuleId = req.swagger.params['dnsRuleId'].value; Default.applicationsDnsRule.GET(appInstanceId,dnsRuleId) .then(function (response) { utils.writeJson(res, response); }) .catch(function (response) { utils.writeJson(res, response); }); }; 183 4 michele.carignani 2019-01-18 15:51:48 +0100 Hi! I will need to check again. Maybe the different result is given by different versions of Javascript/Node. Cannot try at the moment, will update asap. 184 5 fabio.giust 2019-01-21 13:59:42 +0100 Hi, I tried to reproduce the error Michele talks about. I generated the Mp1/MEC 011 node.js server, using the swagger editor tool. system: Linux host-vm01 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux npm --version 6.4.1 here is the error message i got > mp1-api@1.1.1 start /home/fgiust/MEC_APIs/MEC_011 > node index.js Error initializing middleware /home/fgiust/MEC_APIs/MEC_011/controllers/Default.js:6 module.exports.applicationsDnsRule.GET = function applicationsDnsRule.GET (req, res, next) { ^ SyntaxError: Unexpected token . at new Script (vm.js:79:7) at createScript (vm.js:251:10) at Object.runInThisContext (vm.js:303:10) at Module._compile (internal/modules/cjs/loader.js:656:28) at Object.Module._extensions..js (internal/modules/cjs/loader.js:699:10) at Module.load (internal/modules/cjs/loader.js:598:32) at tryModuleLoad (internal/modules/cjs/loader.js:537:12) at Function.Module._load (internal/modules/cjs/loader.js:529:3) at Module.require (internal/modules/cjs/loader.js:636:17) at require (internal/modules/cjs/helpers.js:20:18) npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! mp1-api@1.1.1 start: `node index.js` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the mp1-api@1.1.1 start script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR! A complete log of this run can be found in: npm ERR! /home/fgiust/.npm/_logs/2019-01-21T12_50_23_857Z-debug.log 185 6 fabio.giust 2019-01-21 14:07:44 +0100 Hi, i tried to fix the bug as Michele suggested, by replacing the .GET into _GET (for all verbs in facts), and obtained a partial solution. the server starts, but with an unexpected behavior: request: GET http://127.0.0.1:8081/exampleAPI/mp1/v1/timing/timing_caps response: rror: Cannot resolve the configured swagger-router handler: Default_TimingCaps_GET at swaggerRouter (/home/fgiust/MEC_APIs/MEC_011_fix/node_modules/swagger-tools/middleware/swagger-router.js:414:18) at call (/home/fgiust/MEC_APIs/MEC_011_fix/node_modules/connect/index.js:239:7) at next (/home/fgiust/MEC_APIs/MEC_011_fix/node_modules/connect/index.js:183:5) at /home/fgiust/MEC_APIs/MEC_011_fix/node_modules/swagger-tools/middleware/swagger-validator.js:352:30 at /home/fgiust/MEC_APIs/MEC_011_fix/node_modules/async/lib/async.js:52:16 at /home/fgiust/MEC_APIs/MEC_011_fix/node_modules/async/lib/async.js:361:13 at /home/fgiust/MEC_APIs/MEC_011_fix/node_modules/async/lib/async.js:52:16 at async.forEachOf.async.eachOf (/home/fgiust/MEC_APIs/MEC_011_fix/node_modules/async/lib/async.js:236:30) at _asyncMap (/home/fgiust/MEC_APIs/MEC_011_fix/node_modules/async/lib/async.js:355:9) at Object.map (/home/fgiust/MEC_APIs/MEC_011_fix/node_modules/async/lib/async.js:337:20) apparently there is problem now in routing the request to the right handler 186 7 walter.featherstone 2019-01-21 15:59:39 +0100 I wasn't having problems previously, but now I agree. Ok, I'll accept the merge request. 187 8 walter.featherstone 2019-01-21 16:28:51 +0100 Proposed changes accepted