Did you try to look at the threaddump
(http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/)?
Could you maybe post it?
regards,
Karl
On Thu, Jun 26, 2008 at 7:10 PM, Craig Phillips
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm experiencing something weird in one newly created workspace/project,
> which is pretty much a replica of others...
>
> If I install any of the various telnet bundles, from the one below to the
> original telnetd to the one-off I recreated from source, set up a sandbox to
> run (meaning, bin and bundle and conf and cache directories and all items
> thereof), and run felix, here's the odd behavior:
>
> - The bundles all seem to load and resolve, from what I can tell from
> stdout, almost... (note I also use SCR)
> - Until I hit a keystroke / enter key (such as 'ps'), the services are not
> promulgated
> - At such time I hit a keystroke / enter key, then the services are
> propagated and telnetd gets its shell service and SCR gets busy and any
> play-hello-world bundle I have gets it's pax logger and away we go
> - If I remove shell.tui from the mix ('er, auto.start.1), all the above is
> not necessary... the services load, and telnetd (or telnet.console) and my
> hello-world bundles are all up and running, services and the like
>
> Now, I don't see this same behavior in other "sandboxes", just a newly
> created project I just set up.. all I have is a hello world in it...
>
> Obviously, I'm not asking anyone to diagnose my workspace or anything... All
> I'm asking is whether someone has seen this before and if they remember the
> circumstances and what was the fix...
>
> I'm posting / replying to this thread because I think it is apropos to the
> discussion -- there is obviously some sort of shell conflict with the
> shell.tui bundle, seemingly on the inputStream/outputStream/printStream, but
> it's beyond my comprehension ATT...
>
> Trying to narrow down the difference between this stock hello world app I
> just created could take me a while...
>
> For what it's worth, Craig
>
>
>
> 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
>>>
>
--
Karl Pauls
[EMAIL PROTECTED]
