External monitor not detected by Mac running Yosemite - a solution

A funny thing happened while researching this issue, as it seems that many Mac users that have upgraded to Yosemite have experienced this problem with no resolution.  I found posts on the Apple support site suggesting ridiculous things like getting a new video cable or unplugging the cable from the monitor (but not your Mac) or uninstalling DropBox, when everything worked fine before upgrading to 10.10.  That's like telling someone to stand on one foot, rub your tummy with one hand and the top of your head with the other, but only on a leap year Feb 29th at Noon, and then magically, your external displays will once again work with your Mac.  My external monitor worked like a dream with my old MBP, and it worked with my new one out of the box loaded with Mavericks, but as soon as I upgraded to Yosemite and imported files/profile/settings from my dead MBP's hard drive, POOF!  External monitor no longer is recognized.  If I boot into Mavericks, external monitor works - so I know it's not the monitor or the cable, it's Yosemite that's the problem.  And I had to teach a class to customers just before Christmas and I could not use the projection screen to display my slides, so I had to (GASP!!) use a Windows laptop.  Now how stupid is that, Apple?

I was also looking into getting a 1 TB SSD for my 2014 Mac (my 2011 MBP suffered a fried logic board and had a 1TB SSD in it) and finding that you can't get an after-market SSD to fit inside the Retina MBP's because of the way Apple has designed the hardware interface.  And to top it all off, you can't even get 3rd party external SSD's to boot Yosemite, unless you are fortunate enough to buy a SSD from OWC, which doesn't require a 3rd party Trim driver to function correctly.

Turns out that Apple has activated a feature in the OS called kext signing or signed kernel extensions.  It's partly a security feature to prevent untested or "unapproved" or altered kernel extensions from loading and potentially harming your system.  If I followed the blogs and postings timeline correctly, this was actually introduced in Mavericks, but my Mavericks install is basically pristine so the external display works as expected.

I found a tool that some folks use to enable 3rd party Trim drivers to allow the use of non-Apple SSD's as boot disks.  However, the side effect is that the process to enable a 3rd party Trim involves globally disabling kext signing.  As an experiment, I tried this tool named Trim Enabler, and after it was installed and executed, it disabled kext signing as expected and after a reboot, my external display magically was detected and is working again!

I realize that this is a brute-force, shotgun approach to re-enabling external displays with Yosemite, and I don't recommend this for anyone else to try at home (or at work) on their Mac, but this is the first alternative I have tried that actually allows me to use my external display again.

And if you think about it, it makes sense - 3rd party video drivers get installed all the time and almost none of the companies will take the time and effort to get them approved by Apple.  Sometime the drivers get modified by application installers or patches, so if they are not pristine or are not on the approved list, they don't get loaded and you can't use your external display anymore.

Something needs to be done so that you can enable specific drivers or kernel extensions, but that's a whole 'nother discussion.

To sum it up, for all of you out there who lost the ability to use external displays after upgrading to Yosemite, you may be able to restore the functionality by using a tool like Trim Enabler to disable kext signing on your Mac.  It's a bit risky and I don't recommend it, but it works.

For me, now I can plug my MBP into an external display or projector when I have to teach another class or give a presentation and not have to lug around a Windows laptop just so I can show stuff on the big screen.

Proceed at your own risk and may the force be with you...

.Net programming: XAML Designer Activity Errors

Ugh!  After getting asked to join a team working on a .Net project that combines OSISoft PI/AF databases with Windows WF, I started hitting the wall with the XAMLX/XAML designer not loading and displaying the defined workflow using VS 2010.  There is no documentation on the subject and executing Google/Yahoo/Bing searches in any combination of WF, WCF WF, WF Service, Activity Not Loading due to errors in XAML, etc., I finally found something that pertained to my situation.  The change from building for All Platforms to x64.  Our project sponsor recently made it a requirement for x64 target

Apparently, the XAML Designer can't function correctly when the target is x64, so you have to design and initially build for All Platforms or x86, and you can load and see the designer and custom activities.  Once you are ready to due actual testing of your code, then switch back to x64.

Much thanks to this short but excellent post at Stack Overflow that was the answer.  Now only if the folks at MS will fix their official development tool, I might actually use it more often and work on a few more .Net projects.  If not, then I'll happily keep working in the Java and Open Source solution world.

Citrix Receiver for Mac issues

Ever run into the following error dialog when trying to use applications on a Citrix server:

SSL Error 61: You have not chosen to trust
"XXXX Certificate Authority",
the issuer of the server's security certificate.

Error number: 183

