I have quite big Angular Dart project in PhpStorm. I was able to debug it, but suddenly it doesn't work anymore (for few weeks). I'm not sure what's the reason as I upgraded PhpStorm, Dart Plugin and Dart. But I expect debug to be working with all updates.
I created the simpliest Angular Dart app (ToDo example) to see if it helps. It didn't.
Dart VM version: 2.3.1 (Tue May 21 19:28:38 2019 +0200) on "linux_x64"
PhpStorm 2019.1.2
Build #PS-191.7141.52, built on May 8, 2019
JRE: 1.8.0_202-release-1483-b49 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 5.0.17-300.fc30.x86_64
PhpStorm Dart plugin v191.7221
Google Chrome Version 74.0.3729.169 (Official build) (64bit)
Dart is listening on port 53322 for HTTP connections from browser, PhpStorm is listening on debug port 63344 (and has a connection from Chrome), Chrome is listening on debug port 45389 (and has a connection from PhpStorm).
When I open http://localhost:53322/index.html I see the app, but the execution is not stopped on breakpoints.
I've found similar bugs (https://youtrack.jetbrains.com/issue/WEB-30593, Angular dart on WebStorm. Debug is no more working) but the provided solutions didn't help.
Is there a way to make debug working again? I'd like to avoid downgrading.
Not specific to Angular - debugging web apps doesn't work with SDK 2.3.1. Please follow WEB-39095 for updates.
Workarounds:
Start debug session from WebStorm. Breakpoints won't work. Stop Debug
session.
Without closing the project go to Terminal and run pub global activate webdev 1.0.1.
Start debug session from WebStorm again. Breakpoints should work.
Or:
Run webdev server manually from Terminal explicitly specifying hostname, for example: pub global run webdev serve --hostname 127.0.0.1 web:53322
In the IDE create JavaScript Debug run configuration that opens webdev URL directly, e.g. http://localhost:53322/index.html, press Debug
Update: it was a bug in webdev (no sourcemaps on ipv4). Bug is fixed in webdev 2.0.7. No actions needed, WebStorm will auto-update webdev automatically to the latest version
Related
After upgrading Docker to 4.6.0 on OSX 12.3 I've had a bit of an odd issue when I stop the xdebug listening client in PHPStorm, it seems that subsequent requests always times out because docker is reporting that host.docker.internal has port 9003 open when it's actually closed so the app always waits for the xdebug client.
I installed nmap on my webapp php container and host to test. If I run "nmap -p 9003 localhost" with the debug client running on my host I can see it open, after turning it off in PHPstorm the same scan shows that it's closed however running "nmap -p 9003 host.docker.internal" inside the container reports that it's still open. If I open other services on my host too it seems that ports start showing as open on the docker internal network however never report as closed after shutting them down on the host.
I upgraded to Docker 4.6.1 but the problem still persists.
Any advice would be appreciated.
This has been fixed in Docker 4.8.1
https://docs.docker.com/desktop/mac/release-notes/
UPDATE: Downgrading to Docker 4.5.0 resolved the issue.
This doesn't solve the problem, just helps to avoid restarting Docker while we are waiting for the fix.
Make changes in xdebug.ini:
xdebug.start_with_request=trigger
xdebug.idekey=VSCODE
This tells XDebug to connect to debugger only if "trigger" is present in the HTTP request.
Now, install Chrome extension Xdebug helper, it's old but still works. Open extensions settings (chrome-extension://eadndfjplgieldjbigjakmdgkmoaaaoc/options.html) and set IDE key to "Other" "VSCODE".
Now, when you want to debug, you enable debugging in VSCode and also enable debugging in Chrome using that extension:
When you are done debugging - choose "Disable" in the extension, and PHP won't try to connect to your debugger, even if the port is still open. How it works - extension just sends cookie XDEBUG_SESSION=VSCODE with each request, and XDebug connects to the debugger only when this cookie is present.
P.S. You can replace VSCODE with IDE key that your IDE uses, or just any string.
Good day
Issue below is solved on WildFly 13 by disabling HTTP/2 (while still keeping TLS for HTTPS).
Even the non effected browser and system combos (all the non Apple stuff) seem to load much faster now.
Follow instructions from this post on how to disable HTTP/2:
https://developer.jboss.org/message/984394?et=watches.email.thread#984394
From the ./jboss-cli.sh cli just run:
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false)
And reload / restart the server. All devices render perfectly and fast.
I am leaving the below if somebody else runs into a similar error.
I updated my code and POM file to use the Java EE 8 dependencies for WildFly 13 based on the WildFly 13 BOM POM and the #Balusc JSF 2.3 Java EE 8 kickoff sample application.
So I set it to use:
JSF 2.3.5.Final
OmniFaces 3.1
PrimeFaces 6.2.7
On desktop (all operating systems with all of the latest browsers) the site works 100% and the war is deployed in half the time.
However the site fails to render correctly on my iPhone. I tried all browsers installable from the app store, and the one that looks the nearest to correct is Firefox.
However even with Firefox I can't get pass the login screen.
On Android and all non Apple based products the site works without any error logs.
Is anybody aware of issues rendering JSF 2.3 on Apple based products?
Any pointers on what to look for, add or change will be most appreciated.
See below for log file info:
The initial error only triggered from iOS / Mac OSX is an UNDERTOW error with OmniFaces info (we are using TLS for HTTPS, but before moving all to JSF 2.3 everything worked 100% with zero errors or warnings in logs)
2018-07-30 09:09:18,741 ERROR [io.undertow] (default task-3078) UT005085: Connection io.undertow.server.protocol.http2.Http2ServerConnection#7e55834 for exchange HttpServerExchange{ GET /edsnext/javax.faces.resource/omnifaces.js.xhtml request {accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8], accept-language=[en-us], :authority=[edsnext.megchemsa.com:62543], accept-encoding=[gzip, deflate], :path=[/edsnext/javax.faces.resource/omnifaces.js.xhtml?ln=omnifaces&v=3.1], user-agent=[Mozilla/5.0 (iPhone; CPU iPhone OS 12_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1], :scheme=[https], cookie=[JSESSIONID=U5X9u-A83bccAnpA1XUnEFzmngqI9iDJwuIiU_Qo], :method=[GET], Referer=[https://edsnext.megchemsa.com:62543/edsnext/], upgrade-insecure-requests=[1], Host=[edsnext.megchemsa.com:62543]} response {Expires=[Mon, 30 Jul 2018 09:57:18 GMT], ETag=[W/"5933-1532705069245"], Last-Modified=[Fri, 27 Jul 2018 15:24:29 GMT], Set-Cookie=[JSESSIONID=U5X9u-A83bccAnpA1XUnEFzmngqI9iDJwuIiU_Qo.edsnext; path=/edsnext], Content-Type=[application/javascript], Date=[Mon, 30 Jul 2018 07:09:18 GMT], :status=[200]}} was not closed cleanly, forcibly closing connection
Then the following PrimeFaces resource not found warnings (and login page is rendered incorrectly on iOS)
2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3091) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.eot, from library, primefaces.
2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3084) JSF1064: Unable to find or serve resource, fonts/lato-regular-webfont.svg, from library, primefaces-omega.
2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3082) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.ttf, from library, primefaces.
2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3100) JSF1064: Unable to find or serve resource, fa/fontawesome-webfont.svg, from library, primefaces.
2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3103) JSF1064: Unable to find or serve resource, fonts/lato-bold-webfont.svg, from library, primefaces-omega.
2018-07-30 09:09:21,056 WARNING [javax.enterprise.resource.webcontainer.jsf.application] (default task-3091) : java.nio.channels.ClosedChannelException
EDIT: Added log file info pointing to UNDERTOW errors followed by lots of PrimeFaces missing resources.
EDIT 2:
Ok, I tested this with:
Server side:
CentOS 7.5 all updated
Oracle JDK 10.1
WildFly 13.0.0.Final
JSF 2.3.5.SP1
PrimeFaces 6.2.7
OmniFaces 3.1
The following setups renders the site perfectly with zero errors or warning at debug level:
CentOS GNOME 7.5 Chromium
CentOS GNOME 7.5 Firefox Developer Edition
Windows 10 Chrome
Windows 10 Firefox Developer Edition
Android Studio Nexus 5 AVD APK 28 Chrome
Samsung Galaxy S7 Chrome
Samsung Galaxy S7 Firefox
All browsers installable from the Apple app store including Safari fails to render the site. All have the UNDERTOW error.
Tested with Mac OSX - latest updated version - also fails with the UNDERTOW error.
I logged a bug report with Apple. Problem is though that a substantial amount of users are effected by this due to having to access the Web app via their iPhone or iPad.
What else can I do to expedite this?
To resolve this error disable HTTP/2 on WildFly 13 with:
Follow instructions from this post on how to disable HTTP/2:
https://developer.jboss.org/message/984394?et=watches.email.thread#984394
From the ./jboss-cli.sh cli just run:
/subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false)
Restart / reload the server and all is well.
When running a Dart web app in WebStorm, the "Pub Serve" tab on the ? pane at the bottom reports the following (--port differs from run to run):
/home/tom/dart-sdk/bin/pub serve web --port=46247
Loading source assets...
Loading polymer transformers...
Serving polymer_and_dart web on http://localhost:46247
However, the app will be accessible at http://localhost:63342.
Yet when I run pub serve from the command line, the app will be accessible at localhost:46247:
/home/tom/dart-sdk/bin/pub serve web --port=46247
Can someone explain what WebStorm is doing at the specified port, if it is not to serve the app?
BTW, I am using only Dartium in development.
WebStorm has an integrated proxy that listens on its own port and just forwards to the port pub serve is listening on.
pub serve will be removed in Dart 2.
Currently 4/2018 there is no integration of pub run build_runner serve with IntelliJ but it is work in progress.
Webstorm 2018.1 seems to do something a little different from a proxy. Webstorm runs a web server at the debug port that will respond with a 302 redirect when it receives a GET http://localhost:{{debugPort}}/web/web/{{targetPage}}. The redirect's Location header will refer to the actual location of the target page in the Dart web app.
If, by some chance you need to get the random port programmatically during development, you can enable "Allow unsigned requests" in the Webstorm debugger settings and then write some scaffolding code to get the Location header.
I'm trying to debug worklight 6.1 adapter code (java). I figured the most logical way would be to restart the imbedded liberty server in debug mode. That fails with a message:
ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
Error occurred during initialization of VM
agent library failed to init: jdwp
I followed the process documented for 6.0 at Logging and debugging Java on Worklight Server but I get the same issue there.
Ok, this is silly, but I just figured it out. You do not need to set anything for debug mode. Apparently in 6.1 this is already set. To begin debugging of your java code in the adapter you need to do the following:
Create a debug configuration for a "Remote Java Application".
Set the project to your worklight hybrid project
I set the port to 10777. which is what jdwp was set to in the jvm.options file for the worklight server.
Once you click on debug for that configuration, it will allow you to debug your adapter.
You can see the jvm.options file if you expand the Worklight Development Server definition in the Servers view. See below for an example of the contents of that file.
-Dfile.encoding=UTF-8
-Duser.language=en
-Duser.country=US
-Djava.awt.headless=true
-Dwas.debug.mode=true
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=10777
-Dcom.ibm.websphere.ras.inject.at.transform=true
Uploaded video to youtube on how to do this
I'm trying to get Jenkins (1.510) running on my MacMini with the latest Mountain-Lion Server OSX installed (10.8.3). On the MacMini-server I've two users: admin, ioscoder and as the ioscoder user I logged-in, opened the jenkins-1.510.pkg and after entering the admin password it installed without problems.
However when the Jenkins-home page should come up, using localhost:8080, I get the following error message in Safari:
Safari can't open the page "http://localhost:8080/" because Safari can't connect to the server "localhost".
After logging in as admin and checking the current running services, being DNS, Open Directory, Websites (PHP- and Python web applications disabled), I also get the same error from above when entering the Jenkins address localhost:8080.
When I switched to the admin-user I saw on the welcome screen a Jenkins-user account, which was created by the jenkins-installer package.
What really puzzles me is that on another iMac, running Mountain Lion (NOT the server version of Mountain Lion), I installed Jenkins in the same way and after the installation finished I immediately got a running Safari which resolved the localhost:8080 to the Jenkins home screen.
Anybody ideas or suggestions why Jenkins is not running on a Mountain Lion Server device?
Google-ing for this specific problem didn't give me any clues yet.
After reading the https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins page where an easy installation was mentioned (java -jar jenkins.war) I remembered that java may not have been installed by default on a clean Mountain-Lion Server.
After activating the terminal and typing:
server:~ ioscoder$ java -v
No Java runtime present, requesting install.
it asked me if I wanted to install java. After accepting this and performing an installation of java, I was happy to see the 'Dashboard [Jenkins]' page in Safari for the localhost:8080.