January 22, 2008
I just ran into this problem that eclipse wouldn’t display the J2EE module dependencies for a couple of my projects. The solution I found was to open the MANIFEST.MF files for those projects and delete the classpath entries. I suspect I had some old classpath entries in there which were no longer valid, and the property page code was flipping out about it.
Hope this helps someone …
4 Comments |
eclipse, java ee |
Permalink
Posted by dobes
November 25, 2007
I recently ran into a post where someone said they were dropping TopLikn Essentials in favor of OpenJPA. At the time I was searching for some assistance in fixing some rather impossible to diagnose (mostly due to toplink’s incomprehensible stack traces) ClassNotFoundException. I eventually figured out that toplink’s class loader was broken in some way which I couldn’t fix, and that meant I couldn’t have my entity classes subclass something from some other jar. Or whatever, I haven’t fully diagnosed the problem, and instead decided to spend my time on getting OpenJPA installed.
This turned out to be quite easy – I just downloaded the openjpa binaries and copy the openjpa jar and lib/*.jar from that disitribution into glassfish/domains/domain1/lib, then changed my persistence.xml to specify OpenJPA as the persistence provider:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="db">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<jta-data-source>db</jta-data-source>
...
Even though OpenJPA is more strict about not using field accesses when using property-mode fields (even inside the same class, you can’t use this.x) I’m so happy that it told me this with wonderfully clear error messages, it seems worth the effort to fix my code (by right-clicking a lot and picking Refactor > Encapsulate Field).
Thanks go to Sahoo for showing me how to do this:
http://weblogs.java.net/blog/ss141213/archive/2006/07/using_openjpa_a.html
9 Comments |
database, eclipse, java ee |
Permalink
Posted by dobes
July 29, 2007
I’ve been doing some eclipse/GWT programming and one thing that’s bothered me is that I haven’t had any of the benefits of having the source code – especially having the parameters named properly when I auto-complete something. I finally decided to look into this more closely and I realized that I do have source code for all the GWT classes, so why wasn’t I getting proper completion?
The problem: gwt-servlet.jar was earlier in the classpath than gwt-user.jar. gwt-servlet.jar doesn’t have the source code in it.
The solution: Move Google Web Toolkit to the top of the build path! Now I get lovely documentation when I’m completing, and I don’t have to rename all the parameters to my AsyncCallback implementations.
1 Comment |
GWT, eclipse |
Permalink
Posted by dobes
July 28, 2007
Previously I suggested you could use a folder link to get the GWT plugin to deploy your css/html files directly to the deployed app folder.
I’ve since decided that it’s handier to create an ant build task to copy the files instead, and tell eclipse to run that build file when I change my css or images. To set this up, first create a file called build.xml, which you could base on this:
<project name="Books GWT App">
<property name="glassfish" location="C:\work\glassfish"/>
<property name="gwt-deploy" location="${glassfish}/domains/domain1/applications/j2ee-apps/myEAR/myApp_war/gwt"/>
<property name="gwt-resources" location="src/package/app/public"/>
<property name="appname" value="package.app.App"/>
<target name="deployed.check">
<condition property="is-deployed">
<available file="${gwt-deploy}"/>
</condition>
</target>
<target name="quick-redeploy"
depends="deployed.check"
if="is-deployed"
description="Re-deploy GWT to Already-Deployed App">
<copy todir="${gwt-deploy}/${appname}"
verbose="true">
<fileset dir="${gwt-resources}"/>
<fileset dir="bin.gwt/${appname}"/>
</copy>
</target>
</project>
Now when I am editing the css or adding/removing images, it immediately copies the files into the deployed folder. This technique will work for any static resources deployed to a web app, and will save a lot of time waiting for publish if you’re just working on the static resources.
2 Comments |
GWT, eclipse, java ee |
Permalink
Posted by dobes
July 28, 2007
I previously linked to this GWT plugin for eclipse from eclipseguru.org.
It’s great in that I can easily run my project in the GWT browser, use the debugger, hit refresh to reload my classes, and it automatically compiles and deploys everything when I deploy the server.
One useful trick I’ve come up with is to create a link folder in my GWT project (called deploy.gwt) which points at the already-deployed web app folder. This means that I can deploy my GWT to the webserver quickly by pointing GWT at that link (Project > Properties > GWT Deployment > Output folder = “deploy.gwt”) and using the “GWT Tools > Compile and Publish” context menu item on the project to compile and publish directly into the container. Now I can test in a non-hosted browser after only a few seconds, instead of waiting a minute for a standard glassfish deployment. It also updates the css and images, but not servlets. It is a huge time saver when tweaking CSS and images.
5 Comments |
GWT, eclipse, java, java ee, servlets |
Permalink
Posted by dobes
July 2, 2007
If you’re all set up to do Java Server Faces, but you want to be able to edit the jsf-config.xml using the WTP 2.0 (web tools platform) and have some kind of editing support in eclipse, try this:
Go to Window > Preferences … > General > Content Types > Text > JSP and add “*.xhtml”, or whatever extension you’re using for your facelets.
Now you’ll gain a bit of validation and editing support that wasn’t there before. Hope that helps!
4 Comments |
JSF, eclipse, facelets, java |
Permalink
Posted by dobes