[Design of JBossCache] - PojoCache physical POJO field mapping and region
by ben.wang@jboss.com
Currently, PojoCache 2.0 uses a "flat-space" mapping approach where the user-specified id stores only a "PojoReference" where in turn it refers to the internal workspace under /__JBossInternal__.
This will present some issues when marshalling and eviction are activated (individually) where both involved in a defition of a "Region". In this case, a logical region would comprise of the user-specified id and the internal workspace.
So I am proposing to use "flat-space" per region mapping. That is, when I detect a region is present, say, "/person", then if a user calls attach("/person/joe", pojo), the internal mapping will be like:
| /person
| /joe
| (key, PojoReference)
| /__JBossInternal__
| /sdaj4343xxxx
| (key, pojo)
|
such that the JBossInternal will be located under "/person" region. In this way, the eviction, marshalling, and even partial state transfer will be transparent from PojoCache point of view.
Note:
1. If there is no region found, it will fall back to the global workspace.
2. POJO relationship is maintained only within the region. That is, if joe and mary has the same address. Both joe and mary needs to be located under the same region. I think this is a logical assumption though.
What do people think?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976210#3976210
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976210
19 years, 3 months
[Design of POJO Server] - all files that make up a deployment unit
by bill.burke@jboss.com
I ran into a problem where I only want to scan for .class files in the DeploymentUnit but skip .class files in subdeployments. The current VirtualFile/Visitor code could not handle this situation so I had to extend VisitorAttributes with a isRecurseArchive() option and modify the AbstractVFSContext accordingly.
Then, in my EJB Deployer I do:
unit.getDeploymentContext().getRoot().visit(FilterOnClassFileAndNoRecurseArchives);
I don't know or not if this goes against your abstract notion of things. I'm thinking maybe that DeploymentUnit should have some new methods:
VirtualFile getResource(String name);
List getResources();
List getResources(VirtualFileFilter);
We had this discussion before, but ClassPath just won't cut it as a deployer may or may not want to distinguish between a ClassPath manifest when scanning for deployment resources (i.e. what classes to scan anntotations for).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976200#3976200
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976200
19 years, 3 months
[Design of POJO Server] - Adding new deployers
by kabir.khan@jboss.com
I've run into a problem with the deployers. The .aop archives are not recognized by the JarStructure unless deployed unpacked. Hard-coding this as one of the jarSuffixes in JarUtils would work, but is hacky since this option won't be available to people wanting to create their own deployers for things with unknown suffixes.
I've tried adding some start/stop methods to my AspectDeployer to add/remove the .aop suffix to JarUtils, but this doesn't work since the deployer/aspect-deployers-beans.xml file is read after the VFSDeployemetScanner adds the deployments. In other words FileSystemContext.createVirtualFileHandler() is called for all the deploy/xxx.aop archives BEFORE the AspectDeployer has a chance to add the .aop suffix to JarUtils. FileSystemContext.createVirtualFileHandler() uses JarUtils to check if it should create a JarHandler or a VirtualFileHandler for the context, so for .aop files we always end up with a FileHandler when what we really want is a JARHandler.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3976190#3976190
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3976190
19 years, 3 months