I'm having a problem with a specific function in a CFC being cached, no matter what I do.
Here's the scenario:
The CFC is instantiated in the Application scope, via ColdSpring. The site is live and all is well.
I wanted to make a change to one of the functions, called 'productSearch' within this CFC.
No matter what I do, no change is respected, ever.
I usually restart the application to reinstantiate the CFC, but this has made no difference.
I've tried creating a test page and explicitly instantiating the CFC locally, but it makes no difference.
I've restarted Railo, restarted Tomcat, restarted the server, to no avail.
In fact, the only time that I can see the change I've made, is if I literally rename the function. The fact that this works suggests that the CFC file itself is not being cached, otherwise the newly named function would not be available.
What's more, this only happens on the production server. If I make the exact same change on my dev server, everything works as expected.
I've never seen this before and I'm at a bit of a loss.
I really don't have much code to show that would be of any use - for testing, the function now contains the following:
<cffunction name="productSearch" access="public">
<cfdump var="#CGI#">
<cfabort>
</cffunction>
This fails, but if I rename it to 'productSearch2' it works correctly. For clarification, when I say 'fails' I mean runs the function as if it hadn't changed at all - there was all manner of logic in it before, returning a struct.
Does Railo store a parsed version of CFCs anywhere or something? I just can't see how this is happening!
Turns out this issue was down to a methodology I'm using in my code...
I split my components down into manageable .cfm files, which I then include using DirectoryList and CFInclude from inside a base .cfc file
This works very well for me, however in this instance, a recent merge of dev and live versions of the file in question left me with a .orig file - and as my files are included using DirectoryList, it seems the .orig was being included in the component after the .cfm version was loaded - thus overwriting any functions that exist within both files. This is why renaming the function worked!
Related
I've edited some existing visual queries of Blog 4.0 application and when I was debugging it - it worked perfectly. But then on page it stopped working. Any attempt to use key with Data like Data["Posts"] raises System.Collections.Generic.KeyNotFoundException. App.Query["Blog Posts List"]["Posts"] returns something, but any attempt to access its fields raises another exception (don't remember the name, but it said that there's no such member inside that object).
I didn't rename queries, I didn't change application settings. I just edited logic of 2 queries. I renamed 1 wiring endpoint name across 3 queries in whole chain.
How do I debug it? How can I see what does cshtml receive from database so I don't guess and put my crystal ball away?
In general, App.Query["Name of Query"] will get you the streams of data. You usually need to convert it using AsDynamic() or AsList() to something you can work with.
This should help some; What is Data?
If you're just running into problems with field names, you probably forgot the AsList or AsDynamic, just like #accuraty-jeremy mentioned.
For real debugging, go to insights, you'll see what happens - but in your case it probably won't help, because your working with an object that's not dynamic (so doesn't support .FirstName) until you AsList/AsDynamic it.
My bad: I confused two different files - _List.cshtml and _List Paging.cshtml. So I was searching for an error in the code of wrong file.
I have a WebAPI service, written in ASP.NET (not Core), for which I am trying to generate documentation, in order to allow other devs to use it. I found Swashbuckle, and installed it. Then, since I also use OData for some of my services, I added Swashbuckle.OData. Then, I modified the CustomProvider setting in SwaggerConfig to use the ODataSwaggerProvider. I also set ResolveConflictingActions(apiDescriptions => apiDescriptions.First()) because I had a few Actions with the same URL path, differing only by query string (I'll need to address that later). So far so good.
Then, I tested it. I started my web app, then added "/swagger/" to then end. I got a message stating that it was loading the resource info. However, after several minutes, I got a browser error debug popup, stating "Error: Not enough storage is available to complete this operation." It asks if I want to debug, and if I do, it takes me to the debugger in IE (the browser I'm using). The only code in the stack is either from jquery-1-8-0-min-js or swagger-ui-min-js (this part confuses me, as there is no "swagger-ui-min-js" file in my project; I'm assuming it's embedded in the dll). There is no part of the stack trace that floats back up to my code, and all the code there is minified, so it's very difficult to debug.
However, I do know that it is at least partially working, as three of the controllers do show up in the resulting page after you close the error popup. You can navigate through them, and all the GETs, POSTs, PUTs, and DELETEs seem to be there, and you can test them.
Is it the case that whenever you navigate to the "/swagger/" url, Swagger hits all the URLs in the service, in order to generate the documentation? I'm wondering if maybe it is hitting an action that is taking a particularly long time to run, or possibly its generated documentation is taking too much disk space (I have plenty of space on my disk, but maybe it is referring to RAM?).
Anyway, even if that were not an issue, how can I get it to generate something, some kind of document file, that I can send off to someone? I see no new files added to my folders, so it would seem that it re-does the whole process every time you navigate to the swagger URL.
When I tried the Chrome browser, I no longer had the issue (I was using IE11 before). Not sure what the problem was, but this was the workaround.
I'm struggling with an issue for which I can't find an explanation. I have two development environments that I use for my projects. I created a simple module for Magento and I tested it on one environment. After overcoming all Magento's complications, the module works as expected. This is on XAMPP.
I then copied the module to the development Linux environment, on a hosted server, and it crashes miserably. I did some debugging, and I found out that a call to Mage::getModel() returns bool(false) instead of the instance of the Model I requested.
I double checked all files and directories, and they match. Database is not involved (not from my side, at least, I don't need tables) and both environments have only me as a User, with Admin permissions.
Any suggestion on where should I start looking is welcome, thanks.
Added on 2012/07/09
Model contains a class named Diego_ClientCustomModule_Model_ExternalUserData, which is invoked with $model = Mage::getModel('clientcustommodule/externaluserdata');. Model file resides in Diego_ClientCustomModule\code\local\Diego\ClientCustomModule\Model\. The curious thing is:
If model file is named Externaluserdata.php, it works.
If model file is named ExternalUserData.php (i.e. it matches the class name), it doesn't work.
I'm aware of case sensitivity stuff etc, but, if the alias is all lower-case, how comes it can load a file having the first letter capitalized?
Configuration file
0.1.0
Diego_ClientCustomModule_Helper
Diego_ClientCustomModule_Model
Diego_ClientCustomModule_Block
standard
Diego_ClientCustomModule
ClientCustomModule
Snarking about the framework for which you are asking for help may not be the best strategy for receiving help.
Your issue is likely one of cache (remove var/cache folder to check) or one of improper casing. Note that the first letter of each directory and filename for files loaded by the autoloader (blocks, models, and helpers).
It seems I have found the root cause of the issue, although I can't figure out what kind of logic has been implemented to make it happen.
Model's file name was UserCustomModule.php, which reflected the class name UserCustomModule. That made sense, and worked wonderfully in XAMPP. Once I installed the same module on a Linux box, Magento silently ignored the file and, as previously stated, there's been no way to track down Magento's actions.
Following benmark suggestion, I went through all the files again to check the casing, and everything seemed to match. I then made something, in my opinion, completely stupid, and I renamed the Model file to Usercustommodule.php, leaving the class name untouched (after all, PHP should behave the same on both platforms, unlike the file system). Magically, the module now works! The file name looks cr*p, but it works.
This solved the problem, yet it raises more questions:
For what reason Magento has troubles loading a file with a CamelCase name? If it's Autoloading, it should simply find a file and load it. After all, it loads the Controller, the Block and everything else, and they are all in CamelCase.
Is it written anywhere that one or more files must have only the first letter capitalized? I got enough surprises already, I'd like to avoid new ones, if possible.
Thanks again for the help.
I am finding that my controllers are being called more than once. When I am in debug mode, the paths execute, the UI is rendered, but then the controller break points get hit up to 3 times.
Debugging steps so far:
I have checked that all my routes (routedebugger.dll)
I have a clean view to controller mapping. There are no namespace conflictions.
Is this something to do with the debugger, or is this an issue I need to worry about when the application is deployed?
This symptom is only occurring on my local machine. I used fiddler2 to watch the traffic and there was a favicon call. I fixed that, but don't change anything.
We moved the code based to the servers (running iis) and this does not occur. I don't really have an answer, but do know that it is not affecting the production or QA servers.
I'm calling this one 'closed'.
Due to circumstances beyond my control, my production Camping site appears at mysite.example.com/mysite. I'm pretty sure this is a common Apache / Passenger configuration issue, and I'm not interested in how to fix it right now because the server is out of my control. Suffice to say, the controller for "/" points there and I can't change that any time soon.
Now, for a long time, this wasn't an issue, because R(MyIndexController) points to the correct place. However, I serve my site's CSS using a Rack::Static call to make $SITE_ROOT/public accessible. This means that the stylesheet is at mysite.example.com/mysite/css/style.css. Here's where the problem comes in: the Camping URL() method, when called in my layout, gives http://mysite.example.com, not http://mysite.example.com/mysite. So I can't get it to point to the /css subdirectory, because it's missing a "hop" in the middle. When I run rackup locally, everything is fine (because this file is at localhost:8080/css/style.css), but on the production server I don't know how to fix it.
My question: is there another method (maybe directly from Rack?) that I should be calling instead? I really want to avoid hardcoding it, and/or having a hack to determine whether I'm running locally (for debug) or in production, for every rendering of the layout.
ETA: OK, this gets stranger. Obviously I've abstracted out some of the actual details above, part of which I think I "over-scrubbed". The "top level" URL is actually more akin to /mysite/rest (the developer-centric HTML presentation of our RESTful interface), as opposed to /mysite/management (accounts) or /mysite/ui (JQuery'd / "nice" UI). These are set up in our config.ru, via run Rack::URLMap.new(Hash['/rest' => RestModule, '/ui' => PrettyInterfaceModule, '/management' => UserManagerModule], etc.
So in answer to the comment below, R(Index), from a view in the RestModule, actually returns /mysite/rest/. As an example, I have a "home" link in the layout, which looks like a :href=>R(Index), and generates code that looks like <a href="/mysite/rest/">. The server is configured to serve files from ./public directly at the "site root", so ./public/css/style.css actually does apppear at http://mysite.example.com/mysite/css/style.css, as noted previously. It's that link that I'm having trouble automatically generating, and it's because of the Rack::URLMap that I thought I may have to rely on a native Rack method (not a Camping abstraction) to locate this resource.
So in this case, URL() actually returns http://mysite.example.com/mysite/rest/?
What about something like this?
URL().merge('../css/style.css')
This is an old question so I assume that you did already find a workaround but the new passenger + apache (or ngnix) behaves correctly for camping as far as I could replicate. Your app would be on the Documents root and all the includes in the /public folder so /public/css should be routed correctly regardless of you using a sub folder /mysite or not as passenger doesn't make a difference (again) as far as I can replicate. Therefore this should be easily solvable with passenger 3 + Apache or ngnix.