Insert Witty Irony Here

Thursday June 19, 2008

GlassFish V3 integration integrated

Folks like Ludo and Arun have posted entries about how to use GlassFish V3 TP2 with NetBeans 6.1. The first step is to get the bits from the NetBeans 6.1 beta update center.

One of my colleagues, Peter Williams, recently moved the code into the "main" Mercurial repository for NetBeans. We threw the switch to make the V3 server integration modules part of the trunk builds over the week-end.

This means that folks that want to live on the bleeding edge can get a development environment for GlassFish V3 even faster...

One warning: The bits that are downloaded by the integration module are currently the TP2 release. This will change soon. The V3 bits will be from a promoted build.

(2008-06-19 00:01:01.0) Permalink

Thursday June 05, 2008

Faster NetBeans on Windows... because someone filed a bug report.

Folks that work with NetBeans dev builds may have noticed a little bit of a speed improvement in the last couple of days.

I got involved in a thread on the nbj2ee mailing list. The user was seeing terrible performance on Windows while using directory deployment onto Glassfish V2. The user was able to describe their situation in enough detail that I could replicate the problem and fix it.

But after fixing it, I realized that this was a bigger issue. I figure there is about 800 uses of getOutputStream(), spread over 500 files. So, I filed an issue and another engineer (who knows more about that area of the code) fixed it.

As an added bonus... It looks like both fixes will go into patch 2 for NetBeans 6.1.

(2008-06-05 21:43:11.0) Permalink Comments [4]

New on the Update Center: SIP Application Development Module Suite

Long row, hoed!

You can now get the SIP Application Development modules from the NetBeans Beta update center with NetBeans 6.1.

1. Open the Plugins dialog, by using the Plugins item of the Tools menu.
   
2. Select the SIP Project item from the list of Available plugins.
3. Press the 'Install' button.
   
4. Press the 'Next' button.
   
5. Accept the license.
6. Watch the download status dialog update.
7. Click Finish on the installation summary page.
   

As we make bug fixes to the plugin, we will update the bits on the update center. The freshest bits will always be available from the lib/tools/netbeans directory of the Sailfin install, since it takes a couple days to get the bits pushed onto the update center.

I want to thank a number of folks for their contributions to this project. Ludo did the initial work on a module that would support SIP application development. Ajay Acharya had the unenviable task of moving the code to a new repository and a new package structure. Yvo Bogers contributed the test agent code, which is based on the test agent from Ericsson's SDS product. Elena Asarina identified issues and provided some documentation on how to work with the modules in the early stages. Naman Mehta helped write the "glue" that bridged the Maven1 based Sailfin build and the ant based build used by NetBeans projects. Terena Chinn-Fujii made sure the glued-together build actually built something without taking all day to do it. Jiri Kovalsky and Robert Novak made sure I dotted the license ayes and then put the bit up for the world to struggle with.

(2008-06-05 08:15:51.0) Permalink

Wednesday May 14, 2008

New Improved Tooling for Sailfin

...Now built Pragmatically, end to end...

Some folks may recall that I had done some work to make the Sailfin build for the tooling a bit more pragmatic. With the hustle and bustle to prep for JavaOne, completing that work got delayed.

But, now that work is done....

What does that mean to users? A lot, I hope.

Now, folks will be able to get their hands on tooling bug fixes quick and easy. The Sailfin project's nightly build will have the latest and greatest tooling, without nasty manual intervention.

Ah! A smooth running pragmatic build process... It smell like victory! Or was that Teen Spirit.... Hmmm.

(2008-05-14 22:25:55.0) Permalink

Wednesday March 19, 2008

Test agent evolution

While I have been working with the build infrastructure, I have been making some changes to the test agent. Most of them are pretty minor tweaks and bug fixes.

The most significant change that I have made is on the main "screen". In the past, all the shortcut buttons, like 'ACK', 'CANCEL' and 'BYE' were always enabled. These shortcuts are now enabled and disabled based on the selected item in the history list.

The state of the shortcuts when a request message is selected.

The state of the shortcuts when a response is selected.

I have also extended the Converged Servlet Application to open the test agent automatically, when it is deployed. It isn't much. I hope that it will save users a click or two.

I have also spent some time fixing bugs and doing some clean-up, based on the output of FindBugs.

