It’s Only Software

Debugger Shortcut Keys

I finally had to write this down because I use different IDEs fairly often (for work and personal projects), and the fact that most common run/debug key equivalents differ in every IDE really annoyed me!

A heads up in case anyone is thinking about using these together. Currently (Aug 18, 2008), the release version of Hibernate IDE (aka the Hibernate Eclipse plugin) does not work with Eclipse 3.4 (“Ganymede”) without one of 2 things:

• Unjarring, copying, and rejarring a file from Eclipse 3.3
• Using the Hibernate IDE Nightly Update Site

Discussion for this is covered in the Hibernate Forums and in HBX-1068 in Hibernate JIRA.

Since it’s already fixed in the nightlies, your best bet is to hit the nightly build site for the tools. If you’re afraid of the nightlies and/or the harder install process and want to pull the missing class (“org/eclipse/ui/internal/util/SWTResourceUtil”) from Eclipse 3.3, do this:

• Copy the “org.eclipse.ui.workbench” jar from your Eclipse 3.3 install/plugins directory to a temp directory (say, c:\temp). Mine was called “org.eclipse.ui.workbench_3.3.1.M20070921-1200.jar”
• Extract the missing class file: jar xvf org.eclipse.ui.workbench_3.3.1.M20070921-1200.jar org/eclipse/ui/internal/util/SWTResourceUtil.class
• Copy the “org.eclipse.ui.workbench” jar from your Eclipse 3.4 install/plugins directory to the same directory. Mine was called “org.eclipse.ui.workbench_3.4.0.I20080606-1300.jar”
• Update the JAR file: jar uvf org.eclipse.ui.workbench_3.4.0.I20080606-1300.jar org/eclipse/ui/internal/util/SWTResourceUtil.class
• Copy the Eclipse 3.4 JAR file back to your Eclipse 3.4 install/plugins directory (overwriting the original).

That should do it! Note that this information is only correct until the next version of the Hibernate IDE tools are make into a formal release. The last release date listed on the site was April 9, 2008, so I would guess a new release would occur soon.

I guess I’ve had a busy / buggy weekend noodling around with stuff. I ran into a [known] bug in the latest JSTL/JSF 1.2 Reference Implementation on Tomcat 6.0.14.

I was playing around with Spring MVC 2.5.1, and even the simplest JSP page gave me this:

java.lang.NullPointerException
	com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:312)
	com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:87)
	com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:240)
[snip]

This is interesting, because I wasn’t even using JSF!

It turns out that there’s a bug that is lightly documented in the JSTL/JSF 1.2_07 RI release notes:

There is a chance for an NPE in com.sun.faces.application.WebappLifecycleListener with some configurations (see issue 670). Take for example, installing JSF in a container such that JSF will be available to all web applications. The NPE will occur for an application that doesn’t have the FacesServlet defined within it’s web.xml.

The workaround for this issue is, within the global web.xml for the container (JBoss and Tomcat both have one) add either a FacesServlet definition (no mapping) or add the context init parameter, com.sun.faces.forceLoadConfiguration, with a value of true. NOTE: GlassFish is not affected by this issue.

This is also covered in the Mojarra bug database as bug 670, and the JBoss bug database as bug JBAS-5063.

There’s some discussion in this JBoss forum thread indicating how to solve for JBoss AS, which is a good start.

For Tomcat 6, you can add the following to context.xml:

	<Parameter name="com.sun.faces.forceLoadConfiguration" value="true"/>

One caveat here is if you’re running an Eclipse-based Tomcat instance. Eclipse-configured Tomcat doesn’t have an easily accessible context.xml. Instead, you’ll have to configure this in the global default webapp. Look in your Eclipse workspace for the server configuration (by default, Eclipse will put this in a top-level project called “Servers”).

In the web.xml you’ll find in there, add the following:

 <context-param>
  <param-name>com.sun.faces.forceLoadConfiguration</param-name>
  <param-value>true</param-value>
 </context-param>

This should not be put in your web application’s web.xml!

Once you do this, you should not receive the NullPointerException upon first access to a JSP. It looks like this bug will be fixed in the next RI release of JSF/JSTL.

