[
https://issues.apache.org/jira/browse/JCR-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting reopened JCR-781:
-------------------------------
Hmm, you're right. The problem doesn't seem to be the server ref object, but
rather the default socket factory instance in the JVM not being serializable. I
originally added code to explicitly use the default socket factory in case one
hasn't been specified to avoid potential NullPointerExceptions from the
UnicastRemoteObject implementation.
I removed the explicit checks in revision 529491, which seems to do the trick
for at least the Sun RMI classes, but I'm not too happy about the potential NPE
threat, so I might just revert back to original behaviour and revisit this
issue for Jackrabbit 1.4.
The main problem with the current implementation is that there is no easy way
to select the superclass constructor used by ServerObject to initialize the
UnicastRemoteObject parent. A better solution would probably be to not use
UnicastRemoteObject as the parent. Instead we should perhaps make ServerObject
extend the Remote interface, and use explicit exportObject() calls when doing
the RMI bindings.
> RMI: Allow custom socket factories
> ----------------------------------
>
> Key: JCR-781
> URL: https://issues.apache.org/jira/browse/JCR-781
> Project: Jackrabbit
> Issue Type: New Feature
> Components: rmi
> Reporter: Jukka Zitting
> Assigned To: Jukka Zitting
> Priority: Minor
> Fix For: 1.3
>
>
> The current JCR-RMI server classes always use the default RMI socket factory.
> Provide a mechanism for specifying a custom socket factory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
