Dieter Wimberger wrote:
Hi all,
I'll try to get through step by step.
Rob:
Embedded, probably. Would need to check if I used any API (net, io)
that's >= 1.3.
Felix:
Sure. The idea was from the beginning to provide felix (project) with
the functionality of a remote shell access.
There are only two classes in the telnetconsole bundle that I didn't
write myself: a Latch and a ReentrantLock; however they are actually
code that has been placed in the public domain by Doug Lea (from
Concurrent Programming in Java, which actually was the foundation for
all the java.util.concurrent).
Could there be any conflict releasing these in a package with Apache 2
License?
Also, something has to be done about logging and about having this
build with Maven (I am currently building this with my own relatively
generic ant script).
Craig:
See my answer to Felix (M.); I'll try to put up the sources asap so
you can poke around. Don't get too excited though; the essential part is:
ShellService.executeCommand(line, out, out);
Where line is the input from the client, and out is essentially a
PrintStream that prints to the OutputStream corresponding to the socket.
When it comes to the telnetd-osgi bundle, I have also experienced some
problems in the Felix container; in particular stopping the bundle and
then starting it seems to lead to unexpected results when trying to
connect to it (i.e. the connection fails completely and there are some
NPE's); I am still investigating why (may also be due to something in
the SSH library, so it's not so easy to track down maybe).
Let us know if we can help.
I haven't experienced the shutdown problem in the telnetconsole,
though. Currently I am running it ontop of felix 1.0.4 without much in
it:
[ 0] [Active ] [ 0] System Bundle (1.0.4)
[ 1] [Active ] [ 1] OSGi R4 Compendium Bundle (4)
[ 2] [Active ] [ 1] Apache Felix Shell Service (1.0.1)
[ 3] [Active ] [ 1] Apache Felix Shell TUI (1.0.1)
[ 4] [Active ] [ 1] Apache Felix Bundle Repository (1.0.3)
[ 5] [Active ] [ 1] Apache Felix Telnet Management Console (1.0)
Richard:
Honestly, I actually put together the telnetconsole bundle because I
didn't want to "cripple" telnetd-osgi into something that's no longer
useful for a generic purpose. E.g. trying to figure a way around
installing the configadmin bundle just doesn't make much sense to me
when you need to configure it anyway.
Dieter, I understand your concern, but perhaps I didn't explain the
proposal very well. We weren't discussing something that would "cripple"
telnetd-osgi, in fact the proposal was more about how it should be packaged.
The proposal was to package it with the needed commons classes and
probably the CM interfaces, thus it would be self-contained. By doing
this, we make it possible to use it without CM (i.e., CM would be
optional), but this will require no changes to telnetd-osgi
functionality, it will still register a ManagedFactoryService like
normal and everything will work exactly like it does now.
The only difference is that by packaging it in a more self-contained
way, a CM impl is not necessary and clients can inject their own
configuration directly (i.e., with no CM impl available), thus reducing
the dependency for those that don't need it. This would actually be
possible even if a CM impl was present, unless you turned on security
and forbid bundles from accessing the ManagedFactoryService.
So, no crippling intended, just more "generic" flexibility. Hope that
alleviates some of your concerns. We certainly aren't trying to run away
with your project. :-)
So here is what I suggest:
1. get the telnetconsole bundle into Felix (project):
This should be straigthforward, but see the comments I made to Felix
(M.).
Agreed, we have to look into it.
2. iron out the problems with the telnetd-osgi and figure a way to
have some of the extensions (I am using the templates extensively to
generate output on a shell).
Ok.
There is still the possibility to have it inside or outside of Felix
(project).
From my point of view, I would at least suggest not to try and
"cripple" it (i.e. this translates into: I won't do it, but the code
is open source, and available since more or less 2 years, so anybody
is welcome ;).
Since it is just a packaging issue, we could easily do this with the
maven bundle plugin.
3. provide the glue bundle I wrote (essentially a shell that is hooked
into telnetd-osgi).
This should rather be part of Felix (project). There is only my own
source and all it needs is some Maven magic to build it "the Felix way".
Yep.
Feedback is welcome as always.
Well, that's my $0.02...
-> richard
Regards,
Dieter
