After my talk at JavaOne2013 I felt there was some really useful material which deserved a wider audience so I have decided to use some of it as the basis of this blog article.
At IDR Solutions we use GlassFish and NetBeans on a daily basis, so we’ve had our fair share of mistakes and gotchas. In this article I intend to share our lessons learned using GlassFish and NetBeans to save you time and ridicule from your peers. Skip Straight to the tips.
What is GlassFish?
GlassFish is a fully-blown web-application server. It’s a server that you can run and test your web applications on. For example, at PDF help.org we run our online PDF to HTML5 converter on a GlassFish server. A great thing about GlassFish is that you can run it on a single machine for testing and development and it allows non-java developers to access our Java server application via web services (we can sell Java to non-Java users!).
Why NetBeans?
The reason why we use the NetBeans IDE when working with web applications and GlassFish is because NetBeans has fantastic GlassFish support, you can download the NetBeans Java Enterprise Edition (EE) which comes with GlassFish pre-installed. NetBeans also allows you to access many GlassFish features such as deploying/undeploying web applications and controlling the server state directly from the IDE. Using GlassFish and NetBeans makes it very easy to mix and match technologies (HTML5/CSS/JAVA).
Hints & Tips
When deploying your .war file to the GlassFish server it’s important to ensure that you use the correct spelling and case sensitivity, this is because to ensure your web application has cross-platform support you need to take into account that Windows is case In-Sensitive whilst Unix is case Sensitive.
If you have problems accessing your GlassFish server then ensure you are accessing it on the correct port, by default the administration port is 4848. Directly trying to access the server via a URL won’t work, the URL must include the correct port numbers.
The difference between a .jar and a .war file is that a .jar contains all of your libraries, resouces and property files whilst a .war contains the actual built web application along with the html, java, jsp and javascript. The .war is what you deploy to your GlassFish server.
Cleaning your NetBeans web application will delete the .war file from the “dist” directory, this is usually located in “NetBeansProjects\myApplication\dist”. Whilst building, the web application will create and place the .war file in the “dist” directory. Before you clean and build your web application it is important to make sure your GlassFish server is stopped. If you do not do this then the GlassFish server may throw dependency errors to the server log and you will have a corrupt build.
After you have built your .war file it’s very important to validate it was a successful build. Todo this, as soon as your .war is built you should navigate to the “dist” directory and compare the .war files last modified time against the current system time. This will make sure that the .war file you just built was correctly built and placed in the “dist” directory. If you do not do this then you run the risk of deploying an older or corrupt .war file.
Gotchas
System.out.println(“”) will write to the server log and not the project. NetBeans will output the server log to the console window which makes debugging your web applications easy.
Before you deploy it’s important to ensure you have a stable build. When working on your Web Application, if you are working with linked projects that are also in development then when you are building your .war it’s important to build using stable releases of the linked projects. If you do not do this then your web application may be deployed with bugs and half finished features.
After you have deployed your .war and want to resume development on your web application it is important to remove the stable external .jars of your linked projects and re-link with the projects that are still in development. This ensures that any future changes to your other projects are visible when testing your web application.
If you are having problems seeing your code changes and it’s not because you have forgotten to re-link your project then it may be because you haven’t refreshed your browser window. When working with GlassFish, because viewing code changes are so quick and easy then you may forget something as simple as refreshing your browser window which clears and replaces your cache with the recent changes.
This post is part of our “NetBeans article Index” series and “GlassFish article Index” series. In these articles, we aim to explore NetBeans and GlassFish in different ways, from useful hint and tips, to our how-to’s, experiences and usage of the NetBeans IDE and GlassFish.
I hope you enjoyed this blog-post, if you have any questions or would like to contribute some information then post in the comments below and i’ll reply as soon as I can.