-
1. Re: VFS serialization
"alessio.soldano@jboss.com" wrote:
Those metadata include virtual files that are not available on client side when deserialization occurs.
OK, then the first problem is leaking this information to the client.
Who's responsible for putting that VF there?
Perhaps implementing writeObject on that metadata to exclude the VF?
While we also have some problems with the serialization itself:
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=131031
We need to work out how to properly deserialize more-than-first-level nested jars. -
2. Re: VFS serialization
To answer your question about who's responsible for putting that VF there, consider we deploy a client app on server side ant this causes some data structure referencing resources through vf to be bound to jndi. Then on client side we perform jndi look up and the resources are not available any more through the vf. Thus we're wondering whether it's a valid solution to use the vf to reference resources whose reference has to survive jndi registration/look up. And getting to this would eventually require the vf to be actually serializable.
If this way of proceeding is not valid, we could go for different solutions, for example something like what you suggest. -
3. Re: VFS serialization
It depends what the VirtualFile reference means.
It isn't valid in general, just as File handles aren't serializable,
but (I think?) the VFS will try to reconstruct the path from what it knows for files.
If it is deployed on the server side and references the file on the server
rather than on the client (and they use different file systems), it doesn't mean anything.
It's broken.
If it sent a VFS file that used a webdav protocol that said
"get your resources from this server"
then that would be a different issue. -
4. Re: VFS serialization
I don't think you need to put in the whole VF.
Just put some serializable structure info, either URLs or resources path Strings.
And you can construct the actual VF when needed, leaving the performance issues to the VFS. -
5. Re: VFS serialization
"adrian@jboss.org" wrote:
It depends what the VirtualFile reference means.
It isn't valid in general, just as File handles aren't serializable,
but (I think?) the VFS will try to reconstruct the path from what it knows for files.
If it is deployed on the server side and references the file on the server
rather than on the client (and they use different file systems), it doesn't mean anything.
It's broken.
If it sent a VFS file that used a webdav protocol that said
"get your resources from this server"
then that would be a different issue.
Yes, the VFS should be serializable, but as you say, its as usable as the underlying url. file urls won't be usable unless there is a shared filesystem between the client and server.
The current ws failures are due to JBVFS-17. The serialization of the NestedJarFromStream is broken, and what I'm currently working. -
6. Re: VFS serialization
"alesj" wrote:
I don't think you need to put in the whole VF.
Just put some serializable structure info, either URLs or resources path Strings.
And you can construct the actual VF when needed, leaving the performance issues to the VFS.
Unless the underlying url/uri is remotely accessible, this is not going to work in general as Adrian said.
What is being returned in jbossas4.x servers? -
7. Re: VFS serialization
With the current vfs trunk which includes a fix for JBVFS-17, the JBCTS-752 webservice test is passing for me. I'll create a snapshot for this so the cts runs can resume.
-
8. Re: VFS serialization
OK, thank you all for the clarification and the fix (I ran the failing test using the latest vfs snapshot successfully).