I'm migrating my project from play 2.2.3 to 2.3.8. This went good so far with a little bumps on the road. The only remaining issue is that I just can't run Activator/Play in debug mode. It runs fine without debug though.
I'm using:
activator -jvm-debug 9999 run
My app runs fine and Eclipse debug binds to to port 9999 as expected. But unfortunately it never stops for a checkpoint.
My impression is that the debug is only activated for the JVM that runs Activator, but not the JVM that runs my app, although I have no evidence for this, since my knowledge about Activator isn't advanced enough (I just read somewhere that activator starts a new JVM for each app).
This is because Activator / Play 2.3.8 performs forking of the run process without copying of the debug options. You can cancel forking in your build.sbt:
fork in run := false
Or alternatively you can specify the Java debugging options there:
javaOptions in run +=
"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9999"
With the latter you don't need the -jvm-debug in the activator command line.
I set the
fork in run := false
in my build.sbt.
It did not stop on my breakpoint in the run() method of my Controller subclass. Although later breakpoints are hit when I hit a URL and a RESTful service is hit.
Might this just be a timing issue? I am probably not fast enough to get the debug start, as it uses Standard (socket attach) method so Play has to start before the listener is there. Wondering how you debug the methods that get hit when startup occurs?
Related
I have created several tests for a Polymer web component.
The tests are written according to the guidelines provided in polycast #36.
When I run the tests with Web-Component-Tester locally, all is fine and my tests pass.
When I run the tests in a local browser (chrome and firefox) all is fine.
I've also set up Travis-CI and Sauce Labs for automated testing.
Travis can run WCT locally in the shell. This works perfectly and my tests pass.
However when WCT is run with the sauce plugin enabled, and the tests are run on the sauce labs browsers, ONLY the async tests fail.
My test is waiting for a JS-event to be fired.
I presume the event is never received.
The output from WCT is not really helpful.
It just complains that the done() method is never called.
Does anyone else experience the same problems with WCT and Sauce Labs?
If so, does anyone have a solution for these async tests?
Edit 1:
I should add that my component wraps a native websocket.
The async tests wait for websocket events that are refired by the component after it catches the websocket event.
The issue might have something to do with Sauce Labs' SSL Bumping.
I could not figure out why the external connection fails when run in a Sauce browser.
The solution is to stub the websocket connection such that only the wrapper gets tested instead of the wrapper + websocket.
An aditional advantage to stubbing is of course that the tests run way faster.
I am just getting started with Packer, and have had several instances where my build is failing and I'd LOVE to log in to the box to investigate the cause. However, there doesn't seem to be a packer login or similar command to give me a shell. Instead, the run just terminates and tears down the box before I have a chance to investigate.
I know I can use the --debug flag to pause execution at each stage, but I'm curios if there is a way to just pause after a failed run (and prior to cleanup) and then runt he cleanup after my debugging is complete.
Thanks.
This was my top annoyance with packer. Thankfully, packer build now has an option -on-error that gives you options.
packer build -on-error=ask ... to the rescue.
From the packer build docs:
-on-error=cleanup (default), -on-error=abort, -on-error=ask - Selects what to do when the build fails. cleanup cleans up after the previous steps, deleting temporary files and virtual machines. abort exits without any cleanup, which might require the next build to use -force. ask presents a prompt and waits for you to decide to clean up, abort, or retry the failed step.
Having used Packer extensively, the --debug flag is most helpful. Once the process is paused you SSH to the box with the key (in the current dir) and figure out what is going on.
Yeah, the way I handle this is to put a long sleep in a script inline provisioner after the failing step, then I can ssh onto the box and see what's up. Certainly the debug flag is useful, but if you're running the packer build remotely (I do it on jenkins) you can't really sit there and hit the button.
I do try and run tests on all the stuff I'm packing outside of the build - using the Chef provisioner I've got kitchen tests all over everything before it gets packed. It's a royal pain to try and debug anything besides packer during a packer run.
While looking up info for this myself, I ran across numerous bug reports/feature requests for Packer.
Apparently, someone added new features to the virtualbox and vmware builders a year ago (https://github.com/mitchellh/packer/issues/409), but it hasn't gotten merged into main.
In another bug (https://github.com/mitchellh/packer/issues/1687), they were looking at adding additional features to --debug, but that seemed to stall out.
If a Packer build is failing, first check where the build process has got stuck, but do the check in this sequence:
Are the boot commands the appropriate ones?
Is the preseed config OK?
If 1. and 2. are OK, then it means box has booted and the next to check is the login: SSH keys, ports, ...
Finally any issues within the provisioning scripts
I want to run my playN game in production mode as the development mode is too slow to test. I am not able to click and get the response for buttons and it updates very slow in dev mode. I have read that substituting the IP of the link with "localhost" will do. But even after i have done the same, It is too slow like before.
I need to run the html version only. How can I do this?
You should try running it having the test-html profile active. From PlayN's getting started page:
cd playn-samples/showcase
mvn clean package
mvn test -Ptest-html
Then just browse to http://localhost:8080/ once Jetty has started. I find it significantly faster than development mode. Just substitute the showcase with your own application.
I have a complex, pre-existing Actionscript project to work with at my current employer. The project was originally created with FlashDevelop, which is not an option for me as a Mac user. I can successfully build the project and deploy it to others. It runs as expected.
The problem is with the debugging. I cannot make it work. I believe users of Flash Builder on Windows machines have successfully debugged this project on their machine. I can build and debug projects I make myself. It's THIS particular project, or something about how it is constructed, that is preventing debugging from occurring.
Symptoms:
Starting the program via the Debug button runs the program, but the presence of a breakpoint causes the program to freeze the browser where it is running
Removing the breakpoint or stopping the debugger allows the browser to unfreeze and continue normally
At no point does the breakpoint actually get reached and break into the debugger
Attempting to place a breakpoint during execution results in an internal error: java.lang.NullPointerException
Example log message from within .metadata/.log
java.lang.NullPointerException
!STACK 0
!MESSAGE Error processing debugger commands
!ENTRY com.adobe.flexbuilder.project 4 43 2011-08-24 13:35:07.404
at java.lang.Thread.run(Thread.java:680)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.run(FlexDebugTarget.java:793)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.eventLoop(FlexDebugTarget.java:732)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread$1.run(FlexDebugTarget.java:752)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.access$7(FlexDebugTarget.java:642)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.advanceStateMachine(FlexDebugTarget.java:668)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget$FdbThread.installDeferredBreakpoints(FlexDebugTarget.java:637)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget.access$4(FlexDebugTarget.java:1006)
at com.adobe.flexbuilder.debug.model.FlexDebugTarget.instantiateBreakpoint(FlexDebugTarget.java:1012)
at com.adobe.flexbuilder.debug.breakpoints.FlexLineBreakpoint.instantiate(FlexLineBreakpoint.java:465)
at com.adobe.flexbuilder.debug.breakpoints.FlexLineBreakpoint.findSourceFiles(FlexLineBreakpoint.java:412)
Attempted Fixes:
Cleaned project
Cleared browser cache
Tried different browsers (Yes, I have the debug player)
Deleted .metadata
Deleted workspace
Reinstalled Flash Builder
Reinstalled Debug Flash Player
Restarted Mac
Tried a different SDK
Reordered Java preference for both 32 and 64 bit configurations
Removed symlinks from project configuration (that is, symlinks are no longer needed to correctly find the build or run location)
Cleared Flash logs
Ensured no more than one version of the program was getting compiled (so it can't actually be running from another location)
Explicitly turned on debugging through compiler argument: -debug=true
Changing just about every relevant and lots of irrelevant settings within Project Properties
Project Details:
Interestingly, clicking on Actionscript Applications in the Project Properties results in Flash Builder immediately becoming unresponsive
Uses third-party libraries for functionality that may or may not be Debug builds
Uses third-party code for functionality that is included with the rest of the code via Actionscript Build Path > Source path (note that this folder must be included explicitly for this project even though the path included is already in the source directory)
Runs from a local web server, accessing local database using a custom domain that is not "localhost" nor an IP address (changed for Chrome cookie issues), rather it looks like http://programname.local/
Launch configuration starts the web browser at the correct local url (as opposed to starting up from a file), probably irrelevant
There is one additional compiler argument that simply creates a global, compile-time constant, probably irrelevant
Source and project directories contain svn repository folders and files, probably irrelevant
I have an NDA, so I can only talk about the project and its structure, I can't post code
Configuration:
Mac OS 10.6.8
Flash Builder 4 (through CS5)
Flex SDK 4.0 and 4.5.1
Figured it out. Our app uses a preloader which I had always gotten from others. I had assumed it was compiled to debug because I always got my copy from our debug server. I didn't fully understand how it worked or what it was doing.
Due to a Flash error in the preloader, this morning I was forced to compile it for the first time. Compiling it normally (as debug) I realized the problem with non-debug swfs loading debug swfs might apply here.
Breakpoints worked as expected once I correctly compiled the preloader and fixed its bug. Apparently our preloader is doing the actual loading of the main app. Flash Builder apparently can't handle this setup (non-debug loading a debug swf), whereas FlashDevelop apparently can.
Have you tried restarting your Mac?
I feel your pain, and your list of attempted fixes are what I'd try first :)
I had a similar situation to this and after hours of cursing Adobe I restarted my Mac and that solved it (probably some kind of memory error).
I'm using NetBeans and GlassFish 3.0.1 to create an EJB3 application. I have written a few Unit Tests, which get run via JUnit and make use of the embedded GlassFish. Whenever I run these tests on my development machine (so from within NetBeans), it's all good.
Now I would like to let Hudson do those tests. At the moment it is failing with lookup failure on a resource (in this case the datasource to a JPA persistance unit):
[junit] SEVERE: Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method
[junit] java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'mvs_devel' in SerialContext
After searching around and trying to learn about this, I believe it is related to the embedded GlassFish not having been configured with resources. In other words it's missing a domain.xml file. Right?
Two questions:
Why does it work with NetBeans on my dev box? What magic does NetBeans do in the background?
How should I provide the file? Where does the embedded GlassFish on the Hudson-box expect it?
Hudson is using the same Ant build-scripts (created by NetBeans).
I've read this post about instanceRoot and the EmbeddedFileSystemBuilder, but I don't understand enough of that. Is this needed for every TestCase (Emb. GF gets started/stopped for each bean-under-test)? Is this part of EJBContainer.createEJBContainer()? Again, why is it not necessary to do this when running tests on NetBeans?
Update
Following Peter's advice I can confirm: when running ant on a freshly checked out copy of the code, with the same properties as hudson is configured, the tests get executed!
10-1 it is a classpath issue as IDE's tend to swap paths in and out depending if you run normally or unittests.
Try running the tests on a commandline from a freshly checked out version from your SCM. Chances are you'll have the same error. Debugging on your local machine is a lot easier than on a remote machine.
When it builds reliably on the command line (in a separate directory) then it is time to move to hudson.