I was banging my head against the wall due to this problem. Apparently there is an issue with Spring IDE 2.0.2 running on a Java 6 platform – simply put, it doesn’t work. There’s a JIRA filed on this, along with some discussion [#1], [#2]in the Spring forums. I reverted to manually installing Spring IDE 2.0.1 from the update site (unzip, then use eclipse -clean), and it worked again.

This was on a brand new Eclipse 3.3 install with no prior trace of the Spring IDE plugin

Hopefully this helps someone. The error that I saw upon startup of Eclipse was:

java.lang.NoClassDefFoundError: Could not initialize class org.springframework.core.CollectionFactory
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.<init>(DefaultSingletonBeanRegistry.java:86)
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.<init>(FactoryBeanRegistrySupport.java:40)
at org.springframework.beans.factory.support.AbstractBeanFactory.<init>(AbstractBeanFactory.java:146)
at org.springframework.ide.eclipse.beans.core.DefaultBeanDefinitionRegistry.<init>(DefaultBeanDefinitionRegistry.java:72)
at org.springframework.ide.eclipse.beans.core.internal.model.BeansConfig.readConfig(BeansConfig.java:707)
[snip]

File this one under “silly me”. I was having a heck of a time getting Eclipse 3.3 to find the Glassfish plugin automatically (or even manually) as described in the install guide.

I am sometimes behind a corporate proxy server, but I had the proxy set up in Eclipse when I was trying this, and I was seeing other app servers show up in the “Download additional server adapters” dialog.

Turns out that about half of the server adapter sites serve up their updates via HTTP (Geronimo, IBM, Pramati, and Eclipse proper). The rest use HTTPS (BEA, Glassfish, SAP). This can be determined by opening org.eclipse.wst.server.ui_1.0.205.v20070912.jar, or the equivalent on your version of Eclipse/WTP, and looking at serverAdapterSites.xml. For the curious, you can view the contents of this file in the Eclipse CVS repository.

All I had to do once I figured this out was to update my Eclipse proxy settings to use the same proxy for HTTPS that I was using for HTTP. It’s unfortunate that one doesn’t get any error or warning messages when this happens!

Hopefully this helps anyone else trying to get this installed from behind a proxy.

Recently, while working on a customer’s older EJB 2-based system, I was going a bit nutty having to run a 1-2 minute ant build to execute various code generation tasks (anyone have fond memories of ejbgen like I do? )

I was able to get Eclipse set up to be happy with the relatively complex build structure, and happily discovered the “Ant Builder” capability of Eclipse, which allows ant build tasks to be inserted into the Eclipse build process. Tying this external build process into the IDE helped improve my efficiency while working on this complex project. I’ll go over here briefly how you can use this feature through an illustrative example.
Continue reading “Quick Tip: Using “Ant Builder” to customize Eclipse builds using ant scripts”

I don’t know how many times I’ve accidentally created a General project instead of a Java project, and it always bugged me that you couldn’t convert from General to Java without starting over.

The quick and easy hack is explained well here. Open the relevant .project file and add the following (note that you don’t need the <natures> element if one is already there):

    <natures>
        <nature>org.eclipse.jdt.core.javanature</nature>
    </natures>

It’s too bad you can’t “Add Java Project Nature” from within the Eclipse UI

Make sure you do this with the project closed!

I use Eclipse 3.3.x and WTP 2.x for most of my web development. Recently, I’ve been using an Eclipse-managed Tomcat 6 server for running and deploying web applications.

I’ve run into the problem several times when “Clean Tomcat Work Directory…” just doesn’t work. Fortunately, you can manually find the deployment directory and blow away your deployed web application – if you know where to look.

For Eclipse-managed Tomcat installs, look in the following directory to find the Tomcat setup for your workspace:

.metadata\.plugins\org.eclipse.wst.server.core\tmp0

You’ll see the usual conf, logs, temp, webapps directories. Your web application is most likely deployed in the “wtpwebapps” directory – look for it there and remove (delete) it. Tomcat will be happy once again.

Note that the “tmp0″ designation may differ depending on how many servers you have configured in your workspace.

Further Reading

Web Tools Platform 2.0 “New & Noteworthy” discusses the use of these new WTP 2.0 features in more detail.

I used to be an IntelliJ IDEA user, but have migrated over to Eclipse. One of the things that I initially missed in Eclipse was the availability of the “light bulb” tips to do quick refactors and code optimizations. I have recently discovered that Eclipse has many of the same fixes, but they aren’t advertised as well.

Eclipse differentiates between two types of “quick” tips.

“Quick Fixes” are used when something is actually broken, and Eclipse can provide one (or more) solutions for you, which it can apply to your code. I was able to find a handy list of all the available fixes on the Eclipse site:

http://help.eclipse.org/help33/topic/org.eclipse.jdt.doc.user/concepts/cquickfix.htm

These are great, and I have found that with most basic Java development issues, there’s an appropriate quick fix to solve the issue.

“Quick Assists” are minor refactorings that Eclipse can perform on your behalf. This was the IDEA feature that I missed most when coming over to Eclipse. Here’s the reference list:

http://help.eclipse.org/help33/topic/org.eclipse.jdt.doc.user/concepts/cquickassists.htm

One difference (IIRC) is that Eclipse doesn’t determine which quick assists may be appropriate given your current cursor position – it requires that you select an expression or block in order to figure out which quick assists are relevant.

For those keyboard junkies like myself, a couple notes may be helpful. I remapped (IMO horrible) default key shortcut for Quick Fix and Quick Assist (Ctrl+1) to Ctrl+Enter. This makes it much easier to activate these quick changes without hand gyrations (especially on a laptop keyboard).

Second little helpful tidbit is Alt+Shift+Up (try pressing this repeatedly) to select increasingly higher-scoped compilation units (you kind of have to see this to know how it works).

Hopefully this helps you get something more out of Eclipse, especially if you use it every day!