This content has been marked as final.
Show 7 replies
-
1. Re: Changing the way AbstractVFSDeployment serializes root
starksm64 Jun 16, 2008 2:34 PM (in response to 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.
-
2. Re: Changing the way AbstractVFSDeployment serializes root
alesj Jun 19, 2008 2:52 AM (in response to alesj)"scott.stark@jboss.org" wrote:
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. ;-) -
3. Re: Changing the way AbstractVFSDeployment serializes root
starksm64 Jun 19, 2008 8:19 AM (in response to 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.
-
4. Re: Changing the way AbstractVFSDeployment serializes root
alesj Jun 19, 2008 8:41 AM (in response to alesj)"scott.stark@jboss.org" wrote:
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. -
5. Re: Changing the way AbstractVFSDeployment serializes root
alesj Aug 13, 2008 6:34 AM (in response to alesj)"scott.stark@jboss.org" wrote:
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? -
6. Re: Changing the way AbstractVFSDeployment serializes root
alesj Aug 13, 2008 6:37 AM (in response to 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? :-) -
7. Re: Changing the way AbstractVFSDeployment serializes root
alesj Aug 13, 2008 6:49 AM (in response to 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)); }