Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <20712205.106431280654179292.JavaMail.jira@thor>
Date: Sun, 1 Aug 2010 05:16:19 -0400 (EDT)
From: "Carsten Ziegeler (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Commented: (FELIX-2492) cxr plugin: using src annotations
 causes NoClassDefFoundError and other errors
In-Reply-To: <18290264.64651280395097684.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/FELIX-2492?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1289=
4359#action_12894359 ]=20

Carsten Ziegeler commented on FELIX-2492:
-----------------------------------------

I would suggest people to use the real annotations instead of the javadoc t=
ags anyway :) I haven't encounted such problems with annotations yet and I =
would like to get more feedback about the annotations anyway.
So I tend to agree with Felix to "just" have a nicer error message

> cxr plugin: using src annotations causes NoClassDefFoundError and other e=
rrors
> -------------------------------------------------------------------------=
-----
>
>                 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=C3=BCrig
>
> Using comment tags and having a dependency on slf4j-api causes the scr pl=
ugin to throw a NoClassDefFoundError:
> java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder
> =09at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60)
> =09at com.day.crx.spi.sharepoint.resource.SharepointResourceProvider.<cli=
nit>(SharepointResourceProvider.java:60)
> =09at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> =09at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeField=
AccessorFactory.java:25)
> =09at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.ja=
va:122)
> =09at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
> =09at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> =09at java.lang.reflect.Field.get(Field.java:358)
> =09at org.apache.felix.scrplugin.tags.ClassUtil.getInitializationExpressi=
on(ClassUtil.java:41)
> =09at org.apache.felix.scrplugin.tags.qdox.QDoxJavaField.getInitializatio=
nExpression(QDoxJavaField.java:44)
> =09at org.apache.felix.scrplugin.helper.PropertyHandler.getPropertyName(P=
ropertyHandler.java:239)
> A workaround is to add a 'dummy' dependency to i.e. slf4j-simple. But the=
n
> [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 pl=
ugin might throw other errors:
> java.lang.NoSuchFieldError: name
> =09at org.slf4j.impl.Log4jLoggerAdapter.<init>(Log4jLoggerAdapter.java:75=
)
> =09at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java=
:75)
> =09at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:103)
> =09at com.day.crx.spi.sharepoint.resource.SharepointResourceProvider.<cli=
nit>(SharepointResourceProvider.java:60)
> =09at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> =09at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeField=
AccessorFactory.java:25)
> =09at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.ja=
va:122)
> =09at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
> =09at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
> =09at java.lang.reflect.Field.get(Field.java:358)
> =09at org.apache.felix.scrplugin.tags.ClassUtil.getInitializationExpressi=
on(ClassUtil.java:41)
> =09at org.apache.felix.scrplugin.tags.qdox.QDoxJavaField.getInitializatio=
nExpression(QDoxJavaField.java:44)
> =09at org.apache.felix.scrplugin.helper.PropertyHandler.getPropertyName(P=
ropertyHandler.java:238)
> I think such errors should be handled more gracefully indicating the sour=
ce of the problem. Also it should not be necessary to have a 'dummy' depend=
encies. This was not the case up to version 1.4.1.=20
> If it is absolutely necessary to include such dummy dependencies, the plu=
gin 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 th=
is in the plugin. This is still much better than forcing all clients to ana=
lyze the problem from the stacktrace and then implement workarounds. =20

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.