Community
Participate
Working Groups
Noticed this ClassCastException in TestableProjectFactoryStrategy.perform() when called by MetaDataModelManagerFactory.getMetaDataModelManagerInstance(). Not sure if this is just a test issue or not. From the stack trace it looks like the project argument must be null in MetaDataModelManagerFactory.getMetaDataModelManagerInstance(). However, was wondering if it was correct to pass in the workspace root when trying to create an instance of MetaDataModelManagerFactory if the project is null. The stack appears in the log for the metadata tests for the build today. here's the stack trace... java.lang.ClassCastException: org.eclipse.core.internal.resources.WorkspaceRoot incompatible with org.eclipse.core.resources.IProject at org.eclipse.jst.jsf.common.internal.strategy.TestableProjectFactoryStrategy.perform(TestableProjectFactoryStrategy.java:1) at org.eclipse.jst.jsf.common.internal.strategy.AbstractTestableExtensibleDefaultProviderSelectionStrategy$IdententifiableStrategyWrapper.perform(AbstractTestableExtensibleDefaultProviderSelectionStrategy.java:76) at org.eclipse.jst.jsf.common.internal.strategy.StrategyComposite$DefaultCompositionStrategy.compose(StrategyComposite.java:180) at org.eclipse.jst.jsf.common.internal.strategy.StrategyComposite.perform(StrategyComposite.java:66) at org.eclipse.jst.jsf.common.metadata.internal.MetaDataModelManagerFactory$CompositeFactorySelectionStrategyProvider.getFactoryToUse(MetaDataModelManagerFactory.java:118) at org.eclipse.jst.jsf.common.metadata.internal.MetaDataModelManagerFactory.getMetaDataModelManagerFactoryProviderInstances(MetaDataModelManagerFactory.java:109) at org.eclipse.jst.jsf.common.metadata.internal.MetaDataModelManagerFactory.createNewInstance(MetaDataModelManagerFactory.java:95) at org.eclipse.jst.jsf.common.metadata.internal.MetaDataModelManagerFactory.createNewInstance(MetaDataModelManagerFactory.java:1) at org.eclipse.jst.jsf.common.internal.resource.ResourceSingletonObjectManager.getInstance(ResourceSingletonObjectManager.java:85) at org.eclipse.jst.jsf.common.metadata.internal.MetaDataModelManagerFactory.getMetaDataModelManagerInstance(MetaDataModelManagerFactory.java:57) at org.eclipse.jst.jsf.common.metadata.query.TaglibDomainMetaDataQueryHelper.getMDModel(TaglibDomainMetaDataQueryHelper.java:203) at org.eclipse.jst.jsf.common.metadata.query.TaglibDomainMetaDataQueryHelper.getModel(TaglibDomainMetaDataQueryHelper.java:90) at org.eclipse.jst.jsf.common.metadata.query.TaglibDomainMetaDataQueryHelper.getEntities(TaglibDomainMetaDataQueryHelper.java:123) at org.eclipse.jst.jsf.common.metadata.query.TaglibDomainMetaDataQueryHelper.getEntity(TaglibDomainMetaDataQueryHelper.java:101) at org.eclipse.jst.jsf.common.metadata.tests.TraitValueHelperTests.setUp(TraitValueHelperTests.java:42) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:376) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:209) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:35) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Created attachment 169904 [details] Fix
This exception will only occur if the project is null in a metadata context which is something that is not typical, but is allowed currently but deprecated by the framework. The JUnit test that throws the exception uses a null project. Since a null project context may be being used by adopters, it is more than just a fix for a JUnit. I therefore have marked this as a candidate for RC3.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This is a stop-ship defect. Adopter products could be using the metadata framework similar to that in the Junit test resulting in a CCE. * Is there a work-around? If so, why do you believe the work-around is insufficient? No reasonable workaround * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Verified by running the affected junit test. * Give a brief technical overview. Who has reviewed this fix? See comment 2 * What is the risk associated with this fix? low
I'm fine with this, but I do always get nervous seeing inheritance change this late in the game, so please double check if that's the best solution. Is there any chance this could impact adopters? I know its "internal" ... but, is it the sort of thing anyone would be tempted to (incorrectly) use in a "instanceof" statement? Any reason TestableResourceFactoryStrategy should maybe extend the original TestableProjectFactoryStrategy instead of just implement ISimpleStrategy? I'm asking all this in the spirit of getting you to look twice :) I've no knowledge of this code, and just took a quick glance at patch. But, it is only a 'normal' bug. So .. if there's any risk with current solution, please have others review if inheritance solution is best. But, again, I'm fine with what ever you decide.
Additional review by Cam. Checked into HEAD 5/26/10.
