[
https://issues.apache.org/jira/browse/KAFKA-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138504#comment-15138504
]
ASF GitHub Bot commented on KAFKA-3218:
---------------------------------------
GitHub user rajinisivaram opened a pull request:
https://github.com/apache/kafka/pull/888
KAFKA-3218: Use static classloading for default config classes
Static classloading is better for default classes used in config to ensure
that the classes can be loaded in any environment (OSGi, JEE etc. which rely on
different classloading strategies).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rajinisivaram/kafka KAFKA-3218
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/888.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #888
----
commit c6fd1857fe085f95e9042745e24f762b8b4c550c
Author: Rajini Sivaram <rajinisiva...@googlemail.com>
Date: 2016-02-09T08:05:06Z
KAFKA-3218: Use static classloading for default config classes
----
> Kafka-0.9.0.0 does not work as OSGi module
> ------------------------------------------
>
> Key: KAFKA-3218
> URL: https://issues.apache.org/jira/browse/KAFKA-3218
> Project: Kafka
> Issue Type: Bug
> Components: clients
> Affects Versions: 0.9.0.0
> Environment: Apache Felix OSGi container
> jdk_1.8.0_60
> Reporter: Joe O'Connor
> Assignee: Rajini Sivaram
> Attachments: ContextClassLoaderBug.tar.gz
>
>
> KAFKA-2295 changed all Class.forName() calls to use
> currentThread().getContextClassLoader() instead of the default "classloader
> that loaded the current class".
> OSGi loads each module's classes using a separate classloader so this is now
> broken.
> Steps to reproduce:
> # install the kafka-clients servicemix OSGi module 0.9.0.0_1
> # attempt to initialize the Kafka producer client from Java code
> Expected results:
> - call to "new KafkaProducer()" succeeds
> Actual results:
> - "new KafkaProducer()" throws ConfigException:
> {quote} Suppressed: java.lang.Exception: Error starting bundle54:
> Activator start error in bundle com.openet.testcase.ContextClassLoaderBug
> [54].
> at
> org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:66)
> ... 12 more
> Caused by: org.osgi.framework.BundleException: Activator start error
> in bundle com.openet.testcase.ContextClassLoaderBug [54].
> at
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:2144)
> at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at
> org.apache.karaf.bundle.command.Start.executeOnBundle(Start.java:38)
> at
> org.apache.karaf.bundle.command.BundlesCommand.doExecute(BundlesCommand.java:64)
> ... 12 more
> Caused by: java.lang.ExceptionInInitializerError
> at
> org.apache.kafka.clients.producer.KafkaProducer.<init>(KafkaProducer.java:156)
> at com.openet.testcase.Activator.start(Activator.java:16)
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> at
> org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
> ... 16 more
> *Caused by: org.apache.kafka.common.config.ConfigException: Invalid
> value org.apache.kafka.clients.producer.internals.DefaultPartitioner for
> configuration partitioner.class: Class*
> *org.apache.kafka.clients.producer.internals.DefaultPartitioner could not be
> found.*
> at
> org.apache.kafka.common.config.ConfigDef.parseType(ConfigDef.java:255)
> at
> org.apache.kafka.common.config.ConfigDef.define(ConfigDef.java:78)
> at
> org.apache.kafka.common.config.ConfigDef.define(ConfigDef.java:94)
> at
> org.apache.kafka.clients.producer.ProducerConfig.<clinit>(ProducerConfig.java:206)
> {quote}
> Workaround is to call "currentThread().setContextClassLoader(null)" before
> initializing the kafka producer.
> Possible fix is to catch ClassNotFoundException at ConfigDef.java:247 and
> retry the Class.forName() call with the default classloader. However with
> this fix there is still a problem at AbstractConfig.java:206, where the
> newInstance() call succeeds but "instanceof" is false because the classes
> were loaded by different classloaders.
> Testcase attached, see README.txt for instructions.
> See also SM-2743
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
