I would like to create a service for JIRA. I'm using atlassian-plugin-sdk-3.8.
I write program in java for that service.. When i'm importing the atlassian api
import com.atlassian.jira.project.ProjectManager;
import com.atlassian.jira.ComponentManager;
ProjectManager pm = ComponentManager.getInstance().getProjectCategories();
After i write it, i use atlas-package command.
But here it shows BUILD-FAILURE
[INFO] Compilation failure
F:\services\module\src\main\java\com\first\module\MyPlugin.java:[9,25] cannot fi
nd symbol
could not parse error message: symbol: class ComponentManager
location: package com.atlassian.jira
F:\services\module\src\main\java\com\first\module\MyPlugin.java:20: cannot find
symbol
ProjectManager pm = ComponentManager.getInstance().getProjectCategories();
^
Whats the reason?
Try one of the following depending on your jira api version:
ProjectManager pm = ComponentManager.getInstance().getProjectManager();
ProjectManager pm = ComponentAccessor.getProjectManager();
For more details look at JIRA api
Add dependecies to your pom.xml:
<dependencies>
<dependency>
<groupId>com.atlassian.jira</groupId>
<artifactId>jira-api</artifactId>
<version>${jira.version}</version>
<scope>provided</scope>
</dependency>
<!-- Add dependency on jira-core if you want access to JIRA implementation classes as well as the sanctioned API. -->
<!-- This is not normally recommended, but may be required eg when migrating a plugin originally developed against JIRA 4.x -->
<dependency>
<groupId>com.atlassian.jira</groupId>
<artifactId>jira-core</artifactId>
<version>${jira.version}</version>
<scope>provided</scope>
</dependency>
...
</dependencies>
Related
I tried to list the ECS clusters using the code as follow:
AmazonECS = amazonECS AmazonECSClientBuilder.standard().withRegion(region).withCredentials(new AWSStaticCredentialsProvider(awsCredentials)).build():
amazonECS.listClusters();
However, it gave the error
java.lang.NoSuchFieldError: CLIENT_ENDPOINT
The error stack is something like this:
com.amazonaws.services.ecs.AmazonECSClient in executeListClusters at
line 2220 com.amazonaws.services.ecs.AmazonECSClient in listClusters
at line 2202 com.amazonaws.services.ecs.AmazonECSClient in
listClusters at line 2245
I am not too sure why this error occurred as the other Amazon services did not give me any similar error whatsoever and I have set the region previously based on the client's preference. Any ideas?
Thanks to Nagaraj Trantri the error is caused by the version mismatched of the AWS SDK that I have according to https://github.com/aws/aws-sdk-java/issues/2509#issuecomment-779370672
I had different version for SQS and S3 in pom.xml. After I updated those to same versions, it worked.
It depends on where to look for these versions mismatch.
I am using spark to connect to secrets manager and thus we have 2 places to look at.
My Application dependencies (build.gradle)
spark.yarn.jars
The versions in the above 2 places should match and then it started working
Use this in the pom.xml file. Error is caused due to mismatch in the 'com.amazonaws' dependency versions declared in the pom.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-bom</artifactId>
<version>1.11.739</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-sts</artifactId>
</dependency>
</dependencies>
I am currently trying to add JWT to my quarkus project but I have run into some roadblocks.
In my application.properties I have set the following settings:
mp.jwt.verify.publickey.location=publicKey.pem
smallrye.jwt.sign.key-location = privatetestKey.pem
mp.jwt.verify.issuer=https://example.com/issuer
but now I get the error:
Unknown property 'smallrye.jwt.sign.key-location'
I should have installed every necessary dependency in my pom.xml:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-jwt</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-jwt-build</artifactId>
</dependency>
Or have I forgotten something?
The configuration name was renamed to smallrye.jwt.sign.key.location (no dash between key and location), but I believe that the old one should still work because it was only deprecated.
Please try with the new name: https://quarkus.io/guides/security-jwt#additional-smallrye-jwt-configuration
I recently started upgrading my application JDK version from jdk1.7.0_121_x64 to jdk1.8.0_202_x64. I have some legacy code using Drools 5.4.0.Final. This code is working with JDK version jdk1.7.0_121_x64 without any issue.
Maven dependencies are:
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>5.4.0.Final</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-decisiontables</artifactId>
<version>5.4.0.Final</version>
</dependency>
DRL files are loaded as:
final KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add(resource, ResourceType.DRL);
knowledgeBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
I was aware that there are issues using Drools with JDK 8. I referrred to other SO thread to start with.
When I built my application and executed Junit tests using JDK 8, tests failed with error:
testRunRule(com.company.app.RuleTest) Time elapsed: 0.073 sec <<< ERROR!
java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
As mentioned in SO thread, I found reference to this bugfix ticket DROOLS-329.
Based on approaches mentioned in this bugfix ticket, I tried to use JANINO compiler:
Added following maven dependency:
<dependency>
<groupId>org.codehaus.janino</groupId>
<artifactId>janino</artifactId>
<version>2.5.16</version>
</dependency>
I added following VM argument (I was running tests from eclipse, so in eclipse launch configuration in JRE VM argument added the argument):
-Ddrools.dialect.java.compiler=JANINO
I could still see the wrong class format error. So I modified my code to load DRL files as:
final KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
final Properties props = new Properties();
props.setProperty("drools.dialect.java.compiler", "JANINO");
final KnowledgeBuilderConfiguration config = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration(props, null);
final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(config);
kbuilder.add(resource, ResourceType.DRL);
knowledgeBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
It didn't help. I could still see the wrong class format error.
I followed another apprroach mentioned in this external link. I updated added/updated maven dependencies as:
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>5.4.0.Final</version>
<exclusions>
<exclusion>
<groupId>org.mvel</groupId>
<artifactId>mvel2</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-decisiontables</artifactId>
<version>5.4.0.Final</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jdt.core.compiler</groupId>
<artifactId>ecj</artifactId>
</exclusion>
<exclusion>
<groupId>org.mvel</groupId>
<artifactId>mvel2</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.mvel</groupId>
<artifactId>mvel2</artifactId>
<version>2.1.9.Final</version>
</dependency>
<dependency>
<groupId>org.eclipse.jdt.core.compiler</groupId>
<artifactId>ecj</artifactId>
<version>4.6.1</version>
</dependency>
mvel2 patch is built using:
https://github.com/mkornipati/mvel/tree/2.1.9.Final.Patch
With this wrong class format error is gone. But my tests are now failing with following error:
testRunRule(com.company.app.RuleTest)) Time elapsed: 4.684 sec <<< ERROR!
java.lang.RuntimeException: org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name='ruleCheck']
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (2:80) : Only a type can be imported. java.util.Map resolves to a package
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (2:101) : Only a type can be imported. java.util.HashMap resolves to a package
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:299) : org.drools.spi.KnowledgeHelper cannot be resolved to a type
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:339) : org.drools.template.parser.Row cannot be resolved to a type
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:373) : org.drools.FactHandle cannot be resolved to a type
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:411) : org.drools.template.parser.DefaultGenerator cannot be resolved to a type
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:487) : org.drools.runtime.rule.RuleContext cannot be resolved to a type
at org.drools.rule.Package.checkValidity(Package.java:445)
I don't know how to proceed further. Please let me know if you are able to make Drools 5.4 work with JDK 8.
I used Drools 7.7.0 with Java 8 and worked great for me. I am not sure what is the oldest Drools version that is compatible with Java 8. That said, Drools 5.4.0 was released in 2011. Java 8 was released in 2014, so you can assume it won't be compatible. Java 7 was released in July 2011. Depending on when 5.4.0 was released it might or might not be. Based on that, I expect Drools 5.4.0 to be compatible with Java 6 or earlier. If you want to use Java 8 with Drools, I don't see how you can without upgrading. I think the earliest compatible version is 6.1.0 download.jboss.org/drools/release.
In summary: Either downgrade your project to Java 6 to use Drools 5.4.0 or Upgrade Drools to use 6.1.0. Better yet, upgrade to latest Drools and then figure out what is the latest Java version it supports.
I made a program that parses turtle files with Jena library. These are the dependencies i use:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-iri</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-core</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-arq</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-tdb</artifactId>
<version>3.10.0</version>
</dependency>
So the parsing is working well on my java program but when i create my jar and try to run it, i have these kind of errors :
ERROR JenaService:146 - org.apache.jena.n3.turtle.TurtleParseException: Line 28015, column 79: org.apache.jena.iri.impl.IRIImplException:
<http://www.reussir.fr,> Code: 28/NOT_DNS_NAME in HOST: The host component did not meet the restrictions on DNS names.
Any ideas ?
EDIT
I have a warning for the invalid IRI problem by running my program with the IDE, but still giving me errors with the generated jar.
<http://www.reussir.fr,>
There is a comma in the URI in a place where commas are not allowed.
It is better to find and fix the data problem because it can lead to other problems later if not fixed.
I found the problem, the only dependency i really needed was jena-arq, so i removed others dependencies (especially jena-iri which was throwing the TurtleParseException) and the bad-iri errors became warnings like in the IDE execution logs.
I'm trying to build a mule project in maven which uses a library that in turn uses apache-commons-codec-1.8 . Mule 3.5 currently supports only v 1.3
In order to get around this Ive implemented classloader control in mule and blocked mule from loading its version of the library by doing the following in mule-deploy.properties.
loader.override=-org.apache.commons.codec
In addition I've updated my pom.xml to include the 1.9 version of the library . Here is a snapshot of running mvn:dependency tree on the project.
However, when I run my test method I get a runtime exception
java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.encodeBase64URLSafeString([B)Ljava/lang/String;
at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:64)
at com.nimbusds.jose.util.Base64URL.encode(Base64URL.java:91)
at com.nimbusds.jose.Header.toBase64URL(Header.java:238)
at com.nimbusds.jose.JWSObject.<init>(JWSObject.java:101)
at com.package.components.lastmile.originator.TokenSignerTemplate.sign(TokenSignerTemplate.java:109)
at com.package.components.lastmile.originator.TokenSignerTemplate.signClaim(TokenSignerTemplate.java:122)
at com.package.orchestration.LMSFakeClaimsHandler.testSignParse_Positive(LMSFakeClaimsHandler.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
which is clearly because it's referencing the older version of apache-commons. How do I make sure that it references only the latest version and not the older version?
mule-deploy.properties
#Fri Dec 12 09:58:12 PST 2014
loader.override=-org.apache.commons.codec
redeployment.enabled=true
encoding=UTF-8
domain=default
config.resources=..flows.
.
Relevant positions of pom.xml
<dependencies>
....
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.9</version>
</dependency>
....
<!-- Test to check commons-codec works -->
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-http</artifactId>
<version>${mule.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
P.S: The same snippet seems to work fine on a non mule project, indicating this is a mule related issue.
If you are running the Mule app in Mule server, excluding the lib from the pom will not work, since the codec lib is present in the server itself.
Try to insert the newest codec lib version in the server lib shared folder (maintaining the property loader.override=-org.apache.commons.codec)
Add the following exclusion to your pom.
<dependency>
<groupId>org.mule.transports</groupId>
<artifactId>mule-transport-http</artifactId>
<version>${mule.version}</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
</exclusion>
</exclusions>
</dependency>
And then add the dependency of Commons Codec 1.9.
Then your override property in mule-deploy.properties will work as expected.
Update: 12/30:
The override property seems to be the problem.
loader.override=-org.apache.commons.codec is not correct.
Try the following
loader.override=org.apache.commons.codec
Hope this helps.
I have a similar issue with the jackson-xc. I don't know why Mule 3.5 comes with a mix of jackson 1 and 2 libraries
jackson-annotations-2.1.1.jar
jackson-core-2.1.1.jar
jackson-databind-2.1.1.jar
jackson-core-asl-1.9.11.jar
jackson-jaxrs-1.9.11.jar
jackson-mapper-asl-1.9.11.jar
jackson-xc-1.7.1.jar
And with jackson-xc-1.7.1 instead of jackson-xc-1.9.11 that would be aligned to the version of the other jackson 1 libraries.
In my application it is producing the "classic" library issue exception:
Caused by: java.lang.AbstractMethodError
at org.codehaus.jackson.map.AnnotationIntrospector$Pair.findDeserializer(AnnotationIntrospector.java:1335)
Since using
loader.override=...
into the mule-deploy.properties didn't work (with either override and/or blocking on the package org.codehaus.jackson.xc and on the class org.codehaus.jackson.xc.JaxbAnnotationIntrospector) the only solution I have found goes in the direction of Nuno's answer and is to put the jar we want to use in a lib folder with higher priority than lib/opt
lib/shared has been deprecated but you can use lib/user to override.
I would prefer to use the loader.override (classloader-control-in-mule 3.5) and avoid the modification of all the installation, but for now is the only solution that is working for me.