[
https://issues.apache.org/jira/browse/FELIX-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894353#action_12894353
]
Felix Meschberger commented on FELIX-2492:
------------------------------------------
Comes to mind: Another, even better option than adding a compile-scope
dependency on slf4j-simple is to not use constant fields referring to SLF4J
loggers. There are at least two good reasons for this:
(1) Having a complie-scope dependency on slf4-simple is bad, because the goal
of slf4j is to properly separate the compile time issues (cared for by the
developer) from the run-time issues (cared for by the deployer and/or system
administrator). So, at least, you should mark your slf4j-simple compile time
dependency as optional so as to not transitively forward this dependency.
(2) Having constant references to complex objects makes the work of the
garbage collector unnecessarily hard: The referred-to object can only be
collected once the class containing the static final reference is collected ....
So, your best fix would probably be to change your "static final" reference to
just a "final" reference. And everything would be fine.
> 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.