(2008-03-19 17:02:49.0) Permalink

Tuesday March 18, 2008

Got Sunray? Need Hg?

I helped a co-worker configure his environment (a Sunray) to allow him to clone the NB repository. It actually wasn't very hard. The instructions are in the Netbeans wiki: http://wiki.netbeans.org/HgAndSunrays.

(2008-03-18 13:18:39.0) Permalink

Monday March 17, 2008

Directory Deployment from NetBeans to GlassFish

I published a teaser entry, where I demonstrated the effect of a code change related to directory deployment that I had pushed a couple days before. Since the entry was exposition "thin", I have gotten some questions about it...

After reading through the questions, I figured it would be easy to google up some reference and post them....

Boy, was I wrong!

I hope that this entry will answer the questions and be a "hit" for folks interested in NetBeans, directory deployment and GlassFish. The synonym for directory deployment in the JBoss user community appears to be 'exploded deployment'. The synonym for directory deployment in the WebLogic user community appears to be 'deployment of exploded archive directories'.

When a project is directory deployed into a web container, like Tomcat, or an app server, like GlassFish, a lot of optimizations can occur.

1. packaging the module or app becomes unnecessary.
   No archive is created.
2. unpacking the module or app becomes unnecessary.
   No archive needs to be read and/or transfered and exploded.
3. JSP changes are detectable, if the IDE forwards source changes into the 'deployment directory'.
   NetBeans pushes changes to html and jsp files to the deploy directory. Both servers detect the updates when the page is requested and do the necessary work to display the current content.

NetBeans supports directory deployment of Web Application projects to Tomcat and GlassFish. This has been available for quite some time. I found this reference that alludes to directory deployment with NB 3.6 and Sun Java System Application Server 8.0. NetBeans was extended to support directory deployment of ears and ejb-jars onto GlassFish V2 in the NetBeans 6.0 release.

