I found a fantastic article on Copyblogger entitled, “Do You Recognize These 10 Mental Blocks to Creative Thinking?”. It is a very poignant article and I found that many of the things that I struggle with, when trying to be creative, are listed in the article. Give it a quick read and perhaps you’ll find out something about yourself, and why sometimes you might have a creative block!
Now that I’ve been in Nashville for a full 1/3 of a year, I think it’s time for an update on what I think of the city.
The pitiful lack of use of the turn signal still appalls me. There have now been countless close encounters with ditsy blondes who talk on their cell phone and drive with one hand, and raging, but unheard, diatribes to the idiots who make me wait 10 whole extra seconds at a stop sign because they don’t use the signal. I’ve even yelled at people when their windows are down and they look at me with wide-eyed innocence as if I were a lunatic for expecting them to take their left wrist and flip a plastic bar by 25 degrees.
The heat has been ungodly, and for every person that has told me that this is unusual weather, there’s been another telling me that people have been saying that for 5 years straight. Only time will tell on that one. Never in my life did I expect to sit on my veranda on a sticky, humid night when it’s 88 degrees and think it was the most pleasant weather I’d ever encountered. That was a nightmare evening in Pittsburgh.
People are nicer here, and I’ve now discovered that people are nicer TO YOU if they know you are from Nashville. It’s as if they expect you to become Rhett Butler and speak like a southern gentleman. They smile and ask all kinds of innocuous and polite questions expecting to hear some smooth, southern answer. I’ve received some crestfallen looks when I answer with my Pittsburgh accent.
“Yeah I’m in Nashville now an’ it’s cool n’at. Yinz sould come dahn and check it aht. By da way, yinz like Donnie Iris?”
I was afraid that I would miss the natural beauty of the southwestern PA area. In the heart of the Allegheny Mountain range, the mountains, plentiful forests, and rivers will always hold a special place in my heart. However, I am quickly becoming fond of the beauty of Tennessee. Though there is only 1 river going through Nashville and very few bridges, the suburban sprawl hasn’t removed all of the beautiful forests and gently rolling hills.
One thing that I am taken with is the number of quaint horse ranches that I see on a regular basis. I have to admit, as a Yankee, I imagined everyone in Tennessee and Kentucky owned a horse and that Nashville would have an abundance of charming horse ranches within a stone’s throw of wherever I might live. While the reality certainly doesn’t match the fantasy, I do love the scenery.
I don’t like to complain… it takes a lot of effort and it has no benefit to my life at all. I rarely work with people or tools with which I can’t find a good rhythm. However, I’ve reached a boiling point today and have to vent.
I’ve worked with quite a few of the SCM packages out there in my 15+ years in software development. In my new job, I’ve been thrown into the yawning abyss of StarTeam by Borland. Granted, while the concepts of product itself are not hard to grasp, the implementation of these concepts, in conjunction with a poorly designed interface, is making code management much more of a job than it has ever been for me.
Also, throw in the fact that the processes set up in our department sometimes defy logic (well, mainstream logic, I’m certain there is some kind of logic behind it all).
The concept of breaking up tickets into Change Requests and Tasks certainly sounds promising but it opens a Pandora’s Box if the people using the system are clueless. I’ll keep the atomic process of making individual tickets.
Are Visual Diff and Visual Merge really the best products they could have integrated into StarTeam? I would have rather they left those tools out and required that a third-party tool be integrated.
I don’t want to even get started on floating configuration. I would never trust this process to a tool (especially one this poorly written), and, again, the potential for misuse is huge which ends up wasting a lot of people’s time.
I hate the system tray icon notifications when you have a new task assigned. You double click on the icon and that opens a popup window listed all the new item. Does clicking on the item take you to the task in StarTeam? No, it forcibly loads the “Form Server” (whatever the hell that is and it takes 30 seconds to load up) and open the actual item in another popup. Brilliant.
Ok, that’s the end of my rant. I’ll conclude with the concession that StarTeam may actually be a better product than I’m giving it credit for and that it’s implementation here is faulty. Whichever it is, I hate it.
I won’t go heavily into the reasons why you would want to use Apache as your proxy to JBoss, but I’ll give some popular ones here so you can see if any of the areas interest you.
The reasons I chose to use Apache to act as the web server for my JBoss servers were 1 and 2. I eventually needed to do a little bit of 3. I temporarily had to do number 4, and how easily I have been able to do all of this led me to believe number 5.
The only thing you need to change on JBoss to have Apache act as a proxy to it is ensure that is it not listening on port 80 (which you may have set if it was acting as your web server). Read step 5 in my standalone primer article for instructions on how to change your HTTP port if you haven’t done this before.
I downloaded version 2.0.58 which works just fine for my purposes. However, by the time you read this article, there may be a much better and/or feature-rich version of Apache available. Just download the version you feel best suits your purposes based on your needs.
Find the ‘Listen’ section of in the \Apache\conf\httpd.conf file and specify the IP address and port on which Apache is listening.
Listen <server ip address>:80
Next, you need to tell Apache where to direct traffic coming in on port 80 on that IP address. For this, we use Virtual Hosts.
NameVirtualHost <server ip address>:80
Now that Apache is prepared to accept request for multiple domain names, we need to set up each of those domains using the <virtualhost> tag. All you need to specify is the ServerName property, which the the base URL of the domain, and the ProxyPass property which simply tells Apache where to redirect the original request.
If your JBoss server is internal only and not public facing, you’ll have to use the IP address from Apache since that’s the designator for it.
<virtualhost>
ServerName www.orbwave.com
ProxyPass / http://{jboss server IP}:8080/
</virtualhost>
<virtualhost>
ServerName www.fusioncube.net
ProxyPass / http://{jboss server IP}:8080/
</virtualhost>
If you have both Apache and JBoss sitting on your public web server, you’ll need to use the domain name instead of the IP address.
<virtualhost>
ServerName www.orbwave.com
ProxyPass / http://www.orbwave.com:8080/
</virtualhost>
<virtualhost>
ServerName www.fusioncube.net
ProxyPass / http://www.fusioncube.net:8080/
</virtualhost>
What you need to do is create a seperate Host configuration for the edach domain in the server definition file which is located at \jboss\server\default\deploy\jbossweb-tomcat55.sar\server.xml.
Open that file and you’ll see a Host configuration already for localhost. This is the default host meaning that all traffic directed via your web server port (8080) will be directed to your root application. This will be your default domain, meaning the one for which you don’t define a Host.
Now let’s create a new Host designation that will direct requests for two new domain names.
<Host name="domain2 {this can be whatever you want}" autoDeploy="false" deployOnStartup="false" deployXML="false">
<Alias>www.second-domain-name.com</Alias>
<Valve className="org.apache.catalina.valves.AccessLogValve"
prefix="things" suffix=".log" pattern="common"
directory="${jboss.server.home.dir}/log"/>
<DefaultContext cookies="true" crossContext="true" override="true"/>
</Host>
<Host name="domain3 {this can be whatever you want}" autoDeploy="false" deployOnStartup="false" deployXML="false">
<Alias>www.third-domain-name.com</Alias>
<Valve className="org.apache.catalina.valves.AccessLogValve"
prefix="things" suffix=".log" pattern="common"
directory="${jboss.server.home.dir}/log"/>
<DefaultContext cookies="true" crossContext="true" override="true"/>
</Host>
The last step is to modify the jboss-web.xml file for each application. We’ve set up a brand new Host designation, so now each application can be set up as another root application, except now it sits in its own Host space rather than in the one set up for localhost.
So open up the jboss-web.xml file of the application that will be running for second-domain-name.com. Change the context-root definition to root (/) and then match it up with one of the Host entries you made in the server.xml file.
<jboss-web>
<context-root>/</context-root>
<virtual-host>domain2</virtual-host>
</jboss-web>
Similarly for another application that will be served for third-domain-name.com
<jboss-web>
<context-root>/</context-root>
<virtual-host>domain3</virtual-host>
</jboss-web>
All you need to do is start/restart your Jboss instance and request for both domain names will now be redirected to the appropriate application. Just be sure that you have made the requisite changes to your DNS records and they have propagated.
Been putting this post off for a long time. Well, not exactly putting it off, but since all my hardware and backups were still in Pittsburgh, I didn’t have my blog up, so my hands were tied.
I downloaded CF8 and followed my typical procedures for deploying on JBoss. Everything worked fine. JBoss started up without any errors and I could hit my applications. Then I decided to see if I could still customize the deployment by moving the core ColdFusion files outside the deployment directory and that went without a hitch. I don’t know why, but I was concerned that they might take that option away.
All in all, nothing has changed as far as deployment procedures. I suppose the only change is that now Adobe will answer your phone call if you deploy on JBoss!
Now for upgrading.
The most obvious change is in the web.xml file that comes with ColdFusion. All of the parameter id’s have changed names from macromedia_xxx to coldfusion_xxx.
<context-param id="coldfusion_context_2">
<param-name>coldfusion.compiler.outputDir</param-name>
<param-value>/WEB-INF/cfclasses</param-value>
<description>This is the directory where we will place compiled
pages. It must be relative to the webapp root.</description>
</context-param>
Therefore, if you have added anything in your web.xml – security, custom servlets, etc. – it’s best that you copy your custom definitions to the default ColdFusion web.xml rather than trying to update yours to match all the new names.
As always, ColdFusion does not come with a jboss-web.xml file, so make sure that you have that in place for each application again.