Confusion about using OpenEJB in embedded mode for unit-testing - unit-testing

I started exploring the possibilities of using OpenEJB in embedded mode for unit-testing my EJB3 components. At first I got errors like the below output
Testsuite: HelloBeanTest
Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 1,779 sec
------------- Standard Output ---------------
Apache OpenEJB 3.1.4 build: 20101112-03:32
http://openejb.apache.org/
------------- ---------------- ---------------
------------- Standard Error -----------------
log4j:WARN No appenders could be found for logger
(org.apache.openejb.resource.activemq.ActiveMQResourceAdapter).
log4j:WARN Please initialize the log4j system properly.
------------- ---------------- ---------------
Testcase: sum took 1,758 sec
Caused an ERROR
Name "HelloBeanLocal" not found.
javax.naming.NameNotFoundException: Name "HelloBeanLocal" not found.
at org.apache.openejb.core.ivm.naming.IvmContext.federate(IvmContext.java:193)
at org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:150)
at
org.apache.openejb.core.ivm.naming.ContextWrapper.lookup(ContextWrapper.java:115)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at HelloBeanTest.bootContainer(Unknown Source)
# ... output is the same for all the rest of the tests
The openejb.home property is set as a system property and points to my OpenEJB installation dir.
The HelloBeanTest#bootContainer() is a setUp method and it fails on the JNDI lookup. Shown below.
#Before
public void bootContainer() throws Exception{
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
Context context = new InitialContext(props);
hello = (Hello) context.lookup("HelloBeanLocal");
}
After struggling with problems like this I started to try out OpenEJB in non-embedded mode, and started the container from it's installation directory and deployed the components as an ejb.jar. Deployment was successful and I started creating a stand-alone Java client. The stand-alone Java client is still unfinished, but meanwhile I came back to testing in embedded mode.
To my surprise, the tests suddenly started to pass. I added some more functionality to the component and tests for those. Everything worked just fine. Below is the output for that run.
Testsuite: HelloBeanTest
Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2,281 sec
------------- Standard Output ---------------
Apache OpenEJB 3.1.4 build: 20101112-03:32
http://openejb.apache.org/
------------- ---------------- ---------------
------------- Standard Error -----------------
log4j:WARN No appenders could be found for logger
(org.apache.openejb.resource.activemq.ActiveMQResourceAdapter).
log4j:WARN Please initialize the log4j system properly.
------------- ---------------- ---------------
Testcase: sum took 2,263 sec
Testcase: hello took 0,001 sec
Testcase: sum2 took 0 sec
Testcase: avg took 0,001 sec
I was happily coding and testing until it broke again. It seems that removing the ejb.jar from /apps directory caused it. So, it seems that OpenEJB does the JNDI lookup still from the installation dir, but uses the current dir to find the actual implementations when running in embedded mode. I made this conclusion as the ejb.jar deployed in apps/ dir does not have all the methods that the local version has. (I double checked with javap.) Only the class signature is the same.
After this very long introduction, it's question time.
Can anyone provide any explanation for this behaviour?
Packaging and deploying the EJBs in the apps/ dir before testing is simple task, but can I be sure that even then I am testing the correct implementation?
Does this all have something to do with the openejb.home property pointing at the OpenEJB installation dir?
For summary, OpenEJB version is Apache OpenEJB 3.1.4 build: 20101112-03:32, which is visible in the log outputs as well.
Thanks in advance.

It does have something to do with setting the openejb.home to point to the installation dir.
There's a conf/openejb.xml file that likely has a apps/ listed as where deployments live. All the log output went to the logs/ dir and not in System.out of the test case where you can read it easily.
To use OpenEJB embedded you don't need any config files, directories, or ports. You just include the libs in your project's classpath.
First thing I'd say is to check out the openejb-examples-3.1.4.zip. There are maybe two dozen example projects all setup with both Ant and Maven build scripts. All the examples will work in any environment as long as the OpenEJB libraries are in the classpath. Here's a video of using one of the examples to unit test in Eclipse. I recommend the simple-stateless example as the best starting point.

Related

Bazel test does not work with mingw-gcc . How should I debug this?

