[GLASSFISHPLUGINS-348] Debugger is broken for deployed Glassfish Application Created: 08/Nov/11  Updated: 04/Feb/14

Status: Open
Project: glassfishplugins
Component/s: eclipse
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: crazytrain411 Assignee: Unassigned
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: 1 minute
Time Spent: Not Specified
Original Estimate: 1 minute
Environment:

Glassfish 3.11
Windows 7
JDK 1.6 update 29 both 32 and 64 bit


Tags: debugger, deploy, domain, glassfish, plugin

 Description   

When deploying a glassfish application through the Eclipse plugin, the debugger is not working in the following ways:

-Does not highlight and bring up the current thread and code for the breakpoint
-Can not step through code

This happens only when running the application after:
-Deleting the contents of the folder folder glassfish\domains\<domainname>\eclipseApps
-Right clicking the domain and selecting X Remove while the application is running and stopping the application
-Running the application for the very first time (assuming this would happen since there is nothing in eclipseApps but did not reproduce)

This bug seems to be related to the bug http://java.net/jira/browse/GLASSFISHPLUGINS-347
where the application starts twice. It seems when the application does NOT start twice, the debugger is broken.



 Comments   
Comment by crazytrain411 [ 18/Nov/11 ]

Also note the issue happens with Eclipse Indigo.

I have also tested 32 bit JDK update 26 and it also happens there. Any help regarding this issue would be greatly appreciated.

Comment by eduardohbcs [ 01/Dec/11 ]

Just adding a note that I'm using version 4.2.0.201111040904 of the plugin and I also hit the same issue.

My environment is:
Windows 7
64-bit JDK 1.6 update 27
Glassfish 3.1.1 (build 12)
Eclipse Indigo sr1 (build id 20110615-0604)

This issue is really painful and as crazytrain411 stated, attention to this issue would be highly appreciated.

Comment by crazytrain411 [ 01/Dec/11 ]

Here are my latest findings regarding this issue. I'm also able to consistently reproduce with the following in addition to the two methods described above.

1) The debugger gets broken if there is a spring bean definition error and deployment fails. Upon fixing the error and running again the debugger is in a broken state.

2) If there are breakpoints set in a class and the class signature is changed the debugger will be in the broken state until the breakpoints are removed and the application is run again.

Comment by crazytrain411 [ 05/Dec/11 ]

Here is another thought:

We know that the glassfish application starts twice after a clean&build, and only once if no code was changed.

I realized that on the first deployment its running the old code from the previous version. Is the Jvm debugger not able to hook in properly because of the old code on the first deploy?

It seems to come up and hang without opening the threads at that first deploy.

Comment by georgem4 [ 16/May/12 ]

We have hit the same problem, all three developers.
Actually, we never got it to work without running the server twice.

Comment by crazytrain411 [ 06/Jun/12 ]

Found a workaround for this ridiculous bug. Thanks Glassfish guys for being useless to help with this for 7 months.

Close the debug view and reopen it, done.

There is a link between eclipseApps directory and the <application> block in domain.xml. Its horribly broken.

Goodbye

Comment by eduardohbcs [ 07/Jun/12 ]

This worked for me too.

There seems to be an UI portion of this issue. The debug view tab gets completely 'out of sync' with the debugger ...

Comment by adi3000 [ 29/Jul/12 ]

For information this issue seems to be cross platform. With my platform (from Sun) , debugging is very painfull. Even with removing the Debug view and reopen it

Eclipse 3.8
Sun JDK 7u3 (even with openJDK 6u29)
Glassfish 3.1.2
Eclipse Glassfish Server Tools 2.0.1

I can't trace properly my debugging, just approximatively follow with random F8/F6 and close reopen debug view. It not helping at all.
If somebody could help on it or find a workaround

Thanks

Comment by kithouna [ 15/Apr/13 ]

Any progress on this issue? I very frequently encounter this on OS X using Eclipse 3.7 and GlassFish 3.1.2.2. After starting server in debug mode and when the first break-point hits, the stack in the debug mode is not unfolded. I have to infold it manually. After I do so, clicking on the stack frame where the break occurred does take me to the source file and correct line, but the debugger does not respond to any command. The only thing that succeeds is disconnecting from the debugger.

I need to stop GlassFish and restart Eclipse to be able to debug again. Sometimes it then hangs in the same way and I have to disconnect, stop, restart Eclipse again and sometimes even three times in a row.

This issue makes using GlassFish for an Eclipse user almost impossible and VERY frustrating!

Comment by adi3000 [ 15/Apr/13 ]

