sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konrad Windszus (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SLING-8073) Sling Mock: Make classloading issues with ModelAdapterFactoryUtil.getModelClassUrlsForPackage easier to debug
Date Mon, 05 Nov 2018 09:34:00 GMT
Konrad Windszus created SLING-8073:
--------------------------------------

             Summary: Sling Mock: Make classloading issues with ModelAdapterFactoryUtil.getModelClassUrlsForPackage
easier to debug
                 Key: SLING-8073
                 URL: https://issues.apache.org/jira/browse/SLING-8073
             Project: Sling
          Issue Type: Bug
          Components: Testing
    Affects Versions: Testing Sling Mock 2.3.4
            Reporter: Konrad Windszus


Currently if you have some class loading issue in a used model, you get the following kind
of exception
{code}
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 s <<< FAILURE!
- in <someTestClass>
[ERROR] <myTestMethod>  Time elapsed: 0 s  <<< ERROR!
org.reflections.ReflectionsException: could not get type for name <some Sling Model>
	at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:389)
	at org.reflections.ReflectionUtils.forNames(ReflectionUtils.java:398)
	at org.reflections.Reflections.getTypesAnnotatedWith(Reflections.java:385)
	at org.reflections.Reflections.getTypesAnnotatedWith(Reflections.java:370)
	at org.apache.sling.testing.mock.sling.context.ModelAdapterFactoryUtil.getModelClassUrlsForPackages(ModelAdapterFactoryUtil.java:147)
	at org.apache.sling.testing.mock.sling.context.ModelAdapterFactoryUtil.access$000(ModelAdapterFactoryUtil.java:54)
	at org.apache.sling.testing.mock.sling.context.ModelAdapterFactoryUtil$RegisterModelsBundle.findEntries(ModelAdapterFactoryUtil.java:231)
	at org.apache.sling.models.impl.ModelPackageBundleListener.addingBundle(ModelPackageBundleListener.java:86)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415)
	at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
	at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
	at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)
	at org.apache.sling.testing.mock.osgi.MockBundleContext.sendBundleEvent(MockBundleContext.java:372)
	at org.apache.sling.testing.mock.osgi.MockOsgi.sendBundleEvent(MockOsgi.java:60)
	at org.apache.sling.testing.mock.sling.context.ModelAdapterFactoryUtil.addModelsForPackages(ModelAdapterFactoryUtil.java:91)
	at org.apache.sling.testing.mock.sling.context.ModelAdapterFactoryUtil.addModelsForManifestEntries(ModelAdapterFactoryUtil.java:124)
	at org.apache.sling.testing.mock.sling.context.SlingContextImpl.registerDefaultServices(SlingContextImpl.java:168)
	at org.apache.sling.testing.mock.sling.context.SlingContextImpl.setUp(SlingContextImpl.java:117)
	at org.apache.sling.testing.mock.sling.junit.SlingContext.access$100(SlingContext.java:40)
	at org.apache.sling.testing.mock.sling.junit.SlingContext$1.before(SlingContext.java:127)
	at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
{code}

The problem with that is that the underlying exception is not being exposed. 
Even in the newest Reflections library the original issue is only logged (but in my case I
could not enable the logging) but not contained in the exception: https://github.com/ronmamo/reflections/blob/c95609a4e83e1f3fc71e4b2fc58b17352a16eef7/src/main/java/org/reflections/ReflectionUtils.java#L395

Is it possible to switch to another library which has a better exception handling, otherwise
those class loading issues are almost impossible to track.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message