You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Craig Phillips (JIRA)" <ji...@apache.org> on 2008/07/02 15:59:45 UTC
[jira] Created: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
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
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
Priority: Minor
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.
[jira] Reopened: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall reopened FELIX-619:
-----------------------------------
> 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.
[jira] Commented: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Patrick Forhan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711189#action_12711189 ]
Patrick Forhan commented on FELIX-619:
--------------------------------------
While the fix works when running under Eclipse (another way to make things seem to hang), my text does not get echoed to the console window when running this from the command line.
> 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.
[jira] Updated: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-619:
----------------------------------
Component/s: (was: Shell)
shell.tui
> 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
> Priority: Minor
>
> 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.
[jira] Commented: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855992#action_12855992 ]
Richard S. Hall commented on FELIX-619:
---------------------------------------
For future reference, this is related to this JRE bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809647
The related Equinox bug is:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=40066
> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Patrick Forhan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711201#action_12711201 ]
Patrick Forhan commented on FELIX-619:
--------------------------------------
I need to amend this a bit... for a simple 10-bundle set-up, I see the problem. For a more complex application (nearly 100 bundles) I do not see the issue.
> 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.
[jira] Commented: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711210#action_12711210 ]
Richard S. Hall commented on FELIX-619:
---------------------------------------
I talked to Tom Watson about how they solved this issue in Equinox and apparently there isn't a solution. They simply made this a configuration property. By default, they do not use the "available()" workaround, but when run within Eclipse they do. So, unless we can find another solution, I think we will have to follow a similar route and make this a configuration property for Shell TUI.
> 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.
[jira] Resolved: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ 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
Fix Version/s: shell.tui-1.2.1
Assignee: Richard S. Hall
Committed a patch to try to work around this issue. Basically, we try to determine if there are bytes available before reading from stdin. The current approach might not eliminate the issue completely, since it uses readLine() if there is any input available at all. It might still be possible for the deadlock situation to occur if there isn't a complete line to read. It might be better to implement or our own readLine() that uses available() to only read the available number of bytes until it gets a line feed. However, this is just a hunch.
I have deployed a snapshot.
> 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.
[jira] Commented: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620855#action_12620855 ]
Felix Meschberger commented on FELIX-619:
-----------------------------------------
This is interesting.
* Have you tried this with the latest release of the felix scr bundle ?
* This only happens on the first startup ?
* Or does it happen on each startup ?
* Does it also happen if you install the bundles "manually", e.g. through the shell ?
> 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
> 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
> Priority: Minor
>
> 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.
[jira] Commented: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711196#action_12711196 ]
Richard S. Hall commented on FELIX-619:
---------------------------------------
Thanks for the feedback. Now I remember something about this from the last time we tried to find a fix for this issue. We will look into it.
> 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.
[jira] Commented: (FELIX-619) Shell.TUI causes "new
java.io.ServerSocket()" to hang
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709917#action_12709917 ]
Richard S. Hall commented on FELIX-619:
---------------------------------------
This is related to a JDK bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809647
> 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
> Priority: Minor
>
> 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.