I'm running a MacBook Pro mid-2011 with Mac OS X Lion, and in my case "XXXX" corresponds to Network Solutions.  A project I'm working on has Citrix gateway access to applications, but when I click on one fo the links, I get the error shown above.  I searched the Citrix forums and support pages, and found one article that pertained to the Windows client only, where you had to go into MMC and change some settings to allow pass-thru authentication for all ICA communications.  But there was nothing for Mac (or Linux).  I have the latest version of Citrix Receiver 11.4.3, but there isn't any configuration setting that is even close to what you would do with the Windows client.

I found an old posting from 2003 that pertains to certificates, CTX102462, so I thought I would give this a try since it is easy to backout if the modifications don't work.  A shortcut of the steps are:

1. On a Windows machine that I can successfully  establish a Citrix connection with, I exported the certificate for Network Solutions in DER format.  In my case it was from a Windows 7 VM.

2. renamed the file to have a .crt suffix

3. Opened the keychain access utility on my Mac

4. Imported the .crt file nto my login keychain

5. accessed the Citrix server URL and authenticated

6.  Clicked on an application link, and the application started successfully and I no longer got the error dialog about not trusting the certificate authority on the App Gateway server.

I haven't figured out what to do about my Linux box connecting tot he Citrix server yet - I was getting a similar error when connecting from an Ubuntu Natty Narwhal install.  I guess one OS at a time and I'll post an update if I find a way to get my Linux machine to be able to connect and get successfully authorized to use the available applications...

Accessing Samba share on OS X server from Windows 7

Arrgghhh!!  Working as a consultant for a local city PUD, I helped setup a Samba fileserver running on a Power Mac with Snow Leopard Server on a Windows Domain.  Connecting from another Mac is trivial.  But try and connect from a windows 7 desktop by browsing the network or searching by NetBios name or IP address keeps coming up with: 

error code: 0x80070035 network path not found.  

Even though the server is on the network and is pingable, and is properly attached to Active Directory, the Windows computer can't find the server...

Ok, now I was able to find the server by using it's IP address in the run search box (not via Windows Explorer - which lists the server on the network, but can't find it when you double click the entry), but cannot authenticate.  The Samba access logs say: [user] FAILED with error NT_STATUS_WRONG_PASSWORD, even though I use my domain login when the login prompt appears.

Solved:

I typed in the FQDN when using Windows Explorer to map the network drive, e.g. \\publicserv..lcl\publicdir, and Windows 7 desktops finally can find the Samba server.  Don't ask me why, but the has to be in all caps, even though on all the Windows machines, the domain is in lowercase.

using maven to deploy to Tomcat 7

Ugh! I've been working on a simple webapp for a demo and using Maven for the build process. I was ready to deploy to a stand-alone instance of Tomcat 7 and I started to get a bunch of errors during the build when it came time to deploy to Tomcat. Using the -e switch for maven I started to see messages like:


[INFO] [tomcat:deploy {execution: default-cli}]
[INFO] Deploying war to http://localhost:8084/jasmineproject1
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot invoke Tomcat manager

Embedded error: Server returned HTTP response code: 403 for URL: http://localhost:8084/manager/deploy?path=%2Fjasmineproject1&war=
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Cannot invoke Tomcat manager
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot invoke Tomcat manager
at org.codehaus.mojo.tomcat.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:149)
at org.codehaus.mojo.tomcat.AbstractWarCatalinaMojo.execute(AbstractWarCatalinaMojo.java:70)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: java.io.IOException: Server returned HTTP response code: 403 for URL: http://localhost:8084/manager/deploy?path=%2Fjasmineproject1&war=
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1436)
at org.codehaus.mojo.tomcat.TomcatManager.invoke(TomcatManager.java:604)
at org.codehaus.mojo.tomcat.TomcatManager.deployImpl(TomcatManager.java:662)
at org.codehaus.mojo.tomcat.TomcatManager.deploy(TomcatManager.java:295)
at org.codehaus.mojo.tomcat.AbstractDeployWarMojo.deployWar(AbstractDeployWarMojo.java:85)
at org.codehaus.mojo.tomcat.AbstractDeployMojo.invokeManager(AbstractDeployMojo.java:85)
at org.codehaus.mojo.tomcat.AbstractCatalinaMojo.execute(AbstractCatalinaMojo.java:141)


Apparently, with Tomcat 7, the manager URL has changed, so deployments from an IDE, a build tool or the command line can't be done the old way.

I took look at the Tomcat documentation for the manager application, and the docs say:

All commands that the Manager application knows how to process are specified in a single request URI like this:

http://{host}:{port}/manager/text/{command}?{parameters}

