[
https://issues.apache.org/jira/browse/FELIX-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894009#action_12894009
]
Felix Meschberger commented on FELIX-2492:
------------------------------------------
> Simply failing with a stack trace and relying on the each and every user
> digging into the problem seems not right to me.
YMMV certainly here, particularly as we are talking of "developers" not mere
users in the sense of "my mother" ;-)
But yes, the message could be nicer indicating similarly to FELIX-1726, that a
project dependency is missing.
Whether we should specially highlight SLF4J or not: I certainly don't think so.
It may be your case, that SLF4J is a primary candidate. Other users have other
candidates. So we may probably not generalize, event though SLF4J is certainly
one of the few libraries having such an issue.
> cxr plugin: using src annotations causes NoClassDefFoundError and other errors
> ------------------------------------------------------------------------------
>
> Key: FELIX-2492
> URL: https://issues.apache.org/jira/browse/FELIX-2492
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Affects Versions: maven-scr-plugin-1.4.4
> Reporter: Michael Dürig
>
> Using comment tags and having a dependency on slf4j-api causes the scr plugin
> to throw a NoClassDefFoundError:
> java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder
> at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60)
> at
> com.day.crx.spi.sharepoint.resource.SharepointResourceProvider.<clinit>(SharepointResourceProvider.java:60)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at
> sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> at java.lang.reflect.Field.get(Field.java:358)
> at
> org.apache.felix.scrplugin.tags.ClassUtil.getInitializationExpression(ClassUtil.java:41)
> at
> org.apache.felix.scrplugin.tags.qdox.QDoxJavaField.getInitializationExpression(QDoxJavaField.java:44)
> at
> org.apache.felix.scrplugin.helper.PropertyHandler.getPropertyName(PropertyHandler.java:239)
> A workaround is to add a 'dummy' dependency to i.e. slf4j-simple. But then
> [WARNING] Unused declared dependencies found:
> [WARNING] org.slf4j:slf4j-simple:jar:1.5.0:provided
> Furthermore when the 'dummy' dependency has the wrong version, the scr plugin
> might throw other errors:
> java.lang.NoSuchFieldError: name
> at org.slf4j.impl.Log4jLoggerAdapter.<init>(Log4jLoggerAdapter.java:75)
> at
> org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:75)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:103)
> at
> com.day.crx.spi.sharepoint.resource.SharepointResourceProvider.<clinit>(SharepointResourceProvider.java:60)
> at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> at
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> at
> sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
> at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> at java.lang.reflect.Field.get(Field.java:358)
> at
> org.apache.felix.scrplugin.tags.ClassUtil.getInitializationExpression(ClassUtil.java:41)
> at
> org.apache.felix.scrplugin.tags.qdox.QDoxJavaField.getInitializationExpression(QDoxJavaField.java:44)
> at
> org.apache.felix.scrplugin.helper.PropertyHandler.getPropertyName(PropertyHandler.java:238)
> I think such errors should be handled more gracefully indicating the source
> of the problem. Also it should not be necessary to have a 'dummy'
> dependencies. This was not the case up to version 1.4.1.
> If it is absolutely necessary to include such dummy dependencies, the plugin
> should state so in its error message. Also the slf4j case is so common that
> it might be worth to considering a specific solution/workaround for this in
> the plugin. This is still much better than forcing all clients to analyze the
> problem from the stacktrace and then implement workarounds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.