Changing the way AbstractVFSDeployment serializes root

[alesj]

In AbstractVFSDeployment we do

 public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException
 {
 super.readExternal(in);
 root = (VirtualFile) in.readObject();
 }

 public void writeExternal(ObjectOutput out) throws IOException
 {
 super.writeExternal(out);
 out.writeObject(root);
 }

I would change it to

 public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException
 {
 super.readExternal(in);
 URL url = (URL)in.readObject();
 root = VFS.getRoot(url);
 }

 public void writeExternal(ObjectOutput out) throws IOException
 {
 super.writeExternal(out);
 out.writeObject(root.toURL());
 }

that way you don't serialize all the things that were already touched.
Only re-constructing lazy things on client side when needed.

The only thing with 2nd approach is that you loose parent info, and you probably get different vfs context.
But do we really care about that?

[starksm64]

That will also change the vfs relative path. Different vfs context should not matter, but being able to access the parent breaks the api usage.

[alesj]

That will also change the vfs relative path. Different vfs context should not matter, but being able to access the parent breaks the api usage.

What about this?

 private void writeObject(ObjectOutputStream out) throws IOException, URISyntaxException
 {
 URL url = rootUrl;
 if (url == null)
 {
 VFS vfs = getFile().getVFS();
 url = vfs.getRoot().toURL();
 }
 String pathName = path;
 if (pathName == null)
 pathName = getFile().getPathName();

 ObjectOutputStream.PutField fields = out.putFields();
 fields.put("rootUrl", url);
 fields.put("path", pathName);
 out.writeFields();
 }

 private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException
 {
 ObjectInputStream.GetField fields = in.readFields();
 rootUrl = (URL) fields.get("rootUrl", null);
 path = (String) fields.get("path", null);
 }

And then having a lazy construction on file.

This way a lot less bytes get serialized. ;-)

[starksm64]

That saves bytes, but whether or not its going to work depends on the url being usable on the target jvm deserializing the file. I suppose that is true regardless of how serialization is done.

[alesj]

That saves bytes, but whether or not its going to work depends on the url being usable on the target jvm deserializing the file. I suppose that is true regardless of how serialization is done.

I think this is the right way to do it anyway.

Since you are really forcing structure re-creation on target jvm.
Where in the case of serializing full VirtualFile, you're depending on the impl details - which in our case you might even get wrong info due to in-memory handling of nested zips, or by-passing some permission control that is enforced on server side.

If you would like to have full structure already present, I don't think you would gain much, since you would then 'pay' huge on transport, instead of at re-creation.

[alesj]

I suppose that is true regardless of how serialization is done.

"alesj" wrote:

I think this is the right way to do it anyway.

If you would like to have full structure already present, I don't think you would gain much, since you would then 'pay' huge on transport, instead of at re-creation.

Thinking about it a bit more + hitting Memory VirtualFile issue,
this looks like wrong approach. :-(

Why?
e.g. having Memory VirtualFile, we know how to serialize it -
passing info from server to client, since we transfer bytes that make
up that Memory VirtualFile, where in the case of root+path approach,
that won't work - client JVM doesn't know anything about it.

Hence, I'll revert my changes:
- https://jira.jboss.org/jira/browse/JBDEPLOY-48
- https://jira.jboss.org/jira/browse/JBDEPLOY-72

Although I saw Dimitris increased memory for smoke-tests,
I think we should properly fix how tests access server side deployments.

I believe there's already a JIRA issue about that,
assigned to Shelly if my memory serves me correctly?

But I can go ahead and fix it,
just need to know what I should use - ProfileService or DeploymentManager?
Or do we even have full API to port previous access code?

[alesj]

"alesj" wrote:

Hence, I'll revert my changes:
- https://jira.jboss.org/jira/browse/JBDEPLOY-48

Or I can leave this one?
Since how many times do we expect the root to be Memory VirtualFile? :-)

[alesj]

"alesj" wrote:

Or I can leave this one?
Since how many times do we expect the root to be Memory VirtualFile? :-)

I've added this to AbstractVFSDeployment:

 /**
 * Should we serialize root directly.
 * e.g. the root is memory virtual file instance
 * @see org.jboss.virtual.plugins.context.memory.MemoryContextHandler
 *
 * @param directRootSerialization the direct root serialization flag
 */
 public void setDirectRootSerialization(boolean directRootSerialization)
 {
 this.directRootSerialization = directRootSerialization;
 }

 public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException
 {
 super.readExternal(in);
 directRootSerialization = in.readBoolean();
 if (directRootSerialization)
 root = (VirtualFile)in.readObject();
 else
 {
 VirtualFileSerializator serializator = (VirtualFileSerializator)in.readObject();
 root = serializator.getFile();
 }
 }

 public void writeExternal(ObjectOutput out) throws IOException
 {
 super.writeExternal(out);
 out.writeBoolean(directRootSerialization);
 if (directRootSerialization)
 out.writeObject(root);
 else
 out.writeObject(new VirtualFileSerializator(root));
 }