geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: PortOffset for
Date Thu, 01 Sep 2011 15:53:11 GMT
Hi Russell,

I agree with what you say except that the osgi config admin service is not related to the
geronimo-specific var/ system, and I think we need to move towards
using config admin instead of a geronimo-specific admin service.  osgi config admin deals
with, roughly speaking, sets of configuration info per osgi service.  So to do something like
the port offset we need something that interacts with config admin, recognizes any setting
for any service that is a port, and shifts it.  If it can recognize that its a port :-) it
can also report it on demand.  In a more osgi oriented future we will also need a new way
to recognize that the server is "fully started" and I guess that could trigger listing all
the used ports.

david jencks

On Sep 1, 2011, at 7:01 AM, Russell E Glaue wrote:

> On 08/31/2011 10:18 PM, Jarek Gawor wrote:
>> On Wed, Aug 31, 2011 at 11:07 PM, Shawn Jiang <> wrote:
>>> We just turn it off by default,  the user can still open it easily if they
>>> want.
>> Is it? What does the user need to do today to turn it back on? Modify
>> the geronimo script? I think a system property set on the command line
>> wins over the property set in etc/
> Ideally
> 1. the SSH Service is on by default
> 2. It uses the admin config service - i.e. var/
> 3. a command line option can turn it off or on and change the binding port
> 4. a configuration in var/ can turn it off or on
> 5. the ssh service's bind port appears in the list of services in the server
> startup output.
> None of these are currently done.
> The problem was expressed that though we want the ideal, no one knows right know
> how to make karaf work in this way. This means we need two configuration files,
> one for karaf and one for the rest of Geronimo if we want the SSH service to be
> configurable. This results in a non-conformity - not using a single
> configuration file for all parts of the Geronimo Server.
> So to avoid confusion with first-time users who are expecting the conformity of
> all services using the single configuration file, we turn the ssh service off by
> default. In this way, when Geronimo is shipped, it is shipped with conformity in
> using the single configuration file for the Geronimo Server.
> Then we add a JIRA to have this issue made into the ideal configuration.
> In the mean time, those of use who are no novice with Geronimo, and looking for
> the additional service, can read and become aware of the current issue and
> modify the secondary and non-conforming configuration file to turn the service
> on and use it.
> IMO - all services should conform with the config admin service, otherwise be
> turned off by default (with option to turn on) until it can be made to conform.
> In full releases, non-conformities will cause issues I think we should avoid. If
> this was a snapshot, then perhaps the non-conformity could persist, as it did
> with the ActiveMQ issue (GERONIMO-5987), though it was a show-stopper issue for me.
>>>> Turning off the remote shell also might have some impact on GEP
>>>> as there is a JIRA open on using ssh terminal in Eclipse to connect to
>>>> the server.
>>> Because GEP will start the server with it's own way to control the ssh
>>> server.   I believe the impact here is limited to GEP.
>> I was thinking about using GEP with a remote server.
>> Jarek

View raw message