It seems that when I use a real glassfish server problem does not occurs. I don't know if it still the case, but if so the server built in eclipse glassfish plugin may be involved instead of glassfish itself.

For me it's been a long time that I gt this problem, but it's also have been a long time that I do not use my glassfish server.

Comment by arjan tijms [ 17/Apr/13 ]

This is very common issue. I always use a real Glassfish as well, and I too do encounter it.

I have a feeling though that this is a UI race condition. If I'm in the Java EE perspective when the breakpoint is reached, Eclipse has to switch to the Debug perspective and open the stack at the right position. It frequently hangs here.

If however I'm already in the Debug perspective and have also already opened the debug server so that all threads are rendered then the chance that it hangs seems to be much smaller. I'm not using Glassfish on a daily basis, so this is from a few observations only, but maybe it helps.

Comment by arjan tijms [ 17/Apr/13 ]

p.s.

I encountered these hangs on both Mac OS X (10.7.5) and Ubuntu (12.04 and 12.10).

Comment by piotrik [ 19/Apr/13 ]

Guys I am really confused about this bug. Some of you are encountering it always and some of you "only" frequently. I have tried similar steps as you described for some of the official glassfish examples but I could not reproduce it. Could you describe the type of app you are experiencing the problem with and describe detailed step-by-step instructions how to reproduce it. If these instructions would work for some of the example apps from http://glassfish-samples.java.net/, it would be best.

Comment by arjan tijms [ 04/Feb/14 ]

Could you describe the type of app you are experiencing the problem with and describe detailed step-by-step instructions how to reproduce it.

It's just any type of application. A new dynamic web project in Eclipse with one servlet in it may already cause the hang. It could debug for a while in GlassFish, now every time I try to debug the debugger hangs.

Visually it's always the same as mentioned above.

Although I'm fairly sure the application itself doesn't matter (I've seen it happening with too many totally different ones), I'm currently experiencing it with this app: https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/basic-authentication

(import it as Maven project, then deploy it to GlassFish)





[GLASSFISH-17719] Debugger is broken for deployed Glassfish Application Created: 14/Nov/11  Updated: 23/Feb/14

Status: Open
Project: glassfish
Component/s: ide-integration
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: crazytrain411 Assignee: vince kraemer
Resolution: Unresolved Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.11
Windows 7
JDK 1.6 update 29 both 32 and 64 bit


Tags: 3_1_2-exclude, debugger, deployment, domain, glassfish

 Description   

When deploying a glassfish application through the Eclipse, the debugger is not working in the following ways:

-Does not highlight and bring up the current thread and code for the breakpoint
-Can not step through code

This happens only when running the application AFTER:
-Deleting the contents of the folder folder glassfish\domains\<domainname>\eclipseApps
-Right clicking the domain and selecting X Remove while the application is running and stopping the application
-Possibly when Running the application for the very first time (did not reproduce)

This is an extremely frustrating bug and a potential blocker, re-posted here because of no response on Eclipse plugins and help is needed.



 Comments   
Comment by crazytrain411 [ 14/Nov/11 ]

I'm pretty sure I've seen it other cases but these are the ones we have reproduced with consistency.

Comment by crazytrain411 [ 01/Dec/11 ]

Here are my latest findings regarding this issue. I'm also able to consistently reproduce with the following in addition to the two methods described above.

1) The debugger gets broken if there is a spring bean definition error and deployment fails. Upon fixing the error and running again the debugger is in a broken state.

2) If there are breakpoints set in a class and the class signature is changed the debugger will be in the broken state until the breakpoints are removed and the application is run again.

Comment by eduardohbcs [ 01/Dec/11 ]

I'm also facing the same issue in both ways described.

My environment is:
Windows 7
64-bit JDK 1.6 update 27
Glassfish 3.1.1 (build 12)
Eclipse Indigo sr1 (build id 20110615-0604)
Glassfish Plugin (Oracle Glassfish Server Tools) version 4.2.0.201111040904

This issue is really painful and hurts productivity ...

Comment by sinago [ 06/Dec/11 ]

Same environment as eduardohbcs with the same problem. Productivity has been brought to a halt due to this issue.

Comment by lgraf [ 12/Feb/12 ]

We are also facing this issue with the latest version of the Oracle GlassFish Server Tools (1.7.3.201106220649).

Steps to reproduce:
1. Debug app on server.
2. Debugging work as expected.
3. Undeploy app (remove from server).
4. Stop server.
5. Debug app on server again.
6. Debugging doesn't work properly (thread doesn't get the focus). At this point only manually focusing the thread after each step helps.

This is really a productivity killer. Any plans when this will get fixed?

