[Design the new POJO MicroContainer] - Re: Performance - Update
by mstruk
About 'file.getChild() -> getChildren() madness' ...
getChildren() is only getting called when no handler is found in handler's childCache for the given name. But that does happen a lot (WEB-INF probing ...)
The reason getChildren() is being called is because of the specifics of how .vfslink mechanism works.
** How links mechanism works **
FileSystemContext supports a linking mechanism. You create a properties file and put it in a directory that's somewhere under a FileSystemContext root.
This properties file has to conform to a naming convention - something.vfslink.properties. The first part of the name ('something') is irrelevant - it plays no role.
An example content of this file:
| vfs.link.name=extras
| vfs.link.name.0=extra1.jar
| vfs.link.target.0=${jboss.server.home.url}extra/extra1.jar
| vfs.link.name.1=extra2.jar
| vfs.link.target.1=${jboss.server.home.url}extra/extra2.jar
|
Let's say this file is inside 'deploy' directory. This would create a LinkHandler named 'extras' under 'deploy' FileHandler. And this LinkHandler will contain two children - 'extra1.jar' and 'extra2.jar'.
The result of placing this file are therefore the following additional virtual files:
| deploy/extras
| deploy/extras/extra1.jar
| deploy/extras/extra2.jar
|
Detecting if LinkHandler (the virtual directory containing links) was removed
Link handler can be removed by a) removing .vfslink.properties file that caused its creation, b) changing vfs.link.name property of this same file.
Detecting if link was added
Link handler can be added by a) adding a new .vfslink.properties file, b) changing vfs.link.name property of existing .vfslink.properties file.
The main problem of this design is that there is no one-to-one mapping between LinkHandler name ('deploy/extras' in our example), and the properties file that created it ('something.vfslink.properties' in our example). If we want to determine the current configured state of links we _have to_ find all .vfslink.properties files in parent directory ('deploy' in our case), and process them. That's why getChildren() gets called. We could for example just check the file from which the link was created (LinkHandler contains that info) but that's not enough. This file may have disappeared due to being renamed into something else, which shouldn't affect links configuration - nothing substantial changed.
If we want to optimize this, we need to change the implementation. The simplest change would be to cancel vfs.link.name property and tie LinkHandler name to the first component of .vfslink.properties file - in our example it would have to be called extras.vfslink.properties.
This little change is enough to now be able to avoid having to call getChildren() on the parent in order to process all .vfslink.properties files in parent directory.
I've commited a fix along these lines.
- marko
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168305#4168305
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168305
18 years, 1 month
[Design of POJO Server] - Re: Updating to latest MC projects
by ALRubinger
"adrian(a)jboss.org" wrote : 3) ScopedClassLoaderUnitTestCase
|
| There is a fix for this in the latest jboss-cl release, but the test is currently failing
| because one of the test jars is not getting built:
|
|
| | <testcase classname="org.jboss.test.classloader.test.ScopingUnitTestCase" name="testNestedWarManifest" time="3.222">
| | <error message="no protocol: /home/ejort/jboss-head/testsuite/output/lib/staticarray2.sar" type="java.net.MalformedURLException">java.net.MalformedURLException: no
| | protocol: /home/ejort/jboss-head/testsuite/output/lib/staticarray2.sar
| | at java.net.URL.<init>(URL.java:567)
| | at java.net.URL.<init>(URL.java:464)
| | at java.net.URL.<init>(URL.java:413)
| | at org.jboss.test.JBossTestServices.getDeployURL(JBossTestServices.java:211)
| | at org.jboss.test.JBossTestServices.undeploy(JBossTestServices.java:352)
| | at org.jboss.test.JBossTestCase.undeploy(JBossTestCase.java:276)
| | at org.jboss.test.classloader.test.ScopingUnitTestCase.testNestedWarManifest(ScopingUnitTestCase.java:255)
| |
I haven't seen this packaging error yet, but there is a leak, as reported by Brian:
https://jira.jboss.org/jira/browse/EJBTHREE-1442
..due to Proxies not getting unbound. See linked issue in that JIRA for EJBTHREE-1385, which will resolve it.
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168232#4168232
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168232
18 years, 1 month
[Design of POJO Server] - Re: Updating to latest MC projects
by adrian＠jboss.org
"alesj" wrote : A piece I forgot to mention:
|
| | Index: server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java
| | ===================================================================
| | --- server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java (revision 76315)
| | +++ server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java (working copy)
| | @@ -70,12 +70,11 @@
| |
| | import org.jboss.deployers.spi.annotations.AnnotationEnvironment;
| | import org.jboss.deployers.spi.annotations.Element;
| | -import org.jboss.deployers.spi.deployer.DeploymentStages;
| | import org.jboss.deployers.vfs.spi.structure.VFSDeploymentUnit;
| | import org.jboss.virtual.VirtualFile;
| |
| | /**
| | - * A PRE_REAL deployer which generates metadata from annotations.
| | + * A POST_CLASSLOADER deployer which generates metadata from annotations.
| | * Alternative option to its super class.
| | *
| | * @author Ales.Justin(a)jboss.org
| | @@ -89,7 +88,6 @@
| | public AltAnnotationMetaDataDeployer()
| | {
| | super();
| | - setStage(DeploymentStages.PRE_REAL);
| | setInput(AnnotationEnvironment.class);
| | // add annotations AnnotationMetaDataDeployer scans
| | addAnnotationClass(Stateful.class);
| | @@ -142,7 +140,12 @@
| |
| | Set<Class<?>> classes = new HashSet<Class<?>>();
| | for(Class<? extends Annotation> annotation : annotationOnClass)
| | - classes.addAll(env.classIsAnnotatedWith(annotation));
| | + {
| | + Class<Annotation> annotationClass = (Class<Annotation>)annotation;
| | + Set<Element<Annotation, Class<?>>> elements = env.classIsAnnotatedWith(annotationClass);
| | + for(Element<Annotation, Class<?>> elt : elements)
| | + classes.add(elt.getOwner());
| | + }
| | for(Class<? extends Annotation> annotation : annotationOnMethod)
| | {
| | Class<Annotation> annotationClass = (Class<Annotation>)annotation;
| |
|
| See that removal of explicit DeploymentStage.PRE_REAL.
Yep that works.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168229#4168229
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168229
18 years, 1 month
[Design of POJO Server] - Re: Updating to latest MC projects
by alesj
A piece I forgot to mention:
| Index: server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java
| ===================================================================
| --- server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java (revision 76315)
| +++ server/src/main/org/jboss/deployment/AltAnnotationMetaDataDeployer.java (working copy)
| @@ -70,12 +70,11 @@
|
| import org.jboss.deployers.spi.annotations.AnnotationEnvironment;
| import org.jboss.deployers.spi.annotations.Element;
| -import org.jboss.deployers.spi.deployer.DeploymentStages;
| import org.jboss.deployers.vfs.spi.structure.VFSDeploymentUnit;
| import org.jboss.virtual.VirtualFile;
|
| /**
| - * A PRE_REAL deployer which generates metadata from annotations.
| + * A POST_CLASSLOADER deployer which generates metadata from annotations.
| * Alternative option to its super class.
| *
| * @author Ales.Justin(a)jboss.org
| @@ -89,7 +88,6 @@
| public AltAnnotationMetaDataDeployer()
| {
| super();
| - setStage(DeploymentStages.PRE_REAL);
| setInput(AnnotationEnvironment.class);
| // add annotations AnnotationMetaDataDeployer scans
| addAnnotationClass(Stateful.class);
| @@ -142,7 +140,12 @@
|
| Set<Class<?>> classes = new HashSet<Class<?>>();
| for(Class<? extends Annotation> annotation : annotationOnClass)
| - classes.addAll(env.classIsAnnotatedWith(annotation));
| + {
| + Class<Annotation> annotationClass = (Class<Annotation>)annotation;
| + Set<Element<Annotation, Class<?>>> elements = env.classIsAnnotatedWith(annotationClass);
| + for(Element<Annotation, Class<?>> elt : elements)
| + classes.add(elt.getOwner());
| + }
| for(Class<? extends Annotation> annotation : annotationOnMethod)
| {
| Class<Annotation> annotationClass = (Class<Annotation>)annotation;
|
See that removal of explicit DeploymentStage.PRE_REAL.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168227#4168227
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168227
18 years, 1 month
[Design of POJO Server] - Re: Updating to latest MC projects
by emuckenhuber
"adrian(a)jboss.org" wrote :
| 3) ScopedClassLoaderUnitTestCase
|
| There is a fix for this in the latest jboss-cl release, but the test is currently failing
| because one of the test jars is not getting built:
|
|
| | <testcase classname="org.jboss.test.classloader.test.ScopingUnitTestCase" name="testNestedWarManifest" time="3.222">
| | <error message="no protocol: /home/ejort/jboss-head/testsuite/output/lib/staticarray2.sar" type="java.net.MalformedURLException">java.net.MalformedURLException: no
| | protocol: /home/ejort/jboss-head/testsuite/output/lib/staticarray2.sar
| | at java.net.URL.<init>(URL.java:567)
| | at java.net.URL.<init>(URL.java:464)
| | at java.net.URL.<init>(URL.java:413)
| | at org.jboss.test.JBossTestServices.getDeployURL(JBossTestServices.java:211)
| | at org.jboss.test.JBossTestServices.undeploy(JBossTestServices.java:352)
| | at org.jboss.test.JBossTestCase.undeploy(JBossTestCase.java:276)
| | at org.jboss.test.classloader.test.ScopingUnitTestCase.testNestedWarManifest(ScopingUnitTestCase.java:255)
| |
Hmm well it's actually doing:
| deploy("staticarray.sar");
| ...
| undeploy("staticarray2.sar");
|
So i guess we just can undeploy the right .sar and it should work - right ? :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168225#4168225
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4168225
18 years, 1 month