I'm having trouble with a Jenkins pipeline.
The thing is, it seems one of the steps is running in parallel with another (not intentionally):
I have something like:
...
step("build"){
bat [Visual Basic 6 compile command - vb6.exe file.vbp /outdir my/directory]
if(fileExists("my/directory/output.dll"){
println "SUCCESS"
}else{
error("error")
}
...
}
Ok, the problem is: it checks if the files exist before it's written by the compile command... If I put a sleep 10 before the condition, it always runs OK (for now), but obviously, I don't want to have a sleep command in my pipeline.
I don't know if I can control better the order os execution or if maybe the fault lies in the vb6.exe that creates a thread to write the output and then the main thread returns success before the output being written... does this make sense? Does anyone know how may I solve this problem?
My solution is to make the VB6 compilation step blocking.
This is what I run when working locally on my machine:
cmd /c VB6.exe /make someproject.vbp
And it is also the approach used by the Jenkins Visual Basic 6 plugin (I am the author). See this.
I would like to run a Makefile in IntelliJ whenever a source file changes. Therefore I installed the File Watcher plugin and added a new File Watcher for Go files. In the Watcher Settings I added make as the Program and test for the Arguments.
When I now change a .go file, I get the following error message:
make test
make: *** No rule to make target `test'. Stop.
Process finished with exit code 2
so I assume that the file watcher works in general but is somehow runs the make command in the wrong directory.
When I run make test in a terminal from the root of my project, everything works as expected and I get:
Formatting all packages...
Code analysis with go vet...
Execute test with ginkgo...
[1490735873] Cmd Suite - 1/1 specs • SUCCESS! 120.183µs PASS
[1490735873] Test Helpers Suite - 4/4 specs •••• SUCCESS! 125.046µs PASS
[1490735873] Models Suite - 5/5 specs ••••• SUCCESS! 453.456µs PASS
[1490735873] Services Suite - 16/16 specs •••••••••••••••• SUCCESS! 3.035275ms PASS
Ginkgo ran 4 suites in 855.886243ms
Test Suite Passed
What am I doing wrong - or am I missing the point of using file watchers in IntelliJ?
Solution was that I had to specify the Working Directory in Other Options. When I set this to $ContentRoot$, everything works as expected.
I am using QtCreator 4.1rc1 under Windows with the msvc tool chain. The debugger is cdb from the Windows 8.1 SDK. I had the same issue with older versions of QtCreator.
When I debug my application, then there are many messages to the output (and issues) pane in the form
Exception at 0x773596c2, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) in WinSCard!SCardTransmit
I understand, that this is to be expected under Windows and those exceptions are actually not a problem. But they pollute the output and issues pane and basically render them useless.
So I tried to get rid of the messages. But failed after hours trying. What I tried is the following:
Use the check box 'Ignore first chance access violation' under Tools->Options->Debugger->CDB
Specifying command line arguments to cdb.exe: -xi
Create a script file for cdb.exe to be used at startup to avoid the warnings. The script contained the commands 'SXI 8010000a; SXI 0000071a; SXI e06d7363'. I tried placing the script in several directories and also specifying it with the command line options -cf or -cfr.
When I run cdb.exe from a command line using the startup script, it works! No exceptions are printed to the console. But when I start it from QtCreator, they are there again.
I assume, that QtCreator is using their own startup scripts and those overwrite the ones I specified.
Has anyone succeeded in hiding those exception outputs under QtCreator with cdb?
I have created an release app with rebar3 (beta-4).
Added some eunit tests and wrote some code.
For now I have to debug one test case to see what I have to add to make the implementation to work properly.
I found some articles about using dbg from Erlang console and I found how to write debug info from Eunit. But I need to get info from code that I have to test (the actual implementation(logic)).
Is there a way to debug Erlang code (actual source code, not the test one) when rebar3 is used with eunit argument?
I'm using tracing in terminal like there: https://aloiroberto.wordpress.com/2009/02/23/tracing-erlang-functions/
One way to do this is use rebar3 to run a shell under the test profile, then start the debugger and set up your breakpoints and such:
$ rebar3 as test shell
...
1> debugger:start().
{ok, <0.67.0>}
This will pop up the debugger GUI. Once the debugger is set up and ready, run your test under eunit:
2> eunit:test(your_test_module,[verbose]).
======================== EUnit ========================
your_test_module: xyz_test_ (module 'your_test_module')...
Assuming you set up a suitable breakpoint in the debugger, this will hit it, but you'll likely run into a problem with this approach: by default, eunit tests time out after 5 seconds, which doesn't give you much time for debugging. You need to specify a longer timeout for your test, which is why the example above shows that what's running is a test fixture named xyz_test_, which wraps the actual test with a long timeout. Such a fixture is pretty simple:
-include_lib("eunit/include/eunit.hrl").
xyz_test_() ->
{timeout,3600,
[fun() -> ?assertMatch(expected_value, my_module:my_fun()), ok end]}.
Here, the actual test is the anonymous function, which matches the return value from my_module:my_fun/0, which for this example represents the business logic under test. This example fixture sets the test timeout to one hour; you can of course set it as needed for your application.
I am using WebLogic 10.3 with a Java EE application. Can anyone please tell me how to debug this application?
I think the other answers are somewhat wrong. For windows, if you setup an environment variable called debugFlag to be true or in solaris/unix do the same
debugFlag=true
export debugFlag
DEBUG_PORT=8453
export DEBUG_PORT
, then setDomainEnv.sh or setDomainEnv.cmd are going to be called to start WLS by the other scripts. They look for the debugFlag and DEBUG_PORT, as long as the "production" flag is not set it will pick up the right parameters from the script for debugging (-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE).
YOU SHOULD NOT BE HACKING THESE SCRIPTS. It's going to make deployment and maintenance hard, the entire purpose of the setDomainEnv script is so that the right defaults are used and maintained across the cluster and throughout the entire environment. They are poorly documented I admit.
Note, if you are using the Oracle weblogic maven plugin, the target wls:deploy or wls:start-server will then pick up those environment settings when starting because they call the commands under the hood, and those in turn first call setDomainEnv.
As of right now, if you are using eclipse and have set up a Oracle WebLogicServer, the maven plugin will not attach to it into debug mode when you issue a mvn:deploy, you can either restart it in debug mode (silly), or create a 'Run ==> Debug ==> DebugConfigurations ==> RemoteJavaApplication' with a connection type of 'standard (socket attach)', a host of 'localhost' (or the remote server) and a port (default for me is '8453'). You can then do Run ==> Debug Configurations ==> Local Server Attach.
For me this worked:
In the folder WEBLOGIC_HOME\user_projects\domains\my_domain\bin
There is a file setDomainEnv.cmd
In it I found the code:
if "%debugFlag%"=="true" (
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
) else (
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -da
)
I just put the lines for debug outside the if clause:
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
if "%debugFlag%"=="true" (
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
) else (
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -da
)
After these settings you can debug on port 8453
The port is also configured in this file, you can also change it:
if "%DEBUG_PORT%"=="" (
set DEBUG_PORT=8453
)
Stop the server, run the script, start the server.
Now your weblogic server is setup for debugging.
The best approach to enable debug on weblogic server is as follows:
create a script file
put these lines into your script (for windows):
set debugFlag=true
set DEBUG_PORT=9001
call the start script (e.g.): C:\Oracle\Middleware\user_projects\domains\domain1\bin\startWebLogic.cmd)
So, there will be 3 lines on the script, that's all you need...
There are also more variables you can use....
WLS_REDIRECT_LOG=log_path <- redirect output to a file instead of console window...
JAVA_OPTIONS <- more options for the JVM
EXTRA_JAVA_PROPERTIES <- define aditional properties you may need
What I did to get the Eclipse Debugger working with Weblogic 10 was to lookup the startWeblogic.cmd file in the folder weblogic.10.3.3.0\user_projects\domains\base_domain\bin\ and modify the following line (around line 95):
set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS%
to
set JAVA_OPTIONS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n %SAVE_JAVA_OPTIONS%
Then I stopped any weblogic server that was running from within Eclipse and started Weblogic using the startWebLogic.cmd file.
Then I created a new debug configuration in Eclipse. Go to debug configurations, choose 'Remote Java Application', it should recognize your project, use Standard (Socket attach) for the connection type and specify port 8453 in the connection properties.
Now apply and run. Set some breakpoints in a piece of code that will regularly run and see if it is working.
Try remote debugging the application. You can try these links, thay may be helpful:
http://download.oracle.com/docs/cd/E15051_01/wlw/docs103/guide/ideuserguide/servers/conWebLogicServer.html#DebugRemote
http://eclipse.sys-con.com/node/169364
http://www.jacoozi.com/index.php?option=com_content&task=view&id=119&Itemid=134
Jonnathan Q answer helped me to launch Weblogic in debug mode also. For unix you can use the syntax like this in shell scripts:
debugFlag=true
export debugFlag
DEBUG_PORT=9001
export DEBUG_PORT
and then run startWeblogic.sh and startManagedWeblogic.sh if necessary.
UPDATE: to make our IDEs (Eclipse, IDEA) to stop on breakpoints we deployed our webapp on AdminServer, because in case of deploying to the node in clustered environment our IDEs didn't stop at breakpoints at all.