Registering a new REST Service Mapping in my shared Hosting account, I've found a conflict to an existing Mapping in another account (website). This conflict was declared by an error: "access denied ('java.io.FilePermission' 'D:\[website_root]\SubDomains\[api_subDomain_folder]\[REST_service_mapping_folder]' 'read')".
My suggestion is making the ColdFusion Admin's REST Service Mapping Registration by application scope, similar as ColdFusion Schedule. As know, You can implement a general schedule or by application scope.
So, do you agree to my suggestion?
Copy link to clipboard
You raise a few things there, I_am_Sceiffer.
First, if I understand you correctly, you're saying you would like a feature to register REST services at the application level rather than in the Admin. Good news there: it's already possible. See the docs on CF REST services and this page in particular, which lists 4 ways to register REST services in CFML, one of which is indeed at the application level. See "Option 4: Registering a REST application using the restInitApplication method". After checking out that and other resources on it, if you have remaining issues with it, let us know.
Second, you mention getting a "access denied" error, related to 'java.io.FilePermission'. That would suggest that your host is perhaps using the CF "Sandbox Security" feature, to keep apps in one folder from accessing files in some other folder. Of course that's a good thing, for all concerned. 🙂 But I gather it's that you wanted to use a rest service name that conflicted with the same name that pointed to some other.
I haven't tested if the registration of a service in one app, using restinitapplication, will set things up to allow two of the same name to be used in two different apps. If you find out (or if anyone knows), please do let us know here.
Finally, your title was "how to suggest a new feature", and technically one does that at tracker.adobe.com, which lets you create either bug reports or feature requests. But as you see it can be useful to raise it here first, in case some may see and comment on it before you may try to file something at the tracker site. While folks CAN choose to try to watch for new postings there, I don't find it's nearly as common as folks choosing to watch for new discussions here.
Hi Mr. Arehart!
First of all, thank you so much for your answer! For me, a tiny developer in this world, receiving an answer by you, is one of greatest pleasures I've ever received in my whole life!
Continuing to your mentions. As I know about scheduling, you may register a schedule for your application. It seems that anyone using another application in the same server can register another schedule refered by the same name.
About REST Services registering, as I thought previously, each Service Mapping could be registered for each HOST, when you use restInitApplication with settings struct param (specifically 'useHost' then optionally 'host' variables; if you do not set 'host', ColdFusion assumes the host in cfm page that triggers restInitApplication) after directory and mapping params (using the same restSetting variables' application struct applied at 'this' scope) or generic REST Services whether you do not mention the 'useHost'. If you do not mention 'useHost', the localhost:8500 (considering you set port 8500 for your Admin access) can access each generic REST Service too, then any other web site containig in ColdFusion server.
After doing some tests, I've concluded that registered REST Services for a HOST can be access by its host only, but its Mapping can't be exclusive for the host it belongs only. If someone would try to register a REST Service for another host, the Admin wouldn't allow, then the error 'java.io.FilePermission' would appear. That's the reason I put a generic title suggesting a new feature.
The ColdFusion I'm using is 2018 version (that got a lot of errors and unexpected changes after update 4, althought I'm using update 10) and I'm waiting eagerly for 2020 version. Honestly I'm thinking the lastest stable ColdFusion is version 11. After that, I needed to take a lot of workaround solutions to target the necessities I had. I apologize for my honesty, but the new version is comming and I don't know if those errors would persist. One tiny example is not using bracket notation in 'for..in' statement. I needed to change for dot notation. You have to use "for(scope.variable in scope.complex_variable)" instead of "for(scope['variable'] in scope['complex_variable'])". For Lucee, this problem does not exist. Another problem I've found (and posted in this community) is a transaction function trying to use any private function (specifically a getter or setter), both in the same component. To solve this issue, I needed to change getters and setters' visibility to 'package'. The last problem I've found (and posted in this community too) is a conflict between onCFCRequest event handler AND any REST calling. I spent ONE MONTH (fully dedicated) trying to find this error. If I'd have a project to deliver, I would be fired or dismissed by my client. So, I'm asking myself what if $9.500 can be justified for an application server that is bringing more problems that agility... Then 'agility' and 'stability' were slogans created by Jeremy Allaire to present ColdFusion. Some slogans that Macromedia respected while was managing whe product, but Adobe is not doing so.
Once again, thank you so much for your attention and dedication to my post.
So you're saying that you were already using restinitapplication? If so, sorry. That was not clear from your first post here.
As for the concerns you express about it, those would indeed be ones to raise in tracker. You could put a link to that here once you do, as some may find it and want to discuss it in either replace.
Same for all the rest of the issues you raise.
And sorry to hear that you are having so many, and spending so much time solving them, and that you feel that cf11 is the last stable version. I can tell you that I help hundreds of people per year whose experience is otherwise. But I realize that's little consolation when you've suffered problems (and may even have others you know who feel the same way).
As for cf2020 (or cf2021, as I expect it to be), you don't need to wait to see if it solves your problems. Anyone can use its public beta now. Check out these recent posts from me on the above:
Finally, thanks for your kind regards at the opening. As always, I just want to help. 🙂
Again, thanks and I hear all your concerns. And others share them...and folks in many countries can say the same: no one uses CF where I live, I can't find hosting, I can't find developers. It's really not unique to any country. It's also not unique to CF. It happens with many mature technologies.
For every one of us who have "passion for CF" (or whatever is our tool of choice), a few hundred other folks who used to use it will move on from it for any of many reasons--not least of which is the compulsion like cats to chase the next shiny object, but often it is indeed for what seem legitimate business or economic reasons.
You raise a concern about Adobe "not valuing" CF. Here again, I know that's a frequent lament of some. And in some circles you may hear only news to suggest that must be true. But I can tell you that there are circles where you would NOT be left believing that:
I get it: some people see nothing but negative in their perception of Adobe and how they manage CF. Maybe their bugs are never fixed (even though hundreds of others are, each year). Maybe they don't see any "marketing of CF" (when in fact they won't see any "marketing" of pretty much any similar technology). Maybe they think Adobe could do "more for the community", when in fact many other similar companies don't do much for theirs.
Indeed, as you say, it's usually the community itself which "drives the passion". That's diluted somewhat for CF because many of the most passionate people have moved off of CF, or moved to Lucee (and they may also stop paying attention to CF, and so may not notice that there have been many important improvements and additions to CF--or they may see only the ones that seem to have been "copied from Lucee", when in fact nearly all of Lucee was copied from CF originally of course. Or many dismiss the things that Adobe may add to CF saying that they don't need them. It's almost like Adobe is "damned if they do, damned if they don't".
So as always, these kind of conversations become almost like our current political climate, as different sides pull our their litany of concerns that are countered by the other side. I guess what I'm trying to say is that, just like in America where the mainstream media is by far tilted toward one side, someone hearing only from that side will have a VERY different opinion of things than someone who does hear the other side. (I realize you're in Baazil, so that analogy may break down.)
Indeed, I'll go further and say that it often makes me feel like the "Fox news correspondent" of the CF world, which I realize that brings the same slings and arrows that the real Fox news folks get. But it really is just an attempt to bring light to things that might otherwise not be heard by most folks.
Anyway, we're getting far afield from your original post. And note that BKBK offered a reply (not within this thread but on its own here, which gets back to the original issue you raised.
Copy link to clipboard
> Registering a new REST Service Mapping in my shared Hosting account, I've found a conflict to an existing Mapping in another account (website). This conflict was declared by an error: "access denied ('java.io.FilePermission' 'D:\[website_root]\SubDomains\[api_subDomain_folder]\[REST_service_mapping_folder]' 'read')".
Yes, I can imagine that. In REST, the name you choose for your mapping may appear as part of the URL. When you share a Provider your mapping's name might conflict with someone else's URL.