Getting this message in .log:
!ENTRY org.eclipse.help.base 2 0 2021-03-02 16:03:03.323
!MESSAGE Unable to consume Lucene index from bundle 'org.eclipse.wst.dtdeditor.doc.user_1.1.0.v201903222120 [425]'. The index should be rebuilt with Lucene 8.4.1
Basex version: 9.5.1
Platform: Mac OS 10.13.6
Java: 1.8.0_251-b08
Eclipse: 2020-03
Lucene version in POM: org.apache:lucene-stemmers:3.4.0
Does this matter?
Thanks, Christian.
The fact is that I can't reproduce it. Combining this with the fact that I have no plans to work with non-English data, I must conclude that no identifiable issue exists.
Arthur
Related
After upgrading to jooq 3.17.1 I get the following error:
Error:
/home/runner/work/waste-coordinator/waste-coordinator/webapp/target/generated-sources/jooq/com/myapp/portal/backend/jooq/tables/LoadView.java:[521,84]
text blocks are not supported in -source 11 Error: (use -source 15
or higher to enable text blocks)
It appears to me that it is generating source that is not compatible with JDK11. Is there a flag in the generator somewhere that can make it generate JDK 11 compatible code?
Edit: now I am getting the following compile error
[ERROR] COMPILATION ERROR : [INFO]
------------------------------------------------------------- [ERROR] /usr/local/code/sferion/WasteCoordinator/data/src/main/java/com/wastecoordinator/data/JOOQGenerator.java:[4,24]
cannot access org.jooq.codegen.GenerationTool bad class file:
/Users/benstpierre/.m2/repository/org/jooq/jooq-codegen/3.17.1/jooq-codegen-3.17.1.jar(/org/jooq/codegen/GenerationTool.class)
class file has wrong version 61.0, should be 55.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
Is jooq 3.17 not compatible with JDK 11?
You can download the right distribution to work with JDK 11 from here if you're licensed:
https://www.jooq.org/download/versions
Note that starting from jOOQ 3.17, the jOOQ Open Source Edition increased the baseline JDK version to Java 17, see:
https://github.com/jOOQ/jOOQ/issues/12430
https://blog.jooq.org/3-17-0-release-with-computed-columns-audit-columns-pattern-matching-reactive-transactions-and-kotlin-coroutine-support/
jOOQ is a bit early here, given that Spring will increase their own baseline only later in 2022:
https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
But jOOQ will continue to provide paid support for older JDKs for quite a while, still. At the same time, jOOQ 3.14 - 3.16 will receive patches for another while, too.
As of today, when I try to run some of my programs in IntelliJ today, this message was shown:
Executing pre-compile tasks...
Loading Ant configuration...
Running Ant tasks...
Running 'before' tasks
Checking sources
Finished, saving caches…
Module 'Listen' production: java.lang.NoClassDefFoundError: com/intellij/DynamicBundle
Executing post-compile tasks...
Loading Ant configuration...
Running Ant tasks...
Synchronizing output directories...
13.04.22, 14:54 - Build completed with 1 error and 0 warnings in 4 sec, 39 ms
This line is printed in red: Module 'Listen' production: java.lang.NoClassDefFoundError: com/intellij/DynamicBundle
I don't really have too much of an idea where I should look for the problem.
It seems to not have anything to do with the project itself. I already created a new Project and created a Hello World-program, which resulted in the same error.
Remarkably, yesterday my IntelliJ IDEA version was updated to version 2022.1.
Runtime version: 11.0.14.1+1-b2043.25 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
I have no idea either whether it has anything to do with the new version either.
I maintain another Project, which uses Scala language. That one is messed up even more:
Cannot process toolwindow sbt
java.lang.AbstractMethodError: Missing implementation of resolved method 'abstract com.intellij.openapi.externalSystem.settings.AbstractExternalSystemSettings getSettings(com.intellij.openapi.project.Project)' of abstract class com.intellij.openapi.externalSystem.service.task.ui.AbstractExternalSystemToolWindowFactory.
at com.intellij.openapi.externalSystem.service.task.ui.AbstractExternalSystemToolWindowFactory.shouldBeAvailable(AbstractExternalSystemToolWindowFactory.java:35)
at com.intellij.toolWindow.ToolWindowSetInitializerKt.beanToTask(ToolWindowSetInitializer.kt:262)
at com.intellij.toolWindow.ToolWindowSetInitializerKt.beanToTask(ToolWindowSetInitializer.kt:248)
at com.intellij.toolWindow.ToolWindowSetInitializerKt.access$beanToTask(ToolWindowSetInitializer.kt:1)
at com.intellij.toolWindow.ToolWindowSetInitializerKt$computeToolWindowBeans$1.accept(ToolWindowSetInitializer.kt:278)
at com.intellij.toolWindow.ToolWindowSetInitializerKt$computeToolWindowBeans$1.accept(ToolWindowSetInitializer.kt)
at com.intellij.openapi.extensions.impl.ExtensionPointImpl.processWithPluginDescriptor(ExtensionPointImpl.java:301)
at com.intellij.toolWindow.ToolWindowSetInitializerKt.computeToolWindowBeans(ToolWindowSetInitializer.kt:274)
at com.intellij.toolWindow.ToolWindowSetInitializer$1.get(ToolWindowSetInitializer.kt:101)
at com.intellij.toolWindow.ToolWindowSetInitializer$1.get(ToolWindowSetInitializer.kt:83)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665)
at java.base/java.lang.Thread.run(Thread.java:829)
Any advice?
Best
Stapelüberläufer
I had the same problem after upgrading to Intellij 2022.1
For me, the fix came from Gen's answer. I also had an old Scala plugin, and just removed it as I'm not using it anymore.
If you are looking to upgrade it, go to File -> Settings -> Plugins. From there just hit Upgrade for the plugins you want. After that restart the IDE.
I found that Scala plugin was not updated and updating it to at least version 2022.1.13 fixed it for me.
I upgraded to Intellij 2022.1 and encountered this issue when trying to sync the old gradles projects that used to work for me :
Caused by: java.lang.NoClassDefFoundError: org/gradle/internal/impldep/com/google/common/collect/Lists
Cleaning the caches folder's content (Gradle_HOME/caches) resolved this issue for me
Make sure to also check that the SDK is correctly configured for your project (Java 17 by default) and the Gradle home is well specified in the Settings>Gradle section.
For info, I'm using Java 8 and Gradle 5.5.1 (yes I know :))
Just upgrade the Scala Plugin and its done!
visiting
scala plugin's page
and install it from there worked for me on ultimate version 2022.2.3
I updated from guava 14.0.1 to 15.0 in an application that deploys on WebLogic 12c, and I get a java.lang.NoSuchMethodException during deployment that I've been unable to resolve:
Caused By: java.lang.NoSuchMethodException: com.google.common.base.internal.Finalizer.startFinalizer(java.lang.Class, java.lang.ref.ReferenceQueue, java.lang.ref.PhantomReference)
at java.lang.Class.getMethod(Class.java:1624)
at com.google.common.base.FinalizableReferenceQueue.getStartFinalizer(FinalizableReferenceQueue.java:302)
at com.google.common.base.FinalizableReferenceQueue.<clinit>(FinalizableReferenceQueue.java:90)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:266)
at com.oracle.injection.provider.weld.BasicResourceLoader.classForName(BasicResourceLoader.java:27)
at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:107)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:77)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135)
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349)
at com.oracle.injection.provider.weld.WeldInjectionContainer.deploy(WeldInjectionContainer.java:99)
at com.oracle.injection.integration.CDIAppDeploymentExtension.initCdi(CDIAppDeploymentExtension.java:68)
at com.oracle.injection.integration.CDIAppDeploymentExtension.activate(CDIAppDeploymentExtension.java:47)
at weblogic.application.internal.flow.AppDeploymentExtensionFlow.activate(AppDeploymentExtensionFlow.java:37)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:61)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:586)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:148)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:114)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:339)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:846)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1275)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:442)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:176)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:550)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
I already have been using the WebLogic prefer-application-packages classloader filtering in my weblogic.xml file as described here in order to resolve a runtime conflict in WebLogic 12c as it seems to repackage an older version of the library. This had been working in guava 14.0.1, but does not in 15.0.
As far as I can tell, preferring the com.google.common.* package should include everything. Does this Finalizer class do something special that is happening before the classloader filtering happens, thereby trying to load the old version that appears to have a different API?
Is there an alternative solution to use the guava-15.0.jar packaged with the application instead of what is bundled with the server?
There's an open issue #1527 targeting this problem (Guava 15 cannot be deployed to any JEE6 container) which occured after fixing this one. Please star and / or comment and wait for the fix (comment #33 suggests that version 15.0.1 could be released in near furture).
EDIT:
Meanwhile, the issue was resolved by new maven release:
A note on JEE6 / CDI 1.0
A workaround added in Guava 15.0 to make it compatible with CDI 1.1
(used in JEE7 containers) caused problems for Guava with CDI 1.0 (used
in JEE6 containers).
If you're using Guava in a CDI 1.0 environment, you should use
guava-15.0-cdi1.0.jar instead of the normal Guava jar. In Maven, the
dependency can be specified as:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>15.0</version>
<classifier>cdi1.0</classifier>
</dependency>
If you want to deploy on both JEE 6 and 7 servers, you must use Guava 13 or wait until 16 is released.
As an aditional information, I landed on this question with a similar problem while upgrading to Weblogic 12c due to a conflit between WL and Guava (have tried with versions 11 and 18 of Guava).
I found the solution to be to explicitly prefer my application's lib. I set this on my weblogic.xml:
<prefer-application-packages>
<package-name>com.google.common</package-name>
</prefer-application-packages>
Look at http://docs.oracle.com/middleware/1212/wls/WLPRG/classloading.htm#WLPRG315 for the reference.
Samples run fine on my Windows 7.
However I get the following error on my Ubuntu machine:
Exception in thread "main" java.lang.NoSuchMethodError: org.joda.time.LocalDateTime.toDate()Ljava/util/Date;
at com.alvazan.orm.api.base.spi.UniqueKeyGenerator.generateKey(UniqueKeyGenerator.java:47)
at com.alvazan.orm.api.base.spi.UniqueKeyGenerator.generateNewKey(UniqueKeyGenerator.java:42)
at com.alvazan.orm.api.base.spi.UniqueKeyGenerator.generateNewKey(UniqueKeyGenerator.java:21)
at com.alvazan.orm.impl.meta.data.MetaIdField.fillInAndFetchId(MetaIdField.java:106)
at com.alvazan.orm.impl.meta.data.MetaIdField.translateToColumn(MetaIdField.java:56)
at com.alvazan.orm.impl.meta.data.MetaClassSingle.translateToRow(MetaClassSingle.java:82)
at com.alvazan.orm.layer0.base.BaseEntityManagerImpl.putImpl(BaseEntityManagerImpl.java:117)
at com.alvazan.orm.layer0.base.BaseEntityManagerImpl.put(BaseEntityManagerImpl.java:100)
at com.example.PlayORMExample.createTestData(PlayORMExample.java:89)
at com.example.PlayORMExample.main(PlayORMExample.java:31)
I looked at similar questions on the "stack", but they do not seem to apply to my case.
you either
have the wrong version of the joda-time jar OR
have two joda time jars one of which is the wrong version
later,
Dean (I am a committer on PlayOrm).
I'm using RAD 8.0.4 version. After installing plugins like SVN, Maven and PMD, when I try to open 'Deployment Assembly' option for any EAR project(right click->properties->deployment assembly) its showing that "The currently displayed page contains invalid values".
Can anyone help me out to solve this..??
I met the same issue, and the log in .metadata/log like this:
!ENTRY org.eclipse.jface 4 2 2012-11-23 11:37:45.031
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface".
!STACK 0
java.lang.NoSuchMethodError: org/eclipse/jst/j2ee/componentcore/J2EEModuleVirtualComponent.getDefaultDeploymentDescriptorFolder(Lorg/eclipse/wst/common/componentcore/resources/IVirtualFolder;)Lorg/eclipse/core/runtime/IPath;
I had this same issue. It was because I didn't have all projects being referenced, in my workspace. To fix the issue, I had to remove the references. To do that, I had to open the referenced projects first, then open the deployment assembly, and remove the reference.