I added maven-antrun-plugin and I see a bunch of lines (see below) but I can I tell if the byte-weaving actually occurred? Seems like black magic to me :-). There doesn't appear to be anything different in the eclipselink log file when I run.
[INFO] --- maven-antrun-plugin:1.3:run (default) # austin-dbaccess ---
[INFO] Executing tasks
[java] [EL Config]: metadata: 2013-12-05 16:03:53.182--ServerSession(1858215506)--Thread(Thread[main,5,main])--The access type for the persistent class [class com.sss.dbaccess.TriggerJson] is set to [PROPERTY].
In persistence.xml add to your list of properties. In the log you should then see information about the weaving.
Related
I use cucumber testNG for my project and and already added some configuration based on Configuring BDD for execution and QAF Cucumber but when i run it, GherkinScenarioFactory not run any test.
[main] ERROR com.qmetry.qaf.automation.util.PropertyUtil - resources\application.properties (The system cannot find the path specified)
[main] INFO com.qmetry.qaf.automation.core.ConfigurationManager - ISFW build info: {qaf-Type=core, qaf-Revision=15, qaf-Version=2.1, qaf-Build-Time=20-N
ov-2019 22:28:06}
[main] ERROR com.qmetry.qaf.automation.core.ConfigurationManager - D:\Automation\resources not exist!
include groups []
exclude groups: [] Scanarios location: resources/features
[main] INFO com.qmetry.qaf.automation.step.client.gherkin.GherkinScenarioFactory - scenario.file.loc[Ljava.lang.String;#400cff1a
[main] INFO com.qmetry.qaf.automation.step.client.gherkin.GherkinScenarioFactory - total test found: 0
I've added the dependency qaf and also qaf-cucumber with version 2.1.15. I've also added the #QAFTestStepProvider annotation in the step file. Here's my testng.xml file :
<suite name="MyTest">
<test name="ComparationTest" >
<parameter name="step.provider.pkg" value="com.example.steps" />
<parameter name="scenario.file.loc" value="resources/features" />
<classes>
<class name="com.qmetry.qaf.automation.step.client.gherkin.GherkinScenarioFactory" />
</classes>
</test>
in the feature file I added : Examples: {'datafile': 'resources/data/data.xls'}
and last in cucumber runner I added plugin "com.qmetry.qaf.automation.cucumber.QAFCucumberPlugin"
I'm still learing, can somebody tell me what did i miss?
It looks that you are pointing to wrong location for resources and feature file/directory. You need to provide relative path to project root directory for resources and scenarios directory. If you observe the log also complains that fie/folder not exist.
[main] ERROR com.qmetry.qaf.automation.util.PropertyUtil - resources\application.properties (The system cannot find the path specified)
[main] INFO com.qmetry.qaf.automation.core.ConfigurationManager - ISFW build info: {qaf-Type=core, qaf-Revision=15, qaf-Version=2.1, qaf-Build-Time=20-N
ov-2019 22:28:06}
[main] ERROR com.qmetry.qaf.automation.core.ConfigurationManager - D:\Automation\resources not exist!
Make sure that you have resources directory under project root.
Regarding feature files, according to your current configuration
scenario.file.loc is resources/features. In that case make sure that <project-root>/resources/features is exist. For example your project root is D:/Automation then resources/features points to D:/Automation//resources/features
If not then provide correct relative path to project root.
For example resources/features expects <project-root>/resources/features if it is not there provide correct location.
Same is applied for other resources including properties file and test data files.
For application.properties it is expected under <project_root>\resources\application.properties if it is not there you can provide location by using system property application.properties=<relateive_path_to_project> or alternately place under default location <project_root>\resources.
As a side note,
instead of GherkinScenarioFactory recommended is BDD2 factory com.qmetry.qaf.automation.step.client.text.BDDTestFactory2
Latest version of qaf as of today is 3.1.0-RC1 the version you are using 2.1.15 is quite old.
I'd like to use a proprietary Apache CXF feature (Multipart handling for file upload), which is not covered in the JAX-RS 2.1 spec. Adding the following dependency to my Jakarta EE 8 project results in weird internal Apache CXF NPEs:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxrs</artifactId>
<version>3.3.4</version>
</dependency>
Errors:
[INFO] java.lang.NullPointerException
[INFO] [WARNING ] Exception in handleFault on interceptor org.apache.cxf.jaxrs.interceptor.JAXRSDefaultFaultOutInterceptor#5e2be3a2
[INFO] org.apache.cxf.interceptor.Fault
[INFO] [ERROR ] An unexpected error occurred during error handling. No further error processing will occur.
[INFO] org.apache.cxf.interceptor.Fault
[INFO] [ERROR ] SRVE0777E: Exception thrown by application class 'org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter:64'
[INFO] java.lang.NullPointerException
[INFO] at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
[INFO] at [internal classes]
[INFO]
[INFO] [ERROR ] SRVE0315E: An exception occurred: java.lang.Throwable: java.lang.NullPointerException
[INFO] at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:5075)
[INFO] at [internal classes]
[INFO] Caused by: java.lang.NullPointerException
[INFO] at org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor.filter(JAXRSBeanValidationInInterceptor.java:64)
[INFO] ... 1 more
My understandings from my research for this problem are, that the application can't access the internal CXF code, so the scope provided won't work and with my current solution (shipping the extension with the .war file) it leads to classloader problems.
I'm running on Open Liberty 19.0.0.12 and JDK 11
This is the expected behavior. Apache CXF has many features that go beyond the JAX-RS specification. In the past traditional WebSphere has suffered from problems where they used an open source product to provide some functionality, exposed all of that product's packages/classes, and then users would use them. The problem starts when users then want to pull in a different version or different module configuration of the open source product than what is available in the application server. So then users must package their own version of the product with their app or in shared library, and must resort to classloading tricks like parent-last to avoid loading IBM's version of that product - and this inevitably leads to classloading problems like ClassCastExceptions. The other disadvantage of this approach is that it painted IBM in a corner - for example, if the open source product is no longer supported (i.e. Apache Wink), IBM could not swap out open source products to provide an alternative that also implements the given specification.
Liberty takes a different approach. You can use the IBM-provided features or you can package the third party libraries in your app (or shared library). This solves both of the problems listed above - but does have implications for the scenario you've described.
There are a few different approaches to resolving your issue:
1) Open an issue (or give a +1 to an existing issue) with Open Liberty to officially support the CXF proprietary feature(s) that you are looking for. Depending on the feature requested, it might require using a different package name for the API or it might involve a configuration setting to enable, etc. You can do that here:
https://github.com/OpenLiberty/open-liberty/issues
2) Remove the jaxrs-2.1 feature from the feature manager list in your server.xml, and package the CXF libraries with your app. You would also need to package the JAX-RS API libraries.
3) You could create a user feature ( https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_feat_develop.html ) that exposes the CXF APIs. One note of caution here is that if you expose the org.apache.cxf packages, and then Liberty were to swap open source providers (i.e. switch to Jersey or RestEasy), then the org.apache.cxf packages would no longer be there. That would effectively prevent you from upgrading Liberty versions until you upgraded your user feature to package the CXF modules. Options 1 and 2 are certainly more future-proof.
Hope this helps! Andy
We are migrating JBOSS from 4.0.3SP1 to Wildfly 10.1.0. Our applications are bundled in separate sars which contain standard as well as Dynamic beans.
We are getting "javax.management.ReflectionException: The MBean class could not be loaded by the default loader repository" exception caused by "java.lang.ClassNotFoundException: com.xxx.ccr.common.adapter.PEAdapterLCM". Stack Trace is added in the end. PEAdapter class is a Dynamic MBean and is present in one of the jars in the common modules under /opt/coreservices/wildfly-10.1.0.Final/modules.
We are using standalone-full.xml to start our Wildfly instance (ccr2)
[root#puiqr710dev08 CCR]# ps -eaf|grep ccr2
xxxiq 28948 7529 21 15:17 ? 00:07:10 /opt/Xxx/CCR/jre/bin/java -verbose:class -Ddss.port=31002 -DCONTAINER_UUID=14132c5860baba870160bac5d84e084a -Dlcm.host= xxx.xxxx.xxx.xxx -server -XX:NewRatio=1 -XX:+UseG1GC -XX:+UseLargePages -XX:MaxGCPauseMillis=1000 -XX:GCTimeRatio=10 -XX:+DisableExplicitGC -Dsun.nio.ch.disableSystemWideOverlappingFileLockCheck=true -Ddss.thread_pool_size=24 -Xss250k -Xms256m -Xmx4096m -DUSE_DELAY1=60000 -DUSE_DELAY2=60000 -Dlog4j.configuration=file:/opt/Xxx/CCR/appserver/jboss-boot.log4j.properties -DLOG_FILE_PREFIX=DataProcessingJBoss_puiqdevdads07 -Ddss.message_lifetime=180 -Djava.awt.headless=true -Dorg.jboss.logging.Log4jService.catchSystemErr=false -classpath /opt/Xxx/CCR/jre/lib/tools.jar -jar /opt/coreservices/wildfly-10.1.0.Final/jboss-modules.jar -mp /opt/coreservices/wildfly-10.1.0.Final/modules -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir=/opt/coreservices/wildfly-10.1.0.Final -Djboss.server.base.dir=/opt/coreservices/wildfly-10.1.0.Final/ccr2 -Djboss.bind.address=xxx.xxxx.xxx.xxx -Djboss.bind.address.management= xxx.xxxx.xxx.xxx -c standalone-full.xml
· We have four sars that are deployed in this instance. All sars are deployed successfully.
· We have packaged our sars as follows:
--lib (contains all jars)
--META-INF
|--jboss-deployment-structure.xml
|--jboss-service.xml
· Each sar contains some standard MBeans and few Dynamic MBeans.
· We have defined standard MBeans in jboss-services.xml. They are created properly and can be seen in JConsole.
· We can NOT include definition of Dynamic MBeans in jboss-service.xml as their name is constructed at runtime.
· PEAdapterLCM for which we are getting ClassNotFoundException is a dynamic bean and we are getting this error for all Dynamic MBeans.
· We have created modules for all common jars that were part of “server/lib” folder in JBOSS 4.0.3SP1.
We tried following to fix this error but no luck:
1) packaged contents of all sars in one single sar and deployed it.
2) Added a global module entry in standalone-full.xml which contents dynamic MBeans.
3) Added definition of dynamic MBean in jboss-service.xml (just to see if this makes any difference). With this change, we were able to see the MBean in JConsole. But still got the same error.
So what should be done to fix this error. Are there any changes - how to implement and deploy Dynamic MBeans in Wildfly?
Is there any way in Wildfly we can explicitly mention the MBean server class while starting the Wildfly as it was done in JBOSS 4.0.3SP1 using "-Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl -Djboss.platform.mbeanserver -Dcom.sun.management.jmxremote"
Here is complete stack trace:
^[[0m^[[31m15:01:30,324 ERROR [com.xxx.coreservice.lifecycle.jmx.PEController] (MSC service thread 1-6) Exception in PEController:PEControllerJmxJBossService start for peID 14132c58609742440160974fe69307e0: : javax.management.ReflectionException: The MBean class could not be loaded by the default loader repository
at com.sun.jmx.mbeanserver.MBeanInstantiator.findClassWithDefaultLoaderRepository(MBeanInstantiator.java:104)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(DefaultMBeanServerInterceptor.java:268)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.createMBean(DefaultMBeanServerInterceptor.java:206)
at com.sun.jmx.mbeanserver.JmxMBeanServer.createMBean(JmxMBeanServer.java:326)
at com.avaya.lifecycle.jmx.agent.PEControllerJmx._start(PEControllerJmx.java:55)
at com.xxx.coreservice.lifecycle.jmx.PEController.start(PEController.java:397)
at com.xxx.coreservice.lifecycle.jmx.PEController.startAll(PEController.java:314)
at com.xxx.coreservice.lifecycle.jmx.PEController.startup(PEController.java:238)
at com.xxx.coreservice.lifecycle.jmx.PEController.postRegister(PEController.java:700)
at com.sun.jmx.mbeanserver.MBeanSupport.postRegister(MBeanSupport.java:182)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegister(DefaultMBeanServerInterceptor.java:1024)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:974)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1527)
at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:871)
at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:101)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: com.xxx.ccr.common.adapter.PEAdapterLCM
at com.sun.jmx.mbeanserver.ClassLoaderRepositorySupport.loadClass(ClassLoaderRepositorySupport.java:232)
Thanks for help in advance.
I Have followed steps given in the site to configure maven plugin. When I give "mvn evosuite:generate", it hangs with below detail in console.
[INFO] Going to start job for: com.emirates.gws.service.grouprequest.GroupRequestServiceImpl.
Following are the environment detail
Windows 7
maven-3.2.1
jdk1.7.0_72
Following are the detail shown in console
[INFO] --- evosuite-maven-plugin:0.2.0:generate (default-cli) # gws-grouprequest-implementation ---
[WARNING] The POM for org.slf4j:slf4j-api:jar:1.7.12 is missing, no dependency information available
[WARNING] The POM for org.ow2.asm:asm-all:jar:5.0.4 is missing, no dependency information available
[WARNING] The POM for dk.brics.automaton:automaton:jar:1.11-8 is missing, no dependency information available
[WARNING] The POM for com.googlecode.gentyref:gentyref:jar:1.2.0 is missing, no dependency information available
[WARNING] The POM for net.sf.jgrapht:jgrapht:jar:0.8.3 is missing, no dependency information available
[WARNING] The POM for commons-cli:commons-cli:jar:1.3 is missing, no dependency information available
[WARNING] The POM for org.kohsuke:graphviz-api:jar:1.1 is missing, no dependency information available
[INFO] Going to generate tests with EvoSuite
[INFO] Total memory: 800mb
[INFO] Time per class: 2 minutes
[INFO] Number of used cores: 1
[INFO] Target: D:\EGIT\Projects\GWS\Source\gws-project-MICE\gws-grouprequest\gws-grouprequest-implementation\target\classes
[INFO] Basedir: D:\EGIT\Projects\GWS\Source\gws-project-MICE\gws-grouprequest\gws-grouprequest-implementation
[INFO] SLF4J: Class path contains multiple SLF4J bindings.
[INFO] SLF4J: Found binding in [jar:file:/D:/EGIT/Projects/GWS/M2_REPO/org/evosuite/evosuite-master/0.2.0/evosuite-master-0.2.0.jar!/org/slf4j/impl/S
taticLoggerBinder.class]
[INFO] SLF4J: Found binding in [jar:file:/D:/EGIT/Projects/GWS/M2_REPO/org/evosuite/evosuite-runtime/0.2.0/evosuite-runtime-0.2.0.jar!/org/slf4j/impl
/StaticLoggerBinder.class]
[INFO] SLF4J: Found binding in [jar:file:/D:/EGIT/Projects/GWS/M2_REPO/ch/qos/logback/logback-classic/1.1.3/logback-classic-1.1.3.jar!/org/slf4j/impl
/StaticLoggerBinder.class]
[INFO] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
[INFO] SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
[INFO] * EvoSuite
[INFO] [MASTER] 21:49:11.703 [main] WARN ProjectAnalyzer - Cannot handle com.emirates.gws.service.payments.PaymentServiceImpl due to: class java.lan
g.ClassNotFoundException Method code too large!
[INFO] Going to execute 32 jobs
[INFO] Going to start job for: com.emirates.gws.service.grouprequest.GroupRequestServiceImpl
From your settings, it looks like you are using 1 core, 2 minutes per class, and trying to generate tests for 32 classes: this means it will take up to 64 minutes to complete. However, each time a new class is done (roughly every 2 minutes), you should get a new entry in the logs.
Btw, it seems you are using only 800MB of memory. Just in case, it is better to use some more, eg 1-1.5GB
Following is bit worrying:
[INFO] [MASTER] 21:49:11.703 [main] WARN ProjectAnalyzer - Cannot handle com.emirates.gws.service.payments.PaymentServiceImpl due to: class java.lan
g.ClassNotFoundException Method code too large!
Java does have limits on how large a method can be. EvoSuite needs to add some instrumentation on the bytecode to work, and that might lead to exceed the limit :(
Environment: hudson/sonar/maven2 in ubuntu locally with default parameters
And I got the log from hudson below, I can't figure out where is the problem.
[INFO] Sonar host: http://localhost:9000
[INFO] Sonar version: 2.0.1
[INFO] [sonar-core:internal {execution: default-internal}]
[INFO] Database dialect class org.sonar.api.database.dialect.Derby
[INFO] ------------- Analyzing Game of Life business logic module
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Can not execute Sonar
Embedded error: Can not analyze the project
Cannot stop. Current container state was: CONSTRUCTED
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Can not execute Sonar
And I notice it also has problem when run it command line without hudson
mvn sonar:sonar
I got this problem with .Net plugins for Sonar.
They needed all projects to be analyzed with JDK 6 (even non-.Net projects).
This error was raised when I tried to analyze projects with JDK 5.
Here is the URL of the .Net plugins : http://docs.codehaus.org/display/SONAR/.Net+plugin
The solution I got was to fork the compiler to use a JDK5 compiler on my projects which needed to be analyzed in JDK5 and not JDK6.
See on the .Net plugins page :
Maven and Sonar dotnet plugins need Java6 (at compile time and runtime)
What the sentence does not say is that all projects in your Sonar instance must use Java6.
A JIRA has been created : http://jira.codehaus.org/browse/SONARPLUGINS-1086 .
Got the hints from http://old.nabble.com/Another-%22Current-container-state-was%3A-CONSTRUCTED%22-problem-td28172925.html#a28194257
It seems the problem is inconsistency in maven plugins in my nexus repository, when I change to mirrors.ibiblio.org and clean the .m2 directory, everything goes fine.
BUT I don't know which plugins causes this problem and the log information is so wired, will be nice if some people points which plugin cause this problem and explain the reason for this error information