The other server integration plugins for NetBeans 6.0.1 or NetBeans 6.1 (recently beta'ed) do not support directory deployment.

The recent changes that improve the performance of 'Run Project' and 'Run File' for a JSP file change in web applications and web applications embedded in an enterprise application are available in nightly builds of NetBeans 6.1.

I hope to integrate some of the ideas from a blog entry by JFA in the next few days. This will make even more web-app change scenarios faster.

(2008-03-17 07:50:53.0) Permalink

Wednesday March 12, 2008

Some Directory Deployment Improvements

Old stuff... ant output from second Run File on a jsp... with no code change in the jsp (or anywhere else in the web app)...

init:
deps-module-jar:
deps-ear-jar:
deps-jar:
library-inclusion-in-archive:
library-inclusion-in-manifest:
compile:
compile-jsps:
Incrementally deploying WebApplication137_localhost:4848_server
Completed incremental distribution of WebApplication137
Incrementally redeploying WebApplication137_localhost:4848_server
Start registering the project's server resources
Finished registering server resources
moduleID=WebApplication137
While redeploying, trying to stop the application in target server  completed successfully
While redeploying, trying to remove reference for application in target server  completed successfully
deployment started : 0%
deployment finished : 100%
Deploying application in domain completed successfully
Trying to create reference for application in target server  completed successfully
Trying to start application in target server  completed successfully
Deployment of application WebApplication137  completed successfully
run-deploy:
Browsing: http://localhost:8080/WebApplication137/index.jsp
run-display-browser:
run:

BAD! The IDE is doing a lot of work that is not necessary that I have to wait for it to finish....

Recent changes.

New Stuff... ant output from second Run File on a jsp... with no code change in the jsp (or anywhere else in the web app)...

init:
deps-module-jar:
deps-ear-jar:
deps-jar:
library-inclusion-in-archive:
library-inclusion-in-manifest:
compile:
compile-jsps:
Incrementally deploying WebApplication137_localhost:4848_server
Completed incremental distribution of WebApplication137
run-deploy:
Browsing: http://localhost:8080/WebApplication137/index.jsp
run-display-browser:
run:

SWEET! The IDE avoided doing the unnecessary work, so I can be more productive!

New Stuff... ant output from second Run Project on an Ent App projects that has the web app from the previous tests in it... after the user has changed some content in the JSP....

pre-init:
init-private:
init-userdir:
init-user:
init-project:
do-init:
post-init:
init-check:
init:
deps-jar:
deps-j2ee-archive:
init:
deps-module-jar:
deps-ear-jar:
deps-jar:
library-inclusion-in-archive:
library-inclusion-in-manifest:
compile:
compile-jsps:
do-ear-dist:
Building jar: /export/home/vkraemer/NetBeansProjects/WebApplication137/dist/WebApplication137.war
dist-ear:
pre-pre-compile:
pre-compile:
do-compile:
Copying 1 file to /export/home/vkraemer/NetBeansProjects/EnterpriseApplication158/build
post-compile:
compile:
pre-dist:
do-dist-without-manifest:
do-dist-with-manifest:
Building jar: /export/home/vkraemer/NetBeansProjects/EnterpriseApplication158/dist/EnterpriseApplication158.ear
post-dist:
dist:
pre-run-deploy:
Incrementally deploying EnterpriseApplication158#/WebApplication137_localhost:4848_server
Incrementally deploying EnterpriseApplication158_localhost:4848_server
Completed incremental distribution of EnterpriseApplication158
post-run-deploy:
run-deploy:
Browsing: http://localhost:8080/WebApplication137/
run-display-browser:
run-ac:
run:

SWEET! The IDE was busy, but the time to do all this "work" was almost zero seconds. We may be able to eliminate some of the work from this case, too.

(2008-03-12 13:32:39.0) Permalink Comments [1]

Thursday February 14, 2008

Love the freshest tooling bits?

I wrote up an entry a couple days ago about a new way to get the NBM files that implement the SIP application development support. In that entry I lamented that the process that gets the bits there wasn't very Pragmatic, since it wasn't fully automated and repeatable.

Today, I want to let you know that I have extended the build to be a bit closer to a Pragmatic solution.

Here is what you need to do....

1. Create a workspace directory. Let's call it SFWS.
   mkdir SFWS
2. Change directory into SFWS.
   cd SFWS
3. Checkout the Project Sailfin "bootstrap" code.
   cvs -d:pserver:<java.net.id>@cvs.dev.java.net:/cvs co sailfin/bootstrap
4. Set the correct values for maven.proxy.*
   These properties are found in SFWS/sailfin/bootstrap/project.properties.
5. Change directory into the boostrap directory
   cd sailfin/bootstrap
6. Setup your environment
   maven setup
7. Download the major dependencies for compiling the Project Sailfin code.
   maven bootstrap
8. Checkout the Project Sailfin code, including the tools!
   maven checkout-sailfin \     -Dsailfin.build.dependency.order=ssa-api,common,security,sip-stack,deployment,administration,clb,replication,integration,tools,docs
9. Build the Project Sailfin code, including the tools!
   maven build-sailfin \     -Dsailfin.build.dependency.order=ssa-api,common,security,sip-stack,deployment,administration,clb,replication,integration,tools
   One important thing to note: This step will attempt to download bits for NetBeans 6.0.1. If you aren't connected, this will probably fail.

If you look in SFWS/publish/glassfish/lib/tools/netbeans, you will see the nbm files... built fresh from the source!

You should probably note: these instructions are very similar to the Building SailFin without checking out and building Glassfish instructions.

Update: 22 Feb 2008... the value for sailfin.build.dependency.order needed to change for the checkout-sailfin step...

(2008-02-14 13:16:53.0) Permalink

Friday February 08, 2008

Finding Tools for Sailfin Has Never Been Easier

In the past, I have been sending folks to https://sailfin.dev.java.net/servlets/ProjectDocumentList to get the nbms for the SIP development tooling.

When the code got updated, I would do a build and stage the bits for folks to use. This created some extra work for me, but was a pragmatic solution at the time.

It wasn't a Pragmatic solution, though. I was creating the bits from my personal workspace. I was moving them into position by hand. And that bothered me.

I wanted the bits to be in a more accessible location. I wanted to get the bits to get to that "place" through a more controlled and repeatable process.

Today, we are half way there!

If you get today's nightly build of the project Sailfin code, you will find a new subdirectory tree under lib:

• tools
  • netbeans

The nbms that implement the SIP application development tooling are all there, ready to be installed into NetBeans.

(2008-02-08 10:03:29.0) Permalink

Monday January 14, 2008

NetBeans 6.1 and Project Sailfin

While work is being done on the modules that let users create and test SIP Servlet applications that can be deployed to a Glassfish domain that has been extended to support SIP, one of my teammates has been working on making these applications "visible". We have also been working on making the choice of which type of server to register in the IDE more obvious.

We committed many of the necessary changes over the weekend. If you get a recent nightly build of NetBeans 6.1, you should see the following changes:

1. Explicit reference to Sailfin in the 'Add Server Instance' dialog.
   
2. SIP Servlet applications are now visible in the Services explorer.
   

I was also able to install the latest available builds of the SIP Application Development module and the SIP Protocol Test Agent module into the NetBeans 6.1 build.

There is a fair number of code changes that have been going into NetBeans 6.1 to hit Milestone 1. These changes should finish baking this week. If you want avoid being on the absolute bleeding edge... you may want to wait for the NetBeans 6.1 Milestone 1 release. If you have serious thrill issues: Download, Fire up and Save Often.

(2008-01-14 22:40:58.0) Permalink Comments [1]

Monday January 07, 2008

SIP Application Development Module version 0.4 for NetBeans 6.0

Now that the holiday break is over, it is time to release a new feature in the SIP Application development module: the SIP Listener wizard.

You can find the wizard in the list of items that you can add to a Converged Servlet Application project, via the project's right click menu.

This is what the wizard looks like.

Here is a sample of the code that is generated, if you set the package to "a" and select the SipApplicationSession Listener check box and the SipServletListener check box.

package a;

/**
 *
 * @author vkraemer
 */
@javax.servlet.sip.annotation.SipListener
public class NewSipListener  implements javax.servlet.sip.SipApplicationSessionListener,
	javax.servlet.sip.SipServletListener 
{

    public void sessionCreated(javax.servlet.sip.SipApplicationSessionEvent sase) {
        throw new UnsupportedOperationException();
    }

    public void sessionDestroyed(javax.servlet.sip.SipApplicationSessionEvent sase) {
        throw new UnsupportedOperationException();
    }

    public void sessionExpired(javax.servlet.sip.SipApplicationSessionEvent sase) {
        throw new UnsupportedOperationException();
    }

    public void servletInitialized(javax.servlet.sip.SipServletContextEvent ssce) {
        throw new UnsupportedOperationException();
    }

}

The new build is available in the project's "document list" as version 0.4.

It has been tested a bit with NetBeans 6.0 and Sailfin build 15.

(2008-01-07 18:48:29.0) Permalink

Tuesday December 18, 2007

Using the Test Agent to Debug ClickToDial

I have a rough cut of a write up that describes using the Test Agent to debug the ClickToDial sample app. It is screenshot heavy and verbage light. Since this is a wiki page, please feel free to extend it as seen fit.

(2007-12-18 20:21:40.0) Permalink

Monday December 17, 2007

SIP Application Development Module Suite for NetBeans 6.0

I have been waiting for some issues to get resolved recently. A couple of them got cleared up in the last week which allowed me to get some updates to folks that are doing SIP application development.

I was able to make a couple minor changes to the development module.

• Updated the Servlet template to use Freemarker
• Converted the servlet to conform to the JSR 289 Public Review.
  Of course you know that JSR 289 just published their Public Review... right?
• Integrated the plumbing for context sensitive help.
  Now, if somebody would start to develop the content for that help.... please?
• Upgraded the generated sip.xml to conform to sip-app-1_1.xsd instead of sip-app_1_0.dtd.

You may have noticed that I said 'Suite' in the title. I am not trying to put on airs. Yvo Bogers contributed a new "module" that you can see in the list of available modules on the SailFin project's document list.

The new module is a collection of four NBM's that implement a SIP protocol level test agent. There is a document that describes the test agent functionality. You can use this this module to fire SIP requests and generate responses.

This test agent makes it possible to deploy and test the ClickToDial sample from inside NetBeans on a single computer and see the protocol level messages as they go through the SIP Servlets. Stay tuned for an updated version of the ClickToDial write up, with screen shots and the like, that shows you how to do this.

I have done all my recent testing in NetBeans 6.0.

(2007-12-17 19:19:26.0) Permalink

Wednesday December 12, 2007

Never 'Run' a Web App again!

No..

The last web app hasn't been developed... though some of the ideas that I have seen floated on TechCrunch seem like they are 'A Web App Too Far'. I am talking about how I "do" web-app development in NetBeans.

When you are debugging a Java application in NetBeans, you have the option to 'Apply Code Changes'. You can read this chapter of the NetBeans Field Guide about debugging that describes the 'Apply Code Changes' feature.

You can use this feature of the debugger to significantly reduce the number of times that you deploy a web app that has been targeted to GlassFish.

The best explanation is an example... [To play along at home, I recommend that you get NetBeans 6.0 and GlassFish V2.]

1. Start the IDE
2. Create a new Web Application project that targets a GlassFish domain. (I will call my project WA1 [double-u a one])
3. Create a new Servlet in the project.
4. Use the Debug item on the project's right-click menu.
   (This compiles the project code, starts the server in debug mode, attaches the NetBeans debug session to the server's JVM, deploys the web app and opens the browser on something like http://localhost:8080/WA1. When the browser opens, it will probably say something like "Hello World!" and the browsers title bar will probably say something like "JSP Page".)
5. Change the code in the servlet that you created two steps back from

       protected void processRequest(HttpServletRequest request, HttpServletResponse response)
       throws ServletException, IOException {
           response.setContentType("text/html;charset=UTF-8");
           PrintWriter out = response.getWriter();
           try {
               /* TODO output your page here
               out.println("<html>");
               out.println("<head>");
               out.println("<title>Servlet NewServlet</title>");  
               out.println("</head>");
               out.println("<body>");
               out.println("<h1>Servlet NewServlet at " + request.getContextPath () + "</h1>");
               out.println("</body>");
               out.println("</html>");
               */
           } finally { 
               out.close();
           }
       } 
   

   TO

       protected void processRequest(HttpServletRequest request, HttpServletResponse response)
       throws ServletException, IOException {
           response.setContentType("text/html;charset=UTF-8");
           PrintWriter out = response.getWriter();
           try {
               //* TODO output your page here
               out.println("<html>");
               out.println("<head>");
               out.println("<title>Servlet NewServlet</title>");  
               out.println("</head>");
               out.println("<body>");
               out.println("<h1>Servlet NewServlet at " + request.getContextPath () + "</h1>");
               out.println("</body>");
               out.println("</html>");
               //*/
           } finally { 
               out.close();
           }
       } 
   

   Notice that the changes are in the commenting style of the TODO line and the closing asterisk-slash...
6. Press the 'Apply Code Changes' icon in the Debug toolbar or use the Apply Code Changes item from the Run menu.
7. Switch to your browser and change the URL in the address bar from (something like) http://localhost:8080/WA1 to (something like) http://localhost:8080/WA1/NewServlet.
   At this point the browser should have something like

   Servlet NewServlet at /WA1
   

   in the main window and 'Servlet NewServlet' in the title bar.

FINE PRINT: This depends on a couple of very important things.

1. Directory deployment of web applications to Glassfish. If you turn off directory deployment, this will not work. The updated class needs to get to the right directory for the server to get the changed class file. Archive deployment put the class into directories under the domain's "root".
2. The web app needs to be "stand-alone". A web app that is deployed as part of an enterprise application project will not compile the code for the changed class into the directory where the server expects it to be. The build process of the enterprise application copies the class file of sub module to a special location, to meet the server's exploded application layout constraints.
3. Doesn't apply to classes that are part of a Java Library project that used by your web app. This is really similar to the difference between a stand alone web app and a web app inside an enterprise application project.
4. The change that you make to the class is fairly constrained. If your change "breaks the rules", the 'Apply Code Changes' processing will fail. The error message will look something like this

   The virtual machine does not support this operation: schema change not implemented
   /Users/vbk/NetBeansProjects/WA1/nbproject/build-impl.xml:616: ...
   /Users/vbk/NetBeansProjects/WA1/nbproject/build-impl.xml:232: ...
   BUILD FAILED (total time: 0 seconds)
   

   The class that you were trying to replace will be unharmed on the server. If you run into this type of error, you can just use the project's Debug item to recompile the project and redeploy it.

(2007-12-12 22:17:18.0) Permalink