I am trying to find the code coverage (Not Test Cases) via JaCoCo on Weblogic
Below entry I gave under server -> server start arugment. I can see .exec file is generated at desired location but for every class it's coming as 0 %. Though I'm able to test the same with Windows + Tomcat its is working but I'm getting issue with weblogic on Linux box.
-javaagent:/apps/dev4/deploy/code-coverage/jacocoagent.jar=destfile=/apps/dev4/deploy/code-coverage/jacoco.exec,append=false,includes=*
You need to:
Check whether the JAVA Options are set or not.
Exclude those class files whose methods exceed the 64k limit.
Check the jvm version.
Related
First, important note: This is a project in which the Selenium/Cucumber test suite is working. It's working locally for the developers, and it's working in the Tekton environment.
Second: I have an identical IntelliJ environment as the developers. And other Selenium/Cucumber projects are running fine on my local machine.
When a try to run a fresh copy of the project in question locally, none of the tests start. And, there is no error message.
Normally, this will be cause by missing Glue parameters in the Run/Debug configuration, since IntelliJ for some reason often is unable to add these automatically. This is not the case here.
The test runner when I try to start a specific scenario:
Sorry for the language. The tests are all in Norwegian. But I don't think that matters for seeing the problem.
Normally, when there is an actual error regarding the test step - in the case "Gitt jeg er en vanlig søker" - there would be some info to the right of the steps overview. This is now blank, as can be seen. So, the test stes aren't even started.
The run/debug configuration:
e2e.cucumber.felles is the package where the Java file with the first step definition is located. So, that's not the reason.
Any ideas?
I am getting "Could not reserve enough space for object heap" error when I am trying to start hybris server.
I have set
wrapper.java.additional.1=-Xmx1G
wrapper.java.additional.2=-XX:MaxPermSize=1024M
My machine is 64 bit 8GB RAM Windows
I faced the same problem once, The problem in my case was that too many other Applications were running on my system.
So go to the task manager and check the memory available use.
Close some applications and try running.
Also if you are using eclipse Then, In your eclipse.ini file (this is beside the eclipse executable), replace -Xmx256m with -Xmx1024m (or Xmx512m).
This is not compulsory but in certain cases it works.
If you are using some extension then,
Open YOURPATH/config/local.properties file.
Add the following entry:
config/local.properties
build.parallel=true
Save the file.
(In cases where we have multiple cores in the machine, we can tell hybris to utilize these by building in parallel and in certain cases this too works)
I too faced the same probelm. I followed below steps and set the max heap size to 1GB.
Add the following content to local.properties
tomcat.generaloptions=-Xmx4G -ea -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=true -Djava.endorsed.dirs="%CATALINA_HOME%/lib/endorsed" -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Dfile.encoding=UTF-8 -Dlog4j.configuration=log4j_init_tomcat.properties -Djava.util.logging.config.file=jdk_logging.properties -Djava.io.tmpdir="${HYBRIS_TEMP_DIR}"
ant clean all
start hybrisserver
Reference
https://launchpad.support.sap.com/#/notes/0002437669
I am trying to get our Mavenized web application up and running in a freshly installed IDEA 11.1.4 Ultimate (Windows 7) under a freshly unzipped Glassfish 3.1.2.2. I have done this many times in Eclipse, but am not familiar with IDEA.
I can build and deploy it just fine, but when I try to access pages with JSP-content I get:
PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required
The Glassfish Application Servers entry adds the javax.ejb.jar, javax.servlet-api.jar and javax.servlet.jsp-api.jar as libraries.
I have set the project SDK to point to a full JDK resulting in:
(which does not seem to include a jar with javac)
The IntelliJ tutorials I've found so far, does not mention this problem. My guess would be that the "please start using this JDK" information is not passed on to Glassfish, so it just picks up the system JRE.
What configuration step have I missed? I do not want to edit configuration files - I expect the IntelliJ plugin to do this if I know how to tell it to.
I got the same notification and just changed in admin port -> Configurations -> server-config -> JVM Settings -> Java Home as "C:\Program Files\Java\jdk1.8.0_72", and it started working.
PWC6345: There is an error in invoking javac. A full JDK (not just JRE) is required.
I was getting same error after restarting my glassfish 4 server.When I am trying to access my deployed application it was saying to mention full JDK.
login to Glassfish admin console.(http://localhost:4848).
Go to Configuration---->server-config--->JVM Settings
Set the java home with your correct jdk home (ex:C:\Program Files (x86)\Java\jdk1.8.0_121).
Restart the server.
It will work fine.
Next solution helped me
source: http://alvinalexander.com/blog/post/java/fixing-glassfish-jdk-path-problem-solved
Find your asenv.bat file. C:\Program Files\glassfish-4.0\glassfish\config\asenv.bat
Open it in text editor and find strings like "set AS_ = blahblah"
Add this string there "set AS_JAVA=C:\Program Files\Java\jdk1.7.0_60" (print your own JDK path here). If string "set AS_JAVA= blahblah" already exists then just fix the path.
Add JDK_HOME\lib\tools.jar file to the JDK configuration Classpath.
However, the problem in your case may be different as Glassfish JDK is not taken from IntelliJ IDEA settings, this question may help:
How do I specify the jdk for a glassfish domain?
I am working on an Oracle OSB Build job using Jenkins.
The issue I am facing is: In the sbconfig.jar that's gets crated is not having the full service name.
Ex. If my OSB service name is EmployeeRecordDetailReturnsStorageBOService but in the sbconfig.jar its getting created as EmployeeRecordDetailReturnsStorageBOSer only.
I need the full service name in the sbconfig.jar for my further processing of this jar.
I am using the eclipse based jar <java dir="${eclipse.home}" jar="${eclipse.home}/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar" ...> in my ant build file.
But what I have observed is the java command that we are using has a folder length limit. It could not created the full service name in the sbconfig.jar because the ant build file is in a deep location under the folders like abcd/efgh/ijkl/mnop/qrst/xyz/build.xml so thats why its not able to create the full service name in the sbconfig.jar file. Its seems to be an character length issue in java/JVM.
Can anybody pls let me know how to to over some this problem.
It will not cause any issue when you will be importing the sbconfig.jar back into the sbconsole. So, do not worry about name getting shortened in sbconfig.jar.
If you are facing any issue while importing then let us know.
I have a few EJBs compiled with Weblogic's EJBC complient with Weblogic 9.2.1.
Our customer uses Weblogic 9.2.3.
During server start Weblogic gives the following message:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Consequently, server start takes 1.5 hours instead of 20 min. The next server start takes exactly the same time, meaning Weblogic does not cache the products of the recompilation. Needless to say, we cannot recompile all our EJBs to 9.2.3 just for this specific customer, so we need an on-site solution.
My questions are:
1. Is there any way of telling Weblogic to leave those EJB jars as they are and avoid the re-compilation during server start?
2. Can I tell Weblogic to cache the recompiled EJBs to avoid prolonged restarts?
Our current workaround was to write a script that does this recompilation manually before the EAR's creation and deployment (by simply running java weblogic.appc <jar-name>), but we would rather avoid this solution being used in production.
I FIXED this problem by spending a great deal of time researching
and decompiling some classes.I encountered this when migrating from weblogic8 to 10
by this time you might have understood the pain in dealing with oracle weblogic tech support.
unfortunately they did not have a server configuration setting to disable this
You need to do 2 things
Step 1.You if you open the EJB jar files you can see
ejb-jar.xml=3435671213
com.mycompany.myejbs.ejb.DummyEJBService=2691629828
weblogic-ejb-jar.xml=3309609440
WLS_RELEASE_BUILD_VERSION_24=10.0.0.0
you see these hascodes for each of your ejb names.Make these hadcodes zero.
pack the jar file and deploy it on server.
com.mycompany.myejbs.ejb.DummyEJBService=0
weblogic-ejb-jar.xml=0
This is just a Marker file that weblogic.appc keeps in each ejb jar to trigger the recompilation
during server boot up.i automated this process of making these hadcodes to zero.
This hashcodes remain the same for each ejb even if you execute appc for more than once
if you add a new EJB class or delete a class those entries are added to this marker file
Note 1:
how to get this file?
if you open domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX
you will see this file for each ejb.weblogic makes the hashcodes to zero after it recompiles
Note 2:
When you generate EJB using appc.generate them to a exploded directory using -output C:\myejb
instead of C:\myejb.jar.This way you can play around with the marker file
Step2.
Also you need a PATCH from weblogic.When you install the patch you see some message like this
"PATH CRXXXXXX installed successfully.Eliminate EJB recomilation for appc".
i dont remember the patch number but you can request weblogic for that.
You need to use both steps to fix the problem.The patch fixes only part of the problem
Goodluck!!
cheers
raj
the Marker file in EJBs is WL_GENERATED
Just to update the solution we went with - eventually we opted to recompile the EJBs once at the Customer's site instead of messing with the EJBs' internal markers (we don't want Oracle saying they cannot support problems derived from this scenario).
We created two KSH scripts - the first iterates over all the EJB jars, copies them to a temp dir and then re-compiles them in parallel by running several instances of the 2nd script which does only one thing: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (With error handling of course :))
This solution reduced compilation time from 70min to 15min. After this we re-create the EAR file and redeploy it with the new EJBs. We do this once per several UAT environment creations, so we save quite a lot of time here (55min X num of envs per drop X num of drops)