I read an article https://developers.redhat.com/articles/2021/07/16/whats-new-fabric8-kubernetes-client-version-550#new_features_in_fabric8_kubernetes_client_5_5_0, it mentioned in 5.5 release it adds "Certification management", however, seem I could not find any source codes related to it in fabric8 repo.
when I run a simple code like this
try (CertManagerClient certManagerClient = new DefaultCertManagerClient()) {
CertificateRequest certificateRequest = new CertificateRequestBuilder()
.withNewMetadata().withName("barry_coding_test").endMetadata()
.withNewSpec()
.withRequest(request)
.withIsCA(false)
.addToUsages("signing", "digital signature", "server auth")
.withDuration(Duration.parse("2160h"))
.withIssuerRef(new ObjectReferenceBuilder()
.withName("barry-dlc-cert-issuer")
.withKind("Issuer")
.withGroup("cert-manager.io")
.build())
.endSpec()
.build();
certManagerClient.v1().certificateRequests().inNamespace("barry").create(certificateRequest);
} catch (Exception e) {
e.printStackTrace();
}
It throws error
Exception in thread "main" java.lang.NoSuchMethodError: io/fabric8/kubernetes/client/dsl/base/HasMetadataOperation.<init>(Lio/fabric8/kubernetes/client/dsl/base/OperationContext;)V (loaded from file:/Users/zhBarry#ca.ibm.com/osprey/mvnexample/java-app/dlc-management-service/libs/kubernetes-client-5.8.0.jar by jdk.internal.loader.ClassLoaders$AppClassLoader#40575da4) called from class io.fabric8.certmanager.client.api.v1.internal.CertificateRequestOperationsImpl (loaded from file:/Users/zhBarry#ca.ibm.com/osprey/mvnexample/java-app/dlc-management-service/libs/certmanager-client-5.5.0.jar by jdk.internal.loader.ClassLoaders$AppClassLoader#40575da4).
at io.fabric8.certmanager.client.api.v1.internal.CertificateRequestOperationsImpl.<init>(CertificateRequestOperationsImpl.java:32)
at io.fabric8.certmanager.client.api.v1.internal.CertificateRequestOperationsImpl.<init>(CertificateRequestOperationsImpl.java:28)
at io.fabric8.certmanager.client.V1APIGroupClient.certificateRequests(V1APIGroupClient.java:51)
at com.ibm.si.osprey.App.main(App.java:67)
I could not find source code CertificateRequestOperationsImpl.java at all in the repo.
Any ideas for it? Where can I certmanager implementation in the fabric8 repo?
You wouldn't find CertManager related features in kubernetes-client jar itself. All Fabric8 Kubernetes Client Extensions are available via their own individual jars. For CertManager, you need to add this dependency:
Maven:
<dependency>
<groupId>io.fabric8</groupId>
<artifactId>certmanager-client</artifactId>
<version>5.9.0</version>
</dependency>
Gradle:
implementation 'io.fabric8:certmanager-client:5.9.0'
There is an example placed in https://github.com/fabric8io/kubernetes-client/tree/master/extensions/certmanager/examples/src/main/java/io/fabric8/certmanager/examples/v1 . Maybe this section needs improvement; you're welcome to contribute some more examples if you have some time :-) .
I've tested your sample on a demo project with certmanager-client dependency with certmanager installed on minikube. You can find demo project here: https://github.com/rohankanojia-forks/cert-manager-java-extension-demo
Related
I have a java web application secured with OKTA. I have the below code which throws the below exception,
Client client = Clients.builder()
.setOrgUrl((String)SessionUtils.getSession().getAttribute("serverUrl"))
.setClientCredentials(new TokenClientCredentials((String)SessionUtils.getSession().getAttribute("apiKey")))
.build();
When I run it, I get the below error. I have tried adding the jar by going to the buildPath of eclipse project. I am using the below dependencies in my POM and this used to work before when my project had an ANT build. But I started getting this error when I moved to Maven.
java.lang.IllegalStateException: Unable to find a
'com.okta.sdk.impl.http.RequestExecutorFactory' implementation on the
classpath. Please ensure you have added the okta-sdk-httpclient.jar
file to your runtime classpath. at
com.okta.commons.lang.Classes.lambda$loadFromService$0(Classes.java:205)
at java.util.Optional.orElseThrow(Optional.java:290) at
com.okta.commons.lang.Classes.loadFromService(Classes.java:205) at
com.okta.sdk.impl.client.BaseClient.createRequestExecutor(BaseClient.java:103)
at com.okta.sdk.impl.client.BaseClient.(BaseClient.java:72) at
com.okta.sdk.impl.client.AbstractClient.(AbstractClient.java:60)
at
com.okta.sdk.impl.client.DefaultClient.(DefaultClient.java:117)
at
com.okta.sdk.impl.client.DefaultClientBuilder.build(DefaultClientBuilder.java:322)
I could resolve this by using the okta-sdk-httpclient :v1.5.2 to match some of the other OKTA dependencies that I had in my project.
Below are the dependencies that I had in my project prior to the fix.
-okta-authn-sdk-api :v1.0.0
-okta-authn-sdk-impl :v1.0.0
-okta-http-api :v1.2.8
-okta-commons-lang :v1.2.8
-okta-config-check :v1.2.8
-okta-http-okhttp :v1.2.8
-okta-jwt-verifier :v0.5.1
-okta-jwt-verifier-impl:v0.4.0
-okta-sdk :v0.0.4
-okta-sdk-api :v1.5.2
-okta-sdk-httpclient :v6.0.0
-okta-sdk-impl :v1.5.2
I added Vaadin google maps addon to my Spring boot project. If I want to display map on site, then I get error:
Widgetset 'com.vaadin.DefaultWidgetSet' does not contain an
implementation for com.vaadin.tapio.googlemaps.GoogleMap. Check the
connector's #Connect mapping, the widgetset's GWT module description
file and re-compile your widgetset. In case you have downloaded a
vaadin add-on package, you might want to refer to add on instructions
If I add #Widgetset("com.vaadin.v7.Vaadin7WidgetSet") annotation to UI class, then I get this error:
Failed to load the widgetset:
./VAADIN/widgetsets/com.vaadin.v7.Vaadin7WidgetSet/com.vaadin.v7.Vaadin7WidgetSet.nocache.js?1521722356809
And I have a question: How should a widgetset look like, how to build it? I was looking for examples and tutorials but I still can't do this.
I read that in early Vaadin versions, I should do a manual compilation widget, but in version 8 compiling is automated.
Maybe this is important information, but I use gradle not maven.
Please help me, because I am trying to fix it for a week.
As soon as you include add-ons in your Vaadin project, you need to compile the widgetset and the widgetset needs to include the add-on widgetsets.
I have the following src/main/resources/widgetsets/AppWidgetset.gwt.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Vaadin//DTD Vaadin 7//EN" "https://raw.github.com/vaadin/gwt/master/distro-source/core/src/gwt-module.dtd">
<module>
<inherits name="com.vaadin.DefaultWidgetSet"/>
<!-- include widgetsets of external add-ons here -->
<inherits name="org.vaadin.hene.popupbutton.widgetset.PopupbuttonWidgetset"/>
</module>
This includes the Vaadin PopupButton add-on. Of course you need to adapt it to include your desired add-ons. My gradle build looks like:
configurations {
vaadinAddOns
widgetSetCompilation
themeCompilation
}
dependencies {
themeCompilation('com.vaadin:vaadin-spring-boot-starter')
}
task compileWidgetSet(type: JavaExec) {
// execution of Vaadin GWT compiler
classpath configurations.vaadinAddOns
classpath configurations.widgetSetCompilation
classpath file("${projectDir}/src/main/resources/widgetsets")
main = 'com.google.gwt.dev.Compiler'
args '-war', "${projectDir}/src/main/resources/VAADIN/widgetsets"
args '-strict'
args '-logLevel', 'WARN'
args 'AppWidgetset'
jvmArgs '-Xmx1024M'
doLast {
// clean up unnecessary stuff
file("${projectDir}/src/main/resources/VAADIN/gwt-unitCache").deleteDir()
file("${projectDir}/src/main/resources/VAADIN/widgetsets/WEB-INF").deleteDir()
}
// for the up-to-date check of gradle
outputs.dir("${projectDir}/src/main/resources/VAADIN/widgetsets/AppWidgetset")
}
clean.dependsOn cleanCompileWidgetSet
processResources.dependsOn compileWidgetSet
// on-the-fly theme compilation is disabled in Vaadin production mode, so we do the compilation ourselves
task compileThemes {
def themesFolder = file("${projectDir}/src/main/resources/VAADIN/themes")
new FileNameFinder().getFileNames(themesFolder.toString(), '**/styles.scss').each { path ->
def themeFolder = file(path).getParentFile()
def fileIn = new File(themeFolder, 'styles.scss')
def fileOut = new File("${buildDir}/resources/main/VAADIN/themes/${themeFolder.getName()}/styles.css")
dependsOn tasks.create("compileTheme${themeFolder.getName().capitalize()}", JavaExec) {
classpath configurations.themeCompilation
main = 'com.vaadin.sass.SassCompiler'
args fileIn, fileOut
inputs.dir(themesFolder)
outputs.file(fileOut)
}
}
}
processResources.dependsOn compileThemes
And finally the annotation:
#Widgetset("AppWidgetset")
public class MyUI extends UI {
...
}
This is a lot of manual stuff. You can omit the theme compilation if you do not run in Vaadin production mode for now. I am almost sure that there is a Vaadin gradle plugin out there that simplifies the widgetset and theme compilation but when I was looking for it it didn't match my requirements.
Btw: Vaadin 7 widgetset is not appropriate for Vaadin 8 :)
I sounds like your project is missing build setup for Vaadin extensions requiring client side extensions (aka custom widgetset). This happens often with new Spring users as start.spring.io don't currently support adding third party Maven plugins. Addin vaadin-maven-plugin and doing full build should fix the issue.
To see a Spring Boot project with vaadin-maven-plugin configured, I suggest to use the viritin-spring-archetype and see the generated project (and especially the pom.xml generated by the project). You can also manually copy the relevant parts from the official plain servlet project template (generated by the default archetype or IDE plugins).
When using Gradle the fix is similar in nature. If you created the project using start.spring.io, you can just add the gradle-vaadin-plugin to your project, by adding follow snippet to your build.gradle file, e.g. after buildScript section:
plugins {
id 'com.devsoap.plugin.vaadin' version '1.3.1'
}
You will also need to declare dependencies with client side extensions as follows (use google maps coordinates instead):
vaadinCompile("org.vaadin.addon:v-leaflet:2.0.6")
I have an Eclipse Maven project consisting of multiple modules, some of which contain Xml schemas that I want to generate classes for (using Jaxb). My project layout is as follows:
schemas\core (pom)
schemas\core\types (jar)
schemas\vehicle (pom)
schemas\vehicle\automobile (jar)
schemas\vehicle\civic (jar)
The projects that contain schemas are:
schemas\core\types (xsd\types.xsd)
schemas\vehicle\automobile (xsd\automobile.xsd)
schemas\vehicle\civic (xsd\civic.xsd)
Some of the modules contain schemas that import schemas from other modules:
automobile.xsd imports types.xsd
civic.xsd imports types.xsd, automobile.xsd
Since the schemas are located in different projects I use a classpath catalog resolver along with catalog files to resolve the location of the schemas.
The automobile project depends on schemas in the types project. Here is the entry in its catalog file (catalog.xml):
<rewriteSystem systemIdStartString="http://schemas/core/types/" rewritePrefix="classpath:xsd/" />
Note the use of classpath:xsd/ to tell the catalog resolver to find the schemas on the classpath.
I also use episodes to prevent the classes in types from being re-generated inside the automobile project. Here is a snippit from my pom.xml:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.8.3</version>
<configuration>
<episodes>
<episode>
<groupId>schemas.core</groupId>
<artifactId>types</artifactId>
<version>1.0-SNAPSHOT</version>
</episode>
<episodes>
<catalog>src/main/resources/catalog.xml</catalog>
<catalogResolver>org.jvnet.jaxb2.maven2.resolver.tools.ClasspathCatalogResolver</catalogResolver>
<extension>true</extension>
....
When I run mvn clean install on automobile project everything works file. The schema types.xsd is resolved on the classpath and the classes are ultimately generated.
Where I run into problems is trying to compile the project civic.
The civic project depends on both types.xsd and automobile.xsd. I use a catalog file (catalog.xml) to define the location of the schemas:
<rewriteSystem systemIdStartString="http://schemas/core/types/" rewritePrefix="classpath:xsd/" />
<rewriteSystem systemIdStartString="http://schemas/vehicle/automobile/" rewritePrefix="classpath:xsd/" />
I use episodes to prevent re-generation of the classes. Here is a snippit from the pom.xml for civic:
<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<version>0.8.3</version>
<configuration>
<episodes>
<episode>
<groupId>schemas.core</groupId>
<artifactId>types</artifactId>
<version>1.0-SNAPSHOT</version>
</episode>
<episode>
<groupId>schemas.vehicle</groupId>
<artifactId>automobile</artifactId>
<version>1.0-SNAPSHOT</version>
</episode>
</episodes>
<catalog>src/main/resources/catalog.xml</catalog>
<catalogResolver>org.jvnet.jaxb2.maven2.resolver.tools.ClasspathCatalogResolver</catalogResolver>
<extension>true</extension>
...
When I try to run mvn clean install on the civic project I run into problems. It complains about not being able to resolve the public/system ids. Here are some of the error messages I get:
Could not resolve publicId [null], systemId [jar:file:/_m2repository/schemas/vehicle/automobile/1.0-SNAPSHOT/automobile-1.0-SNAPSHOT.jar!http://schemas/core/types/types.xsd]
[ERROR] Error while parsing schema(s).Location [].
com.sun.istack.SAXParseException2;
IOException thrown when processing "jar:file:/_m2repository/schemas/vehicle/automobile/1.0-SNAPSHOT/automobile-1.0-SNAPSHOT.jar!http://schemas/core/types/types.xsd".
Exception: java.net.MalformedURLException: no !/ in spec.
....
For some reason it cannot find types.xsd when trying to parse the jar file from the automobile project.
Does anyone know why this might be happening?
Thank you.
Note - I was experimenting around with tying to get things to work and I did find one way. If I remove the episodes from the pom.xml file I no longer get the error, however, the project civic ends up with all the types from the dependent modules (which is something I am tying to avoid by using the episodes).
If you want to see the full catalog.xml and pom.xml files for each project please see the following links:
types: http://pastebin.com/Uym3DY6X
automobile: http://pastebin.com/VQM4MPuW
civic: http://pastebin.com/eGSVGwmE
Author of the maven-jaxb2-plugin here.
I have just released the 0.10.0 version of the maven-jaxb2-plugin. This release fixes the MAVEN_JAXB2_PLUGIN-82 issue which is related to the reported problems.
This was actually NOT a bug in the maven-jaxb2-plugin, but an issue (or, better to say a few issues) in the XJC itself:
https://java.net/jira/browse/JAXB-1044
https://java.net/jira/browse/JAXB-1045
https://java.net/jira/browse/JAXB-1046
These issues cause problems when catalog and binding files are used together. This was also the reason why the Maven artifact resoltion did not work correctly in certain cases.
In the 0.10.0 release, I have implemented workarounds for JAXB-1044 and JAXB-1045. I will try to get my patches to the XJC via pull requests, but you know, I'm not sure, when/if Oracle guys will accept my PRs.
In the maven-jaxb2-plugin I've now implemented quite reliable workarounds. See this test project here:
https://github.com/highsource/maven-jaxb2-plugin/tree/master/tests/MAVEN_JAXB2_PLUGIN-82
This does exactly what you want: resolves schema via catalog AND Maven resolver to the resource from another artifact. Basically, this rewriting:
REWRITE_SYSTEM "http://www.ab.org" "maven:org.jvnet.jaxb2.maven2:maven-jaxb2-plugin-tests-MAVEN_JAXB2_PLUGIN-82-a:jar::!"
now works fine.
In case of problems do mvn -X and check the output, you'll also see the statements of the catalog resolver in the log. This might give you hints, what does not work.
Here's another project which uses schemas, bindings and the catalog itself from one central artifact:
https://github.com/highsource/w3c-schemas
Snippets from the POM:
<schemas>
<schema>
<url>http://www.w3.org/1999/xlink.xsd</url>
</schema>
</schemas>
<schemaIncludes/>
<bindings>
<binding>
<dependencyResource>
<groupId>${project.groupId}</groupId>
<artifactId>w3c-schemas</artifactId>
<resource>globalBindings.xjb</resource>
<version>${project.version}</version>
</dependencyResource>
</binding>
</bindings>
<catalogs>
<catalog>
<dependencyResource>
<groupId>${project.groupId}</groupId>
<artifactId>w3c-schemas</artifactId>
<resource>catalog.cat</resource>
<version>${project.version}</version>
</dependencyResource>
</catalog>
</catalogs>
Catalog:
REWRITE_SYSTEM "http://www.w3.org" "maven:org.hisrc.w3c:w3c-schemas:jar::!/w3c"
Binding:
<jaxb:bindings schemaLocation="http://www.w3.org/1999/xlink.xsd" node="/xs:schema">
<jaxb:schemaBindings>
<jaxb:package name="org.hisrc.w3c.xlink.v_1_0"/>
</jaxb:schemaBindings>
</jaxb:bindings>
So how all of this works:
Schemas as well as the catalog and global bindings are stored in the central artifact w3c-schemas.
The project wants to compile the URL http://www.w3.org/1999/xlink.xsd.
The catalog rewrites this URL into the systemId maven:org.hisrc.w3c:w3c-schemas:jar::!/w3c/1999/xlink.xsd. (There's a /w3c/1999/xlink.xsd resource in the w3c-schemas jar).
This systemId is then resolved my the Maven catalog resolver (delivered my the maven-jaxb2-plugin) into the "real" URL which will be some jar:... URL pointing to the resource within the w3c-schemas artifact JAR in the local repository.
So the schema is not downloaded from the Internet but taken from the local resource.
The workaround keep the "original" systemIds, therefor you can customize the schema using its original URL. (The resolved systemId won't be convenient.)
The catalog file and the global bindings file will be the same for all the individual projects, so they're also put into the central artifact and referenced there using the dependencyResource.
I have the same problem. Schema C imports B and A, B imports A. Generating sources for A, works, B is also fine and for C a MalformedUrlException pops up.
I'm still investigating the error but a workaround is to use the systemIdSuffix (Oasis spec 1.1) to match the systemId and rewrite it. You need to do the following:
Remove the 'catalogResolver' element from the plugin configuration in the poms.
Replace the content of the catalog file for the 'automobile' project with the following:
<systemSuffix systemIdSuffix="types.xsd" uri="maven:schemas.core:types!/types.xsd"/>
Replace the content of the catalog file for the 'civic' project with the following:
<systemSuffix systemIdSuffix="types.xsd" uri="maven:schemas.core:types!/types.xsd"/>
<systemSuffix systemIdSuffix="automobile.xsd" uri="maven:schemas.vehicle:automobile!/automobile.xsd"/>
Let me know if this works for you.
I faced similar problems. I used the sample projects found here.
I modified these projects in 2 ways:
1) Have an A project with 2 namespaces and a local catalog file. Have a project B depending on this, using the episode of A in B.
2) Have an A project, a B project and a C project. B relies on A and C relies on B.
In both cases I got the same exception as you. But I started to realize in situation 2 what is happening.
This is the exception:
com.sun.istack.SAXParseException2; IOException thrown when processing "jar:file:/Users/sjaak/.m2/repository/org/tst/b-working/1.0/b-working-1.0.jar!http://www.a1.org/a1/a1.xsd". Exception: java.net.MalformedURLException: no !/ in spec.
So, it tries to resolve namespace http://www.a1.org/a1/a1.xsd relative to project B when building project C. I traced the problem back to com.sun.tools.xjc.reader.internalizerAbstractReferenceFinderImpl, method startElement.
The solution I use is adapting the org.jvnet.jaxb2.maven2:maven-jaxb2-plugin. I used their MavenCatalogResolver (the default one as pointed out above) and made a small change, simply not offering the whole systemId: jar:file:/Users/sjaak/.m2/repository/org/tst/b-working/1.0/b-working-1.0.jar!http://www.a1.org/a1/a1.xsd, but in stead use a pattern that only offers the part after the exclamation mark for resolving.
Here's the code:
package org.jvnet.jaxb2.maven2.resolver.tools;
import java.net.URI;
import java.net.URISyntaxException;
import java.net.URL;
import java.text.MessageFormat;
import org.jvnet.jaxb2.maven2.DependencyResource;
import org.jvnet.jaxb2.maven2.DependencyResourceResolver;
import com.sun.org.apache.xml.internal.resolver.CatalogManager;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class MavenCatalogResolver extends
com.sun.org.apache.xml.internal.resolver.tools.CatalogResolver {
private final static Pattern PTRN = Pattern.compile("^jar:file:(.*).jar!(.*)$");
public static final String URI_SCHEME_MAVEN = "maven";
private final DependencyResourceResolver dependencyResourceResolver;
private final CatalogManager catalogManager;
public MavenCatalogResolver(CatalogManager catalogManager,
DependencyResourceResolver dependencyResourceResolver) {
super(catalogManager);
this.catalogManager = catalogManager;
if (dependencyResourceResolver == null) {
throw new IllegalArgumentException(
"Dependency resource resolver must not be null.");
}
this.dependencyResourceResolver = dependencyResourceResolver;
}
#Override
public String getResolvedEntity(String publicId, String systemId)
{
String result;
Matcher matcher = PTRN.matcher(systemId);
if (matcher.matches())
{
result = super.getResolvedEntity(publicId, matcher.group(2));
}
else
{
result = super.getResolvedEntity(publicId, systemId);
}
if (result == null) {
return null;
}
try {
final URI uri = new URI(result);
if (URI_SCHEME_MAVEN.equals(uri.getScheme())) {
final String schemeSpecificPart = uri.getSchemeSpecificPart();
try {
final DependencyResource dependencyResource = DependencyResource
.valueOf(schemeSpecificPart);
try {
final URL url = dependencyResourceResolver
.resolveDependencyResource(dependencyResource);
String resolved = url.toString();
return resolved;
} catch (Exception ex) {
catalogManager.debug.message(1, MessageFormat.format(
"Error resolving dependency resource [{0}].",
dependencyResource));
}
} catch (IllegalArgumentException iaex) {
catalogManager.debug.message(1, MessageFormat.format(
"Error parsing dependency descriptor [{0}].",
schemeSpecificPart));
}
return null;
} else {
return result;
}
} catch (URISyntaxException urisex) {
return result;
}
}
}
This actually fixed my problem. I'll investigate a bit more. I've got the feeling there might be some XJC arg that I could use, or perhaps the catalog XML format offers more possibilities.
Hope it helps.
I am trying to compile and run the storm-kafka-starter project at
https://github.com/TheHydroImpulse/storm-kafka-starter
The main function for KafkaTopology looks like:
public class KafkaTopology {
public static void main(String[] args) throws Exception {
List<String> hosts = new ArrayList<String>();
hosts.add("localhost");
SpoutConfig kafkaConf = new SpoutConfig(StaticHosts.fromHostString(hosts,1),
"test-topic","/kafkastorm","discovery");
kafkaConf.scheme = new SchemeAsMultiScheme(new StringScheme());
kafkaConf.forceStartOffsetTime(-2);
TopologyBuilder builder = new TopologyBuilder();
builder.setSpout("spout", kafkaSpout, 2);
builder.setBolt("printer", new PrinterBolt()).shuffleGrouping("spout");
Config config = new Config();
config.setDebug(true);
if(args!=null && args.length > 0) {
config.setNumWorkers(3);
StormSubmitter.submitTopology(args[0], config, builder.createTopology());
}
else {
config.setMaxTaskParallelism(3);
LocalCluster cluster = new LocalCluster();
cluster.submitTopology("kafka", config, builder.createTopology());
Thread.sleep(10000);
cluster.shutdown();
}
}
}
The jar compiles using maven. But on running the topology, I get the error:
Exception in thread "main" java.lang.NoClassDefFoundError:
storm/kafka/KafkaConfig$BrokerHosts
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
at java.lang.Class.getMethod0(Class.java:2694)
at java.lang.Class.getMethod(Class.java:1622)
at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486)
Caused by: java.lang.ClassNotFoundException: storm.kafka.KafkaConfig$BrokerHosts
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 6 more
The local repository does have BrokerHosts in the storm-kafka jar and I have imported the KafkaConfig library in my java file. I cannot figure out the cause of the error. Any suggestions would be appreciated.
I had similar issues using the 0.9.2_incubating version of Apache Storm.
The isssue is caused because the actual storm distribution doesn't have the kafka libraries in the /lib folder. I was able to resolve the error by copying the following libraries (that I used to compile & build the topology) to the /lib folder from where i ran Storm
storm-kafka-0.9.2-incubating.jar
kafka_2.10-0.8.1.1.jar
scala-library-2.10.1.jar
Remember that the actual versions in your case might vary. Take the ones that you use to build your storm topology (i.e. from .m2 or .gradle dependencies folder)
Note: I am not using the exact same starter project mentioned above but the fix will be similar.
I went through the storm-user groups and the issues on the storm-kafka-starter github page. It turns out that the error is due to two reasons:
Version incompatibility among versions of storm, kafka and kafka-storm
Missing jars on the classpath
My initial setup did not work even after including all the necessary dependency jars in the /storm/lib folder. Turns out that the storm-kafka-starter project mentioned works only for storm 0.9.x versions.
Also see post here on which setup works best - https://groups.google.com/d/msg/storm-user/V_j_JZmFsb4/E4_II9ork3UJ
I went through the same integration woes. Finally got a working example together.
You are welcome to check it out here >
https://github.com/buildlackey/cep
(click on the storm+kafka directory for a sample program that should get you up and running).
I failed to use to correct maven build command. Using
mvn clean install assembly:assembly
and using the jar with dependencies fixed it form me.
Changed pom.xml from
<dependency>
<groupId>org.apache.storm</groupId>
<artifactId>storm-kafka</artifactId>
<version>1.0.2</version>
<scope>provided</scope>
</dependency>
to
<dependency>
<groupId>org.apache.storm</groupId>
<artifactId>storm-kafka</artifactId>
<version>1.0.2</version>
</dependency>
Now it works for me!
I'm trying a project for school using JMS and ActiveMQ.
I copied the block of code from O'Reilly's books "Java Message Service 2nd Edition Jun 2009". It uses the publish and subscribe method and is in fact a small chat where everyone connected to the topic can send messages to everyone and everyone can see everyone else's messages. I compile the program and everything is ok, i try to run it and it gives me the following exception:
Exception in thread "main" javax.naming.NoInitialContextException: Cannot instantiate class: org.apache.activemq.jndi.ActiveMQInitialContextFactory [Root exception is java.lang.ClassNotFoundException: org.apache.activemq.jndi.ActiveMQInitialContextFactory]
I found that this problem might be because of 2 reasons:
activemq-all-5.2.0.jar is not added to classpath.
BUT added it the classpath (EnvironmentVariables->select ClassPath->Edit and add the following: "D:\Programming\JMS\ActiveMQ\apache-activemq-5.2.0" (THIS IS HOW YOU ADD IT NO?!?!)
jndi.properties file is not defined properly or has not been added to the classpath.
BUT i CREATED IT and added it's folder to the classpath. Here is what it contains:
java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory
java.naming.provider.url = tcp://localhost:61616
java.naming.security.principal=system
java.naming.security.credentials=manager
connectionFactoryNames = TopicCF
topic.topic1 = jms.topic1
What is the problem? I have tried for ages to make it work. Am i doing something wrong? :(
Does the jndi.properties file path matter? or it only has to be placed in classpath and from here it can be found?
I also ran the activemq.bat from the bin folder D:\Programming\JMS\ActiveMQ\apache-activemq-5.2.0\bin\
[Edit]---------------------
So it works in Eclipse, BUT
Now i've properly added the .jar file in environment variables and i've run the client from windows's cmd. It doesn't give any errors, when i write in Eclipse's console, it appears in cmd console, everything ok, but when i try to write in cmd it gives an error at this line:
publisher.publish(message);
and it says
java.lang.NoSuchMethodError: org.apache.activemq.ActiveMQMessageProducerSupport.getDestination()Ljavax/jms/Destination;
Any ideas? I'd really like to be able to run it in CMD. :(
---------------------[/Edit]
Well I'm on Linux right now, but I bet it has to be:
D:\Programming\JMS\ActiveMQ\apache-activemq-5.2.0.jar
Also, if you run it with Eclipse and go to Project -> Build Path and this jar then there shouldn't be any problems. Anyhow can you post the CLASSPATH variable?
EDIT
I can't help you if you can't help me. This is related to any other future questions or work in general, provide details - it is always helpful. Will be much helpful if you would provide the EXACT command that you are running in CMD and the code of the class where this happens.
java.lang.NoSuchMethodError
generally it means that the jar is in place, class also, BUT the method is not. It happens when you compile with one version of the jar and at runtime provide a jar where this method was removed, thus the JRE can't find it throwing the error.
I just tested on my computer
I do not understand why it does not work for you, but it does for me. Here is my class:
package com.test;
public class Publisher {
public static void main(String[] args) {
try{
ConnectionFactory factory = new ActiveMQConnectionFactory("tcp://localhost:61616");
Connection connection = factory.createConnection();
ActiveMQSession session = (ActiveMQSession) connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Topic destination = session.createTopic("FOO.TEST");
TextMessage textMessage = session.createTextMessage("Sample Payload");
TopicPublisher publisher = session.createPublisher(destination);
publisher.publish(textMessage);
session.close();
connection.close();
} catch(Exception e){
e.printStackTrace();
}
}
}
Everything is fine if I run it from eclipse with one single dependency in Maven:
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-core</artifactId>
<version>5.2.0</version>
Then I do it with java and javac
javac -classpath /home/eugen/.m2/repository/org/apache/activemq/activemq-core/5.2.0/activemq-core-5.2.0.jar:/home/eugen/.m2/repository/javax/jms/jms/1.1/jms-1.1.jar Publisher.java
Notice that the only thing I added is the two jars.
Then java:
java -classpath /home/eugen/.m2/repository/org/apache/activemq/activemq-core/5.2.0/activemq-core-5.2.0.jar:/home/eugen/.m2/repository/commons-logging/commons-logging-api/1.1/commons-logging-api-1.1.jar:/home/eugen/.m2/repository/org/apache/camel/camel-core/1.5.0/camel-core-1.5.0.jar:/home/eugen/workspace/t/src/main/java/:/home/eugen/.m2/repository/javax/jms/jms/1.1/jms-1.1.jar:/home/eugen/.m2/repository/org/apache/geronimo/specs/geronimo-j2ee-management_1.0_spec/1.0/geronimo-j2ee-management_1.0_spec-1.0.jar com.test.Publisher
I added a few needed jars to the classpath and run it - it works perfectly.
Cheers, Eugene.
I ran into the same issue and it was a space (or what appeared to be a space) at the end of my property config.
java.naming.factory.initial = org.apache.activemq.jndi.ActiveMQInitialContextFactory
Also note that you don't necessarily have to embed the jar file into your client code. Simply including the activemq-all as a maven dependency will work as well.