I found googlechecks.xml from https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml . Imported it to checkstyle and have been trying to use this in checkstyle 5.6.1(Eclipse juno 4.2,JRE1.6). Problem occurs at FileExtension property.
I also want to add new rules in the xml file. Could anyone please let me know how to overcome this problem? That would be a great help and reapply appreciable.
Why are you trying to use so ancient checkstyle version (current is 7.1, last jdk7 based one is 6.19) and xml file from the latest master version?
Upgrade your checkstyle to at least 6.19 before using that file.
Or you can try to use older google checks, e.g. from the:
6.1.1 release: https://github.com/checkstyle/checkstyle/blob/c17bf06af9334ea1f6096868e591e6ee62774540/src/main/resources/google_checks.xml
5.8 release (when it first appeared): https://github.com/checkstyle/checkstyle/blob/8e4c7f743e5eebb38d039d15d8718d7b25587976/google_checks.xml
Related
I'm getting this error "invalid version 0 on git_proxy_options" from libgit2. This did not happen until very recently (I have recompiled my code so it may be a version issue). I'm not using a proxy. Does anyone know anything about this? What causes this message? Is there anything I can do to stop the failure? Either a fix or or a work-around will do.
Specifically, I am using the Rust crate git2 version 0.13.23. I am doing a fetch that triggers the error. This is on Fedora 34 on x86_64. I have searched on this but there does not seem to be any matches that help.
git2 = {version="0.13.22", features = ["vendored-libgit2"]}
in Cargo.toml fixed the issue.
Interesting...
I had upgraded libgit2 to 1.3.0 from 1.1.1. That broke my existing cargo install, so I unpacked the previous libgit2.so.1.1 with a symlink to libgit2.so.1. That's when this error condition showed up. After thinking a bit I decided to symlink libgit2.so.1.3 to libgit2.so.1.1 and it built my new cargo version which linked to the new libgit2.so.1.3. Then I deleted my libgit2.so.1.1 stuff. Kinda weird, and usually you expect things not to work when it has been linked to a previous .so version.
I have upgraded to the latest Checkstyle plugin (8.41.1) using IntelliJ 2021.
I'm trying to configure a custom google checkstyle xml file, so I took the lates example from Github and tried to set it as config file to the checkstyle plug but I'm getting the following exception
com.puppycrawl.tools.checkstyle.api.CheckstyleException: cannot initialize module TreeWalker - cannot initialize module JavadocMethod - Property 'accessModifiers' does not exist, please check the documentation
at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:473)
at com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:201)
at org.infernus.idea.checkstyle.service.cmd.OpCreateChecker.execute(OpCreateChecker.java:61)
...
...
If I'm setting the builtin Google check then it works.
Any idea?
I took the lates example from Github
This is the issue. You should be using the config that was built for the version of checkstyle you are using. You pulled in master's config which contains new features that have not been released.
See https://github.com/checkstyle/checkstyle/blob/49d1ea3835e017133ada46555d2214e017fc6fe2/src/main/resources/google_checks.xml
Refer the raised jira issue in below link .
https://wso2.org/jira/browse/IDENTITY-4633
Any solutions for solving this issue..,
We tried to temperorly solve this issue by editing sqlscripts.java file by downloading it from github, compiled it and tried to pack in same jar file (using winzip, as jar files are zip finally).
As part of the change we had removed TOKEN_SCOPE column from relevant sql query, but still error in log describes 'invalid column TOKEN_SCOPE'
Kindly suggest to make any further changes or share me the jar file.
I am using wso2 identity server v5.1.0
Thanks.
This issue seems to be already reported in https://wso2.org/jira/browse/IDENTITY-4532
This issue is already fixed in 5.2.0 which will be released soon. You can try the 5.2.0 beta from https://github.com/wso2/product-is/releases/tag/v5.2.0-beta
You can find the fix from the PR in the jira I have pointed.
I think I have found an error with the current (snapshot) JSF 2.0 Myfaces 2.2 Version; I think I am not the only one having this issue:
when I want to create a link with the following style:
<h:link outcome="../../test" />
I get following error:
PM org.apache.myfaces.shared.renderkit.html.util.OutcomeTargetUtils
getOutcomeTargetHref Warning: Could not determine NavigationCase for
UIOutcomeTarget component {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: ..
When i try it with an old snapshop version (e.g. 2013-04-24), the links are created correctly, also when the outcome-site is in the same folder as the linking file.
anyone else having this problem or is there a way to fix this? I dont't want to switch back to the old version because it has much more serious problems than this link issue
It is a bug caused by the new JSF 2.2 spec, which enforces the use of ResourceHandler.createViewResource(...), and that code internally has a check to avoid ../ or ./ in the resourceName. It has been fixed on MYFACES-3839.
I've got a problem with "javax.el.CompositeELResolver" which is used by TomEE's "javaee-api-6.0-5.jar".
Version information and svn-repository here:
http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec/1.0.2
Source of class CompositeELResolver here:
http://svn.apache.org/viewvc/geronimo/specs/tags/geronimo-el_2.2_spec-1.0.2/src/main/java/javax/el/CompositeELResolver.java?view=log
In the "invoke" method I get a null pointer exception because the for-loop iterates through the whole resolvers-array which has got fields with value "null". I suppose this is not avoidable because of the "add" method that doubles the array size if required but does not initialize any values. Shouldn't there be a check if the resolver is "null" in the "invoke" method before using it?
For comparison I ran my application with another javax.el implementation and it's working properly:
<dependency>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
<version>2.2</version>
</dependency>
Am I wrong with my supposition?
I found a similar-sounding issue here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50293
Is it possible that multi-threading causes my problem?
Solved.
TomEE uses version 1.0.2 of http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec
The bug is fixed in version 1.0.4
Based on the fixed geronimo el spec 1.0.4 version it is easy to fix the javaee-api-6.0-5.jar package.
Just download the newest jar file from here http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec/1.0.4
and change the javax.el package in javaee-api-6.0-5.jar with the files comes from geronimo el 2.2 spec 1.0.4 jar files
I did it using mc under linux browse the content and copy from one to another. And I tested and works perfect.
Of course you can do it with jar utils as well :-)
It was strange for me that this problem did not exist in 32 bit windows environment but only in 64 bit linux environment. Anyhow the fix solves the problem.
Hope that there will be a javaee-api-6.0-6.jar soon :-)