Troubled By Using NetBeans to Slice Up GlassFish on Windows

I got caught up in a couple very interesting issues where three large bodies of code collide that I figure somebody out there would want to avoid. If you are doing development in the GlassFish project's codebase with NetBeans on Windows this entry may help you.

  • Issue: Building modules from within NetBeans fails due to file locking problems
    One example of this is the admin-cli module. The build script for the module updates the admin-cli.jar file, but that script fails if it is triggered from inside NetBeans.
    Probable cause
    The module that allows users to control an application server built from the GlassFish source code is probably using the jar when you run the build.
    Work Around
    Do not register the directory where the GlassFish module build scripts deposit jars as a platform root for your NetBeans development environment. NetBeans will open them to provide deployment and configuration support. In a Windows environment, this causes locking issues.

    If you need to to use NetBeans to deploy apps to an application server that you are actively changing (at ITS source code level), use a stable installation of the server as the platform. You can deploy applications to your "in-play" version of an application server by registering its domain as a remote instance.

  • Issue: Using Step-[In/Out/Over] doesn't behave the way I expect it to and some of the code ends up in 'Hidden Source' nodes in the NetBeans debugger's Stack window.
    I ran into this while debugging code that was in the package org.apache.catalina... I had set a breakpoint in the code and saw
    - Hidden Source Calls
     - SomeClass.java (line 71)
     - SomeOtherClass.java (line who-cares)
    - MoreCode.java
    - ...
    
    when I expected to see
    - SomeClass.java (line 71)
    - SomeOtherClass.java (line who-cares)
    - MoreCode.java
    - ...
    
    Things appeared to go south when I did a Step-over. I expected to see
    - Hidden Source Calls
     - SomeClass.java (line 72)
     - SomeOtherClass.java (line who-cares)
    - MoreCode.java
    - ...
    
    but got
    - SomeClasshandlingSystemErr.java (line x)
    - Hidden Source Calls
     - SomeClass.java (line 71)
     - SomeOtherClass.java (line who-cares)
    - MoreCode.java
    - ...
    
    Probable Cause
    The J2EE Debugger module. This module does a lot of fancy footwork to optimize the debugging experience for folks that are developing J2EE and Java EE application with NetBeans. One of the things that helps these folks is hiding the stack frames that are from the middleware layer. This isn't very helpful to folks that are actually debugging that same middleware layer.
    Work Around
    Finish your current debug session and disable the module. You can do this with the Module Manager, opened by selecting the item of the same name from the Tools menu.
    I have always restarted the IDE at this point, too. 
    That may not be necessary, but I do it anyway.
    
Comments:

Post a Comment:
Comments are closed for this entry.
About


Vince Kraemer writes the entries in this blog.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News
Blogroll

No bookmarks in folder

automarks