I'm following this really basic example here to setup gtest with bazel:
http://google.github.io/googletest/quickstart-bazel.html
it works fine (and tests pass) but I would like to use mingw gcc compiler with this (not the default mysys). Upon running this I get a single test failed, with no output displayed.
I can easily build or run files using this compiler. My output is below ( if it helps at all ):
C:\Users\<user>\Desktop\testProj>bazel test --test_output=all //:hello_test --verbose_failures
DEBUG: Rule 'com_google_googletest' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "5cf189eb6847b4f8fc603a3ffff3b0771c08eec7dd4bd961bfd45477dd13eb73"
DEBUG: Repository com_google_googletest instantiated at:
C:/users/<user>/desktop/testproj/WORKSPACE:3:13: in <toplevel>
Repository rule http_archive defined at:
C:/users/<user>/_bazel_<user>/x2p76flj/external/bazel_tools/tools/build_defs/repo/http.bzl:355:31: in <toplevel>
INFO: Analyzed target //:hello_test (0 packages loaded, 0 targets configured).
INFO: Found 1 test target...
FAIL: //:hello_test (see C:/users/<user>/_bazel_<user>/x2p76flj/execroot/__main__/bazel-out/x64_windows-fastbuild/testlogs/hello_test/test.log)
INFO: From Testing //:hello_test:
==================== Test output for //:hello_test:
================================================================================
Target //:hello_test up-to-date:
bazel-bin/hello_test.exe
INFO: Elapsed time: 0.269s, Critical Path: 0.08s
INFO: 2 processes: 2 local.
INFO: Build completed, 1 test FAILED, 2 total actions
//:hello_test FAILED in 0.0s
C:/users/<user>/_bazel_<user>/x2p76flj/execroot/__main__/bazel-out/x64_windows-fastbuild/testlogs/hello_test/test.log
INFO: Build completed, 1 test FAILED, 2 total actions
The log file is also empty, and shows what the stdout here shows
For anyone who runs into this issue in future, you simply need to add linkopts=["-static"], to your cc_test rule. Not sure why it wasn't correctly dynamically linking

Getting error while building project "com.bea.util.jam.internal.javadoc.JavadocClassloadingException:"

I am getting error while trying to build a java project in TeamCity. The same project builds and excecutes well on my local. I recently pushed changes to this project on GitLab. This is my first time working with GitLab and TeamCity together. Other projects have no issues during build. I am unable to understand what is causing this error:
[15:58:54][Step 1/1] compile.earCommons (4s)
[15:58:54][compile.earCommons] echo
[15:58:54][compile.earCommons] echo
[15:58:54][compile.earCommons] wlcompile (4s)
[15:58:59][wlcompile]
com.bea.util.jam.internal.javadoc.JavadocClassloadingException: An error
has occurred while invoking javadoc to inspect your source
files. This may be due to the fact that $JAVA_HOME/lib/tools.jar does
not seem to be in your system classloader. One common case in which
this happens is when using the 'ant' tool, which uses a special
context classloader to load classes from tools.jar.
This situation elicits what is believed to a javadoc bug in the initial
release of JDK 1.6. Javadoc attempts to use its own context classloader
tools.jar but ignores one that may have already been set, which leads
to some classes being loaded into two different classloaders. The
telltale sign of this problem is a javadoc error message saying that
'languageVersion() must return LanguageVersion - you might see this
message in your process' output.
This will hopefully be fixed in a later release of JDK 1.6; if a new
version of 1.6 has become available, you might be able to solve this
by simply upgrading to the latest JDK.
Alternatively, you can work around it by simply including
$JAVA_HOME/lib/tools.jar in the java -classpath
parameter. If you are running ant, you will need to modify the standard
ant script to include tools.jar in the -classpath.
[15:58:59][Step 1/1] Process exited with code 1
[15:58:59][Step 1/1] Ant output
[15:59:10][Step 1/1] Process exited with code 1 (Step: Ant)
[15:58:59][Step 1/1] Step Ant failed
****Update****
Build Step: Ant
Step 1:
Runner type: Ant (Runner for Ant build.xml files)
Execute: If all previous steps finished successfully
build.xml file: \ant\build.xml
Working directory: same as checkout directory
Targets: none specified
Ant home path: C:\apache-ant-1.7.0
Additional Ant command line parameters: -lib c:\WebLogic\12.1.2\wlserver\server\lib\javaee.jar;c:\WebLogic\12.1.2\wlserver\server\lib\weblogic.jar;c:\WebLogic\12.1.2\wlserver\server\lib\webservices.jar
JDK home path: c:\Program Files\Java\jdk1.7.0_80
JVM command line parameters: not specified
Reduce test failure feedback time: OFF
Java code coverage: disabled
Docker Settings
Docker Image: unset
I'll appreciate any help in this regard.
I found there was character encoding issue with one of the files that prevented compiler from loading the java classes. Once that was fixed, the build worked fine.

