I am using the latest Spring framework 4.1.5 and Hibernate-Entity-Manager 4.3.8 along with Javax.Persistence-api 1.0.2 all with JPA 2.1. This spec relies on Java EE 7. I noticed that in Resin 4.0.42, it uses "javaee-16.jar". The issue is I am getting the following exception:
Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()
[Ljavax/persistence/Index;
at
org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:973)
at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:824)
at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3845)
Method javax.persistence.Table.indexes() only exists in Java EE 7
(Javax.Persistence-api 1.0.2) as a JPA 2.1 spec and NOT in Java EE 6 as a
JPA 2.0 spec.
Problem is my code is based on JPA 2.1. Is there anyway I can classload
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
even after Resin has classloaded: javaee-16.jar first?
Got it working where I load child libs first, not the other way around. Resin was loading Parent-first. I noticed others were having the same challenge with implementing JPA 2.1 on an app server that only implements JPA 2.0. The key is that each app server has their own specific way to configure child libs (or your app's libs) first.
In my case, in Resin.xml, add the following:
<class-loader>
<servlet-hack/>
</class-loader>
I has a similar error due to resin has jpa 2.0 and the app want jpa 2.1
fixed by added the lib to resin classpath in resin config file
<server-default>
<jvm-classpath>path/to/lib/hibernate-jpa-2.1-api-1.0.2.Final.jar</jvm-classpath>
....
<server-default>
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.
I'm trying to make new icefaces project which generated using: ICEfaces 3.3.0 project integration for Eclipse.
I didn't modify anything on the project. but when i try to run on the server, i got an error:
cannot Deploy MyProject
Deployment Error for module: MyProject:
Exception while loading the app : java.lang.Exception:
java.lang.IllegalStateException: ContainerBase.addChild:
start: org.apache.catalina.LifecycleException:
java.lang.NoSuchFieldError: SKIP_ITERATION
before that, I'm using ICEfaces 3.2.0 project integration for Eclipse and no problem.
I'm using Eclipse Indigo, GlassFish server 3, Mojarra 2.1.6
Thanks before
java.lang.NoSuchFieldError: SKIP_ITERATION
As per the javadoc, that field was added in JSF 2.1.
So, this error suggests that your webapp's runtime classpath is polluted with a JSF 2.0 API JAR file. Perhaps in the /WEB-INF/lib? Get rid of it. Glassfish already ships with JSF bundled, you don't necessarily need to supply your own. Or, from the other side on, this can also happen if you deploy to an ancient Glassfish instance which bundles JSF 2.0 and JSF 2.1 was actually bundled in your webapp in an attempt to upgrade it. If so, then you should edited the Glassfish config file sun-web.xml or glassfish-web.xml, depending on GF version. See for detail the answer to this related question: How to update Mojarra version in GlassFish
I have built my project with maven
All builds successful and eclipse properties generation is also successful
But when I open the project in Eclipse 4, I am getting this error
An internal error occurred during: "Loading descriptor for SALYExplorer.".
org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'taglib' not found. (platform:/resource/SALYExplorer/src/main/webapp/WEB-INF/web.xml, 313, 10)
At that location I have some properties
Though the project runs smoothly and everything is fine, just while exploring the project in Navigation pane, Eclipse always throws this error box (quite annoying).
COde at that location
<taglib>
<taglib-uri>xx.tld</taglib-uri>
<taglib-location>/WEB-INF/tld/xx.tld</taglib-location>
</taglib>
and xx definations int it's file
<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"
"http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_2.dtd">
<taglib>
<tlib-version>1.0</tlib-version>
<jsp-version>1.2</jsp-version>
.........
</taglib>
The problem is not the taglib at all, it's just a bad error description by Eclipse.
it is the project facet vs. web.xml dtd.. their versions must match!
if the web.xml says:
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
but the project has a
"Dynamic Web Module 2.5"
then this error will occur.. change facet to 2.3 or web.xml to 2.5... in other words: they must match..
I ran into this error while trying to update a maven project in Eclipse (ALT+F5).
web.xml
<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
and project facet
Dynamic Web Modul 3.0
Here is how I could fix it:
Removed all xmls-schema definition from the web-app element
<web-app>
then update the maven project (ALT+F5).
Re-insert the schema definitions and re-update project (ALT+F5).
According to jsp_2_1.xsd included from web-app_2_5.xsd, taglib tag should be in jsp-config tag:
<xsd:complexType name="jsp-configType">
<xsd:annotation>
<xsd:documentation>
The jsp-configType is used to provide global configuration
information for the JSP files in a web application. It has
two subelements, taglib and jsp-property-group.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="taglib"
type="javaee:taglibType"
minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="jsp-property-group"
type="javaee:jsp-property-groupType"
minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID"/>
When I wrapped taglib in js-config, the error disappeared.
<jsp-config>
<taglib>
<taglib-uri>http://www.springframework.org/tags/form</taglib-uri>
<taglib-location>/WEB-INF/taglibs/spring-form.tld</taglib-location>
</taglib>
</jsp-config>
Previous parsers were probably more lenient. My config: Eclipse Luna, built-in maven 3.2.1, web.xml 2.5, Dynamic Web Project facet 2.5.
For the time being if it's just the annoying Error Message that you want to fix, then as a short-term fix take a look at disabling validation here : Eclipse 'loading descriptor' takes ages
If the above does not work, an alternative would be to use AHK (Autohotkey) which would take slightly more work at your end. (I have been using an AHK script for a couple of years now to get rid of the Eclipse Error popups that I don't care about)
Eclipse Bug 198630 was raised almost 5 years back and in that there is a comment which has an almost identical error message as the OP. (The bug itself was finally closed as not being reproducible).
I have the following questions for you :
Would it be possible for you to show us the Error log ? (To get at the error log you can either take a look at the Error Log View or by looking at the actual file : WORKSPACE_HOME/.metadata/.log. Please take a look at this for more detailed information. )
Are you using any specific Server Adapters like WebLogic or Glassfish ?
I have the following recommendations :
In the eclipse bug thread, the problem was fixed at least once by updating to a specific JST version. Hence, would it be possible for you to run an Eclipse update and see whether the problem is resolved ? (This can be done by going to Help -> Check for Updates)
Would it be possible to try importing the project in Eclipse Indigo (instead of
Juno, which you currently have) and see whether you can reproduce
the problem ? (Eclipse Indigo downloads are available here and I believe you would need the Java EE version)
I just got the same symptoms, with a web-app project using maven. In my case, was related to struts taglib tags in web.xml, and the project having a struts v1.2.9 dependency. I solved the problem by switching to struts v1.3.10. Don't ask why this solved the problem.
If you are in the same situation and you upgrade your struts dependency from 1.2.9 to 1.3.10, be sure to use at least dtd v2.3 in the DOCTYPE declaration of your web.xml:
!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd"
or you'll get another problem (your webapp won't startup without an internet connection)
Hope this helps
I suspect that the problem is with Eclipse web Tools Platform and Java EMF Model. Here is an image of a list of plugins including Java EMF Model and JEM stuff from Eclipse Web Tools Platform:
https://stackoverflow.com/users/1503535/nitin-gurram, does your stack trace look like this?
!ENTRY org.eclipse.core.jobs 4 2 2012-09-28 12:10:00.554
!MESSAGE An internal error occurred during: "Loading descriptor for grch97.".
!STACK 0
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'taglib' not found. (platform:/resource/grch97/WEB-INF/web.xml, 891, 11)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:319)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:278)
at org.eclipse.jem.internal.util.emf.workbench.ProjectResourceSetImpl.getResource(ProjectResourceSetImpl.java:1003)
at org.eclipse.jst.jee.model.internal.JEE5ModelProvider.getModelResource(JEE5ModelProvider.java:169)
at org.eclipse.jst.jee.model.internal.Web25ModelProvider.getModelObject(Web25ModelProvider.java:44)
at org.eclipse.jst.jee.model.internal.JEE5ModelProvider.getModelObject(JEE5ModelProvider.java:215)
at org.eclipse.jst.jee.model.internal.common.AbstractMergedModelProvider.loadProviders(AbstractMergedModelProvider.java:261)
at org.eclipse.jst.jee.model.internal.common.AbstractMergedModelProvider.access$2(AbstractMergedModelProvider.java:255)
at org.eclipse.jst.jee.model.internal.common.AbstractMergedModelProvider$LoadModelsWorkspaceRunnable.run(AbstractMergedModelProvider.java:278)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.jst.jee.model.internal.common.AbstractMergedModelProvider.loadModel(AbstractMergedModelProvider.java:249)
at org.eclipse.jst.jee.model.internal.common.AbstractMergedModelProvider.getMergedModel(AbstractMergedModelProvider.java:219)
at org.eclipse.jst.jee.model.internal.common.AbstractMergedModelProvider.getModelObject(AbstractMergedModelProvider.java:139)
at org.eclipse.jst.jee.ui.internal.navigator.Web25ContentProvider.getNewContentProviderInstance(Web25ContentProvider.java:69)
at org.eclipse.jst.jee.ui.internal.navigator.LoadingJeeDDJob.run(LoadingJeeDDJob.java:50)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'taglib' not found. (platform:/resource/grch97/WEB-INF/web.xml, 891, 11)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.reportUnknownFeature(XMLHandler.java:1985)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleUnknownFeature(XMLHandler.java:1949)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.handleUnknownFeature(XMIHandler.java:145)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLHandler.java:1893)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:1017)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMIHandler.java:81)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:995)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:706)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHandler.java:163)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:175)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:240)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1505)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1284)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
at org.eclipse.jem.internal.util.emf.workbench.ProjectResourceSetImpl.demandLoad(ProjectResourceSetImpl.java:811)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
... 14 more
I managed to fix this by removing the validator out of the .project file for each of the projects that had the issue.
I had a similar error using eclipse 4.3 (Kepler), maven 3.1.0, tomcat 6.0.37 and jdk7 (have also jre6 installed), and found a solution to fix it or at least to get rid of the tedious errors by configuring tomcat in eclipse.
In Preferences->Server-> Runtime Environments, define a new run time environment "Apache Tomcat 6.0" and select the jre6 installation from the installed JREs.
Then review the Targeted Runtimes in the project's properties. Apache Tomcat v6.0 should be associated with Java Runtime Environment v1.6 (if not yet defined press new and check that the selected JRE is a java 1.6 runtime).
Hope it helps
I was able to update the project Java facet to 1.5 and the errors stopped.
In my case, this problem got resolved by using the version
org.eclipse.emf.ecore.xmi_2.10.2.v20150123-0348 and org.eclipse.emf.ecore.xmi.source_2.10.2.v20150123-0348 and
org.eclipse.emf.ecore.xmi_2.10.2.v20150123-0348 and
org.eclipse.emf.ecore.xmi.source_2.10.2.v20150123-0348 and
org.eclipse.emf.common_2.10.1.v20150123-0348
jars in the build path.
Earlier jars of old version were being used inspite of new version present.
Right click on the project in Eclipse -> Build Path -> Configure Build Path -> Project Facets -> Uncheck Dynamic Web Module
Note: This approach is good as long you dont plan to run the web-app from within eclipse thru an embedded app server.
I have got an EAR with two plain libraries. One of them being scala-library. If I deploy the EAR with Netbeans it works as expected. While this is OK for development the final product should be deployable via the command line. For this I use:
asadmin --user … deploy --upload ./target/…-ear.ear
which fails with:
org.glassfish.api.admin.CommandException: remote failure: Error occurred during deployment: Exception while deploying the app […-ear] : C:\Work\Workspa
ces\…\Glassfish\…\applications\scala-library-2.8.0.jar. Please see server.log for more details.
Befehl deploy fehlgeschlagen.
Searching the net I found out that handling libraries have become more strict with Java EE 6 / Glassfish 3.x and that it is not enough to add them to the lib folder inside the ear any more. Only the author neglected to mention what is needed now.
I found new <module><java> entries for the META-INF\application.xml — but that did not help either:
<module>
<java>scala-library-2.8.0.jar</java>
</module>
So the question: Does anybody know what you have to do to add libraries to an EAR file for Java EE 6 / Glassfish 3.x?
PS: I use Maven to build - if that makes any difference.
Well it seems I found the solution myself (again). After adding a library-directory entry to the end of the META-INF\application.xml the deployment runs thou:
<library-directory>lib</library-directory>
</application>
The strange thing is that lib the default for library-directory. So I guess it must be a bug in Glassfish itself not handling the default correctly. If you use Maven make sure to use bundleDir in your pom.xml so that the libs are place in the right place:
<jarModule>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
<bundleDir>lib</bundleDir>
</jarModule>