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.
Related
I'm trying to get started with Sidekick for Dapr, and am having trouble telling Sidekick where the dapr components are.
By default it's going to %USERPROFILE%.dapr\components, but I'd rather it go to a folder local to the solution.
Looking at the code it appears that adding the following to the appsettings.json should work, but it isn't picked up.
"DaprSidekick": {
"RuntimeDirectory": "dapr",
"ComponentsDirectory": "C:\\Dev\\DaprPOC\\components",
}
However the components folder invariably becomes %USERPROFILE%\.dapr\components
Any help on how I specify the component locations with Sidekick?
When you set "RuntimeDirectory": "dapr" Sidekick will automatically look for component files in the dapr/components subdirectory in your solution. Try removing the ComponentsDirectory entry so it returns to defaults, and try a directory structure like this:
|-- MyProject
| |-- MyProject.csproj
| |-- dapr
| | |-- config.yaml
| | |-- components
| | | |-- my_component.yaml
The Dapr Sidecar should then load my_component.yaml.
You can also manually add the components directory in the dependency injection:
services.AddDaprSidekick(configuration, p => p.Sidecar =
new DaprSidecarOptions() { AppId = "daprservice", ComponentsDirectory = "C:\\Dev\\DaprPOC\\components" });
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.
Running mvn idea:idea to generate IntelliJ IDEA project files we stumble into a folder that must be avoided, let's say .avoidMe, which is located inside every folder as a placeholder.
folder1
|
+- .avoidMe
|
+- folder2
| |
| +- .avoidMe
|
+- folder3
| |
| +- .avoidMe
. . .
I've looked at idea:idea exclude options but none of them accepts wildcars (e.g. .avoidMe , "/.avoidMe/" or else ) so that I need to add every possible path to the exclude property ( e.g. folder1/.avoidMe,folder1/folder2/.avoidMe,folder1/folder3/.avoidMe )
The idea here is to use it to run IDEA inspections and publish the results into Sonar.
Is there any way to exclude file search using a wildcard or any other trick than exhaustive path search ?
are there any other ways to run IDEA inspections and publish them into Sonar ?
You should never use mvn idea:idea, it's obsolete and was not updated for years. It's also known to generate incorrect projects with the bugs that will be hard to trace later.
Instead, just import pom.xml in IDEA, project files will be generated by IDEA automatically.
You can then Exclude certain folders in Project Structure | Modules | Sources. Be aware that this configuration will be lost on the next reimport.
There is another configuration to exclude folders that is global and will be not lost on reimport: Settings | File Types | Ignore files and folders.
I'm trying to create a war that is to be deployed in an EAR and that should contain only images.
My war source organization is as follows :
+---src
| +---main
| | +---java
| | +---resources
| | | \---META-INF
| | | \---resources
| | | \---images
| | | placeholder_image.jpg
| | | placeholder_template.png
| | |
| | \---webapp
| | \---WEB-INF
| \---test
| +---java
| \---resources
and my war effective organization is
+---META-INF
\---WEB-INF
\---classes
\---META-INF
\---resources
\---images
placeholder_image.jpg
placeholder_template.png
The images I want to serve are in the src/main/resources/META-INF/resources/images folder.
I package this war using maven-war-plugin.
Under which url will those images be available on my local machine, provided my war is indicated as available under the http://localhost:8080/myapp/ path ?
None. Content from WEB-INF is not statically served, resources is for classpath resources. You need to put the images (folder) directly under webapp or add an servlet that serves the content.
This depends on whether you deploy the war in a Servlet-3-compatible container like Tomcat 7 or Jetty 8.
If so, your resources should be visible under http://localhost:8080/myapp/images/....
See also this post, where the only difference is that the resources are packaged in a jar. For jars, this feature makes more sense than for WEB-INF/classes, as, like the first answer points out, you should simply put your resources directly into src/main/webapp if they are located in the same Maven module.
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.