I am pretty green at arquillian and have some problem with it.
Could you please try out this (probably great) arquillian example for MDB:s?
https://github.com/mcs/arquillian-jms-mdb
I also downloaded the JBoss 7.2.0 from:
https://www.redpill-linpro.com/products/jboss/downloads-jboss-and-wildfly
I do not think you need any more setup actually, I bet you have a JDK installed already.
How ever, when I build it with mvn clean install, the container seems to start but the test is never executed. I just get:
Running com.github.mcs.arquillian.mdb.example.ExampleMDBBadTest
apr 17, 2018 3:20:37 EM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: ["C:\Program Files (x86)\Java\jdk1.8.0_92\bin\java", -Xmx768m, -XX:MaxPermSize=384m, -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y, -ea, -Djboss.home.dir=C:\Fredrik\Applications\jboss-as-7.2.0.Final, -Dorg.jboss.boot.log.file=C:\Fredrik\Applications\jboss-as-7.2.0.Final\standalone\log\boot.log, -Dlogging.configuration=file:/C:/Fredrik/Applications/jboss-as-7.2.0.Final/standalone/configuration/logging.properties, -Djboss.bundles.dir=C:\Fredrik\Applications\jboss-as-7.2.0.Final\bundles, -jar, C:\Fredrik\Applications\jboss-as-7.2.0.Final\jboss-modules.jar, -mp, C:\Fredrik\Applications\jboss-as-7.2.0.Final\modules, -jaxpmodule, javax.xml.jaxp-provider, org.jboss.as.standalone, -server-config, standalone-full.xml]
Listening for transport dt_socket at address: 8787
...nothing more happens.
Second, if I stop it and run again the port 8787 seems to still be in use, I need to kill the process from the task manger after finding out the PID.
I bet the example is great.
What do you think guys, what I'm I doing wrong?
Best regards
Fredrik
The message Listening for transport dt_socket at address: 8787 means that the JVM is suspended waiting for a debugger to connect to port 8787. If you take a look at the command which starts the JVM you'll see this system property:
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y
This is what tells the JVM to "suspend" and wait for a connection on 8787.
This system property is configured in the project's arquillian.xml
I got in touch with the author himself and he pointed out that I need to run with Java 7, so in my cmd I set:
set MAVEN_OPTS=-Xms512m -Xmx1024m
set PATH=%PATH%;C:\Fredrik\Applications\Maven\apache-maven-3.3.9\bin
set M2_HOME=C:\Fredrik\Applications\Maven\apache-maven-3.3.9
set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_75
cd C:\dev\git\test\arquillian-jms-mdb-master
I also noticed that I needed to add this property in the arquillian.xml
<property name="jbossHome">C:\Fredrik\Applications\jboss-as-7.2.0.Final</property>
Second I noticed that it seems like I have to set "suspend=n", else it just behave like before, it just stops and "Listening for transport dt_socket at address: 8787"
Third I noticed that I needed to add these lines to the pom, else I got
"Error assembling EJB: META-INF/ejb-jar.xml is required for ejbVersion 2.x"
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ejb-plugin</artifactId>
<configuration>
<ejbVersion>3.0</ejbVersion>
</configuration>
</plugin>
Please comment if you disagree to my "workarounds" above.
How ever I think this arquillian example is great and helped me a lot!
Best regards
Fredrik
Related
I have build a very simple project of hello world in
Payara 5 (5.181)
JSF 2.3
JDK 1.8
CDI 2.0
Maven
and encountered a problem
Unable to start server due following issues: Launch process failed with exit code 1
in console it throws an error of :
Error: Could not find or load main class server\payara5\glassfish.lib.grizzly-npn-bootstrap.jar
[PIC] Payara 5 Error
It seems that the Payara Tools for Eclipse suffer by several bugs that may cause this. In my case, the following workarounds helped:
The Payara installation path should not contain spaces (e.g. Program Files\Payara)
It seems that only Java 8 is supported at the time
Open the domain.xml configuration file for the domain you are trying to start (typically payara_install_path/glassfish/domains/domain1/config/domain1.xml) and search for "Xbootclasspath". You should find a couple of lines like
<jvm-options>[1.8.0|1.8.0u120]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.6.jar</jvm-options>
<jvm-options>[1.8.0u121|1.8.0u160]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.7.jar</jvm-options>
<jvm-options>[1.8.0u161|1.8.0u190]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.jar</jvm-options>
<jvm-options>[1.8.0u191|1.8.0u500]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
Depending of your installed Java version (try running java --version) and choose the appropriate line (most likely the last one). Remove the remaining lines and remove the [...] part at the beginning of the chosen line so you will get something like
<jvm-options>-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
After this, the tools seem to start normally.
The Problem is with Java version. The grizzly-npn-bootstrap-1.8.1.jar Jar is placed in bootclasspath, thats why it requires proper java version to start payara server. So remove unnecessary bootstrap jar from domain.xml.
In Windows:
1) Go To ---C:\Users\xxxx\payara5\glassfish\domains\domain1\config\domain.xml
2) According to my java verson(java version "1.8.0_191") I deleted the following lines from domain.xml. So delete according to your java version.
<jvm-options>[1.8.0|1.8.0u120]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.6.jar</jvm-options>
<jvm-options>[1.8.0u121|1.8.0u160]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.7.jar</jvm-options>
<jvm-options>[1.8.0u161|1.8.0u190]-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.jar</jvm-options>
3) Remove this [1.8.0u191|1.8.0u500] part from jvm-options & Edit the line in your domain.xml(w.r.t java -version) as shown below
<jvm-options>-Xbootclasspath/p:${com.sun.aas.installRoot}/lib/grizzly-npn-bootstrap-1.8.1.jar</jvm-options>
4) restart your server.
As Radkovo said, "The Payara installation path should not contain spaces (e.g. Program Files\Payara)", so I moved the Payara to the Documents folder.
Problem solved!
I am using open-source Pentaho distribution from github.com (version 6.1-SNAPSHOT).
In Spoon there are some step missing (e.g. There is no Mongodb input/output step listed) and I cant add dataservice to step (There are no errors, this option just isn't on the list).
I have reinstalled everything (removed .kettle and .pentaho directories as well as whole source and distribution) but it didn't help.
This is what I get at spoon startup:
16:05:50,304 INFO [KarafInstance]
* Karaf Instance Number: 1 at ~/pentaho-kettle/d
ist/./system/karaf//data1
Karaf Port:8801
OSGI Service Port:9050 *
Dec 23, 2015 4:05:51 PM org.apache.karaf.main.Main$KarafLockCallback
lockAquired
INFO: Lock acquired. Setting startlevel to 100
2015/12/23 16:05:53 - cfgbuilder - Warning: The configuration
parameter [org] is not supported by the default configuration builder
for scheme: sftp
Dec 23, 2015 4:05:58 PM
org.pentaho.caching.impl.PentahoCacheManagerFactory$RegistrationHandler$1
onSuccess INFO: New Caching Service registered
16:06:04,009 ERROR [KarafLifecycleListener] The Kettle Karaf Lifycycle
Listener failed to execute properly. Releasing lifecycle hold, but
some services may be unavailable.
I suspect that
ERROR [KarafLifecycleListener] The Kettle Karaf Lifycycle Listener
failed to execute properly. Releasing lifecycle hold, but some
services may be unavailable.
has something to do with it as missing plugins reside somewhere under karaf/ directory.
It was working just fine week ago.
I am using Ubuntu 15.04.
I will be grateful for any hints.
Greetings.
you are using a non stable release. this is the place where you can download the latest stable release http://sourceforge.net/projects/pentaho/
Agreed with jipipayo, For Pentaho CE version, download it from http://community.pentaho.com/ official instead of github. It is highly possible that the codes in github might be in unstable condition.
Also in case you have a missing plugin, try using the Pentaho Marketplace and download the required plugins.
Hope this helps :)
I am deploying a large Java project on Sonar using "Findbugs" as profile and getting the error below:
Caused by: java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
Java heap space
What i have tried to resolve this:
Replaced %SONAR_RUNNER_OPTS% with -Xms256m -Xmx1024m to increase the heap size in sonar-runner bat file.
Put "sonar.findbugs.effort" parameter as "Min" in Sonar global parameters.
But both of above methods didn't work for me.
I had the same problem and found a very different solution, perhaps because I'm having a hard time swallowing the previous answers / comments. With 10 million lines of code (that's more code than is in an F16 fighter jet), if you have a 100 characters per line (a crazy size), you could load the whole code base into 1GB of memory. I set it 8GB of memory and it still failed. Why?
Answer: Because the community Sonar C++ scanner seems to have a bug where it picks up ANY file with the letter 'c' in its extension. That includes .doc, .docx, .ipch, etc. Hence, the reason it's running out of memory is because it's trying to read some file that it thinks is 300mb of pure code but really it should be ignored.
Solution: Find the extensions used by all of the files in your project (see more here):
dir /s /b | perl -ne 'print $1 if m/\.([^^.\\\\]+)$/' | sort -u | grep c
Then add these other extensions as exclusions in your sonar.properties file:
sonar.exclusions=**/*.doc,**/*.docx,**/*.ipch
Then set your memory limits back to regular amounts.
%JAVA_EXEC% -Xmx1024m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m %SONAR_RUNNER_OPTS% ...
this has worked for me:
SONAR_RUNNER_OPTS="-Xmx3062m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m"
I set it direct in the sonar-runner(.bat) file
I had the same problem when running sonar with maven. In my case it helped to call sonar separately:
mvn clean install && mvn sonar:sonar
instead of
mvn clean install sonar:sonar
http://docs.sonarqube.org/display/SONAR/Analyzing+with+Maven
Remark: Because my solution is connected to maven, this is not the direct answer for the question. But it might help other users who stumple upon it.
What you can do it to create your own quality profile with just some Findbugs rules at first, and then progressively add more and more until you reach his OutOfMemoryError. There's probably only a single rule that makes all this fail because your code violates it - and if you deactivate this rule, it will certainly work.
I know this thread is a bit old but this info might help someone.
For me the problem was not like suggested by the top-answer with the C++ plugin.
Instead my problem was the Xml-Plugin (https://docs.sonarqube.org/display/PLUG/SonarXML)
after I deactivated it the analysis worked again.
You can solve this issue by increase the maximum memory allocated to the appropriate process by increasing the -Xmx memory setting for the corresponding Java process in your sonar.properties file
under SonarQube/conf/sonar.properties
uncomment below lines and increase the memory as you want:
For Web: Xmx5123m -Xms1536m -XX:+HeapDumpOnOutOfMemoryError
For ElasticSearch: Xms512m -Xmx1536m -XX:+HeapDumpOnOutOfMemoryError
For Compute Engine: sonar.ce.javaOpts=-Xmx1536m -Xms128m -XX:+HeapDumpOnOutOfMemoryError
The problem is on FindBugs side. I suppose you're analyzing a large project that probably has many violations. Take a look at two threads in Sonar's mailing list having the same issue. There are some ideas you can try for yourself.
http://sonar.15.n6.nabble.com/java-lang-OutOfMemoryError-Java-heap-space-td4898141.html
http://sonar.15.n6.nabble.com/java-lang-OutOfMemoryError-Java-heap-space-td5001587.html
I know this is old, but I am just posting my answer anyway. I realized I was using the 32bit JDK (version 8) and after uninstalling it and then installing 64bit JDK (version 12) the problem disappeared.
I've found a number of possible matches to this problem but none that work for me.
I'm using Apache Camel to deliver a file as an email attachement. It works perfectly using the following maven goals:
jetty:run
jetty:run-exploded
jetty:run-war
I'm using java 1.6. My deployment container is tomcat6. In tomcat6 and tomcat7 I get the following exception:
org.springframework.mail.MailSendException: Failed messages: javax.mail.MessagingException: Missing start boundary; message exception details (1) are:
Failed message 1:
javax.mail.MessagingException: Missing start boundary
at javax.mail.internet.MimeMultipart.parsebm(MimeMultipart.java:882)
The advice on the web suggests this is a class loader problem. Its either that the activation-1.1.jar or mail-1.4.4.jar files are not being found, or the mailcap file in mail-1.4.4.jar is not being found.
I've tried putting these jar files in tomcat/lib. I've tried copying the mailcap from the jar file into the META-INF directory of the exploded war. Neither of these make a difference.
Versions:
Windows: Apache Tomcat/7.0.5 JDK 1.6.0_27-b07 Apache Camel 2.8.0-fuse-00-08
Linux - the versions that come with ubuntu 10.04 LTS - I'll check these later and add.
This is a simplified version of my camel routes:
<route id="uploadFileForm">
<from uri="jetty:http://0.0.0.0:9095/premier"/>
<to uri="velocity:form.html"/>
</route>
<route id="uploadFile">
<from uri="jetty:http://0.0.0.0:9095/fup"/>
<to uri="log:mail?showBody=true&showHeaders=true"/>
<to uri="smtp://localhost"/>
<setHeader headerName="content-type"><constant>text/plain</constant></setHeader>
<setBody><constant>Message Sent</constant></setBody>
</route>
This is what the log shows:
[4 - seda://mail-ws-audio-files] mail INFO Exchange[ExchangePattern:InOut, Headers:{Connection=Keep-Alive, CamelHttpServletRequest=org.eclipse.jetty.servlets.MultiPartFilter$Wrapper#bb32c5, upfile=D:downloads!37SQFTS.pdf, CamelHttpPath=/fup, subject=BBC Premier League Update - Edition 1, CamelHttpQuery=null, CamelHttpServletResponse=HTTP/1.1 200
, UntilMessage=until 10:30 GMT when a second bulletin is available (Mon-Fri only), Host=localhost:9095, User-Agent=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E), Accept-Encoding=gzip, deflate, bulletin_type=am, to=julian.cable#yahoo.com, cc=admin#localhost, breadcrumbId=ID-B1-L0N336601-58958-1335935026761-0-2, CamelHttpUrl=http://localhost:9095/fup, Content-Length=24896, Referer=http://localhost:9095/premier, from=jfbcable#gmail.com, Accept=image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*, Accept-Language=en-GB, Content-Type=multipart/form-data; boundary=---------------------------7dc3a8371906f6, CamelHttpUri=/fup, Cache-Control=no-cache, CamelHttpMethod=POST}, BodyType:String, Body:Dear Partner,
please find attached the latest edition of our file.
A minimal example maven project is here and the war is here. If you run the project in eclipse or with
mvn jetty:run
and then use the form at http://localhost:9095/premier
You will get a "cannot contact server" exception. But if you deploy the war to tomcat you will get the missing start boundary exception. If you edit applicationContext.xml and replace the ** with valid values, it will actually send an email.
Any ideas?
I have tried your simplified camel route sample, it works well with mvn jetty:run.
In my Tomcat 7.0.27, Java 6, it actually works. The mail was sent correctly. The only difference is I don't use the:
mvn install
Instead using:
mvn package
Then copy the target/test-mail-0.0.1-SNAPSHOT.war to the Tomcat webapps folder, and start tomcat (bin/startup.sh or bin/startup.bat).
Hope this works for you as well.
My suggestion that you pick the same Tomcat version as I had and follow the same step.
Other source of problem you should:
Check is whether you have environment variable CATALINA_HOME or CATALINA_BASE unsuspectingly to you set to point to other Tomcat installation.
Also in the environment variable, check the content of your JRE_HOME or JAVA_HOME (when using JDK), and your CLASSPATH variable. You should set your classpath to $JAVA_HOME/jre/lib:$JAVA_HOME/jre/lib/ext:. or %JAVA_HOME%/jre/lib;%JAVA_HOME%/jre/lib/ext;. (the last dot is very important)
Substitute JAVA_HOME/lib with JRE_HOME if you are running on JRE only.
What version of JVM are you running. I am using Oracle JDK 6. Are you using OpenJDK/J9 or something else?
I've got a working solution to my problem, but not an answer to my question. My original route set works every way I've tried it except in Tomcat and requires no java code (of my own).
I've taken a brute force approach and moved the jetty generated attachement to the body, and then later in the route, move it back to an attachment. It gets me to something I can deploy, but its a hack.
Still looking for a way to deploy my original route set in Tomcat 6.
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.