[Design of POJO Server] - VFS isLeaf() vs isDirectory()/isFile()
by adrian＠jboss.org
To avoid the confusion around the isDirectory()/isFile
I've modified the VFS api to have the single method
isLeaf() which is effectively isCannotHaveChildren()
I also fixed the isArchive() so that it means either:
1) It is an archive
2) It is a structure pretending to be an archive, e.g. an unpacked directory
While I was doing this I reworked the VisitorAttribues to
remove the notions of directory.
I also changed it so all the defaults are false to make it less
confusing.
The mappings are as follows (if you have uncommitted code):
isFile() -> isLeaf()
isDirectory() -> isLeaf() == false
VisitorAttributes.NO_DIRECTORIES -> VisitorAttributes.LEAVES_ONLY
VisitorAttributes.RECURSE_DIRECTORIES -> VisitorAttributes.RECURSE
VisitorAttributes.RECURSE_NO_DIRECTORIES -> VisitorAttributes.RECURSE_LEAVES_ONLY
setIncludeDirectories(false) -> setLeavesOnly(true)
setIgnoreHidden(false) -> setIncludeHidden(true)
Hopefully this should avoid some of the confusion that has crept into
the api? Especially in the jar handlers.
Finally, I think the VFSScanner should be changed according
the TODO I added to the code, if it is doing what I think it is doing?
| // TODO replace . in the name with isArchive() == false?
| else if (component.getName().indexOf('.') == -1 && this.doRecursiveSearch)
| {
| // recurse if not '.' in name and recursive search is enabled
| addDeployments(list, component);
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974818#3974818
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974818
19 years
[Design of POJO Server] - Re: Why is DeploymentUnit.getDeploymentContext() deprecated?
by adrian＠jboss.org
"bill.burke(a)jboss.com" wrote :
| As far as Class-path manifest goes, I think we are screwed either way. For auto-scanning of the PU you will want to scan only the classpath manifest of one particular jar in web-inf/lib.
|
You make it sound like the jars in WEB-INF/lib are should be separate
deployment units?
anonymous wrote :
| Also, what about an EJB-JAR within an EAR? Is the EJB-JAR a DeploymentUnit I assume? If it is a DeploymentUnit does its ClassPath contain EAR/lib jars? If so this is really bad as again, I need to treat the EJB-JAR as its own unit.
Each deployment unit has its own classpath.
That way it is possible to implement one classloader per
deployment unit or what is done now, a classloader
for the whole deployment by consolidating the classpath with
that visitor I mentioned before.
Feel free to extend the model to whatever fine granularity you
require.
e.g. making each jar in WEB-INF/lib its own deployment unit
e.g.2. separating the classpath into internal/external (manifest)
components
This api is not final until we understand what
the real deployers need.
to do
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974804#3974804
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3974804
19 years