Friday, January 10, 2014
This update introduces support for OS X 10.9 Mavericks. It fixes the web server connector issue on OS X 10.9 reported on bug #3653076. Which itself had a solution by another very smart developer but the bug itself was filled with whiny developers that didn't care to read the comments and find a solution themselves. Instead it was filled with people complaining that they were now not able to work, which I found quite silly. Oh well, my days here are limited as this is the year I am committing to make the full switch and I got RoR and iOS Development on my radar.
You can refer to this technote.
And if you want to entertain yourself with whiny comments check out the bug.
Thursday, October 24, 2013
This is a follow up to my original post Help ColdFusion not working in the sky. I was basically having the same issue here at the ColdFusion Summit 2013, since my hostname continued to get automatically set when I would join the WIFI network. So each time I restarted my local ColdFusion server it would fail if it could not ping itself and I quickly got tired of adding aliases in my /etc/host file. I then decided to ask the question "Why does this happen" and apparently there is a setting on Mac that lets your Hostname get set automatically and this is located in the /etc/hostconfig file (if it is not there it is because it is the default setting - read more about this here).
Basically all you have to do is open that file and set it to the value you'd like and it will no longer get overwritten when joining networks. For example, I changed mine to the value I have in my sharing tab.
Now when I join new networks my hostname stays as is and I can restart ColdFusion as many times as I want without any more issues. On another note, I upgraded to Mavericks which introduced other headaches of ColdFusion not working which there is a temporary fix here. I will most likely post about this later but for now, it CF does not work for you it is due to the connector not working on Apache 2.2.4 which is what Mavericks comes with.
Friday, August 30, 2013
You see the image on your phone, it looks great, you upload it, you get excited and then ... disappointment. Your image is either sideways or upside down and you have no idea why! I am sure it even gets better for some of you.
You are having a relaxing day and a client calls you because their site is broken, or they think it is. Well it is not and the issue is simply due to a small change Apple did to make the camera work just a little faster. I can't seem to find when they did this (wanted to post to it) but I believe around the release of the iPhone 4s is when this occurred. What the camera does is take the picture and rather than fixing the orientation before it saves, it adds the orientation rules to the EXIF metadata. It even gets better, by some posts I read, it appears that some Operating Systems ignore this metadata and then the image itself is received by a third party either sideways or upside down. I don't experience this because I am on a Mac so the orientation is shown correctly but not in a browser. First some examples of what I mean.
Below is the test image open in Preview and in Chrome. As you can see the image is upright in preview, the correct orientation but it Chrome it is sideways.
So first lets look at our image and see why we are getting this. Now, there are 2 ways to get EXIF Metadata with ColdFusion. One is
ImageGetEXIFMetadata()and the second is
ImageGetEXIFTag(). The first returns a full struct of all the metadata and the latter lets you look for a specific key. For my example I will use
ImageGetEXIFMetadata(), so we can see what that looks like.
As you can see, there is a key named orientation with a value of "Left side, bottom (Rotate 270 CW)". These are the instructions of how to rotate the image for the correct view, or how it was taken, how ever you interpret. I have seen 4 possible outputs in my tests which are as follows:
- Top, left side (Horizontal / normal)
- Left side, bottom (Rotate 270 CW)
- Bottom, right side (Rotate 180)
- Right side, top (Rotate 90 CW)
Now an interesting thing happens, look at the image below:
The image in Chrome is fixed but now my Mac shows it sideways, why? Well simple, when we rotated the image and saved it again, the EXIF data stayed intact, so my Mac still will follow the instructions and rotate the image. This might not be of big concern but lets say your user downloaded the image file and then it did this, it would appear .. well broken.
There are a couple of ways to fix this, some more involved than others, like getting a Java Library to be able to either remove the orientation key from the metadata or rewrite all the metadata. With ColdFusion there is a simple way to just clear the metadata and that is using
ImagePaste(). I will use
ImageCopy()as it required less code.
By adding one line to our example above, our new image would have all the metadata stripped and the file would now render properly on the OS and the Browser. If the metadata is important for you to keep, I suggest looking at other options but this is for a quick easy web only view, so it really doesn't matter much to me. If it did, I would most likely save the metadata somewhere I can retrieve later for analytics in relation to the image or like I recommended, use a library to overwrite the 1 key. The final code example is as follows:
And the final output:
Thank you for reading and hope this helps someone having this particular issue.
Saturday, July 20, 2013
Unable to initialise License service: coldfusion.server.ServiceException: host9772188245.direcpc.com: host9772188245.direcpc.com: nodename nor servname provided, or not known.
So I decided to do a quick Google search and found the following post.
Now I am on a Mac and that post was for Red Hat but what I did notice is that they talk about the hostname, then it clicked, I've read this somewhere before, where ColdFusion would fail if the service could not access the License server by hostname.
So I opened up my terminal and typed hostname and was returned with host9772188245.direcpc.com which was weird because I know my hostname is suppose to be Giancarlos-MacBook-Pro.local. Now I've flown in other flights with WiFi an never had this issue so I decided to do a quick test. I disconnected from my WiFi connection on my SouthWest flight and typed hostname and like magic back to normal. Apparently, this service overwrites your hostname when you connect, in turn causing ColdFusion to fail startup if done after WiFi connection.
The quick fix was to open up my hosts file and type the following:
After that I restarted ColdFusion and I was back on track!!! So if your ColdFusion Server fails to start while you are up in the sky, remember, check your hostname and make sure you can ping it. If not then ColdFusion will fail to start.
Hopefully this helps someone who runs into this issue as well. Hair pulling incident averted!
Wednesday, July 3, 2013
- Firewall Requirements
If you have a firewall you have to open up the following default ports or which ever you change to:
- 8575 Default for WebSocket Server - you can edit this in the CF Admin
- 1243 Default for Flash fall back - flashPolicyPort (if you care about IE 9 and before) - you can edit this in <cf_home>/ColdFusion10/cfusion/lib/neo-websocket.xml
A little gotcha on the Flash fall back. If you allow this and IE tries to access this and you have changed the default path to your scripts directory which is recommended, it fails because the SWF is always requested from /CFIDE/ ... so you need to still map this directory. If you do, I say create the CFIDE inside your site and then map the scripts directory directly inside rather than opening the entire directory Good thing about 10 is you can just map the directory and block access to the admin by IP. Also on IIS 7 you can restrict access to /CFIDE/administrator and any other directory you want my using Request Filtering.
This is referenced in the /CFIDE/scripts/ajax/package/cfWebSocketMain.swf file lines 1069 and 1070.
The fix is as stated above (map CFIDE) or edit the file and change the path to reflect your new path you set in the admin but that requires you to remember that in case there is an update to these files and it gets overwritten.
So IE10 will not connect to your web socket if being requested from an HTTPS site. Currently it is not supported but in the works as specified here:
You can see in post above the hack I tired but no luck connecting to wss:// even if I forced it. So for now if you need to support IE, you must make the page initiating the call a regular non-secure page.