Also iam a bit confused about the glassfish plugin project http://java.net/jira/browse/GLASSFISHPLUGINS. Is this the JIRA for the eclipse pluign: http://marketplace.eclipse.org/node/867? Iam asking because the versioning in JIRA seems to be different (does not contain the latest version (1.7.3) from the marketplace/updatesite).

Comment by kumara [ 13/Feb/12 ]

-> ide_integration sub-component

Comment by crazytrain411 [ 24/Feb/12 ]

Its been 4 months since the issue was reported. There's 6 participants and 9 votes. Can this at least be looked at?

If more information is required please specify.

Comment by crazytrain411 [ 06/Jun/12 ]

Found a workaround for this ridiculous bug. Thanks Glassfish guys for being useless to help with this for 7 months.

Close the debug view and reopen it, done.

There is a link between eclipseApps directory and the <application> block in domain.xml. Its horribly broken.

Goodbye

Comment by idididid [ 11/Jun/12 ]

Hello, I am facing the same problem.

I noticed few more things:

On the Debug view, in my stack trace, I found the exact class with the breakpoint is paused and it had this comment: "(Suspended breakpoint at line XX)". When I clicked the line, suddenly the green line appeared. Yet, as soon as I clicked F6 to continue, It went out of sync again, just the next line became suspended. Weird.

I checked the processes running on my computer and found that there are several "java.exe" processes running at the same time. (eclipse runs on javaw.exe). After further investigation I found out that when there is only one "java.exe" running - everything works fine and I am able to debug. Then, restarting the server creates sometimes a new "java.exe" and this is the point where I can't debug anymore. Maybe eclipse got confused...

Any thoughts?

Ido

Comment by adi3000 [ 29/Jul/12 ]

For information this issue seems to be cross platform. With my platform (from Sun) , debugging is very painfull. Even with removing the Debug view and reopen it

Eclipse 3.8
Sun JDK 7u3 (even with openJDK 6u29)
Glassfish 3.1.2
Eclipse Glassfish Server Tools 2.0.1

I can't trace properly my debugging, just approximatively follow with random F8/F6 and close reopen debug view. It not helping at all. Seems to be the same issue than idididid
If somebody could help on it or find a workaround

Thanks

EDIT : Find a better workaround : using another glassfish server (not the one included with Glassfish plugin ), I've maid a proc on my redmine :

http://code.a-dream-zone.com/redmine/issues/26

Workaround : Use another glassfish server than the one include on eclipse plugin
1- Download http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/release/glassfish-3.1.2.zip
2- Unzip anywhere you want (ie : on your workspace)
3- On Window > Preference > Server > Runtime Environment clic on Add...
4- Choose GlassFish Server Open Source Edition 3 (Java EE 6)
5- Check Create a new local server (to display it below Internal Glassfish Server
6- Use the proper JDK (jdk1.7.0_03)
7- Application Server Directory : /path-to-your-workspace/glassfishv3/glassfish (must be the glassfishv3/glassfish directory of the place where you unzip your glassfish server), then click next
8- Leave Administration Id and password as default (admin and blank password), check than Domain Directory follow path to glassfishv3/glassfish/domains/domain1
9- Click on finish, the new server should have appeared as GlassFish Server Open Source Edition 3 (Java EE 6) on your Server view

Deploy your application as you've done under Internal Glassfish 3.1.2 (dont forget to check the runtime environment of each project to be using the right server libraires)

Comment by adi3000 [ 30/Jul/12 ]

4- Choose GlassFish Server Open Source Edition 3 (Java EE 6)

Excuse me for this mistake but I was using a 3.0.1 server first and then upgrade it to 3.1.2. It does not seem to be the same thing as when I just erase my server to perform my tutorial, I found that glassfish modules lib are not the same. So instead of using Open Source Edution 3, use the Glassfish 3.1.2 (obvious isn't it ?)

Good luck for the rest

Comment by xiul [ 19/Aug/13 ]

Idob from stackoverflow.com found a workaround, I test it and it works for me, I'm using glassfish 3.1.2.1 with the eclipse (STS) extension 3.1.2 and jdk 7

source: http://stackoverflow.com/questions/10685361/eclipse-skipping-breakpoints

"Set remote debug

1. Go to your glassfish admin console and set your glassfish to work on debug mode.
Click on configuration --> server-config --> JVM settings, and check debug enabled check box.
Restart server

2. In eclipse - start server on normal mode (not debug - it is useless).

3. Go to Debug configurations and locate "Remote Java Application"

4. Create a new Remote java app debug config

5. Enter name (lets say Glassfish-Debug)

6. Choose project to debug

7. Enter your own IP address in the host section and set the port to 9009

That's it. Now all you have to do is always start your Glassfish in normal mode and then go to Debug configurations and run This Glassfish remote debugging you just set.

And now I'm getting to the annoying part: After rebuild your project, sometimes you might get again out of sync. You just need to disconnect the remote debugging session and run it again. Small price to pay.

I hope it helps."

Comment by arjan tijms [ 23/Feb/14 ]

Just for everyone's information, this issue is still current with GlassFish 4.0 and the latest server runtime as of the time of writing. Tested on OS X and Ubuntu.





[ADFEMG-39] Run large ADF jspx page in debug mode, get error "java.lang.InternalError: name is too long to represent" Created: 27/Jul/12  Updated: 25/Aug/12  Resolved: 25/Aug/12

Status: Closed
Project: adfemg
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Kevin Angus Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Originally encountered on JDeveloper 11.1.1.6 on Mac OS X 10.7.4.


Status Whiteboard:

Weblogic bug 9211308: Status 11 - Code Bug (Response/Resolution)

Underlying Java bug 6294277 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6294277
Fixed in JDK8.

Tags: debugger, error, jdeveloper

 Description   

Running an ADF app from JDeveloper in debug mode, when navigating to an ADF jpsx page over a certain size the following error appears:

<LifecycleImpl> <_handleException> ADF_FACES-60098:Faces lifecycle receives unhandled exceptions in phase RENDER_RESPONSE 6
javax.faces.FacesException: javax.servlet.ServletException: java.lang.InternalError: name is too long to represent
	at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:415)
	at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
	at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
	at oracle.adfinternal.view.faces.config.rich.RecordRequestAttributesDuringDispatch.dispatch(RecordRequestAttributesDuringDispatch.java:44)
	at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
	at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
	at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44)
	at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$OverrideDispatch.dispatch(FacesContextFactoryImpl.java:267)
	at com.sun.faces.application.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:469)
	at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:140)
	at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:189)
	at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:193)
	at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._renderResponse(LifecycleImpl.java:911)
	at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:367)
	at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:222)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
	at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
	at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
	at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
	at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.adf.share.http.ServletADFFilter.doFilter(ServletADFFilter.java:62)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:205)

