I have a mavenized Spring 3 project that builds and runs fine on one machine. The exact same project builds fine on a second machine, but when I try to hit a page (one that works fine on the other machine), I get the following stacktrace:
java.lang.VerifyError: (class: org/apache/jsp/tag/web/generate_002dvalidation_tag, method: _jspx_meth_c_005fset_005f13 signature: (Ljavax/servlet/jsp/tagext/JspTag;Ljavax/servlet/jsp/PageContext;[I)Z) Incompatible argument to function
java.lang.Class.getDeclaredConstructors0(Native Method)
java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
java.lang.Class.getConstructor0(Class.java:2699)
java.lang.Class.newInstance0(Class.java:326)
java.lang.Class.newInstance(Class.java:308)
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:635)
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:52)
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:685)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1530)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2417)
org.apache.jasper.compiler.Node$Root.accept(Node.java:495)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2361)
org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:703)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:210)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:347)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:327)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:314)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:589)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238)
org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1047)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:817)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
The only difference that I can think of is the version of Java. On the machine where the project works, the version is 6 update 17, whereas on the second machine (where the project does not work), the version is 6 update 22. The pom's are exactly the same.
It looks like the problem is centered around a custom tag, but I can't figure out what it is. What could be causing this problem?
UPDATE
I took a look at the target directories on both machines and noticed the following:
On the machine where the project doesn't work, the lib directory has el-api-2.2.jar
On the machine where the project works, there is tomcat directory under target which contains the following:
`-- tomcat
|-- conf
| |-- tomcat-users.xml
| `-- web.xml
|-- logs
|-- webapps
`-- work
`-- localEngine
`-- localhost
`-- _
|-- org
| `-- apache
| `-- jsp
| |-- tag
| | `-- web
| | |-- generate_002dvalidation_tag.class
| | `-- generate_002dvalidation_tag.java
| `-- WEB_002dINF
| `-- jsp
| `-- starship
`-- SESSIONS.ser
This directory is not present on the machine where the project works
On the machine where the project works, there is a war directory under target, which is not present on the machine where the project does not work (however both machines produce a war file under the target directory)
On the machine where the build does not work, the war file is 4,135,195 bytes, whereas on the other it is 4,104,569 bytes. This difference comes from the inclusion of the el-api-2.2.jar file.
I'm not sure what this means.
According to this answer,
java.lang.VerifyError can be the
result when you have compiled against
a different library than you are using
at runtime.
I suggest you to compile it on each machine and compare the content within the war file (assumming, from the stacktrace, you are building war project).
Do you happen to compile it on linux vs Windowsy by any chance? It is possible that you may have the same library with the different version within the classpath. On different OS, the order at which the class are loaded are different. The correct one maybe loaded first on your machine running JDK 6u17.
I normally open the war file in a 7zip browser and check whether there are any same library of different versions. Some libraries use the different artifact name but actually the same, e.g. spring-bean and org.springframework.bean.
According to my experience, sometimes the verifications get complex generics-related things wrong. Also, sometimes instrumentation can pose problems to it. If you know that the verification error should not appear, but it still does, verification can be disabled with -noverify startup option.
Sometimes it is also disabled for other reasons such as performance.
For more details on disabling verification, see this thread.
More than java version, I think the problem is due to the difference in the versions of Java EE libraries.
Is it possible that the two machines have different app servers or different versions of the app server? Also, are the libraries provided by the container (like servlet-api.jar or jsp-api.jar) being packaged in the war?
Though the reason mentioned by gigadot is correct, but I would definitely check below before moving to something else:
Check the cglibs in my classpath.
Check the hibernate versions in my classpath.
Chances are good that having multiple or conflicting version of any of the above could cause unexpected issues like the one in question.
Related
When running glide install on my project, I get the following error:
[ERROR] Error scanning github.com/golang/protobuf/proto/testdata: cannot find package "." in:
/Users/bevernie/.glide/cache/src/https-github.com-golang-protobuf/proto/testdata
[ERROR] Failed to retrieve a list of dependencies: Error resolving imports
When checking protobuf's source code, I can in fact see that there is no such package. I however don't directly use protobuf, so the error must come from one of the dependencies I use.
When running glide tree on my project, there is only one instance of github.com/golang/protobuf/proto/testdata:
|-- github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
| |-- github.com/golang/protobuf/proto/test_proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto/test_proto)
| | |-- (Recursion) github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
| |-- github.com/golang/protobuf/ptypes/any (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)
| | |-- (Recursion) github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
github.com/golang/protobuf/proto/testdata (glide get github.com/golang/protobuf/proto/testdata)
|-- github.com/golang/protobuf/ptypes/any (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)
| |-- github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
| | |-- github.com/golang/protobuf/proto/test_proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto/test_proto)
| | | |-- (Recursion) github.com/golang/protobuf/proto (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/proto)
| | |-- (Recursion) github.com/golang/protobuf/ptypes/any (/Users/bevernie/Programmation/work/src/github.com/golang/protobuf/ptypes/any)
which doesn't really help me pinpoint the source of the problem.
Do you have any suggestions as of how to fix the issues?
My project was compiling just fine until a week or two ago (I use Docker to deploy in production, so the glide install was run every time and never failed before that, and I haven't added any new dependency recently).
Before your own PR (995), there was glide issue 968
It looks like it's caused by a repository's structure changing, i.e. a sub-package being moved, or removed entirely.
Workarounds proposed by Elliot Wright (seeruk):
If the package that has been updated is under your own control, then I've since found it easier to use some of the newer Go features like type aliases to ease the pain from refactoring.
So, instead of just moving a package, move it and then make aliases to the new location in the old one so that your older code still works.
Then, gradually move things over. Basically just mark things as deprecated but make sure they're still usable for a little while until you've ported new code over.
If the package is not in your control, then you can always clone the version you want manually to your vendor folder and make your updates in your code.
Once you're done, Glide should let you update again.
If it's much more complex, sometimes it's even easier to revert to using go get until you're done updating packages, and rely on your $GOPATH contents.
It's far from ideal, but there are ways you can work around it at least.
In the mean time, I've also made an issue about this on dep.
I think they're looking into a way of disabling this kind of check if you just want the tool to trust you as the developer.
So you can check if you have the same issue using godep, or even the bleeding-edge vgo.
I have some composites that will be used in other projects, in the developing time I used to test it in a dynamic web project created inside Eclipse IDE an then put its .jar in the lib folder
The .jar was package like this:
MyComponentProject
|-- META-INF
| |-- resources
| | `--
| | |-- comp
| | | `-- someComposite.xhtml
| | |-- template
| | | `-- someTemplate.xhtml
| | |
| |-- faces-config.xml
| `-- MANIFEST.MF
and here an teste page:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:p="http://primefaces.org/ui"
xmlns:libcomp="http://java.sun.com/jsf/composite/comp"
xmlns:libcompAP="http://java.sun.com/jsf/composite/comp_ap"
template="/templates/template_blank.xhtml">
<ui:define name="inc_act">
<ui:include src="/comp/compActions.xhtml" />
</ui:define>
It was working fine in this way but now I have to make a REAL test project using Maven.
The new project was created and was working fine in the first run, but as I started putting more composites in the main test page I started getting the following error from one of the composites:
javax.servlet.ServletException: /index.xhtml #157,32 <libcomp:compActions>
Tag Library supports namespace: http://java.sun.com/jsf/composite/comp,
but no tag was defined for name: compActions
At first I thought I just need to take it out to get everything working again but when I did it I started getting an error from the template:
javax.servlet.ServletException:
/index.xhtml #8,61 <ui:composition template="/templates/template_blank.xhtml">
Invalid path : /templates/template_blank.xhtml
I don't know what is going on...the template is in the same place always had. I can't figure out why it worked for a while and then now it stoped finding the template....and now I can't get it working again!
Any thought about what could it be?
I put the .jar again in a dynamic web project and it works, so I don't think it is a bad package problem at all.
I'm using JAVA 7, JBoss EAP 6.3, JSF 2.1 and Primefaces 5.0.
I've found what happened and came back to share, might be useful to someone else...
I figure out that the problem only appears when "MyComponentProject" is opnened in my Eclipse worksoace, in order to get it working again I just need to close "MyComponentProject" project.
I dont know an explanation for its cause, the problem first happened when I noticed a problem and get the project opnened again to make a debug and then everything screwed up.
I am new to gradle so this question may be silly, but i have a project configured with the 'java' plugin like so:
apply plugin: 'java'
and it has a file structure like so:
src
`-- test
|-- java
| `-- com/example/Test.java
`-- resources
`-- com/example/test.txt
When i run gradlew testClasses (or processTestResources more specifically) the Test.class appears in the build folder but the test.txt does not get copied. am I missing something? my understanding is that this should be standard behaviour. do i need to include it in the CopySpec?
I am running gradle 1.10
After a brief look at my build directory for the project, I noticed there is a seperate folder for resources apart from classes. So it is copying there.
from what I understand the resources folder is available on the classpath at runtime, But I was expecting the physical (meta-physically speaking) file to be in the same directory as the Test.class file in my code. hence my question.
I'm working on a project which uses JAAS and unfortunately for me Tomcat requires a file to be put in a META-INF folder in the root of the war
app.war
|__META-INF
| |___context.xml
...
I think that it's already weird since the default META-INF location for WAR's is in the classes folders.
app.war
|__WEB-INF
| |__classes
| |__META-INF
...
So I'm using Maven, which states that anything in src/main/resources/META-INF will be copied to the appropriate place, which it does. The weird thing is that it is also creating a META-INF folder in the root of the file structure leaving me with 2 META-INF folders.
Project Structure
app
|__src/main/java
|__src/main/resources
| |__META-INF
| |__context.xml
...
After mvn package
app
|__META-INF [1]
|__WEB-INF
| |__classes
| |__META-INF [2]
| |__context.xml
...
So, if the war standard states that META-INF should be under classes folder, as in #2, why maven war creates the #1 folder. And is there a way to make it copy files into that folder instead of #2?
Regards
So I found this:
Two Meta-Inf folders - normal structure?
which states that having 2 META-INF folders is not a problem. Digging a little I found:
JAR File Specification
which states about the META-INF folder:
A JAR file is essentially a zip file that contains an optional META-INF directory. ...The META-INF directory, if it exists, is used to store package and extension configuration data, including security, versioning, extension and services.
and this:
JSR-000315 JavaTM Servlet 3.0
which, on section 10.6, states about the WAR file structure:
When packaged into such a form, a META-INF directory will be present which
contains information useful to Java archive tools. This directory must not be directly
served as content by the container in response to a Web client’s request, though its
contents are visible to servlet code via the getResource and getResourceAsStream
calls on the ServletContext. Also, any requests to access the resources in META-INF
directory must be returned with a SC_NOT_FOUND(404) response.
So from the WAR spec the right place is WEB-INF/classes/META-INF. Yet, since war is a special jar file, it makes sense to have /META-INF as a point for extensions. One can see such different uses in JPA persistence.xml vs. Tomcat context.xml files: the former should be placed in WEB-INF/classes/META-INF while the latter in /META-INF.
I have a monolith Gradle project that contains multiple subprojects, each with its own subprojects, like so:
project
|
|-- subprojectA
| |-- models
|
|-- subprojectB
| |-- models
This compiles fine but the issue is when I try to add a dependency on :subprojectB:models to :subprojectA:models, Gradle thinks :subprojectA:models is trying to add a dependency on itself and complains of a circular dependency, even though I specify the fully qualified path like so (in subprojectA's build.gradle):
compile project(':subprojectB:models')
How can I avoid this? Can subprojects not have the same name even if their paths are unique?
Project identity for dependency resolution is based on the group:name:version or GAV coordinates, as explained in the linked Gradle issue.
So you need to make sure your different models project have different GAVs.
One way to make this happen is to make the subprojectA (or B) part of the group.
Another way is to assign names that are not based on the containing folder.
That's currently a known Gradle issue as Gradle by default uses the parent directory name as the project name. You can work around the issue as described here by assigning unique subproject names in the root project's settings.gradle like so:
include ':subprojectA:models', ':subprojectB:models'
project(':subprojectA:models-a').projectDir = file('subprojectA/models')
project(':subprojectB:models-b').projectDir = file('subprojectA/models')