Validating Debugging Configuration on PhpStorm - phpstorm

I'm using the latest PhpStorm on Windows. Following the instructions on
https://blog.jetbrains.com/phpstorm/2016/06/debugging-vvv-vagrant-setup-with-phpstorm/
I was able to validate the connection.
However the I can't connect to PhpStorm from Chrome and X-debug helper.
When I return to the validation I see the message from the error page.
The path on Windows to create validation script is
C:\Users\Adrian\Projects\vagrant\drupal

I noticed, that I can use the X-debug despite of this error.
This "issue" relates more to PHPStorm team rathen then stackoverflow.

Related

HTML launch.json [duplicate]

Trying to debug my javascript code in Visual Studio. Selected "Start Debugging" and I get the following error message "configuration 'Run Current File' is missing in launch.json" (not pictured--error msg vanished after 5 seconds). I also got redirected to this launch.json file but have no idea what I need to type here.
I already have installed Node.js. I have restarted my computer, as well as edited the syntax of my javascript before debugging.
I am very very new to programming and am not sure what could be missing. Help please!
launch.json is used for to launch an app for debugging. It has settings geared for things like mapping to your workspace source code or defining the Chrome port to use.
Check full details here

chrome : unable to read local files by using `-allow-file-access-from-files `

Introduction
Honestry,I'm not native English user,so my English is not better.
If you have any question, ask me by comment.
what I wanna do
As a premise,when you try to access local files by web site link,IE or FireFox can access( by simple setting) ,but Chrome can't access for their security poricy.
I found the ways to do this, like below:
add --allow-file-access-from-files option when you execute chrome.exe
build a local server like nginx or Apache HTTP Server,which meditate to access local data
Use chrome extentionEnable local file links
Due to business restrictions,I should resolve this problem by method 1. but I can't enable loacl data link though I set option correctly.
I googled why I can't,but I couldn't find why it won't work.
(In the first place,I can't even find Google official description of --allow-file-access-from-files.How predecessors find that method ... )
While searching、I found person who have the same question、Google Forum.
I'm convinced that this is not my simple miss,but more deep problem,so I decided to make this question.
what I tried
I rebooted computer,killed all process related to chrome,then change directory where contains chrome executable file,and execute chrome.exe --allow-file-access-from-files
I rebooted computer,killed all process related to chrome 、create shortcut on my Desktop ,which destination is "/path/to/chrome/chrome.exe"--allow-file-access-from-files
After execute chrome,I checked chrome boot option to accesschrome://version/.Both method, I could boot chrome by add --allow-file-access-from-files option,but can't achieve first purpose to access local file access.
what I wanna know
lacking or similar to --allow-file-access-from-filesoption、
(solution similar to method 2 or method 3,like "Give up option solution,and use nginx as local server" is unnecessary)
or other solution
Additionary,if you know below info,please teach me.
- Google official documentation which descriptionsallow-file-access-from-files
( Indended to Oracle official Javadoc of Java.)
Using Tool
Chrome Version : 78.0.3904.87
OS : WIndows 7 SP1

PhpStorm - xDebug on demand not attaching

I tried out your new feature "xedbug on demand". I stuck to these guides (https://www.jetbrains.com/help/phpstorm/2016.3/configuring-xdebug.html and https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/).
I see that in the php Server menu when I add the path to the xdebug that PhpStorm recognizes it (the label switches from "not installed" to "XDebugger 2.4.1").
So everything seems to be fine but when I use the debugger via the bug-icon, it never attaches/stops for the breakpoint.
I activated the xdebug-Logfile, but it stays completely empty.
Furthermore I commented everything xdebug-related out in the php.ini.
The xdebug-port is still on 9000 (default).
Any ideas what I can do about it?
Update: I'm using the debugger via phpStorm's "PHP Web Application" and the debug-icon. I'm debugging php files which are executed via an apache vHost.
PS: Checked IntelliJ forum and Stack posts, didn't find anything helpful though...
"Xdebug in demand" option works for CLI debugging only (Run/Debug Configuration of "PHP Script" type; will also work for other CLI-mode configs, e.g. "PHPUnit") be it local or remote.
Quote from the aforementioned introduction blog post:
To use the great new feature, first, you need to disable Xdebug for command line PHP scripts.
That option does not work for web pages served via web browser (e.g. Apache/nginx/IIS) or when just listening for any incoming debug connections (Zero-config approach) where actual debug is initiated outside of IDE.
The reason is very simple: when launching debugger for CLI script, IDE launches your php executable (your configured PHP Interpreter, e.g. php.exe on Windows) with additional parameter (-z: check php --help output or here) that can load such additional extension.
But when you debugging a web page then whole PHP is not controlled by PhpStorm: it's your web server (Apache/nginx/IIS/etc) that communicates with PHP .. and you cannot pass such arguments at this stage.

Why can't I reach Glassfish admin gui?

Either I start Glassfish domain from NetBeans or from the asadmin console, I can't reach the admin panel.
When I navigate to http://localhost:4848, first there's a page saying "The Admin Console is starting. Please wait.", then it tries to redirect to a page having title "Login", but it loads, loads, loads forever. My CPU usage reaches 100% and nothing happens until I stop the server.
I tried Glassfish v3.1, v3.1.2 and also the freshest v4.0, without any modification.
About a year ago, v3.1 worked for me; I have no idea what could happen.
The server log says Glassfish can't find image files.
I uploaded the server log here: http://notepad.cc/share/LvaZvH23sF
I read somewhere that renaming the console-updatecenter-plugin.jar, and the NO_NETWORK=true option can solve similar problems, but these couldn't help for me.
I use JDK 7, and I'm on Windows 7 if it matters.
(edit) Summarizing what happened, from my past comments:
The admin panel was unreachable in Google Chrome and Internet Exlorer.
I managed to reach the admin panel in Firefox, and even in Chrome's incognito mode, but the cause was not AdBlock.
Chrome dev console complained about a 404 error.
After a while, I was able to reach the admin panel in Chrome, in normal mode too, so from that point I couldn't reproduce the problem.
Try access the console in this url: http://localhost:4848/login.jsf
In http://localhost:4848 redirect to http://localhost:4848/common/index.jsf and not work because the url not exists.
I noticed this in your log:
[2013-08-04T10:52:12.761+0200] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=34 _ThreadName=admin-listener(2)] [timeMillis: 1375606332761] [levelValue: 900] [[
Context path from ServletContext: differs from path from bundle: /]]
Following that warning, there are a lot of info messages that the server can't find resources that it expects:
[2013-08-04T10:52:16.495+0200] [glassfish 4.0] [INFO] [] [com.sun.jsftemplating] [tid: _ThreadID=133 _ThreadName=admin-listener(6)] [timeMillis: 1375606336495] [levelValue: 800] [[
JSFT0004: The requested resource (/images/button/primary-mini-roll.gif) is not available.]]
...etc.
I'm curious as to how you installed the Glassfish servers. Did you use the windows installer? If you simply used the installer to update an existing Glassfish installation, an incorrect configuration could have been carried over.
The easiest solution to your problem is to download the ZIP distribution. Extract that to a new directory, start the asadmin tool via the command line and run the command:
asadmin> start-domain domain1
That should give you a completely fresh installation and should work without any problems. There's a good blog post here on getting started with Glassfish 4, it would be worth skimming through to make sure there's nothing you've missed.
not sure if this is still a problem but I got something similiar and I could resolve this by setting an admin password and enabling secure-admin (glassfish 3.1). Not sure if the secure-admin is necessary though, so setting a password might be enough.
download and extract glassfish zip
glassfish3/bin/asadmin start-domain
glassfish3/bin/asadmin change-admin-password (default is user "admin" with no password, so just hit [ENTER] two times)
glassfish3/bin/asadmin enable-secure-admin (might be skipped, just see what works for you)
glassfish3/bin/asadmin restart-domain
Now the admin-gui should be available on http://localhost:4848 and also from other machines via http://your.ip.or.address:4848
Good luck
I've had this happen to me when I enable "Default Principal To Role Mapping":
After I enable this and restart the domain, I'm never able to login again. I had to change the following line on domain.xml (with the domain stopped) :
<security-service default-principal-password="admin" activate-default-principal-to-role-mapping="true" default-principal="admin">
to this:
<security-service>
I didn't find any serious error in your log. Maybe another program doesn't let GlassFish works correctly. For example antivirus.
Had a similar problem.
It happened when I put a primefaces 5.x jar file in my /JAVA_HOME/jre/lib/ext directory and when I removed it all went back to normal.
Through research I found that apparently the admingui clashes with some "3rd party JSF helper stuff".
Hope this helps somebody.
When Running on Chrome you may get this error due to this issue. https://github.com/eclipse-ee4j/glassfish/issues/22439
Admin gui is accessible on Firefox though.
Try this : http://mike.meessen.biz/blog/?p=281
I had exact
first there's a page saying "The Admin Console is starting. Please
wait.", then it tries to redirect to a page having title "Login", but
it loads, loads, loads forever.
problem and it worked for me.
I was in a similar situation and I found that in FF I cannot get access to console but in IE and Chrome with http://localhost:4848/login.jsf I can.
In Eclipse stopping the server and cleaning maybe will help. Afterwards you can access it via http://localhost:4848/common/index.jsf
The solution is quite simple.
There is an apllication/project that you were working on that had some errors. Simply undeploy them using the following procedure:
1.Go to Services tab then Servers then Glassfish Server 4.1
2.Right click on Glassfish Server 4.1 and click on the dropdown to list what under Glassfish Servers.
3.Expand Applications and undeploy all applications to start full receovery of the admin console.
4.Start Glassfish
5.Launch the admin console
Make your domain writeable thats the key guys
it ll work no need to other kinda wierd stuff

Parsed Console Output Error in Hudson

im running Hudson continuous integration for db unit.
when i run the job the console output is displaying the SUCCESS, but then why do the Parsed Console Output keep returning this error:
ERROR:Failed to parse console log :
log-parser plugin ERROR: Cannot parse log: Can't read parsing rules file:
i already installed the parse-log plugin & i already restarted the Hudson..
i installed the plugin using remote PC
any help and suggestion is appreciated. Thanks!
1) Place the Parser Rule File in the JENKINS_HOME location.
2) Configure that log parser console output in the Global COnfiguration settings and Name it.
3) Add this option in the Post Build Actions and Select the Name
ok silly me..
i forgot to configure the global configuration in hudson that link to the parser rule file..
problem solved.
I'm posting this in case anyone else has a specific case of this problem. This issue started when upgrading from 1.509.2 to 1.554.3... I had the parsing rules file in the win\system folder which was a known issue when running Jenkins as a service. Well I guess they fixed it by this version. I moved the parsing rules back into Jenkins Home folder and it worked fine again.