I am trying to upgrade to Jersey 2.26. I have added the new hk2 dependencies that are needed:
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
</dependency>
I use the jersey-bom 2.26.
I use Genson for JSON binding, like this:
Genson genson = new GensonBuilder().withBundle(new JAXBBundle()).setSkipNull(true).create();
rc.register(new GensonJaxRSFeature().use(genson));
Formerly, everything worked fine, now some of my tests fail with a somewhat cryptic NPE:
java.lang.NullPointerException
at org.eclipse.yasson.internal.serializer.DeserializerBuilder.isJsonValueEvent(DeserializerBuilder.java:155)
at org.eclipse.yasson.internal.serializer.DeserializerBuilder.build(DeserializerBuilder.java:110)
at org.eclipse.yasson.internal.Unmarshaller.deserializeItem(Unmarshaller.java:56)
at org.eclipse.yasson.internal.Unmarshaller.deserialize(Unmarshaller.java:50)
at org.eclipse.yasson.internal.JsonBinding.deserialize(JsonBinding.java:45)
at org.eclipse.yasson.internal.JsonBinding.fromJson(JsonBinding.java:85)
at org.glassfish.jersey.jsonb.internal.JsonBindingProvider.readFrom(JsonBindingProvider.java:99)
Funny thing, that if I run from Eclipse it all works out.
Does anyone have hints on debugging/troubleshooting this? It is a rather large project (with rest-client modules etc), so it is difficult to post relevant code without knowing which parts are interesting..
Related
I'm using Intellij Idea 2022.2.3, while I wanna use jetty runner, the lastest jetty version is 1.4.20, and I got an error as below:
com.intellij.diagnostic.PluginException: The default implementation of method 'getId' is deprecated, you need to override it in 'class com.github.guikeller.jettyrunner.conf.JettyRunnerConfigurationFactory'. The default implementation delegates to 'getName' which may be localized, but return value of this method must not depend on current localization. [Plugin: JettyRunner-GK]
at com.intellij.diagnostic.PluginProblemReporterImpl.createPluginExceptionByClass(PluginProblemReporterImpl.java:23)
at com.intellij.diagnostic.PluginException.createByClass(PluginException.java:83)
at com.intellij.diagnostic.PluginException.reportDeprecatedDefault(PluginException.java:110)
at com.intellij.execution.configurations.ConfigurationFactory.getId(ConfigurationFactory.java:75)
at com.intellij.execution.impl.RunnerAndConfigurationSettingsImpl.writeExternal(RunnerAndConfigurationSettingsImpl.kt:265)
at com.intellij.execution.impl.RunnerAndConfigurationSettingsImpl.writeScheme(RunnerAndConfigurationSettingsImpl.kt:321)
at com.intellij.configurationStore.LazySchemeProcessor.writeScheme(scheme-impl.kt:65)
at com.intellij.execution.impl.RunConfigurationSchemeManager.writeScheme(RunConfigurationSchemeManager.kt:121)
at com.intellij.execution.impl.RunConfigurationSchemeManager.writeScheme(RunConfigurationSchemeManager.kt:21)
at com.intellij.configurationStore.schemeManager.SchemeManagerImpl.saveScheme(SchemeManagerImpl.kt:393)
at com.intellij.configurationStore.schemeManager.SchemeManagerImpl.save(SchemeManagerImpl.kt:333)
at com.intellij.configurationStore.Scheme_implKt.save(scheme-impl.kt:164)
at com.intellij.execution.impl.RunManagerImpl.getState(RunManagerImpl.kt:643)
at com.intellij.execution.impl.RunManagerImpl.getState(RunManagerImpl.kt:78)
at com.intellij.configurationStore.ComponentStoreImpl.commitComponent(ComponentStoreImpl.kt:334)
at com.intellij.configurationStore.ComponentStoreImpl.commitComponents$intellij_platform_configurationStore_impl(ComponentStoreImpl.kt:240)
at com.intellij.configurationStore.ComponentStoreWithExtraComponents.commitComponents$intellij_platform_configurationStore_impl(ComponentStoreWithExtraComponents.kt:94)
at com.intellij.configurationStore.ComponentStoreImpl$commitComponentsOnEdt$$inlined$withEdtContext$intellij_platform_configurationStore_impl$1.invokeSuspend(ComponentStoreImpl.kt:723)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution$Companion$scheduleWithinConstraints$1.invoke(BaseConstrainedExecution.kt:68)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution$Companion.scheduleWithinConstraints(BaseConstrainedExecution.kt:71)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution.scheduleWithinConstraints(BaseConstrainedExecution.kt:38)
at com.intellij.openapi.application.impl.BaseExpirableExecutorMixinImpl.access$scheduleWithinConstraints$s1153900543(BaseExpirableExecutorMixinImpl.kt:12)
at com.intellij.openapi.application.impl.BaseExpirableExecutorMixinImpl$scheduleWithinConstraints$$inlined$Runnable$1.run(Runnable.kt:19)
at com.intellij.openapi.application.TransactionGuardImpl.runWithWritingAllowed(TransactionGuardImpl.java:209)
at com.intellij.openapi.application.TransactionGuardImpl.access$100(TransactionGuardImpl.java:21)
at com.intellij.openapi.application.TransactionGuardImpl$1.run(TransactionGuardImpl.java:191)
at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:881)
at com.intellij.openapi.application.impl.ApplicationImpl$3.run(ApplicationImpl.java:513)
at com.intellij.openapi.application.impl.FlushQueue.doRun(FlushQueue.java:75)
at com.intellij.openapi.application.impl.FlushQueue.runNextEvent(FlushQueue.java:118)
at com.intellij.openapi.application.impl.FlushQueue.flushNow(FlushQueue.java:42)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:779)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:730)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:724)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:749)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:918)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:766)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$6(IdeEventQueue.java:450)
at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:791)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$7(IdeEventQueue.java:449)
at com.intellij.openapi.application.TransactionGuardImpl.performActivity(TransactionGuardImpl.java:105)
at com.intellij.ide.IdeEventQueue.performActivity(IdeEventQueue.java:624)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$8(IdeEventQueue.java:447)
at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:881)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:493)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:207)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:92)
It looks like that plugin is out of date with your version of Intellij. It seems like the plugin has not been updated recently and is looking for a new maintainer.
You could
fork it and make the changes suggested in the error message (it doesn't seem like it would be too complicated)
Downgrade your intellij - probably a bad idea, but if you are really in a pinch might be the fastest way to get past this
Find an alternate solution; perhaps use the jetty maven plugin which appears to be still supported and has easy commands to run jetty (which can be put into an intellij run configuration)
I would recommend the last way. If you are already using maven, it will be pretty easy. If you are not using maven then it is a good opportunity to learn how to use it as it is very helpful for managing java projects
Although I am looking for a new maintainer I still am maintaining the plugin.
Please raise an issue on GitHub so this can be fixed, cheers!
Project link: https://github.com/guikeller/jetty-runner
PS: raised an issue on your behalf:
https://github.com/guikeller/jetty-runner/issues/81
I love the maven-versions-plugin but sometimes I forget to run it for a while. Is there a way to make a maven build fail (and thus have a continuous build fail) when certain important dependencies are out of date?
I think you're approaching this incorrectly. Mail yourself the output of the maven-versions-plugin if you want, but don't fail the build due to changes outside of your control.
Even more, why would you want to needlessly update to the latest versions? I have seen many tricky problems appear due to upgrades which have brought slight changes to previous behaviour.
This, in general, is a bad practice - to update versions automatically. There is no practical reason of using the latest version of any package. If the library you're using satisfies your requirements you should stay with this version for security/stability reasons. And forever.
I think that maven-versions-plugin is an anti-pattern itself.
ps. When and if you want to do integration testing of modules developed by different teams/programmers, it is "integration testing". Even in this case I still think that on-fly version updating is the wrong approach. Root project should not do this integration testing, instead, every sub-module (or JAR, in your case), has to be responsible for integration testing of itself together with the rest of the system. When a sub-module increases its version it has to validate whether everything is still fine, and only then has to release a new version to the repository. And when the sub-module is doing the validation it has to be dependent on statically specified version numbers.
We're using Maven at work at quite regularly we get the error message "The artifact has no valid ranges". After a long time of Googling and experimenting I realised what this error message means: The artifact does have valid ranges, just too many of them.
For example, my master POM has a dependency on superframework v.1.0 only, but there is also a transitive dependency on superframework v.0.5-0.9.
Until now, whenever I had such a problem I've looked at the (very cryptic) error message and sorta guessed which POM I needed to change - basically a lot of trial an error. The problem is that mvn dependency:tree doesn't work if you have a dependency resolution problem.
The Eclipse plugin sometimes helps a little, but sometimes it is way off.
Any tips on how to resolve these problems?
This might not be the expected answer but my advice would be to actually not use dependency ranges as they worsen build reproducibility.
I prefer to use fixed versions (which also make dependencies conflicts resolution easier, see the note at the bottom of 9.4.3. Dependency Version Ranges) and use intensively the Dependency Convergence report to manage them.
This isn't a direct answer to my question but rather a word of advice. I learned something new since askin the question: the order in which dependencies are listed in the POM files, much to my surprise, does matter.
So, if you include a dependency on
superframework [0.5,1.5)
it will fetch the latest available version, say 1.1.
If you then have a transitive dependency further down that includes
superframework [0.5, 1.0)
Maven will generate this misleading error, since it will not select anything other than the 1.1 it already has, even though it could just select 0.9 without producing a version conflict. If you swap the order, weirdly, it works.
Am I right in thinking that this is a flaw in Maven's behaviour?
I have a project that builds with maven2 and runs a series of JUnit test cases against the code. This has worked fine up until this point, where I now have 2 tests that must run in a certain sequence for things to work correctly, let's say TestA and Test (A then B). Unfortunately, maven2 doesn't understand this, so I'm looking for a way of convincing it that it needs to run the tests in this order.
The problem is that I'm setting some final static fields in TestB, but I'm doing this from TestA, which itself uses those fields, and successful execution of the test depends on those fields being set to their new values (there is absolutely no way around this, otherwise I would have taken that road long before now). So, it is imperative that TestA loads first, and it will of course cause TestB to be loaded when tries to access it. However, maven2 has decided that it will run TestB then TestA, which means those final fields are already set and cannot be changed.
So what I'm looking for is either a way to specify the order in which the tests are executed (A then B, every time), or a way to easily cause TestB to be reloaded by whichever classloader that JUnit uses.
EDIT - one other option might be some option like the old JUnit GUI tool has, that causes all classes to be reloaded for each test. I have looked and looked and not found such a flag in the maven junit plugin, if such a thing exists, then that would also work.
Fork mode can force each test to run in its own JVM so every class is re-loaded for each test.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>pertest</forkMode>
</configuration>
</plugin>
The test order in JUnit is intentionally undefined, this is not a Maven issue and it's probably just luck that your tests were running OK up until now.
Sal's answer addresses your question directly, however forking the JVM on each test for large test counts can hugely increase your build time.
An alternative approach would be to use a testing library such as PowerMock (it currently works with EasyMock and Mockito) to clear the static fields in TestB's initialisation, this avoids the need for any JVM forking, and ensures your tests are portable.
From the PowerMock website:
PowerMock is a framework that extend other mock libraries such as EasyMock with more powerful capabilities. PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more. By using a custom classloader no changes need to be done to the IDE or continuous integration servers which simplifies adoption. Developers familiar with EasyMock will find PowerMock easy to use, since the entire expectation API is the same, both for static methods and constructors. PowerMock extends the EasyMock API with a small number of methods and annotations to enable the extra features. From version 1.1 PowerMock also has basic support for Mockito.
I am currently in the process of replacing the IBM WebService framework with Axis2. When generating the code from the WSDL file, I use the Maven plugin WSDL2Code. However, the code created is always wrong. Or rather, the packagenames are always wrong, which in turn makes every method called uncallable (creating even more errors, up to 10.000+ errors in eclipse).
Here's an example of what is actually going on (this is just an example I made specifically to get advice):
<plugin>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-wsdl2code-maven-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>Test</id>
<goals>
<goal>wsdl2code</goal>
</goals>
<configuration>
<packageName>test.testpackage</packageName>
<databindingName>xmlbeans</databindingName>
<wsdlFile>${basedir}/wsdl/service.wsdl</wsdlFile>
<outputDirectory>${basedir}/testdirectory</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
In theory, this should generate code with the package name "test.testpackage" in the directory testdirectory/test/testpackage. However, instead it creates the following package: Src.test.testpackage in the directory testdirectory.src.test.testpackage. It always adds a "src" to both package name and directory - if I change the package name to src.test.testpackage, it will generate the following package: src.src.test.testpackage.
This, of course, leads to a huge problem, because every generated file has the following error:
"The declared package "src.test.testpackage" does not match the expected package
"src.src.test.testpackage"
I'm at a complete loss here. I simply can't find any reason at all why it should add "src" everywhere. I've noticed an auto-generated build.xml file containing a value called sourcedirectory = x/src (or something similar), but there's nothing I can do to affect this value (trying to change it and then save the file makes no difference, obviously, since it's just generated again the next time I run maven).
Oh, and I generally use the command "mvn clean install" and version 1.4.1 of WSDL2Code, so it's not one of the old wsdl2code:wsdl2code bugs.
If anyone has any idea of what is actually wrong here, I'd greatly appreciate it.
Thanks in advance.
Version 1.4.1 has a few more configuration options that are not really documented (have a look at the the source of org.apache.axis2.maven2.wsdl2code.WSDL2CodeMojo)...
Just use <flattenFiles>true</flattenFiles> - that should solve your problem :-)
This question is quite old, so I don't know if you're still having the problem...
I would recommend using Axistools Maven Plugin instead, it worked great in our case.
Maybe 'src' is part of ${basedir} ?
I'm afraid not. Even if it was, the strange problem shouldn't occur then - the path would then be correct being testdirectory/src/test/testpackage, thus causing no problem with the package name. The problem now arises because it is placed in a directory the package does not expect - it expects ${basedir}/testdirectory/insert.package.here.divided.by./, but instead it gets ${basedir}/testdirectory/src/insert.package.here.divided.by./.
The src should not be present in that part of the path.
This is connected with those "genius" of(or user of) maven/axis2 that practically takes decisions for you ... see this:
[Axis2 mailing list entry][1]
[1]: http://markmail.org/search/?q=[Axis2]+indrit#query:[Axis2 Mailing List entry]%20indrit+page:1+mid:a34wbp7l3pljagsz+state:results