Deployment redeploy

[alesj]

After spending a day on figuring out why my jboss-minimal-tests are not working as they should I also stumbled upon a question what happens if metadata changes?

I remember I had previous discussion about this with Scott.
I even found TODO (which is probably my) in
- http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/system/server/profile/basic/ProfileImpl.java
But I can see I never given it enough of thought, since I only yesterday saw that we're missing all this functionality in deployers.

Why 'missing all this functionality in deployers'?
Since in order for a client to know if the metadata has been changed, it needs to know where metadata resides, but that's is server side (structure) detail.

So this is what I came up with.
Few pseudo code lines.

The entry point to all should of course be - as for all other deployment things - DeployerClient:

 // deleted, modified, nothing
 ModifcationType getModificationType();

First we need to know if client slide Deployment still exists:

boolean exists();

which for VFSDeployment it would check if the root still exists.

Then we need to get server side representation of deployment - DeploymentContext.

And recursively check it is was modified.

if (deploymentContext.isModified())
 return true;

List<DeploymentContext> chidren = deploymentContext.getChildre();
for (DeploymentContext child : children)
 return checkModified(child);

Probably in case of VFSDeploymentContext we will check the root and metadata locations.

So at the end, impl in MainDeployerImpl would look like

ModificationType getModificationType(Deployment deployment)
{
 if (deployment.exists() == false)
 return DELETED;

 DeploymentContext context = getContext(deployment);
 if (context.isModified())
 return MODIFIED;
 else
 return NONE;
}

(OK, bunch of assert checks missing, but we get the picture :-))

So ProfileImpl would then simply call this method to see which deployment need to be handled.

Sounds OK?

[starksm64]

That todo is in the basic profile impl to see if we should be looking at the metadata files for modification. Hot deployment in terms of what has changed is part of the profile contract, not the deployer layer. I don't think the change your describing is a valid extension of the deployer api.

[alesj]

That todo is in the basic profile impl to see if we should be looking at the metadata files for modification. Hot deployment in terms of what has changed is part of the profile contract, not the deployer layer.

How are you planning on checking metadata from profile?
As I see it, metadata is server side structure contract.
And with jboss-structure.xml you can have it any where.

And it's only (vfs) deployment context that holds that info - which is what we don't want to expose, impl detail.

[starksm64]

That vfs holds the info is a profile implementation detail, and that the vfs my be involved is why it should not be in the deployer layer. There is no requirements for vfs to be used for deployers. We have run into this with pure programatic deployments not having associated VirtualFiles.

The hot deployment function depends on the profile and how it stores deployments. A vfs based profile has to deal with the vfs aspects that would affect this.

[alesj]

There is no requirements for vfs to be used for deployers. We have run into this with pure programatic deployments not having associated VirtualFiles.

Sure, that's why I'm saying Deployment(Context) should hold that methods.
It's just that we currently know how to impl that on top of VFS.
e.g. for plain Deployment(Context) it could either be noop or simple defaults (true to exists, false to isModifed).
And I don't see how names like exists(), isModified() cannot be used for any kind of deployment.

In this case, this would just make your profile even more basic, at least on modification level.
That you map deployment against vfs/uri that's your impl detail.
But part of that profile could be then used any where.

[starksm64]

and I'm saying the deployment api should not support those methods. To me is an oxymoron to ask a DeploymentUnit/Context whether it exists. That is what a profile is about.

[alesj]

"alesj" wrote:

How are you planning on checking metadata from profile?
As I see it, metadata is server side structure contract.
And with jboss-structure.xml you can have it any where.

And it's only (vfs) deployment context that holds that info - which is what we don't want to expose, impl detail.

We can argue about that, but you haven't answered my questions from above. ;-)

[starksm64]

A file system based profile like basic looks to the metadata files using the vfs.

[alesj]

A file system based profile like basic looks to the metadata files using the vfs.

Looks where? ;-)
How will it know where to look if I deploy some bogus deployment described via jboss-structure.xml?

[alesj]

And this issue also falls into this topic:
- http://jira.jboss.com/jira/browse/JBAS-4545

e.g.
having a type info (ear, war, sar, ...) on deployment could help us 'avoid' newly added jsp's - (War|Ear|Sar)StructureModificationChecker

[starksm64]

"alesj" wrote:

A file system based profile like basic looks to the metadata files using the vfs.

Looks where? ;-)
How will it know where to look if I deploy some bogus deployment described via jboss-structure.xml?

The jboss-structure defines the classpath and metadata locations. If its not consistent with what the profile impl consisders metadata, hot deployment is broken. A virtual war composed of many vfs locations should be described via a vfs level mapping if both the profile and deployers are to have the same view.

[starksm64]

"alesj" wrote:
And this issue also falls into this topic:
- http://jira.jboss.com/jira/browse/JBAS-4545

e.g.
having a type info (ear, war, sar, ...) on deployment could help us 'avoid' newly added jsp's - (War|Ear|Sar)StructureModificationChecker

The type is only available from the ManagedDeployment view. I doubt JBAS-4545 is relevant any longer as the profile does not scan into deployments for changes.

[dimitris]

I've made a quick test, as described on JBAS-4545, creating a dummy jmx-console.war/tst.jsp, and jmx-console is re-deployed, so the problem is still there.

I understand that we monitor the top level deployment for changes (in this case the jmx-console.war directory) so any changes in the directory content (addtions/removals/updates) causes it's date to be modified, which in turn triggers the re-deployment.

For unpacked deployments shouldn't we monitor some inner META-INF/web.xml descriptor, like in 4.x ?

[starksm64]

Monitoring the metadata files for changes was the point of this discussion. It should be part of the profile impl is what I'm arguing. Why the profile is looking down to the jsp level is something that needs to be looked at. Its the Profile.getModifiedDeployments call implementation that has this behavior.

[alesj]

Why the profile is looking down to the jsp level is something that needs to be looked at. Its the Profile.getModifiedDeployments call implementation that has this behavior.

basic.ProfileImpl.getModifiedDeployments
 else if( root.hasBeenModified() )

this goes down to File.lastModified for directories
Which does this

I understand that we monitor the top level deployment for changes (in this case the jmx-console.war directory) so any changes in the directory content (addtions/removals/updates) causes it's date to be modified, which in turn triggers the re-deployment.

Just ran a simple test to verify this 100%.

public class DirChecker implements Runnable
{
 private static File dir = new File("C:\\tmp");
 private long lastModified;

 public static void main(String[] args)
 {
 DirChecker target = new DirChecker();
 target.lastModified = dir.lastModified();
 new Thread(target).start();
 }

 public void run()
 {
 boolean changed = false;
 while (changed == false)
 {
 long lm = dir.lastModified();
 if (lm > lastModified)
 {
 System.out.println("lm = " + lm);
 changed = true;
 }
 }
 }
}

So I don't see how are you gonna pull this one off in a short time/simple change - w/o metadata change tracking.