[
https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-619.
-----------------------------------
Resolution: Fixed
I added a configuration property to enable the workaround: shell.tui.checkinput
It is false by default. This probably won't solve all of our issues, but it is
something. We can always re-address this issue if necessary in a future release.
> Shell.TUI causes "new java.io.ServerSocket()" to hang
> -----------------------------------------------------
>
> Key: FELIX-619
> URL: https://issues.apache.org/jira/browse/FELIX-619
> Project: Felix
> Issue Type: Bug
> Components: Shell TUI
> Affects Versions: felix-1.0.4
> Environment: Windows; Best to run in a sandbox, fork java if
> necessary (for full effect)... By sandbox, I mean a directory structure /
> project area that's sterile, shall we say
> Reporter: Craig Phillips
> Assignee: Richard S. Hall
> Priority: Minor
> Fix For: shell.tui-1.4.0
>
>
> To save me from typing it in again, here's the dev mailing list excerpt:
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
> I uncovered an issue in which the Shell.TUI will cause "new
> java.io.ServerSocket()" to hang;
> Through process of elimination / gutting, pretty much to the point of a small
> bundle with an activate() method (I'm using SCR) and a "new
> ServerSocket(1234, 1)", with a couple log events pre and post, I determined
> that the construction of the ServerSocket will not return (nor timeout,
> IIRC), if the Shell.TUI bundle is started first;
> In other forms of the telnet shell, which do not use SCR/DeclarativeServices,
> I remember I had to put install and start those bundles prior to the
> Shell.TUI... However, because I changed the ordering a la SCR (my bundle is
> installed and started, but SCR does not start my "service" and activation
> thereof until my dependencies are satisfied, in this case to shell service
> and log service), my bundle activation falls behind the shell.TUI
> activation...
> So, the Shell.TUI must be causing some sort of conflict with ServerSocket ...
> I did not dig deeper than that... Not sure if someone would ask me to file a
> bug or not... I'm just putting this out there... maybe others have come
> across this, but I don't know...
> I solved my immediate problem by simple removing Shell.TUI from the
> auto.start list;
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
> autotart:
> felix.auto.start.1= \
> file:bundle/org.craig.shell.play01.jar \
> file:bundle/org.osgi.compendium-1.0.1.jar \
> file:bundle/org.apache.felix.shell-1.0.1.jar \
> file:bundle/org.apache.felix.shell.tui-1.0.1.ja
> file:bundle/org.apache.felix.configadmin-1.0.1.jar \
> file:bundle/org.apache.felix.bundlerepository-1.0.3.jar \
> file:bundle/org.apache.felix.scr-1.0.0.jar \
> file:bundle/pax-logging-api-1.0.0.jar \
> file:bundle/pax-logging-service-1.0.0.jar \
> file:bundle/pax-confman-propsloader-0.2.1.jar
> Play01.java:
> package org.craig.shell;
> import org.osgi.service.component.ComponentContext;
> import org.osgi.service.log.LogService;
> import org.apache.felix.shell.ShellService;
> import java.io.*;
> public class Play01
> {
> protected ShellService shell = null;
> protected LogService log = null;
> protected void activate(ComponentContext context) throws Exception
> {
> ServerSocket myListener = new ServerSocket(1234, 1); // Note from Craig
> - this will hang if TUI is started (presumably first)
> }
> protected void deactivate(ComponentContext context) throws Exception
> {
> }
> protected void setLog(LogService log)
> {
> this.log = log;
> }
> protected void unsetLog(LogService log)
> {
> this.log = null;
> }
> protected void setShell(ShellService shell)
> {
> this.shell = shell;
> }
> protected void unsetShell(ShellService shell)
> {
> this.shell = null;
> }
> This is the dot.bnd file, which uses the BND tool (as an ANT task), and
> creates the manifest and OSGI-INF metadata thereof:
> Bundle-SymbolicName: org.craig.shell.play01
> Bundle-Name: org.craig.shell.play01 - shell play01
> Bundle-Description: shell play01
> Bundle-Version: 1.0.0
> Export-Package: org.craig.shell
> Import-Package:
> org.osgi.framework,org.osgi.service.component,org.apache.felix.shell,org.osgi.service.log
> Service-Component=org.craig.shell.Play01; \
> log=org.osgi.service.log.LogService; \
> shell=org.apache.felix.shell.ShellService;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