Browser is blank.

When the same actions are performed not in debug mode, no error appears and the page works as expected.

According to MOS note 1076679.1,

This is a bug in the Sun JDK, and, as such, there is not a specific fix from Weblogic. There are a few suggestions for workarounds:

  • Break up the large JSP to compile separately and put together with 'include' tags
  • Compile with JRockit, which does not have this issue
  • Compile without -Xdebug

I believe JRockit is not recommended to be used in development. I resolved the issue by partitioning my page using jsp:include and fragments, reducing its size.



 Comments   
Comment by duncanmills [ 27/Jul/12 ]

Is this page composed of regions & task flows or is it just one big page assembled with jsp:includes?
The problem with the latter approach is that you'll have to do a lot more work in the future if you want to migrate off the JSP engine onto Facelets.

Comment by Kevin Angus [ 27/Jul/12 ]

Hi Duncan,

It was previously just a large, page with neither regions nor includes. I do use task flows as popups but the main functionality of the page is complex and doesn't necessarily suit the use of regions.

I have a number of popups defined in the page under the af:form element so I simply moved them all into a fragment file referenced by an include, to see if it worked around the bug. It did so I am happy for the moment but will plan in time to look at further refactoring the page, perhaps with regions if I identify any opportunities for this.

Cheers,

Kevin

Comment by duncanmills [ 27/Jul/12 ]

Another issue is to look for repetition on the page. That may indicate the opportunity to use some declarative components or iteration to cut down on the duplication.
My gut feeling is that if the page is getting this large there is something wrong in some way - either in the required design / information density which may not be your fault or some issue of duplication as above.
The last time I encountered this issue it was a duplication problem and everything was so much easier to maintain once we're derived a declarative component to represent that information in a simple concise tag.

Comment by Kevin Angus [ 27/Jul/12 ]

I already use a lot of iteration actually. It is a very functionally rich screen for advanced users so will always be on the large side I suspect. The page has to some extent evolved to this size as more features have been added. I believe I have implemented these features in an efficient manner, however, I take your point, the potential for refactoring is no doubt there. I will include adding declarative components as something to look into during this process. Cheers.

Comment by chriscmuir [ 06/Aug/12 ]

If there's no update to this issue in a week's time I'll close it as resolved.

CM.

Comment by chriscmuir [ 25/Aug/12 ]

Issue closed.





Generated at Fri Jul 03 08:50:17 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.