[
http://jira.nuxeo.org/browse/NXP-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Stefanescu resolved NXP-2147.
------------------------------------
Resolution: Fixed
Fixed.
Wrote a custom RMIClassLoader impl.
and register it in nxshell (or Apogee) using
-Djava.rmi.server.RMIClassLoaderSpi=NuxeoRMIClassLoader
> nxshell is not working when installed in a path containing spaces
> -----------------------------------------------------------------
>
> Key: NXP-2147
> URL: http://jira.nuxeo.org/browse/NXP-2147
> Project: Nuxeo Enterprise Platform 5
> Issue Type: Bug
> Reporter: Bogdan Stefanescu
> Assignee: Bogdan Stefanescu
> Priority: Major
>
> This bug is caused by a java RMI bug
> First some introduction to RMI: when app A invoke app B through RMI then app
> A will serialize the request
> and along each serialized object class it encodes a "location" string.
> This location string is useful on B side if the encoded object class is not
> known by B (not in classpath of B)
> In that case the "location" string is used as a *codebase* (a site from where
> classes are living) so that B will try to download
> jars existing in that codebase. A codbase is a list of URLs. In the current
> implementation java is encoding the codebase
> by separating URLs with spaces.
> So the codebase is an URL from where an application may download classes if
> they are not found on the local JVM.
> So app A is sending a req to app B (inside the reuqest each class serialized
> and annotated with a codebase location)
> App B is reading the request and respond to app A by encoding the response +
> a codebase for each class encoded in the response.
> That way both A and B are able to instantiate classes even if they are not
> existing locally.
> The problem with the current java RMI impl is that the codebase location
> encoded by app A is not decoded correctly by app. B
> For example if you have a set of urls (here urls1) that are used as the code
> base of A and that are sent to B encoded as a string
> then the urls2 decoded by B are not always the same as the one sent by A! :)
> urls1 -> A.urlsToString -- send the encoded urls to B --> B.stringToUrls ->
> urls2
> => you may have urls1 != urls2
> This is always happening when an url in urls1 contains a space. This is
> because the urlsToString method is encoding the urls by separating them with
> a whitespace. So that if you encode the following urls:
> "file:///Program Files/Nuxeo", "file:///Program Files/Nuxeo/lib"
> you will obtain a string:
> "file:///Program Files/Nuxeo file:///Program Files/Nuxeo/lib"
> That will be decoded as 4 URLS:
> "file:///Program", "Files/Nuxeo", "file:///Program", "Files/Nuxeo/lib"
> And obviously when you want to instantiate these strings as URLs you will
> obtain a MalformedURLException
> This case can be very easy fixed in java code by using a "," delimiter
> instead of a " " (space) one.
> Anyway a real fix will be to correctly escape encoded URLs.
> In fact this looks more like a bug of the java URL impl. that doesn't encode
> correctly URLs when calling (removing spaces from URl string
> representation). If URLs were correctly implemented RMI would work too.
> (Ex: new URL("file:///C:/Program Files/MyApp").toExternalForm() will return
> "file:///C:/Program Files/MyApp")
> Because of this nxshell is not working when installed in a path containing
> whitespaces (in linux too - not only in windows)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nuxeo.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
