I'm trying to partially mock a class from a signed Jar file (actually, the target class is in the Eclipse API).
Is there any way to do that with Mockito? I tried out several workarounds, but the result is always something like this:
org.mockito.cglib.core.CodeGenerationException:
java.lang.reflect.InvocationTargetException-->null
...
Caused by: java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.SecurityException:
class "org.eclipse.jdt.launching.AbstractJavaLaunchConfigurationDelegate$$
FastClassByMockitoWithCGLIB$$6e308a80"'s
signer information does not match signer information of other classes
in the same package
...
A Bit of Googling showed me that PowerMock might help me, but I would like to avoid introducing a new dependency for my project.
Thanks in advance!
I believe CGLIB had been tweaked to support signed packages, but there might be some issues.
Could you make a simple project, that demonstrate the problem and open an issue on the mockito project ?
Are you running the mocks inside OSGI ?
Brice
Related
I am getting following exception when trying to call feature file of another module from different module with logs as,
org.graalvm.polyglot.PolyglotException: TypeError: Access to host class utils.Utils is not allowed or does not exist.
Following is the file which I am trying to run as,
https://github.com/bipin-k/karate-automation/blob/master/sample-automation/src/main/java/sample.feature
https://github.com/bipin-k/karate-automation
karate error description
Please read this answer for hints on how to handle re-use across Java modules: https://stackoverflow.com/a/58339662/143475
Recommendation is to avoid it as far as possible. And things like call read('../../../../core-utilities/src/main/java/java-functions-calls.feature') lead to un-maintainable tests: https://stackoverflow.com/a/54126724/143475
Most likely the problem is because in the project where you make the call - the utils.Utils class is simply not on the Java "classpath". You should probably take the help of someone who knows Java well, or stick to a simpler "single module" Java project.
I'm trying to upgrade my applications from Liberty 18.0.0.1 to 18.0.0.2 but they all are now failing on:
java.lang.NoClassDefFoundError: javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter
...
stacktrace
the problem seems to be with ldapRegistry-3.0 - once that feature is enabled all jax-rs requests are failing. Once I remove ldapRegistry the code works fine, but I need this feature for my applications...
I've even built small example to demonstrate it, with single RestEndpoint /v1/api/employee : Sample project server config
Is this a bug, can I report it somewhere? or am I doing something wrong here?
Here is the server dump
Thank you
This seems to be caused by a subtle split package classloading conflict. I was able to reproduce this issue with Liberty 18.0.0.2 and the underlying exception looks something like this:
java.lang.NoSuchMethodException: javax.xml.bind.annotation.W3CDomHandler.createUnmarshaller(javax.xml.bind.ValidationEventHandler)
In this case it seems that javax.xml.bind.annotation.W3CDomHandler was loaded from classloader A, and javax.xml.bind.ValidationEventHandler was loaded twice -- once from classloader A and once from classloader B. The error we get here is caused by the JVM looking for javax.xml.bind.annotation.W3CDomHandler.createUnmarshaller(javax.xml.bind.ValidationEventHandler) where both classes are from classloader A, but instead it looks for a createUnmarshaller(ValidationEventHandler) method where ValidationEventHandler comes from classloader B.
This bug will be resolved in the next version of Liberty (18.0.0.3)
I am using OpenEJB in some unit (integration) tests for my database module, following this example here: http://tomee.apache.org/examples-trunk/application-composer/README.html
I am using an #Module annotation to provide PersistenceUnit java object as opposed to a 'test' persistence.xml file and I am overriding the provider to use hibernate (for specific reasons) as below.
unit.setProvider(org.hibernate.jpa.HibernatePersistenceProvider.class);
Using version 4.2.11.Final version of Hibernate this works fine, but in upgrading to 4.3.8.Final i am now getting an IllegalArgumentException stating that no persistence.xml exists.
Caused by: java.lang.IllegalArgumentException: File [FullParthToMyJar.jar:file:FullParthToMyJar.jar!/META-INF/persistence.xml] referenced by given URL [file:FullParthToMyJar/jar:file:FullParthToMyJar.jar!/META-INF/persistence.xml] does not exist
Is there anyway to stop this scanning from occuring as my project maven enforcer plugin is forcing me to use the later version.
Thanks.
Thanks for your response, but we ended up using a persistence.xml file to avoid losing time, which fixed the issue.
I'm triying to run a JavaFX Rest client using CXF. A very simple test. When I try to get an URL I get the org.apache.cxf.BusException: No conduit initiator was found for the namespace http://cxf.apache.org/transports/http. I took a look at some related questions here, but no luck. Any help would be appreciated.
Then only maven dependency I added was cxf-rt-rs-client 3.1.0
The code is:
WebClient client = WebClient.create("http://www.stackoverflow.com");
client.type("text/html").accept("text/html");
System.out.println(client.get());
Stacktrace:
Caused by: org.apache.cxf.BusException: No conduit initiator was found for the namespace http://cxf.apache.org/transports/http.
at org.apache.cxf.bus.managers.ConduitInitiatorManagerImpl.getConduitInitiator(ConduitInitiatorManagerImpl.java:110)
at org.apache.cxf.endpoint.AbstractConduitSelector.getSelectedConduit(AbstractConduitSelector.java:104)
at org.apache.cxf.endpoint.UpfrontConduitSelector.selectConduit(UpfrontConduitSelector.java:77)
at org.apache.cxf.message.ExchangeImpl.getConduit(ExchangeImpl.java:159)
at org.apache.cxf.interceptor.MessageSenderInterceptor.getConduit(MessageSenderInterceptor.java:71)
at org.apache.cxf.interceptor.MessageSenderInterceptor.handleMessage(MessageSenderInterceptor.java:46)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.jaxrs.client.AbstractClient.doRunInterceptorChain(AbstractClient.java:624)
at org.apache.cxf.jaxrs.client.WebClient.doChainedInvocation(WebClient.java:1100)
The shading overwrites bus-extension.txt file. Programmatically your can fix it by initializing it.
void initializeCxf() {
final Bus defaultBus = BusFactory.getDefaultBus();
final ConduitInitiatorManager extension = defaultBus.getExtension(ConduitInitiatorManager.class);
extension.registerConduitInitiator("http://cxf.apache.org/transports/http", new HTTPTransportFactory());
}
Based on the comment by #hba you can also try following in case the above does not work
extension.registerConduitInitiator("http://cxf.apache.org/transports/http", new HTTPTransportFactory(defaultBus));
You are fine with your Maven dependencies.
Client construction looks a bit off per CXF 3.x guides, wherein JAX-RS 2.0 is supported.
See AX-RS 2.0 Client API.
Try this code:
WebTarget target = ClientBuilder.newClient().target("http://stackoverflow.com/");
Response response = target.request().get();
System.out.println(response.getEntity().getClass().getName());
Using this code, you will learn the response entity is an input stream .. a sequence of characters being the HTML content of the StackOverflow home page.
If you're feeling adventurous, and to demonstrate I'm not a charlatan, add the following dependency to your POM:
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
<version>1.3.2</version>
</dependency>
and then attempt this:
WebTarget target = ClientBuilder.newClient().target("http://stackoverflow.com/");
System.out.println(IOUtils.toString((InputStream) target.request().get().getEntity(), "UTF-8"));
You will be rewarded with a textual rendering (on standard output) of the StackOverflow home page – equivalent to performing a "view source" operation in your browser.
I don't know what your ultimate goal is, but if you're attempting to build anything useful from information on the StackExchange network, I suggest use of their APIs documented here.
Best of luck!
I got the same exception when using Apache CXF REST client in JavaFX project. The code is below:
MyClass rest = (MyClass) JAXRSClientFactory.create(endpoint, MyClass.class, Collections.singletonList(new JacksonJsonProvider()));
System.out.println("Service health: " + rest.health());
A test with plain Java project works fine with the same code and same dependencies. It is apparently a conflict between JavaFX and Apache CXF. I am trying to figure out why.
If you guys already solved this issue, that should be great to update this thread, which is the only result on Google search.
Updated solution:
After a while, I found that the default Maven project does not include enough the dependencies in the plugin "maven-dependency-plugin". I tried to add more packages in the list but still not work. So the final solution is in this thread: How to package an Apache CXF application into a monolithic JAR with the Maven "shade" plugin. Shade plugin is much better and works.
Trying my hand at CDI for the first time. I'm using Glassfish v3. When I deploy my app, I get the following failure:
java.io.IOException:
com.sun.enterprise.admin.cli.remote.RemoteFailureException:
Exception while loading the app :
org.glassfish.deployment.common.DeploymentException:
java.lang.IncompatibleClassChangeError:
com.example.arizona.client.ArizonaService
and
com.example.arizona.client.ArizonaService$App
disagree on InnerClasses attribute
at
com.fuhrer.idea.glassfish.server.GlassfishServer3.doParseResponse(GlassfishServer3.java:28)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.parseResponse(GlassfishServer3Base.java:156)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.invoke(GlassfishServer3Base.java:127)
at
com.fuhrer.idea.glassfish.server.GlassfishServer3Base.handleDeployment(GlassfishServer3Base.java:78)
at
com.fuhrer.idea.javaee.server.JavaeeServerInstance$2.run(JavaeeServerInstance.java:131)
I should mention that I'm not even actually using injection, or any other CDI features yet. This is just trying to get the dependencies straightened out.
I've had the same issue, but with Weld in Tomcat. Problem for me was caused by changing an inner class definition to a normal class. Resulted, in my case, in having the old innerclass still in the classes directory but with a new parent class.
Cleaning the classes directory worked for me.
Nearly a year later I'm sorry to say that I never solved this, and for various reasons moved on to another stack altogether: Tomcat, Wicket and Wicket-CDI, all of which have worked great for me.