Dan, could you please help with this?

Can't it happen that you put some invalid breakpoint? (indicated by broken icon)

Itried it with (Build 200806230002) on glassfish v2 and debugger normally hit my breakpoint in doFilter() method...

"gtzabari", could you please provide further information? Can you provide the source code - On what line have you put
the breakpoint? 

I'll reply by the end of the week. Unfortunately I'm busy with work which is due by tonight ;)

Sorry it took me so long to reply. I can confirm that the latest dev build of Netbeans allows breakpoints in doFilter()
but init() will always fail. Please confirm if you see the same on your side.

Reassigning to debugger.

I've reproduced the behavior, breakpoints in doFilter() are hit, but in init() are not.
Even when I submit method breakpoints on all methods in the Filter implementation class, first method breakpoint is hit
on doFilter(), not on init().

From that it looks like the debugger submits the breakpoint after init() is executed. Will investigate further...

Moving to web module.

Filter.init() is called during deployment *BEFORE* debugger is started. Therefore debugger can not stop there.
nbjpdaconnect task is called cca 250ms *after* Filter.init() - "connect-debugger" target in build-impl.xml.

Not sure whether "jspdebug" is the correct component, it's basically about build-impl.xml of Web module and
deployment/debug sequence.

Can someone in the web team please confirm whether the problem is in this component and whether you plan on fixing it in
6.5? Thank you :)

*** Issue 148528 has been marked as a duplicate of this issue. ***

See Issue 148528 as it explains exactly how to workaround, but also that it should be possible to fix it to debug
normally whether this is jspdebug or web. 

Per:
http://wiki.netbeans.org/BugPriorityGuidelines#section-BugPriorityGuidelines-P2

I'm upping the priority. For those of us who use the debugger and know we can start the server in debug mode, connect to
it, then deploy our module and test it this is a practical workaround, so for me it wasn't such a show stopper or in my
face issue, but for a quite a number of folks I think this would be a difficult workaround without it being documented,
but then where would it be documented so they can find the solution without first spending a couple hours or more trying
to figure out the issue.

Petr H, could you please investigate? Thanks.

This would need debugger to connect to server before the app is loaded. Unfortunately the deploy task performs three
actions: starts server (if needed), undeploys app (if there is the old version) and deploys the new one. The debugger
would have to connect just before the third step (otherwise it could hit breakpoints in the old app).

As the deploy code is one big chunk of tightly connected code without any reasonable test I wouldn't to fix few weeks
before the release - high probability of regressions. Anyway this issue has to be there for several releases, but
reported just twice. Plus the WA exists.

Any other opinions?

Previously existing yet only mentioned twice really isn't a good thought when thinking of quality and project survival
though. What about the guy who might have run into the issue, didn't know to do what I did, spent hours trying to get it
to work, and instead picked up a different IDE? 

Not being harsh, just honest, but the health of the project is based on users, and those users perceptions dictate
whether they are users or not, and death by a 1000 needles isn't a good experience for anyone including the project and
developers, and enough workarounds and we soon have 1000 needles.

Not saying that is what you are advocating. You may just mean to let it slide to the next release and fix it, and that
is understandable, but I believe it is in everyone's best interest that it remain a P2 and be able to be fixed in the
next release instead of existing into another, and I simply point to death by 1000 needles as a good enough reason as it
affects quality, and again, not preaching, but just examining it from a realist perspective. 

What if it were the straw that broke the decision makers back in a company where NB is the main IDE, it's a large
company, and they would be willing to purchase support from Sun? That would hurt everybody.

Wade,
I agree with you. I've never said it should be P3 and I've never said it shouldn't be fixed in the next release. The
thing we have to consider is: Do we want to make the major code change right now - the change that can easily introduce
P1 regressions which will be definitely more visible? Nothing more.

I understand your concerns about the guy who run into this issue and this issue should be fixed. I'm just trying to be
pragmatic - do we want to take the risk (maybe we do)? I just provided the evaluation, possible consequences and facts
about the duplicates. I even didn't say we shouldn't fix it and intentionally didn't lower the priority.

Your point about decision maker is right, but it can be applied to any bug of any priority.

Sure. That is why I made it a point to say you may not even be advocating specific things, and that it is understandable
to skip this release. I agree it can be applied to any bug, just that sometimes, and again not saying anyone
specifically does it on purpose, bugs fall through the cracks when they get pushed. So, I just wanted to stress
(re-stress?) the importance of quality related issues even when a workaround exists, and the need for them to be addressed. 

Thanks for evaluating the issue by the way :-D. I should have ended my last comment with that statement. I think you and
the rest of the NB team do an outstanding job.

I agree with both of you. I understand why this is unlikely to make it into 6.5, but I would appreciate you fixing it
very soon after that release because I honestly run into this use-case about once a week, needing to debug Filter.init().

In short, I would feel better about this if you set target milestone to the next release instead of "future" because
I've seen countless issues disappear into that black hole before ;)

I think this issue may be misfiled, since it is not about breakpoints set in JSP. I think the right component may be
debuggercore. Changing component to debuggercore.

Reassiging to issues@debuggercore.

Moving back.
I've already wrote that the debugger can not catch that breakpoint, since it's started too late.

<snip>
Unfortunately the deploy task performs three actions: starts server (if needed), undeploys app (if there is the old
version) and deploys the new one. The debugger would have to connect just before the third step (otherwise it could hit
breakpoints in the old app).
</snip>

phejl and/or mentlicher, could you provide more detail on how we would make this change? Is it a change we would make in
the web.core or web.debug modules? Marking incomplete.

The change probably has to be made to the action itself. Look into ant script (build-imp.xml) of web project. You will
see something like this:

    <target
depends="init,compile,compile-jsps,-do-compile-single-jsp,-pre-dist,-do-tmp-dist-with-manifest,-do-tmp-dist-without-manifest"
description="Debug project in IDE." if="netbeans.home" name="debug">
        <nbdeploy clientUrlPart="${client.urlPart}" debugmode="true"/>
        <antcall target="connect-debugger"/>
        <antcall target="debug-display-browser"/>
        <antcall target="connect-client-debugger"/>
    </target>

You can see that debugger is connected *after* application deployment - so the debugger can't stop in init methods
(these were already executed in that time).

The nbdeploy task performs app server start (if needed), undeployment of the old version (if any) and deployment of the
new application. So you need to split the task or allow it to execute the connect target before the deployment (or at
least before starting the app - I'm not whether these two phases are clearly separated on all servers - I think they are
not :/ ). The starting point for you is *j2ee.ant* module that will quickly lead you to *j2eeserver* where you will find
the Deployment.deploy(). As you see the API is one big action. So you need this split or allow co execute the connect
debbuger task before the deployment.

This is not an easy task.

*** Issue 73450 has been marked as a duplicate of this issue. ***

Mostly a deployment issue, so assigning to Thuy.

Modified the order of the tasks in the "debug" target to make sure the server is connected to a debugger before a web
app is deployed as follows:
1. Start server (if needed)
2. connect the server to a debugger
3. deploy the web app
 
changeset: http://hg.netbeans.org/main/rev/e6c579d13c90