where {host} and {port} represent the hostname and port number on which Tomcat is running, {command} represents the Manager command you wish to execute, and {parameters} represents the query parameters that are specific to that command.

But when I use the path /manager/text for anything I get a server response of:


FAIL - Unknown command /text


Does anyone know what the correct URL to deploy a webapp to Tomcat 7 is now? For now, I can get away with using NetBeans deploying directly to Tomcat and not using maven to build and deploy, but in the long run that is not a solution...

Update:
Found an obscure link, which I cannot remember off the top of my head, that documented that the URL for using the manager in Tomcat 7 should be /manager/html and not /manager/text as the Tomcat documentation states. Hmm... makes you wonder sometimes if someone actually verifies documentation before publishing it to the world...

Jasmine Javascript debugging? Maybe not quite there...

Whew! Sorry about going dark for a while. Am no longer a consulting Tech Architect at Boeing Commercial Aircraft and just started in a SW Architect/Engineer position at Fabric WorldWide...

Inherited the responsibility for writing new and maintaining existing Javascript plugins used in BA/BI of websites. Lot's of interesting asynchronous code, not necessarily strictly adhering to the "X" in AJAX. Since the code loads and executes asynchronously, it is difficult to unit test during the build process. So I have been looking into Javascript testing frameworks that can 1) run headless, i.e. not require a browser; 2) not require jQuery or other framework that supplies DOM access; 3) can test code asynchronously; 4) is compatible with Maven; 5) provides Mock capabilities.

Some candidates were Screw-Unit, jsUnit, QUnit, JSpec, YUI Test, DOH, and Jasmine. For one reason or another they started to drop off the list and that left me with Jasmine. It took a little while to get everything installed correctly into my dev environment and getting Maven configured corectly, but once that was done, it seemed like it would be smooth sailing to test some new code I was writing.

Interestingly, when I had Firebug activated on FF 4.x, I would get a SyntaxError when trying to eval() a regular expression string. I figured I could catch that error in a Jasmine test before it even got to a browser session. Unfortunately, no - Jasmine's Javascript engine does not generate an error when executing eval() on the same string that I sent to the browser. I had been counting on it trapping the error so I could return something informative to the caller, but it looks like I will have to try something else...

So much for trapping and throwing errors in Javascript during unit testing...
SIGH!

Jetspeed-2 and NetBeans 6.8

Well, I have been looking at Open Source portal products that are "easy" to setup and use and yet powerful enough to satisfy an enterprise. I settled on trying Apache Jetspeed-2, since it has licensing that is favorable to a business that might want to use it in a product offering, and it is fully compliant to the Java Portlet Standard 2.0.

Installing the demo version was easy, and it came with a bunch of portlets ready to use. But, I want to be able to create portlets myself and the Java development tool I have been using the past several years is NetBeans.

At first, it seemed as if there would be no support for developing and deploying portlets from NetBeans to Jetspeed-2 or even modifying/building Jetspeed from source. I asked a friend and all he said was "use Eclipse instead!" Which really isn't an option where I'm working these days.

I installed the Generic Portlet plugin and added the Jetspeed-2 server (Tomcat 6 server type) to the Servers list in NetBeans. I created a new Java Web project and chose the Portal Framework, with View only premissions. NetBeans pulled in the Portlet Standard 2.0 libraries along with the Jetspeed-2 libraries and created a portlet source file for me. I thought, "cool, this will be easy.", but the hard part was just beginning. Of course, NetBeans creates an index.jsp file for you, but as I was working along and built the WAR file, I noticed that the portlet.xml file was not continuously updated like the web.xml file does.

After building, I tried to deploy via NetBeans. It works, but it was deployed as a regular web application and not as a portlet for Jetspeed-2. If the server properties for Tomcat allowed you to specify the deployment directory, then NetBeans might be able to deploy the code to the proper place. As it was, I could bring up my code as a web application, but Jetspeed-2 didn't know a thing about it, so it did not show up as an available portlet to add and use.

So for the moment, I have to manually drop the .war file into the /webapps/jetspeed/WEB-INF/deploy/local/ directory in order for my portlet to be usable. I also found that the path to my .jsp files is all messed up because you are deploying your .war file underneath Jetspeed-2, which is itself a web application. So the path I found that worked so nicely and that I was able to specify in my portlet.xml when I deployed dirctly from NetBeans, no longer worked and I kept getting NPE's or path not found errors from Jetspeed. Now that I know the actual path, I have a couple of ways to specify the correct path, but it was such a pain...

Now that I have a basic "Hello World" portlet running, I'll start working on more complicated portlets and plan on posting my experiences with NetBeans and Jetspeed-2. Until then, happy coding!