Java Debugging Deployed Glassfish @PostConstruct Unable to Debug

Question

I can debug a Java application in NetBeans and have debugged other projects in NetBeans. However, when deploying a Singleton in Glassfish and setting a breakpoint on the @PostConstruct annotation I am unable to debug. I have set the target server to debug on and I set the breakpoint where the debugger should debug from and I start the server in debug mode. However, I am still unable to debug in NetBeans. Below is the code:

@Startup
@Singleton
public class Listener {

    @PostConstruct
    public void init() {
        System.out.println("init");   
    }
}

I set the breakpoint on the System.out.println("init") statement. The steps that I follow are:

1) Build Jar file 2) Start Glassfish server 3) Deploy the Jar file 4) Start the server in Debug mode 5) The "init" is printed in the Console in NetBeans but I am unable to debug.

I have tried attaching a debugger on many different ports, but I either get connection refused or it can't debug.

I am using NetBeans 1.7.2. I have tried the same with other versions of NetBeans but still the same problem.

The above is only a sample code, but there is more code but I am unable to debug. I can't find any solution on Google.

Could you give this a try?

Answer 1

You have to:

1. Start server in debug mode (when it start's dt_socket port is printed)
2. Attach debugger Debug -> Attach Debugger...
3. Set breakpoint
4. Deploy your app

@PostConstruct is called during deployment, so the order of steps you provided is incorrect, because the code is invoked before you attached to debugger.

Answer 2

Did you try this with eclipse? As I remember, I had no problem in debugging the @PostConstruct method in eclipse.

On more thing to mention: - A @Singleton bean lives as long as your application lives on the server... So if you want to debug its @PostConstruct, I would suggest opening the glassfish server console, and using the disable application option from console... until that, the @PostConstruct won't be called, since the bean is container managed...