Changing a Web Site to use hosted WordPress

I got an email from my friend Athens who had just relaunched her web site at http://www.athenskconsulting.com/ but was now having problems with email.

The first thing I did was to run over to the MX Toolbox site to see what was going on with her servers. A quick look and saw that her mail servers were pointing to mail.athenskconsulting.com, which resolved back to her WordPress blog.

Before she pointed everything to her WordPress site, everything had been working. Unfortunately, the directions at http://en.support.wordpress.com/domains/map-existing-domain/ had given her some unfortunate information, that really weren’t accurate for what she was trying to do.

Her DNS and email were previously hosted at GoDaddy (along with her old web site), and all she was really trying to do was to get her company URL to point at the blog site that she’d set up on WordPress. The instructions I mentioned before give a way to accomplish that, by repointing the domain DNS servers to be the ones that WordPress provides.

The unfortunate thing about that approach is that in order for this transition to happen smoothly, you have to transfer all of your DNS records into the WordPress settings so that things like your mail server will continue to work (following the instructions at http://en.support.wordpress.com/domains/custom-dns/

Now this might be OK if you are a geek and know what MX and CName records should look like, but typing in a DNS file in the format that WordPress expects it is much more difficult than using the GoDaddy DNS control panel (which helps prevent you from making mistakes).

I got on the phone with her, and the first thing I had her do was to switch her DNS servers back to GoDaddy. This is done by going to the Domain Manager page in GoDaddy and looking for the section that says “Name Servers”.

Clicking on the link that says “Set Nameservers” brings up a dialog that allows you to set the DNS (which had been set to the WordPress servers per the instructions mentioned previously):

 

This of course fixed the mail problem (along with other URL’s), but broke her web site again (which I expected it would).

We then clicked the “Launch” link on the same Domain Manager page by looking for the section that says “DNS Manager”:

 

This brings up the actual DNS zone editor that I talked about previously. Now the first thing you should do is to back up the zone records by using the import/export button on the DNS manager:

This gives you the basic information that you might have needed if were you going to follow the instructions on the WordPress site. It creates a text version of the information of the DNS Zone records in a standard format.

But unless you really need to move off GoDaddy for some reason, you don’t want to do that. Instead, you just need to set up a wildcard CNAME record for the WordPress blog, and make sure to remove any old A records that might be pointing to the wrong place.

So for Athens, we needed to delete all of her “A” records (since she no longer has a physical server), and add a CName that looked like:

And once DNS propogated, she was up and running again at http://www.athenskconsulting.com/

A quick trip back to the MX Toolbox site to check and her mail servers are now pointing back to GoDaddy again:

Clicking the link that says “ns lookup” shows that the domain is now using the GoDaddy DNS servers again:

The one other thing I do to make sure things are working is a DNS propogation check (http://www.whatsmydns.net/), which shows which servers will resolve the host and which don’t.

All the little green checkmarks mean everything is happy all around the world, and now everybody is resolving her site properly.

So in summary: if somebody tells you to change your DNS servers, think first and see if an alias will work better …

Unexpected Consequences – Jenkins and PHPUnit

I am a big fan of Test Driven Development (TDD) and tools like Hudson/Jenkins to automate the process of having a continuous integration build system are key.

On my current project we recently started moving things to Amazon EC2, and rather than put everything on one big server, I thought I’d follow the best practices in cloud computing and make a number of small special purpose servers to take care of the project’s needs.

We’ve had a Jenkins server running for a bit, so rather than reinventing the wheel, I figured I could copy my Jenkins configuration to a new server and get things up and running.

I fired up a new Tomcat server on Amazon Elastic Beanstalk, and loaded up the Jenkins WAR file, which quickly got me to a working Jenkins server. This project is written in PHP, so I had to install PHP after that, which meant logging in to the server and running through the whole PHP and PHPUnit setup.

Once that was done, I scp’d the Jenkins folders from the old server, edited the Tomcat startup files to include the environment variable to point Jenkins to the right place, changed a few permissions, and everything appeared to be working.

I could log in, I fired up the build, and it appeared to be running – very cool.

But that was when the flaw in the design of the PHP unit tests was exposed ….

I was watching the output of the phpunit tests, and noticed two things:

1. The tests seemed to be taking a really long time
2. Every test was failing

Watching the console, each time a test would fail, the little “E” would print, then a few seconds would go by and another “E” would appear. Finally after many minutes (because we have a LOT of classes to test) the error output appeared, and looked something like this for EVERY test:

     [exec] 1) aa_accounts_controllerTest::testMainSingle     [exec] PHP_Invoker_TimeoutException: Execution aborted after 1 second     [exec]      [exec] /home/jenkins/workspace/ftp_final/db/database_error.php:7     [exec] /home/jenkins/workspace/ftp_final/db/database.php:87     [exec] /home/jenkins/workspace/ftp_final/db/aa_accounts_db.php:42     [exec] /home/jenkins/workspace/ftp_final/model/aa_accounts_model.php:177     [exec] /home/jenkins/workspace/ftp_final/tests/apps/abstractAaAcountsTest.php:64     [exec] /home/jenkins/workspace/ftp_final/tests/apps/aa_accounts_ControllerTest.php:17

And of course there were 5297 of these … I did some Google searches for the PHP_Invoker_TimeoutException which mostly pointed to issues with upgrade from one version of PHPUnit to another, but the versions on the old server and this one were the same.

So my next step was debugging an individual tests. Running the test from the command line gave me the same error, odd. But then I ran the test using php instead of the phpunit call, and found the problem: I was getting a timeout trying to open a database connection.

The issue as it turns out, is a design flaw in our code that hadn’t showed up before: all the classes invoke a database connection class that sets up the connection to the database as soon as they are loaded.

Since the Elastic Beanstalk server was in a different security group than was allowed to connect to the RDS database, it was unable to connect at all, and PHPUnit would simply timeout before the connection failed (by default phpunit sets 1 second as the acceptable for a test to run in order to catch endless loops).

Now in theory our tests shouldn’t be hitting the database (at least not for these unit tests since we don’t want them updating anything on the backend), so this problem turned out to be very fortuitous. Because the Jenkins server couldn’t reach the database, it exposed a flaw in our unit tests: we weren’t mocking all the things we needed to, so the tests were actually opening connections to the database.

With some refactoring of the test classes to mock the database access layer, the tests all succeeded. Next we’ll need to do the actual DBUnit tests for the database, and Selenium or HTTPUnit tests for all the front-end and AJAX stuff.

JPA and Maven and multiple persistence units

I needed to convert an existing Netbeans build to use Maven in order to stabilize the code and support Test Driven Development.

Generally this was a fairly simple process: just move all the source files and resources to the right folders in a new Maven project, and add the dependencies.

Everything was going swimmingly until I ran my first tests and got this really lovely set of errors that didn’t really tell me what was going on:

javax.annotation.processing.FilerException: Attempt to recreate a file for type com.omnistools.GaclAcl_

Now at this point I normally just do a few Google searches and find out how somebody else has solved this problem, but I really wasn’t having any luck at all finding an answer.

I did run across a couple of posts that mentioned seeing this error when using multiple persistence units in the persistence.xml.

Now my project does have a persistence unit for testing outside GlassFish (my chosen EJB container), so my first thought was to move that PU to the “right” place for my tests. So I copied the persistence.xml from src/main/resources/META-INF to the src/test/resources/META-INF and changed them so there was only one PU in each.

Well, that seemed to work for a minute, no more exception on the compile step. But now I had a new problem: I was getting an error that the PU couldn’t be found:

Tests in error:
testinsertTrackingCustomerUnFixed(com.omnistools.service.util.CompanyCustomerTrackingTest): No Persistence provider for EntityManager named ProjectTest-ejbPU
testinsertTrackingWithoutCustomerUnFixed(com.omnistools.service.util.CompanyCustomerTrackingTest): No Persistence provider for EntityManager named ProjectTest-ejbPU
testinsertTrackingCustomerFixed(com.omnistools.service.util.CompanyCustomerTrackingTest): No Persistence provider for EntityManager named ProjectTest-ejbPU
testinsertTrackingWithoutCustomerFixed(com.omnistools.service.util.CompanyCustomerTrackingTest): No Persistence provider for EntityManager named ProjectTest-ejbPU

So doing a bit of digging, it appears that the persistence.xml only gets copied once and only from the src/main/resources/META-INF folder.

I must have tried a thousand different permutations and combinations until I realized that I could have an ugly workaround that is not ideal.

The issue is that if both have the “exclude-unlisted-classes” set to true, the javac compiler tries to recreate the annotation classes during the compiler:compile and of course fails on the second PU because the classes have already been created.

So to get this to work, I set the “exclude-unlisted-classes” to false for one of the PU’s, which gets me the generated meta classes, and the tests fail (because the PU doesn’t include the required entities).

I then flip the flag back to true, and run the build again. Since the classes have already been compiled, the compile:compile doesn’t run, and the tests can succeed.

And then finally, I run across a bug report on the NetBeans site: http://netbeans.org/bugzilla/show_bug.cgi?id=183779. Now this bug talked about setting some compiler flags (in particular -proc:none which tells the compiler not to generate meta classes).

Workaround was proc:none to the javac compiler args as described here: http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html

        <plugin>            <groupId>org.apache.maven.plugins</groupId>            <artifactId>maven-compiler-plugin</artifactId>            <version>2.3.2</version>            <configuration>                <source>1.7</source>                <target>1.7</target>                <compilerArguments>                    <endorseddirs>${endorsed.dir}</endorseddirs>                    <proc:none/>                    <Xlint/>                    <Xlint:-path/>                    <verbose />                </compilerArguments>                <showDeprecation>true</showDeprecation>            </configuration>        </plugin>

Now my Maven build works like a charm. Both persistence units are defined in my persistence.xml, and both have the “exclude-unlisted-classes” set to false, and not only do my tests work, but the deployment is now successful as well.