AndroidStudio 3.2 test configuration does not work

After migrating to AS 3.2 android JUnit test run configuration does not work, all types "All in directory",
"All in package" etc.
I mean it does work, but always claims that:
0 test classes found in package '<default package>'
Process finished with exit code 254
Empty test suite.
using ./gradlew test triggers every test
and every single test can be run by AS using that green play button inside editor (for class or single method)
but not for package, module etc.
How to fix that ?
many thanks
Wojtek
Declare your test classes as public
Fixed in Android Studio 3.2.1
So just update AS to newest version and the problem disappears

Gradle test task - Gradle 1.6 and with Gradle 2.3 or later

I have a Java project.
PS: In my project, I don't have any java program/source code in src/test/java. - This folder just contains a blank.txt file.
I have two different Gradle versions:
Gradle 1.6 with Java 7 (as Java 8 is NOT compatible with Gradle 1.6 or any version < less than 1.10 version if I'm correct).
The other version is: Gradle 2.3 with Java 8.
Using both of the above mentioned Gradle 1.6 + Java7 OR Gradle 2.3 + Java 8 versions my project build successfully.
Though, I noticed one thing: That while running the build, it calls "test" task automatically (as per the Gradle design, test task runs for free); I found during Gradle 1.6 + Java7 run --- I see the following output.
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources
:testClasses
:test
:check
As you'll notice, it says I don't have any test source code (i.e. src/test/java doesn't contain any source code OR there's nothing new for Gradle to compile this time may be nothing changed since last time gradle ran the build) and that's why compileTestJava task is showing UP-TO-DATE in front of it.
But, :test task is showing that it ran successfully. I have used jacoco (code coverage) section within test { .. } task, then it actually ran that part (as there is no UP-TO-DATE in front of test task). Jacoco section is NOT defined in my project's build.gradle but actually it's coming from a top level / GRADLE_HOME/init.d/some-common-top-level.gradle file (where test { ... has jacoco { ... } .. } section in it).
As I mentioned above, test task didn't say UP-TO-DATE, therefore, after Gradle build process was complete, I can see it created the following folder/files structure inside build/tmp/expandedArchives/org.jacoco.... folder:
$ ls -ltr build/tmp/expandedArchives/
total 4
drwxr-xr-x+ 1 e020001 Domain Users 0 Jul 7 20:45 org.jacoco.agent-0.7.2.201409121644.jar_778m6tp3jrtvcetasufl59dmau
$ ls -ltr build/tmp/expandedArchives/org.jacoco.agent-0.7.2.201409121644.jar_778m6tp3jrtvcetasufl59dmau/
total 272
drwxr-xr-x+ 1 e020001 Domain Users 0 Jul 7 20:58 META-INF
-rwxr-xr-x 1 e020001 Domain Users 2652 Jul 7 20:58 about.html
-rwxr-xr-x 1 e020001 Domain Users 272311 Jul 7 20:58 jacocoagent.jar
drwxr-xr-x+ 1 e020001 Domain Users 0 Jul 7 20:58 org
The same is NOT happening when I'm running Gradle 2.3 and Java8.
Build is successful but I'm not getting build/tmp/expandedArchives/org.jacoco.... folder containing jacocoagent.jar file.
Any idea, why Gradle 2.3 is not creating this jacoco specific .jar file.
With Gradle 2.3+Java8, the following output shows UP-TO-DATE in front of both :compileTestJava and :test tasks (which was not the case with Gradle 1.6 for test task).
I ran "gradle clean build".
:compileTestJava UP-TO-DATE
:compileTestGroovy UP-TO-DATE
:processTestResources
:testClasses
:test UP-TO-DATE
:check
I need Gradle 2.3 to generate this jacocoagent.jar under build/tmp/expandedArchives/org.jacoco..... folder so that I can use it in a downstream Jenkins job (which runs non-Unit tests) as this project does have some Integration tests and I'm fetching the jacocoagent.jar from the parent main build job (which runs gradle clean build including test task) in downstream job so that I can pass it to TOMCAT JVM while starting Tomcat (so that I can get jacocoIT.exec code coverage for IT tests). But, after I switched to Gradle 2.3, all projects where I don't have src/test/java ... now jacocoagent.jar is not getting created and the copy artifact plugin fails while trying to copy the .jar file from parent job.
One more point:
With Gradle 1.6 + Java7, if I run gradle clean build, it successfully creates that jacocoagent.jar inside build/tmp/expandedArchives/org.jacoco..... folder but it works this way, only when I run gradle clean build or "gradle clean; gradle test".
If I run gradle clean build, and then remove build/tmp folder, and now just run: gradle test, it shows me UP-TO-DATE in front of both :compileTestJava and :test tasks and doesn't create build/tmp/expandedArchives/org.jacoco.... folder containing jacocoagent.jar file.
For more info, I'm attaching the profile run (i.e. using --profile option) while running gradle test task for Gradle 1.6 + java 7.
I see that, in the profile html file that when test task is run, it first calls compileJava as per Gradle process logic and then test task and it's also calling depedencies --- :jacocoAgent (as per the dependency resolution tab):
But,
with Gradle 2.3 + Java8, the dependency Resolution / order and Task execution step is not same (or in the order as compared to Gradle 1.6) for generating or showing any reference to jacocoAgent dependency as it's not even calling it.
Running Gradle1.6 +Java7 test task with -i (or --info) option shows why it ran test task even though I had no test source code, see the reason why:
Note: Recompile with -Xlint:unchecked for details.
:processResources
Skipping task ':processResources' as it has no source files.
:processResources UP-TO-DATE
:classes
Skipping task ':classes' as it has no actions.
:compileTestJava
Skipping task ':compileTestJava' as it has no source files.
:compileTestJava UP-TO-DATE
:processTestResources
Executing task ':processTestResources' due to:
No history is available.
:testClasses
Skipping task ':testClasses' as it has no actions.
:test
file or directory '/my/workspace/project/build/classes/test', not found
Executing task ':test' due to:
No history is available.
file or directory '/my/workspace/project/build/classes/test', not found
Finished generating test XML results (0.001 secs)
Generating HTML test report...
Finished generating test html results (0.012 secs)
BUILD SUCCESSFUL
you can force the test task to be executed no matter what the status of inputs and outputs are:
test{
outputs.upToDateWhen{false}
}
for earlier gradle versions you can ensure the class directory exists by
task createTestClassesDir << {sourceSets.test.output.classesDir.mkdirs()}
test.dependsOn createTestClassesDir
Summary:
With Gradle 2.3, if there are no valid .java/.groovy (or etc) test code, then test task won't even run and thus there'll be no jacocoagent.jar created somewhere deep in build/tmp/exapandedArchives/org.jacoco.xxx.... folder.
Solution was to include the following (in top level $GRADLE_HOME/init.d/some-global-file.gradle) inside allprojects { .... } section. All we are doing is, if src/test/java (standard) or any legacy folder structure (src/java if your project structure is like this) doesn't have any valid test source code, then we can add a dummy test file (DummyTestXYZ.java or groovy) and let test task run which will generate jacocoagent.jar (which we can use / tie in Tomcat options for generating jacoco report for non-unit aka integration tests). This way, if your main build job calls a downstream/child job to run your IT tests, it won't fail as it can fetch jacocoagent.jar (from main build job's workspace) as test task will create jacocoagent.jar in build/tmp/expandedArchives/org.jacoco.xx.x.xx..x folder (that you can get using Copy Artifact plugin in Jenkins).
PS: Change the if statement logic acc. to your own folder setup i.e. in which folder you'd want to create the DummyTestXYZ.java file. In our case, all new projects were using src/test/java (standard folder structure as per Maven/Gradle standard) and during the new project creation, we are adding valid sample unit tests checked-in to the source control. Thus, in the logic below, we are actually ignoring to create this DummyTestXYZ.java in case src/test/java exists and creating this file only if src/test/java folder doesn't exist in the project (i.e. this is a project which has legacy folder structure) + test/java (legacy folder for storing JUnit unit tests) has no .java programs and/or if test/java doesn't exist then create it first and then create the dummy file. I know, we could have uploaded jacocoagent.jar at some location on Jenkins server and use that file while starting Tomcat for getting code coverage for IT tests. The dummy test file we added requires junit:junit:4.10 or 4.11 library version for the :compileTestJava task to succeed.
compileJava {
doLast {
def dirName = "${projectDir}/test/java"
if(!file( "${projectDir}/src/test/java" ).exists())
if(!file( dirName ).exists())
new File( dirName ).mkdirs()
if(file( dirName ).exists()) {
def javaCnt = new FileNameByRegexFinder().getFileNames(dirName, /.*\.java/).size()
if(javaCnt == 0) {
def f = new File( dirName , 'DummyTestXYZ.java' )
def w = f.newPrintWriter()
w.println('import org.junit.Test;')
w.println('')
w.println('public class DummyTestXYZ {')
w.println('#Test' )
w.println('public void test() {')
w.println('}')
w.println('}')
w.close()
}
}
}
}
test {
doFirst {
testResultsDirName = "test-results/UT"
testReportDirName = "tests/UT"
}
maxParallelForks = 5
forkEvery = 50
//ignoreFailures = true
// Following Jacoco section is required only in Jenkins
// But a developer can uncomment them if they want this feature to work for their
// Desktop local Gradle builds.
jacoco {
//Following vars works only with versions >= 1.7 version of Gradle
destinationFile = file("$buildDir/jacoco/UT/jacocoUT.exec")
}
doLast {
if (file("${projectDir}/test/java/DummyTestXYZ.java").exists()) {
println "++"
println "++"
println "++"
println "======================================================="
println "DEV Team – Please add valid Unit tests in this project."
println "======================================================="
println "++"
println "++"
println "++"
sleep(30 * 1000)
new File("${projectDir}/build/classes/test").deleteDir()
new File("${buildDir}/jacoco/UT").deleteDir()
new File("${buildDir}/test-results/UT").deleteDir()
delete "${projectDir}/test/java/DummyTestXYZ.java"
}
}
}
//Do the same (as above test code) for any other similar test tasks like integartionTest, acceptanceTest etc..
jacocoTestReport {
//cleaning any compile time generated (for ex: JiBx classes files) so that jacoco task won't fail for not finding the actual source files (.java/.groovy for the compile time generated .class files)
doFirst {
delete fileTree (dir: "${buildDir}/classes", include: "**/JiBX_*.class")
}
group = "Reporting"
description = "Generate Jacoco coverage reports after running tests."
//ignoreFailures = true
executionData = fileTree(dir: 'build/jacoco', include: '**/*.exec')
reports {
xml{
enabled true
//Following value is a file
destination "${buildDir}/reports/jacoco/xml/jacoco.xml"
}
csv.enabled false
html{
enabled true
//Following value is a folder
destination "${buildDir}/reports/jacoco/html"
}
}
sourceDirectories = files(['src/java','src/main/java', 'src/main/groovy'])
classDirectories = files('build/classes/main')
doLast {
if (file("${projectDir}/test/java/DummyTestXYZ.java").exists()) {
delete "${projectDir}/test/java/DummyTestXYZ.java"
}
}
}

Jenkins for django project, failed build after many times successful building

I am using Jenkins to running my Django (Django=1.5.2, Python=2.7) project. Everything went fine before today. But now I tried to merge the updated file from git and got failed building, which stuck here:
[EnvInject] - Loading node environment variables. It took unreasonable long time and estimated running time shows N/A.
I didn't change any settings and environment variables. What is the problem?
PS:
There is one change I just found in Job Config History. Our IT guys (SYSTEM) added the code below:
<hudson.tasks.BuildTrigge>
<childProjects>PROJECT_NAME-Staging</childProjects>
<threshold>
<name>SUCCESS</name>
<ordinal>0</ordinal>
<color>BLUE</color>
<completeBuild>true</completeBuild>
</threshold>
</hudson.tasks.BuildTrigger