JBossDeveloper

"alesj" wrote:

"adrian@jboss.org" wrote:

This avoids also trivially allows you to avoid unpacking them again, since you can ask this cache.

... since it solves (b), (c) and (d).

Another use case that's puzzling me.
Or, actually it's the same as before, just new problems. :-)

* deploy/ (the context root)
** myapp.ear (packed)

So, during structure recognition, we already get a few unpacked nested jars.
Then it turns out that the user requested this app to be temped.

To be true to our unpacking/temp performace reasons (= reuse as much as possible),
do we then re-use this existing (from structure recognition) unpacked jars as children in temp's structure
(which would shake current impl severely, as we would have to 'unnaturally' re-wire handlers),
or do we just live with more copies (probably needing to know where it came from; client view vs. server view)?

e.g. VFSContext::addCacheInfo(path, viewType, handlerCopy);

Thinking about it even more ...

"alesj" wrote:

How do you then handle these three calls:
(1) root::getChildren()
(2) root::getChild("myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class")
(3) VFS::getRoot(new URL("${jboss.deploy}/myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class"))

I would expect for (1) not to use temp, otherwise I won't know when my original myapp.ear was deleted.
For (2) and (3) I would like to use all the existing temps I could get in order not to re-unpack something.

"alesj" wrote:

So, during structure recognition, we already get a few unpacked nested jars.
Then it turns out that the user requested this app to be temped.

To be true to our unpacking/temp performace reasons (= reuse as much as possible),

"alesj" wrote:

But this two new 'findings' shouldn't stop you from
adding some content to this problems. ;-)

Another issue concerning temp modification. :-(

It's the way how we track if deployment is modified.
Currently we do it based on VFSDeploymentContext,
which will point to the temps if deployment is temped.

Meaning we won't notice if the real deployment is modified.

We need to move "Deployment::hasBeenModified" off the VFSDeploymentContext.
I guess some combination of VFSDeployment and VFSDeploymentContext's metadata locations.

I'll see what can be done ...

"alesj" wrote:

We need to move "Deployment::hasBeenModified" off the VFSDeploymentContext.
I guess some combination of VFSDeployment and VFSDeploymentContext's metadata locations.

I'll see what can be done ...

Index: src/main/org/jboss/system/server/profileservice/repository/MutableDeploymentRepository.java
===================================================================
--- src/main/org/jboss/system/server/profileservice/repository/MutableDeploymentRepository.java (revision 83887)
+++ src/main/org/jboss/system/server/profileservice/repository/MutableDeploymentRepository.java (working copy)
@@ -37,8 +37,10 @@
 import java.util.concurrent.locks.ReentrantReadWriteLock;
 import java.util.zip.ZipInputStream;

+import org.jboss.deployers.client.spi.Deployment;
 import org.jboss.deployers.structure.spi.DeploymentContext;
 import org.jboss.deployers.structure.spi.main.MainDeployerStructure;
+import org.jboss.deployers.vfs.spi.client.VFSDeployment;
 import org.jboss.deployers.vfs.spi.structure.VFSDeploymentContext;
 import org.jboss.profileservice.spi.DeploymentContentFlags;
 import org.jboss.profileservice.spi.ModificationInfo;
@@ -320,9 +322,19 @@
 */
 protected boolean hasBeenModified(VFSDeploymentContext deploymentContext, boolean checkRoot) throws IOException
 {
+ Deployment clientDeployment = deploymentContext.getDeployment();
+ if (clientDeployment instanceof VFSDeployment == false)
+ {
+ if (log.isTraceEnabled())
+ log.trace("Deployment is not VFS based: " + clientDeployment);
+ return false;
+ }
+
+ VFSDeployment deployment = VFSDeployment.class.cast(clientDeployment);
+ VirtualFile root = deployment.getRoot();
+
 if (checkRoot)
 {
- VirtualFile root = deploymentContext.getRoot();
 // no need to check metadata locations if archive or root
 if (root.isArchive() || root.isLeaf())
 return root.hasBeenModified();
@@ -338,15 +350,20 @@
 {
 for(VirtualFile child : children)
 {
- String pathName = child.getPathName();
- Long timestamp = lastModifiedCache.get(pathName);
- long lastModified = child.getLastModified();
- lastModifiedCache.put(pathName, lastModified);
- if (timestamp != null && timestamp < lastModified)
+ // get client side metadata - if exists
+ VirtualFile clientChild = getClientChild(root, child);
+ if (clientChild != null)
 {
- if (log.isTraceEnabled())
- log.trace("Metadata location modified: " + child);
- return true;
+ String pathName = child.getPathName();
+ Long timestamp = lastModifiedCache.get(pathName);
+ long lastModified = clientChild.getLastModified();
+ lastModifiedCache.put(pathName, lastModified);
+ if (timestamp != null && timestamp < lastModified)
+ {
+ if (log.isTraceEnabled())
+ log.trace("Metadata location modified: " + clientChild);
+ return true;
+ }
 }
 }
 }
@@ -368,6 +385,21 @@
 }

 /**
+ * Get client side child.
+ *
+ * @param root the client root
+ * @param child the server child
+ * @return matching client child if exists
+ * @throws IOException for any error
+ */
+ protected VirtualFile getClientChild(VirtualFile root, VirtualFile child) throws IOException
+ {
+ String rootPathName = root.getPathName();
+ String childPathName = child.getPathName();
+ return root.getChild(childPathName.substring(rootPathName.length()));
+ }
+
+ /**
 * Cleanup last modified cache for path name.
 *
 * @param pathName the path name

"alesj" wrote:

Does this look legit enough?

"alesj" wrote:

"alesj" wrote:

Does this look legit enough?

This needs more work, as sub-deployments don't have Deployment instance.
I'll dig further.

public interface StructureModificationChecker extends StructureListener
{
 /**
 * Has structure been modified.
 *
 * @param root the structure's root
 * @return true if structure has been modified, false otherwise
 */
 boolean hasStructureBeenModified(VirtualFile root);
}