Hi,
Just tried it out... super small and super fast... For the tiny solution, this
looks perfect...
Any chance I could see the source? I want to learn! :)
BTW - I'm working through the tutorial page on the Felix shell service as I
want to do other mediums, such as JMS and JMX...
Kind regards, Craig Phillips
From: Dieter Wimberger
Sent: Wed 6/25/2008 6:10 PM
To: dev@felix.apache.org
Subject: Re: telnetd discussion
Richard, all:
Thought I put the "simple access alternative" together so you can
decide upon facts not ideas.
http://www.karanet.at/~wimpi/felix/org.apache.felix.telnetconsole.jar
Size is close to 15kB, only dependency is the felix shell service
bundle. Port is 6666 by default and may be configured using the system
property "osgi.shell.telnet.port".
(No command history, but BS, DEL and Strg-U work).
Regards,
Dieter
On 25 Jun 2008, at 15:35, Richard S. Hall wrote:
Dieter Wimberger wrote:
Richard, all:
I'd suggest to first take a step back and ask yourselves a question.
As far as I understood from the discussion, you would be looking
for an occasional, simple telnet based remote access to the felix
shell service.
If this is correct, then I wonder whether it really requires a
telnet/SSH2 compliant server with connection management to achieve
this. Actually, taking equinox as an example, it's nothing more
than a simple single connection without any telnet protocol
negotiation happening at all.
So, this is the question I'd suggest to ask yourselves before we
proceed to find a solution:
Do you need something like the simple equinox "telnet" access, or
do you need a "real" telnet/SSH server?
If the answer is "we need a simple access", then I would actually
suggest to hack a simple listener implementation into the glue
bundle, make it "the telnet" bundle and go with it (from my point
of view, telnetd-osgi would be simply an overkill tool for that job).
Good question. Most of my use cases would be the simple variety, but
I wouldn't want to be constrained to it either. I think the point,
for me, is to create a useful tool that is flexible enough to be
used in simple cases as well as more sophisticated ones.
-> richard
Regards,
Dieter
The following is intended as a summary of the recent discussion on
telnetd (most of this analysis is from an email Felix Meschberger
sent me).
Felix, could you please drop me a copy of this analysis? :)
The following bundles are necessary for remote shell access to
Felix:
1. Felix' standard shell bundle (i.e., shell bundle).
2. Dieter's telnetd bundle (i.e., telnetd bundle).
3. Dieter shell-telnetd glue bundle (i.e., glue bundle).
Dieter also mentioned that the telnetd bundle depended on a
commons bundle, but we could easily package this into the telnetd
bundle so that it is self-contained (we can help make this happen
with the maven bundle plugin).
From Felix' analysis, we could simplify creating remote shell
access by having the glue bundle inject a dummy configuration into
telnetd's ManagedServiceFactory so that the Config Admin
dependency could be optional. This all sounds good. (We could even
consider embedding the telnetd stuff directly into the glue
bundle, but that is another discussion.)
Given this setup, we can ponder where should the telnetd and glue
bundle projects reside? The obvious choices are at the Source
Forge telnetd site or at Felix. I think that any combination can
be reasonably argued. Here is my personal take...
I definitely think it makes sense to create a subproject for the
glue bundle at Felix, I am less certain about the telnetd bundle
itself. While I definitely want to support the telnetd bundle, I
am not sure if it really falls into the scope of the Felix project.
I guess the question is, is telnetd a completely generic telnet
implementation that could easily be used outside of OSGi or not?
If so, then it seems like it should be separate from Felix. On the
other hand, if the implementation is somehow tied to OSGi, then it
might make sense to host it at Felix.
Another possibility is that telnetd is generic, but that it has
some sort of wrapper that integrates it into an OSGi environment,
then maybe it makes sense to host the wrapper at Felix, keeping
the generic library at SF.
I would definitely like to see this functionality available. My
mind is open as to how to achieve it, so what does everyone else
think?
-> richard