[Design of POJO Server] - WeakTypeCache breaks when run with SecurityManager
by kabir.khan＠jboss.com
|
| org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/Users/kabir/sourcecontrol/microcontainer/subversion/aop-mc-int/target/t
| ests-classes/org/jboss/test/aop/junit/MicrocontainerJunitSmokeTestCase.xml@3,49
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177)
| at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:147)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:295)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:439)
| at org.jboss.test.aop.junit.AOPMicrocontainerTestDelegate.deploy(AOPMicrocontainerTestDelegate.java:74)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.setUp(MicrocontainerTestDelegate.java:83)
| at org.jboss.test.aop.junit.AOPMicrocontainerTestDelegate.setUp(AOPMicrocontainerTestDelegate.java:58)
| at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
| 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:38)
| 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: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
| 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.Class.getClassLoader(Class.java:588)
| at org.jboss.util.collection.WeakTypeCache.peek(WeakTypeCache.java:260)
| at org.jboss.util.collection.WeakTypeCache.getClass(WeakTypeCache.java:236)
| at org.jboss.util.collection.WeakTypeCache.get(WeakTypeCache.java:67)
| at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getTypeInfo(IntrospectionTypeInfoFactoryImpl.java:308)
| at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getAnnotations(IntrospectionTypeInfoFactoryImpl.java:128)
| at org.jboss.reflect.plugins.InheritableAnnotationHolder.getAnnotation(InheritableAnnotationHolder.java:108)
| at org.jboss.reflect.plugins.AbstractAnnotatedInfo.getUnderlyingAnnotation(AbstractAnnotatedInfo.java:55)
| at org.jboss.xb.builder.JBossXBBuilder.initSchema(JBossXBBuilder.java:133)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.initSchema(JBossXBNoSchemaBuilder.java:202)
| at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:190)
| at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:118)
| at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.resolve(DefaultSchemaResolver.java:308)
| at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:302)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:407)
| 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)
| ... 18 more
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153058#4153058
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153058
17 years, 7 months
[Design of POJO Server] - Re: profile service, farming
by bstansberry＠jboss.com
anonymous wrote : DeploymentStages.REAL would be too far as real runtime components would start to be created. Maybe we would just need to run it through the DESCRIBE phase, maybe PRE_REAL. The main problem is a disconnect between a system that looks valid in terms of everything being there, vs actually having all of the runtime components in place.
Yes, REAL is too far, at least right now. :) I said real based on this comment in DeploymentStages
| /** The installed stage - could be used to provide valve in future? */
| DeploymentStage INSTALLED = new DeploymentStage("Installed", REAL);
where I interpreted the "valve" as being the notion Adrian described in an old thread of bringing a deployment all the way to being ready to handle requests, and then at the last stage switching JNDI refs, connectors, etc to use the new version. But we're clearly not ready for that yet. :)
anonymous wrote : There really is no one controlling entity other than the admin layer. The admin layer calling the profile service api to do the deployment is what triggers everything, dealing with failures and rolling back to the previous version, but all participants need to be properly written with dependencies in place to allow a failure to be unwound.
anonymous wrote : So by running the deployments across the cluster to the DeploymentStages.DESCRIBE phase, we know whether or not all dependencies can be satisfied. The only possible coordinator is the admin layer driving the profile service api usage. Maybe your driving at, do we want this to be an old farming deployment type of service?
No, I was being muddleheaded. In Vegas we agreed that it's going to be the admin layer that drives this. In the 2 years since I've just been looking at MainDeployer and the deployers and got my thinking in a muddle. I need to look more at the DeploymentManager API; sounds like that's where ability to do things like "running the deployments across the cluster to the DeploymentStages.DESCRIBE phase" will be exposed.
anonymous wrote : So I think we need to look at a FarmServiceUnitTestCase that uses the profile service DeploymentManager to validate the various types of things that can happen with a two node deployment say, and figure out what will/won't work for the initial release.
Sounds good; that will be my focus.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153036#4153036
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153036
17 years, 7 months
[Design of EJB 3.0] - Re: Validation of Complete EJB2.x Views: EJB3 or Metadata?
by ALRubinger
"wolfc" wrote : Some things can not be checked in metadata, because they require the correct class loader.
I'd intended for these to be done from the context of the Annotation Processing Deployers, where the CL is available.
"wolfc" wrote : In the end, somewhere in the deployer chain something like:
| Set<InvalidConstraint<JBossMetaData>> violations = someValidator.validate(jbossMetaData, "ejb3");
| should occur.
How about:
Set<InvalidConstraint<JBossMetaData>> violations = new HashSet<InvalidConstraint<JBossMetaData>>();
| violations.addAll(ejb21ViewCompleteValidator.validate(jbossMetaData));
| violations.addAll(validBusinessInterfaceValidator.validate(jbossMetaData));
| violations.addAll(validEjb21InterfaceValidator.validate(jbossMetaData));
| ...etc...
Then we can process all the validation failures and report them to the bean developer together, as opposed to failing on the first error only and hiding the rest.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153026#4153026
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153026
17 years, 7 months
[Design of POJO Server] - Re: profile service, farming
by scott.stark＠jboss.org
"bstansberry(a)jboss.com" wrote :
| This again has a coordination aspect; e.g. bean A on node 1 expresses a dependency on bean B that will be deployed on node2. If both A and B are known, cluster-wide, to the respository, you don't want A's deployment to fail with a missing dependency just because node 2's deployers haven't processed B yet.
|
So by running the deployments across the cluster to the DeploymentStages.DESCRIBE phase, we know whether or not all dependencies can be satisfied. The only possible coordinator is the admin layer driving the profile service api usage. Maybe your driving at, do we want this to be an old farming deployment type of service?
"bstansberry(a)jboss.com" wrote :
| When I think in terms of priority order though, I'm thinking somewhat differently. To me, it's
|
| 1) Restoring some sort of ability to have repository information synchronized. This is really the only thing the old farming did, in a half-assed way ;). I'd like to have this for 5.0.0.GA as I don't like taking something away, even if was half-assed.
|
| 2) Sorting out the "coordination" issue I've been talking about. The lack of that kind of coordination IMHO has always been the biggest weakness in the old FarmService.
|
So I think we need to look at a FarmServiceUnitTestCase that uses the profile service DeploymentManager to validate the various types of things that can happen with a two node deployment say, and figure out what will/won't work for the initial release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153017#4153017
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153017
17 years, 7 months
[Design of POJO Server] - Re: profile service, farming
by scott.stark＠jboss.org
"bstansberry(a)jboss.com" wrote :
| anonymous wrote : So 'hotdeployment' is purely a profile implementation detail, how we reconcile local repositories across a cluster would be part of the org.jboss.profileservice.spi.DeploymentRepository.getModifiedDeployments() implementation.
|
| But that doesn't get to controlling how the profile changes get reflected in the runtime. That's a task of the MainDeployer and the deployers.
|
Ok, that is true. Additions/removals to the profile do need to be passed through the MainDeployer to bring a running system in sync with the profile.
"bstansberry(a)jboss.com" wrote :
| An ear is deployed on all 4 nodes of a cluster. New version of the ear is deployed. Goal is that the ear be brought to a certain deployment stage (DeploymentStages.REAL?) on all nodes in the cluster such that we know the deployment will work on all nodes. A 2PC "prepare". At that point a cluster-wide "commit" is executed, the deployments are brought to the final stage where they handle requests, and the old version is removed. If there is a failure during the "prepare", the new version is rolled back and the old version left in place.
|
Ok, DeploymentStages.REAL would be too far as real runtime components would start to be created. Maybe we would just need to run it through the DESCRIBE phase, maybe PRE_REAL. The main problem is a disconnect between a system that looks valid in terms of everything being there, vs actually having all of the runtime components in place.
"bstansberry(a)jboss.com" wrote :
| There can be other variations on the above, but the main point is there is a multistep deployment process that requires intra-cluster communication at various points. Who controls that process is my question -- doesn't seem like its a concern of the DeploymentRepository, also doesn't seem like a proper concern of a deployer. My last post mentioned "some variant of the HDScanner concept" but that's not it either; you're right, HDScanner is just a trivial link between the profile and the MainDeployer and shouldn't be made into something else. Seems like this is at least partly a concern of a cluster-aware MainDeployer.
|
There really is no one controlling entity other than the admin layer. The admin layer calling the profile service api to do the deployment is what triggers everything, dealing with failures and rolling back to the previous version, but all participants need to be properly written with dependencies in place to allow a failure to be unwound.
"bstansberry(a)jboss.com" wrote :
| This is the part I need to dig into more to get a better understanding of what you mean. Perhaps that will answer my question above. :)
|
It won't. The metadata repository is just a hiearchical source of metadata that has scopes that can be where server/cluster wide defaults are picked up. It has to fit into any cluster wide notions, but solves nothing in of itself.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152999#4152999
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152999
17 years, 7 months