[
https://issues.apache.org/jira/browse/FELIX-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eoghan Glynn updated FELIX-2063:
--------------------------------
Attachment: felix_2063.patch
Patch attached, please review and commit if OK.
> [karaf] hardcoding org.ops4j.pax.exam.rbc.rmi.port property in raw pax runner
> --vmOptions is problematic when 1099 is not the next free port
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-2063
> URL: https://issues.apache.org/jira/browse/FELIX-2063
> Project: Felix
> Issue Type: Bug
> Components: Karaf
> Affects Versions: karaf-1.4.0
> Reporter: Eoghan Glynn
> Fix For: karaf-1.4.0
>
> Attachments: felix_2063.patch
>
>
> Pax-runner calculates the next free port to use on the "client side" of the
> RMI connection, whereas the "server side" RMI registry takes its port from
> the org.ops4j.pax.exam.rbc.rmi.port property regardless of whether this is
> free or not.
> Therefore the org.ops4j.pax.exam.rbc.rmi.port should not be hard-coded via
> the rawPaxRunnerOption("--vmOptions", ...) mechanism.
> Now the whole point of setting the raw --vmOptions was to avoid the
> karaf-specific system.packages setting being overridden by pax-runner.
> However a similar effect can be achieved without having to specify a
> org.ops4j.pax.exam.rbc.rmi.port property if the
> org.ops4j.pax.exam.container.def.PaxRunnerOptions.vmOption is used instead of
> the org.ops4j.pax.exam.container.def.PaxRunnerOptions.rawPaxRunnerOption.
> This approach appears to work even when another process is hogging port 1099.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
