[Design the new POJO MicroContainer] - Re: Updating Kernel to XB 2.0.1.Beta3 leads to weird mvn iss
by jaikiran
"alesj" wrote :
|
| Can someone try this out?
Fails for me too (with 2.1.0.Beta3 of JBossXB). But the tests fail even when they are run as a single test, on my system.
Here's the error logs, which show that it's a SecurityManager exception originating from JBossXB:
-------------------------------------------------------------------------------
| Test set: org.jboss.test.kernel.config.test.ElementXMLTestCase
| -------------------------------------------------------------------------------
| Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.808 sec <<< FAILURE!
| testElement(org.jboss.test.kernel.config.test.ElementXMLTestCase) Time elapsed: 0.694 sec <<< ERROR!
| org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/NotBackedUp/jpai/business/jboss/wc/jbossas/projects/microcontainer/trunk/kernel/target/test-classes/xml-test/org/jboss/test/kernel/config/test/testElement.xml@5,49
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177)
| at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:147)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:147)
| at org.jboss.test.kernel.config.support.XMLUtil.<init>(XMLUtil.java:76)
| at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.bootstrapXML(AbstractKernelConfigTest.java:74)
| at org.jboss.test.kernel.config.test.ElementXMLTestCase.instantiateElement(ElementXMLTestCase.java:53)
| at org.jboss.test.kernel.config.test.ElementTestCase.testElement(ElementTestCase.java:54)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at junit.framework.TestCase.runTest(TestCase.java:168)
| at junit.framework.TestCase.runBare(TestCase.java:134)
| 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.extensions.TestDecorator.basicRun(TestDecorator.java:24)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
| at junit.framework.TestResult.runProtected(TestResult.java:128)
| at junit.extensions.TestSetup.run(TestSetup.java:27)
| at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
| at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
| at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
| at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
| at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
| Caused by: java.lang.ExceptionInInitializerError
| at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:261)
| at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:307)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
| at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
| at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
| at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
| at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
| at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
| at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
| at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
| at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
| at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
| at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:173)
| ... 33 more
| Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission xb.builder.useUnorderedSequence read)
| at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
| at java.security.AccessController.checkPermission(AccessController.java:427)
| at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
| at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
| at java.lang.System.getProperty(System.java:628)
| at org.jboss.xb.builder.JBossXBBuilder.<clinit>(JBossXBBuilder.java:87)
| ... 48 more
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223547#4223547
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223547
17 years
[Design the new POJO MicroContainer] - Re: Improving the process of applying AnnotationPlugins on M
by jaikiran
Ales,
I haven't yet given this a try, will do it some time tonight. But as i mentioned earlier, i think this won't solve our issue completely :) Here's what i mean:
- As can be seen in the attached MCAnnotationPlugin_BEFORE screenshot, in the JIRA, its the call to MetaDataRetrievalToMetaDataBridge.getComponentMetaData that would have to be minimized
- Right now, its being called for every single method/field in the object hierarchy.
- Consider this case:
public class FirstPOJO
| {
|
| private Integer fieldOne;
|
| private Integer fieldTwo;
|
| ... totally 20 such fields, which are of no meaning to MC
|
| // One single field which is relevant to MC (annotation plugin)
| @Inject
| private SomeMCBean tobeInjected;
|
| ... 20 getter/setter
| }
|
|
public class SecondPOJO extends FirstPOJO
| {
|
| private Integer doNotBotherMC;
| .. such 20 more fields and getter/setters
|
| // the only method, which is relevant to MC (annotation plugin)
| @Inject
| public void setSomeBean(SimplePOJO mcbean)
| {
| ....
| }
|
|
| }
|
|
In this example, we just have a one level hierarchy of the MC pojos. In this hiearchy, there just 1 field and 1 method which MC (ideally) needs to process for annotation plugins. The rest 40 odd methods and fields in this hierarchy are of no relevance to the MC.
However, the way it currently behaves, MC first creates the ComponentMetaData for each of these 40 odd fields and methods, then checks for any relevant MC annotations and if not found (correctly) ignores those members.
Now, assuming that we introduced the @MCAnnotations annotation. In that case, the POJOs will have this:
@MCAnnotations (Inject.class)
| public class FirstPOJO
| {
| ...// rest code remains the same
|
@MCAnnotations (Inject.class)
| public class SecondPOJO extends FirstPOJO
| {
| ...// rest code remains the same
|
|
This still won't solve our original issue, because on finding the @MCAnnotations (Inject.class), MC is still going to create the ComponentMetaData for all those 40 fields/method (out of which only a couple are relevant for MC).
I guess, we either have to reduce the number of calls to getComponentMetaData() or tune the getComponentMetaData() itself.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223507#4223507
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223507
17 years