I use JMockit in functional tests. I need to mock classes which are deployed on jetty server.
That classes were loaded with WebAppClassLoader, so I can't mock them because JMockit uses AppClassLoader.
URLClassLoader
|
|-Launcher$AppClassLoader
|-WebAppClassLoader
Questions:
How to make jetty-server classes visible to JMockit?
Is it possible to specify JMockit ClassLoader?
Related
After using micronaut-inject for dependency injection if new bean is created we have to use --rerun-tasks flag in order for kapt to work otherwise its not injecting newly created beans
seems gradle cache issue
What can be the possible solution or configuration that might be missing
When testing Eclipse RCP plugins, it is good practice to have all test classes and resources live in a dedicated (test) fragment.
This way all classes in the host plugin can be accessed, no matter if those packages are actually exported or not.
But what if I have a common test infrastructure, that is used by many plugins?
I cannot put this into a fragment, since I cannot reuse classes inside a fragment somewhere else.
A fragment does not exist at runtime. It is merged with its Fragment-Host.
You either need to place the code in a regular bundle/plug-in, or use a poxy bundle that exposes the classes of the fragment to be accessible from other fragments or bundles. For example:
Host
Bundle-SymbolicName: org.example.test.util
Eclipse-ExtensibleAPI: true
Fragment
Bundle-SymbolicName: org.example.test.util.impl
Export-Package: org.example.test.util.impl
Fragment-Host: org.example.test.util
However, the latter approach uses the Eclipse-specific Extensible-API header that is only understood by the Equinox OSGi implementation.
Therefore, my recommendation would be to leave the actual test classes in a fragment that corresponds to the bundle-under-test and put the reusable test helpers in a dedicated bundle.
I am using Anypont Studio 5.3.0 and server runtime 3.7.0. I want to invoke a main() method from my component. Application is developed using Maven, SpringBoot and JPA. It sits in the jar file and have the following structure.
com
package
Application.class (with main method)
another package
Other classes
lib
other jars
META-INF
persistance.xml
MANIFEST.MF
Org
springframework boot loader and other spring classes.
when file arrives with file pattern that I detect with mule polling component I would like to invoke Java component in mule flow that has main class and all the supporting classes.
Thanks,
David
did you mavenize your Application? If yes, you can add that as a dependency in your mule project pom, which is also mavenize. But you need to make sure that the jars are added in your maven repository i.e. execute first "mvn clean install" to your java application. Otherwise, add the jars in you build path. When you are able to do those, you can create a spring bean or create a java component in mule where they could call your class with main() method.
I never came across this kind of production scenario where there is a need to call main method of java class in enterprise application. Are you sure you have only main method to access other classes, it should have initialize, spring way of injection etc. Simple answer to you question, create a mule java component and override onCall method to call Application(class).main. I will never do this kind of stuff [for sure it will give more problems based on what is being written in main method]. In general we will use main method invocation in desktop application. if possible work on (or let the application team to work on) jar file to have better initializing options
I am following this article: http://www.softwarepassion.com/it-coverage-with-arquillian-jacoco-extension/ to get test coverage for arquillian integration tests. My project is a multi module though and I don't know where to put the plug in and dependencies. Is it in the top pom, the artifact-making module or in the integration test module?
Thank you
To some extent it depends on the details of your Maven setup, which aren't in your question. Here is some general advice.
1) Where should you put the arquillian-jacoco and jacoco dependencies?
These dependencies should probably go wherever the rest of your Arquillian dependencies are. My understanding is that it is simply having these dependencies that triggers Arquillian to use JaCoCo, not the plugin declaration; even if these dependencies are in a parent of the POM with the actual Arquillian tests, the Arquillian test classes should still be instrumented. You wouldn't put these dependencies in a sibling module to the module with the tests though as they need to be inherited by the integration test module (unless this sibling module has been declared as a dependency of the test module of course).
2) Where should you put the JaCoCo plugin declaration?
As noted above, you may not even need this declaration, depending on what you are trying to achieve. If you want to generate a report, rather than just the jacoco.exec files, then you will need to declare the plugin and an execution with the report goal. You may also want to declare the plugin with the prepare-agent goal if you have other tests that you wish to be instrumented with JaCoCo, such as unit tests.
If you are going to declare the plugin, it can be treated the same way as any other Maven plugin. If you want to run JaCoCo across multiple modules by default you could choose to put the plugin declaration in your parent POM within the regular 'plugins' tag and have it inherited by all child modules, or you may wish to put it in the parent POM within the 'pluginManagement' element so the configuration can be inherited (see http://maven.apache.org/pom.html#Plugin_Management). Alternatively, if you only want to run Arquillian tests in your integration test module, you could also simply declare the plugin in this module's POM (given that you want a report, and without the prepare-agent goal if you're only instrumenting Arquillian tests).
Hope that helps!
I have an .ear file with the standard lib directory.
I have a .jar file in that lib directory. It contains UserInfoManager, which is an interface. It contains (for these purposes) no other classes. It also contains a META-INF/beans.xml file.
I have another .jar file in that lib directory. It contains a class named UserInfoResource that is a JAX-RS resource class. That class has the following inside it:
#Inject
private UserInfoManager userManager;
Next, I have an EJB .jar file at the root of the .ear file. It contains a class named UserManagerBean that implements the UserInfoManager interface. This class is annotated with #Stateless and basically nothing else (thus making it a local stateless session bean exposed via its local business interface (UserInfoManager). This .jar file also has a META-INF/beans.xml file.
Next, I have a .war file with an Application class in it and nothing else. This serves as the "mounting point" for any and all JAX-RS resources discovered at deployment time present in the lib directory. I do not declare this Java EE 6 module as a CDI bean archive since it contains no beans.
This spec-compliant arrangement fails at deployment time. Weld (the CDI implementation in GlassFish 3.1.2) claims that the injection point detailed above cannot be satisfied, as there are no known implementations of UserInfoManager available to it.
When that injection point is annotated with #EJB instead, everything works fine.
How do I get CDI to inject a local stateless session bean reference into a JAX-RS resource that is present on the classpath?
Update: Because no matter how I look at this it seems like a specification violation, I have filed a bug with a testcase attached. I encourage readers to take a look and see if they can get it to work.
Update: The workaround is to make sure that your JAX-RS classes are not bean archives, but are annotated with #ManagedBean. In addition, the {{.war}} file that serves as their mount point must be a bean archive (must have a {{WEB-INF/beans.xml}} file). Some combination of these requirements is a CDI specification violation. The following bug tracks these issues: http://java.net/jira/browse/GLASSFISH-18793
Jersey does not treat Resources as managed beans unless there is an explicit scope/#ManagedBean annotation attached to it. So, you need to annotate your resource with #ManagedBean or #RequestScoped for the injection to work.
Seems the problem occurs only if beans.xml is included in the resource jar file. When I remove it and attach #ManagedBean annotation to the resource class (instead of #RequestScoped, since #RequestScoped does not work if no beans.xml is present) it works. I am not a CDI expert, so not sure if this is as designed or a bug.