Category: Geekdom

(Based on information from this entry at the Dojo Foundation BLOG. This information is for Windows machines, specifically for concurrently running Firefox 1.0.7 and 1.5.0.x, but the same information applies to other versions of Ff as well. David Schontzler’s aforementioned post covers ‘Nix machines.)

As a Web developer on some fairly complex projects, it’s important to be able to run the current Firefox browser, as well as the previous release.

These instructions are based on having first installed Firefox 1.0.7.

Locate your current Firefox profile. Normally it will be in a folder under your Application Data folder, typically such as the following:

C:Documents and Settings{user_id}Application DataMozillaFirefox

Copy the entire Firefox directory someplace convenient, so you have a backup, for when you miss a step and something goes horribly wrong. (I know—this would never happen to me, either, but I was grateful I had a backup the two times I munged this setup and had to fix my initial Ff 1.0.7 installation.) You want to be able to fix your Firefox extensions in the event your running of Firefox 1.5 tries to upgrade them, which is a one-way process.

Then download and install Firefox 1.5.0.x, to a location other than the default location. (I recommend using a directory named C:Program FilesMozilla Firefox 1.5, as C:Program FilesMozilla Firefox is the default.) Do not launch Firefox 1.5 yet. (Be sure not to tell the install wizard to launch Firefox at the end.) If you do, you’ll need to quit the browser, and replace the now-upgraded profile folder with the one you backed up.

To allow you to clearly identify separate processes in the Task Manager process list, and to avoid accidentally running the Firefox 1.5 installation without the batch file that will preserve the Firefox 1.0.7 profile information, I recommend renaming the C:Program FilesMozilla Firefox 1.5firefox.exe to firefox15.exe. However, if you choose to perform this step, you’ll need to rename firefox.exe to firefox15.exe each time you perform an upgrade (such as from 1.5.0.3 to 1.5.0.4) of Firefox 1.5. (See “Future Upgrades,” below.)

Next, you’ll need to create a batch file to launch Firefox 1.5 and load a Firefox 1.5-specific profile:

set MOZ_NO_REMOTE=1

start "Firefox" "C:Program FilesMozilla Firefox
1.5firefox15.exe" -P "Firefox 1.5"

set MOZ_NO_REMOTE=0

The above batch file presumes that Firefox 1.5 is installed in the directory specified, that the executable is named firefox15.exe, and that a user profile named Firefox 1.5 will normally be used. If you’ve used values for any of these items that are different than the recommendations above, alter the portions marked in red accordingly.

The first time you launch Firefox 1.5, the Profile Manager will appear. Create a profile that matches the name used in your batch file.

If you want to change the icon shown (on the taskbar and the Firefox title bar), create a new icon and place it in C:Program FilesMozilla Firefox 1.5chromeiconsdefault with the name main-window.ico. You can find one that has a “1.5” overlaid atop the regular Firefox icon here. You can also find utilities to change the text in the title bar itself, such as the Titlebar Tweaks Firefox extension—which, ironically, has not yet been officially updated for Ff 1.5.0.x (as of June 7, 2006). You can install an updated, but unofficial, version from here.

I have also found that using significantly different themes (skins) for my different Firefox versions helps keep them straight at a glance.

And, of course, if you prefer to make Firefox 1.5 your default Ff version, do so, and modify the batch file to point to 1.0.7 instead.

Future Upgrades

The best thing to do when one is about to upgrade Firefox 1.5.x, is rename the firefox15.exe back to firefox.exe, run the ugprade, and then rename it back. If you don’t, you’ll find that your firefox15.exe is still around, but that the upgrader has added its own firefox.exe, requiring a delete-and-rename, as well as producing some interesting quirks, like Firefox not realizing it’s been upgraded because the .exe you’re running is the old one, while everything else is new.

Don’t believe everything you’ll find online. If you work in a moderately complex environment (meaning, you’re running a managed server instance via an admin server instance on WebLogic), you’re sure to be led astray by the dozens of articles offering guidance into this elusive technique. You don’t have to emulate Ray Milland, if you follow this advice:

If you Google “Remote debugging WebLogic” you’ll find a host of discussions about modifying the startWebLogic.cmd or startWLS.cmd files. Ignore them all (assuming you’re using WebLogic 8.1 or later)! (Also remember, never verb a noun.)

Let me review the scenario that I am actually addressing here:

• You will be remote-attaching to a running WebLogic instance, rather than launching the instance from within your IDE. (I use Eclipse, because I’m cheap—and because version 3.1.1 really works great, unlike its predecessors—but these instructions apply to just about anything.)
• You run your WebLogic application as an instance under a WebLogic managed server, and start/stop it using the Remote Start options in the WebLogic console.
• You’ve tried desperately to get your debugger to attach, or your breakpoints to be hit, to no avail.
• You have deadlines looming, and if you don’t get this one problem solved, you can never see your family again.

Okay, perhaps I went a bit overboard on the scenario, but if you’re reading this, I expect, like me, BEA’s WebLogic isn’t a platform you use every day, but one that you need to work on occasionally.

The key is that most of the documentation presumes you won’t be running your application from the WebLogic Server Console, and gives no indication that the JVM arguments, in such a case, go in a completely different place. Here’s how to prove to the world that you weren’t going insane:

1. Log on to the WebLogic console, via http://{servername}:9999/console. YMMV as far as the port number (after {servername}) is concerned.
2. Using the navigation tree, click on the domain on which your application resides, open the Servers branch beneath it, and click on your application’s name.
3. With the Configuration tab in the top row selected, click on the Remote Start tab in the second row. (Be sure you don’t have Control selected in the top row, otherwise you’ll think I am just as batty as the authors of the previous 743 help documents you’ve read.)
4. Scroll down to the Arguments: field, and add your debug settings to the JVM arguments in that field. In my case, I added -Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n, which (among other things that are too cool for me to share) allows the debugger to attach to port 8787 (address=8787), and the server to start without waiting for a debugger to attach (suspend=n).



5. Click on Apply.
6. Then click on Control in the first row of tabs, and be sure Start/Stop is selected in the second row of tabs.
7. Finally, you’ll need to either gracefully or forcefully shut down the server by using the links provided, and then restart the server. (You’re actually only restarting your application; the ambiguous language surrounding server is another problem.)
8. Attach Eclipse to the server by Configuring a new Remote Java Application under Debug … Feed it parameters of the server name and 8787 (or whatever port you provided in the JVM arguments).



9. Debug your problem.
10. For goodness’ sake, go home and see your family!

Drop me an e-mail using the link in the sidebar, or leave a comment, if I’ve goofed anywhere. I never claimed to be perfect. Sheesh.