Archive for the ‘eclipse’ Category
This is one of these notes to self that I keep writing on the blog…
Add the following java options when launching an application (or application server) to get a dump if the application throws an OutOfMemoryException
We are using this on out local and development servers at work, and then using Eclipse MAT to diagnose the cause.
So far, it is been a pleasure working with MAT. We are maintaining some legacy web application which occasionally crashes due to OOM, so we took a dump and fed it to MAT.
Despite of my attempts to look at the wrong places (since we got OOM) on a webservice, MAT kept showing me our real memory problem until I understood it. The exception on the webservice was only collateral damage… most of the memory was being used in the tests run before the actual crash.
Now we save more than 2.5Mb on each http session, since it turned out that the application was caching too much, too many times (on every session, instead of sharing the data at the application level).
Eclipse has a large ecosystem. So large that it is reasonable to assume that most people will not know many of the available tools.
That can be a problem in the corporate world, where you would like all the developers using the same tools, and have those tools installed easily and fast.
One simple way of achieving this is to setup a corporate p2 mirror with the standarized extensions that all developers can/should/must install. To achive that, this simple script can be used to create a mirror on the p2-mirror folder:
@echo off SET ECLIPSE=D:\usuarios\java\eclipse-jee-galileo-RC4 echo Mirroring metadata for %1 java -jar %ECLIPSE%\plugins\org.eclipse.equinox.launcher_*.jar ^ -application org.eclipse.equinox.p2.metadata.repository.mirrorApplication ^ -source %1 ^ -destination p2-mirror ^ -destinationName "Corporate P2 Repo" ^ -verbose ^ -compare echo Mirroring artifacts for %1 java -jar %ECLIPSE%\plugins\org.eclipse.equinox.launcher_*.jar ^ -application org.eclipse.equinox.p2.artifact.repository.mirrorApplication ^ -source %1 ^ -destination p2-mirror ^ -destinationName "Corporate P2 Repo" ^ -verbose ^ -compare
Just invoke it with the url of the repository you want to mirror, and call it as many times as needed.
mirror http://q4e.googlecode.com/svn/trunk/updatesite-iam mirror http://q4e.googlecode.com/svn/trunk/p2-nightly mirror http://eclipse-cs.sf.net/update/ mirror http://findbugs.cs.umd.edu/eclipse/ mirror http://pmd.sourceforge.net/eclipse mirror http://download.eclipse.org/technology/subversive/0.7/update-site/ mirror http://www.polarion.org/projects/subversive/download/eclipse/2.0/update-site/
Now you only have to make the p2-mirror folder available (in shared network folder or published on an http server) so everyone can access it.
This is quite rough, so any suggestions for improvements are welcome!
I have been deep into configuring a development ecosystem with my client lately, with a boring session of integration tests for another project going in parallel, so I wanted to try something different for a change.
Eclipse 3.5 is about to come out and I have been playing with the RCs for a while. I’m on a Mac, so one of the things I wanted to see the new support for Cocoa (so far works great, but I have not been able to use Java 6 or 64bits). The other one was updating Eclipse IAM to run on the new Eclipse.
Creating a Lift project
Step one is creating the project from the lift archetype.
After all dependencies are downloaded I was welcome with some build errors on the test cases, which seem to be caused by Lift’s open dependency on Jetty (there were some refactorings in Jetty 7).
Setting an upper bound of 7.0.0 for the jetty dependency fixed those.
<dependency> <groupid>org.mortbay.jetty</groupid> <artifactid>jetty</artifactid> <version>[6.1.6,7.0.0)</version> <scope>test</scope> </dependency>
Clean the project and the errors are gone.
Running the project
Starting with Lift, suggests running the project launching jetty from maven. I wanted to use WTP instead, so I tried to install the Jetty adapter by using the support in WTP for downloadable adaptors. Unfortunately, the installation did not work, so I used the built-in support for Tomcat 5.5 instead.
Before getting into the next chapter of Starting with Lift, I played around with the application I had just built.
- Changes to index.html were shown immediatly
- Same thing when modifying the default.html template
- Modifying the HelloWorld class to return a new value causes the context to be reloaded and the changes can be seen live (no redeployment needed)
- Adding a second method to HelloWorld and using it on the index.html template works as above (as expected)
End of chapter one
There might be some surprises down the road, but the initial impression has been good.
- IAM has “just worked” and stayed out of the way in a non-java project (there is no special support on IAM for Scala or Lift, although esmi is on the works)
- WTP performed well. I expect the issues with the installation of the Jetty adapter to go away soon, since Jetty has joined Eclipse.
- About Lift and Scala… well, I have a lot of things to learn yet.
I am looking forward to keep using these tools together (at least go through the Starting with Lift guide!).
Sometimes you spend time developing and testing your new bundle using the runtime workbench launched from the same eclipse, and everything is fine… until some user installs that bundle and finds that it does… nothing!
The OSGi console is a great help in such cases. The `diag` command can tell you what’s wrong. Usually it is a dependency that is missing.
Start by launching eclipse from the command line with the
-console command line option.
diag your.bundle.id, and you’ll see eclipse telling you what’s wrong.