You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2009/04/03 13:18:13 UTC
[jira] Resolved: (JCRRMI-13) Enhancement to get RMI through
firewalls
[ https://issues.apache.org/jira/browse/JCRRMI-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting resolved JCRRMI-13.
---------------------------------
Resolution: Fixed
Fix Version/s: 2.0
Assignee: Jukka Zitting
Implemented in revision 761613.
I made the port number an attribute of the ServerAdapterFactory class, so you can easily set it in Java code when instantiating the server:
{code}
ServerAdapterFactory factory = new ServerAdapterFactory();
factory.setPortNumber(...)
RemoteRepository remote = factory.getRemoteRepository(repository);
{code}
If the port number is not explicitly set, then it is set to the value of the proposed org.apache.jackrabbit.rmi.port system property. If that property is not set, then the default value 0 (for a random port) is used.
> Enhancement to get RMI through firewalls
> ----------------------------------------
>
> Key: JCRRMI-13
> URL: https://issues.apache.org/jira/browse/JCRRMI-13
> Project: Jackrabbit JCR-RMI
> Issue Type: Improvement
> Environment: RHEL Linux 5.0
> Reporter: Tony Richardson
> Assignee: Jukka Zitting
> Fix For: 2.0
>
>
> It is difficult to get RMI through a firewall with the current implementation of org.apache.jackrabbit.rmi.server.ServerObject. As it selects a random port for RMI execution. This issue can be resolved by adding a system property and modifying the default constructor as shown below.
> private static Integer bindPort = Integer.getInteger("org.apache.jackrabbit.rmi.port", new Integer(0));
> /**
> * Creates a basic server adapter that uses the given factory
> * to create new adapters.
> *
> * @param factory remote adapter factory
> * @throws RemoteException on RMI errors
> */
> protected ServerObject(RemoteAdapterFactory factory)
> throws RemoteException {
> super(bindPort.intValue());
> this.factory = factory;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (JCRRMI-13) Enhancement to get RMI through
firewalls
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Apr 3, 2009 at 4:19 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> I apologize if I missed a discussion on this, but how will commons/jcr-rmi
> be included if jcr-rmi is already a subproject of trunk or the 1.5 branch?
> If jcr-rmi is going to appear in trunk shouldn't it be an external link to
> commons/jcr-rmi?
See the recent discussions on the JCR Commons subproject. JCR-RMI is
the first component that I'm moving outside the main Jackrabbit trunk.
The new official location is jackrabbit/commons/jcr-rmi/trunk. Having
a separate JCRRMI Jira project for this component is a part of this
change.
So far I've left the jackrabbit-jcr-rmi directory intact in
jackrabbit/trunk to avoid breaking things there before we make a
proper standalone release of JCR-RMI.
If people find this confusing, we can drop the jackrabbit-jcr-rmi
directory already now and replace it with a static dependency to the
latest released version of the component.
BR,
Jukka Zitting
Re: [jira] Resolved: (JCRRMI-13) Enhancement to get RMI through firewalls
Posted by Ralph Goers <ra...@dslextreme.com>.
I updated jackrabbit trunk to try to look at the code changes and
didn't see anything updated. I then blew away trunk and checked out
jackrabbit/trunk. Still, these changes weren't there. I then looked at
the commit email and noticed the changes actually went to jackrabbit/
commons/jcr-rmi.
I apologize if I missed a discussion on this, but how will commons/jcr-
rmi be included if jcr-rmi is already a subproject of trunk or the 1.5
branch? If jcr-rmi is going to appear in trunk shouldn't it be an
external link to commons/jcr-rmi?
Ralph
On Apr 3, 2009, at 4:18 AM, Jukka Zitting (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/JCRRMI-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Jukka Zitting resolved JCRRMI-13.
> ---------------------------------
>
> Resolution: Fixed
> Fix Version/s: 2.0
> Assignee: Jukka Zitting
>
> Implemented in revision 761613.
>
> I made the port number an attribute of the ServerAdapterFactory
> class, so you can easily set it in Java code when instantiating the
> server:
>
> {code}
> ServerAdapterFactory factory = new ServerAdapterFactory();
> factory.setPortNumber(...)
> RemoteRepository remote = factory.getRemoteRepository(repository);
> {code}
>
> If the port number is not explicitly set, then it is set to the
> value of the proposed org.apache.jackrabbit.rmi.port system
> property. If that property is not set, then the default value 0 (for
> a random port) is used.
>
>> Enhancement to get RMI through firewalls
>> ----------------------------------------
>>
>> Key: JCRRMI-13
>> URL: https://issues.apache.org/jira/browse/JCRRMI-13
>> Project: Jackrabbit JCR-RMI
>> Issue Type: Improvement
>> Environment: RHEL Linux 5.0
>> Reporter: Tony Richardson
>> Assignee: Jukka Zitting
>> Fix For: 2.0
>>
>>
>> It is difficult to get RMI through a firewall with the current
>> implementation of org.apache.jackrabbit.rmi.server.ServerObject. As
>> it selects a random port for RMI execution. This issue can be
>> resolved by adding a system property and modifying the default
>> constructor as shown below.
>> private static Integer bindPort =
>> Integer.getInteger("org.apache.jackrabbit.rmi.port", new Integer(0));
>> /**
>> * Creates a basic server adapter that uses the given factory
>> * to create new adapters.
>> *
>> * @param factory remote adapter factory
>> * @throws RemoteException on RMI errors
>> */
>> protected ServerObject(RemoteAdapterFactory factory)
>> throws RemoteException {
>> super(bindPort.intValue());
>> this.factory = factory;
>> }
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>