[Design the new POJO MicroContainer] - AccessControlException in AnnotationValueImpl
by kabir.khan＠jboss.com
I'm able to run the org.jboss.test.kernel.annotations.test.override.XXXOverrideXMLTestCase tests from the command-line, but when I try from my IDE I get the following exception. I'm not sure why it works in one environment and not the other. Flavia/Ales, can you please try this as well?
| org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/Users/kabir/sourcecontrol/kernel/trunk/subversion/kernel/target/test-classes/xml-test/org/jboss/test/kernel/annotations/test/override/testExternalOverride.xml@3,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.annotations.test.override.ExternalAnnotationOverrideXMLTestCase.getTester(ExternalAnnotationOverrideXMLTestCase.java:49)
| at org.jboss.test.kernel.annotations.test.override.ExternalAnnotationOverrideTestCase.testExternalOverride(ExternalAnnotationOverrideTestCase.java:90)
| 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
| at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
| Caused by: org.jboss.xb.binding.JBossXBRuntimeException: access denied (java.lang.RuntimePermission accessDeclaredMembers)
| at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.installCallbacks
| at org.jboss.beans.metadata.plugins.AbstractClassLoaderMetaData.classLoader
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.classLoader
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.rethrowWithLocation(JBossXBNoSchemaBuilder.java:2079)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:379)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElements(JBossXBNoSchemaBuilder.java:354)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:238)
| at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:291)
| at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:181)
| at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:160)
| at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:315)
| at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:277)
| 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)
| ... 29 more
| Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)
| 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.checkMemberAccess(SecurityManager.java:1662)
| at java.lang.Class.checkMemberAccess(Class.java:2125)
| at java.lang.Class.getDeclaredMethods(Class.java:1762)
| at sun.reflect.annotation.AnnotationInvocationHandler.getMemberMethods(AnnotationInvocationHandler.java:257)
| at sun.reflect.annotation.AnnotationInvocationHandler.equalsImpl(AnnotationInvocationHandler.java:169)
| at sun.reflect.annotation.AnnotationInvocationHandler.invoke(AnnotationInvocationHandler.java:40)
| at $Proxy22.equals(Unknown Source)
| at org.jboss.reflect.plugins.AnnotationValueImpl.equals(AnnotationValueImpl.java:148)
| at java.util.HashMap.put(HashMap.java:422)
| at java.util.HashSet.add(HashSet.java:194)
| at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.mergeAnnotations(AbstractBeanInfoFactory.java:352)
| at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanProperties(AbstractBeanInfoFactory.java:311)
| at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:157)
| at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:124)
| at org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:81)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:893)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:812)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:800)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:556)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:515)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1745)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1179)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:812)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:800)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:556)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:515)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1745)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1179)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:812)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:800)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:556)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:515)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1745)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1179)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:812)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:800)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:556)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:515)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createElementBinding(JBossXBNoSchemaBuilder.java:394)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:374)
| ... 49 more
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250253#4250253
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250253
16 years, 7 months
[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by tfennelly
The old "using the mep" for sync/async responses chestnut again... Sorry Kev ;)
Here was what was said on IM that time...
anonymous wrote : (12:18:47) Tom Fennelly: another quick one... the mep issue
| (12:18:55) Tom Fennelly: what was the issue with the?
| (12:19:26) Tom Fennelly: you don't wanna use it to decide whether or not a respnse is sent back?
| (12:19:33) Kevin Conner: The mep of the service has no bearing on the http gateway, it is an impleme
| ntation config
| (12:19:36) Kevin Conner: You can't
| (12:19:57) Kevin Conner: A response can be sent back from a OneWay mep if it chains the request
| (12:20:13) Kevin Conner: Service A (OneWay) -> Service B (RequestResponse)
| (12:20:37) Kevin Conner: It is an implementation detail and not part of the service contract
I'm not trying to contradict Kev, but given our current model where the gateways are configured on the services, I don't understand why the service mep is not an indicator of whether or not the invoked http-gateway should return the service response as its response (mep=RequestResponse), or should simply return an empty response as its response (mep=OneWay).
It seems to me like having an additional sync/async config on the gateway would be very confusing for users. I think this is what's being proposed, right?
So, assuming we add a "sync" flag on the http-gateway, how should the gateway respond when...
1. gateway sync=true, service mep=OneWay?
2. gateway sync=true, service mep=RequestResponse?
3. gateway sync=false, service mep=OneWay?
4. gateway sync=false, service mep=RequestResponse?
If the http-gateway used the mep, what use case breaks, and how does it break i.e. what actually goes wrong e.g. with the chained services example outlined in the IM?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250252#4250252
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250252
16 years, 7 months
[Design the new POJO MicroContainer] - Re: Does ScopeKey need to maintain a sorted (in ScopeLevel.l
by smarlow＠redhat.com
Updates to ScopeKey are here http://pastebin.com/m2fc19bab
UnmodifiableScopeKey is here http://pastebin.com/m19feda54
Perhaps we could make further MDR changes to reduce the number of times that ScopeKey.equals is called during AS startup. The above changes shouldn't break any existing API and we still pass the serialization ScopeKey unit test. If we agree on making these changes, I'll add unit tests for UnmodifiableScopeKey.
Other changes:
Index: src/main/java/org/jboss/metadata/plugins/repository/basic/BasicMetaDataRepository.java
===================================================================
--- src/main/java/org/jboss/metadata/plugins/repository/basic/BasicMetaDataRepository.java (revision 92394)
+++ src/main/java/org/jboss/metadata/plugins/repository/basic/BasicMetaDataRepository.java (working copy)
@@ -108,8 +108,9 @@
{
if (retrieval == null)
throw new IllegalArgumentException("Null retrieval");
- ScopeKey key = retrieval.getScope();
+ ScopeKey key = retrieval.getScope().getOptimizedKey();
key.freeze();
return retrievals.put(key, retrieval);
}
Index: src/main/java/org/jboss/metadata/plugins/context/AbstractMetaDataContext.java
===================================================================
--- src/main/java/org/jboss/metadata/plugins/context/AbstractMetaDataContext.java (revision 92394)
+++ src/main/java/org/jboss/metadata/plugins/context/AbstractMetaDataContext.java (working copy)
@@ -114,7 +114,8 @@
for (Scope scope : scopes)
key.addScope(scope);
}
- scopeKey = key;
+ scopeKey = key.getOptimizedKey();
}
return scopeKey;
}
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250232#4250232
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250232
16 years, 7 months
[Design of JBossXB] - Re: JBossXB should swap out the Context ClassLoader before i
by rodos77
"pfrontiero" wrote : The only way we have been able to get around this problem is to disable the WarClassLoaderDeployer (by commenting it out in war-deployers-jboss-beans.xml), however, this is not an ideal workaround.
If you application depends on using the version of xerces included in your war, this approach will not work as it essentially forces your app to use the xerces bundled with JBoss. If you're going to use this approach, you may as well just remove the xercesImpl.jar from your war. This way you will at least keep the war classloader isolation for yours, and other apps on the server.
The other way to achieve the same result as with your approach is to use jboss-classloading.xml and set parent-first=true as specified in the linked post above. But again, this will change the standard servlet spec classloading semantics and will still not allow you to use your xerces version.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4250224#4250224
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4250224
16 years, 7 months