Well, form looking at the code I can say that shell.remote might have an issue in regard to ShellService tracking. It is possible that it might not pick your service. Please fill a JIRA issue against shell.remote.
I did test the services command and it seems to be working just fine for me. I would need to see your code to figure out what is going on. Again, please attach it to a JIRA or post it inline. regards, Karl On Tue, Mar 31, 2009 at 10:16 PM, Karl Pauls <[email protected]> wrote: > The mailing list doesn't allow attachments. Please create a JIRA issue > and attach the files there. > > regards, > > Karl > > On Tue, Mar 31, 2009 at 10:06 PM, Jacques-Olivier Goussard > <[email protected]> wrote: >> Hi >> I reproduces the pb with a very simplistic code. See attached JogShell.java >> and manifest. My manifest doesn't >> export anything and simply import the felix shell stuff. >> I start felix with: >> felix.auto.start.1= \ >> file:repository/org.apache.felix.shell-1.0.2.jar \ >> file:repository/com.jog.felix.1.0.0.jar \ >> file:repository/org.apache.felix.shell.tui-1.0.2.jar \ >> file:repository/org.apache.felix.shell.remote-1.0.2.jar >> >> I get: >> Welcome to Felix. >> ================= >> DEBUG: WIRE: 1.0 -> org.ungoverned.osgi.service.shell -> 1.0 >> DEBUG: WIRE: 1.0 -> org.osgi.service.startlevel -> 0 >> DEBUG: WIRE: 1.0 -> org.apache.felix.shell -> 1.0 >> DEBUG: WIRE: 1.0 -> org.osgi.framework -> 0 >> DEBUG: WIRE: 1.0 -> org.osgi.service.packageadmin -> 0 >> DEBUG: WIRE: 2.0 -> org.apache.felix.shell -> 1.0 >> DEBUG: WIRE: 2.0 -> org.osgi.framework -> 0 >> DEBUG: WIRE: 3.0 -> org.apache.felix.shell -> 1.0 >> DEBUG: WIRE: 3.0 -> org.osgi.framework -> 0 >> DEBUG: WIRE: 4.0 -> org.apache.felix.shell -> 1.0 >> DEBUG: WIRE: 4.0 -> org.osgi.framework -> 0 >> -> switch >> Felix shell ?true >> -> ps >> START LEVEL 1 >> ID State Level Name >> [ 0] [Active ] [ 0] System Bundle (1.4.0) >> [ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.2) >> [ 2] [Active ] [ 1] Jog Shell (1.0.0) >> [ 3] [Active ] [ 1] Apache Felix Shell TUI (1.0.2) >> [ 4] [Active ] [ 1] Apache Felix Remote Shell (1.0.2) >> -> services 2 >> >> Jog Shell (2) provides: >> ----------------------- >> -> >> >> So this states no services have been registered, though obviously shell TUI >> finds my ShellService instance as the >> 'switch' command shows. >> -> services -u 3 >> >> Apache Felix Shell TUI (3) uses: >> -------------------------------- >> -> >> >> So shell TUI doesn't seem to even use the service. >> >> Looks like a bug in the 'services' command no ? >> /jog >> >> On Tue, Mar 31, 2009 at 9:51 AM, Jacques-Olivier Goussard >> <[email protected]> wrote: >>> >>> Will do. I'll try to make a buindle that does only contain that code. >>> Do you have an explanation though on why the register in two steps would >>> lead to different results >>> than register in one step ? >>> /jog >>> >>> On Tue, Mar 31, 2009 at 9:34 AM, Karl Pauls <[email protected]> wrote: >>>> >>>> Make sure your are importing what you are exporting. The framework >>>> will filter services based on visibility of the classes. It sounds >>>> like your bundle gets wired to a different version of the packages >>>> (maybe because it is embedding its own version and not importing them >>>> or its only exporting). Maybe post your manifest files so that we can >>>> see whats going on (additionally, you could set the framework log >>>> level to debug to see the wiring information) ... >>>> >>>> regards, >>>> >>>> Karl >>>> >>>> On Tue, Mar 31, 2009 at 3:27 PM, Jacques-Olivier Goussard >>>> <[email protected]> wrote: >>>> > Hi >>>> > I'm seeing a strange behavior on felix 1.4 for >>>> > BundleContext.registerService(String[], Object,Properties). >>>> > I'm trying to install my own ShellService with this kind of code: >>>> > // Grab the default shell >>>> > mFelixShell = >>>> > mContext.getServiceReference(ShellService.class.getName()); >>>> > // Register ourself as the highest ranking service, so that we >>>> > bypass Felix shell. >>>> > Properties props = new Properties(); >>>> > props.put(Constants.SERVICE_RANKING, Integer.MAX_VALUE); >>>> > // Register as both a Command and a ShellService so that the >>>> > Felix >>>> > shell gets a command to switch to this one >>>> > mShellReg = mContext.registerService(new String[] { >>>> > ShellService.class.getName(),Command.class.getName() }, this, props); >>>> > And my autostart is >>>> > >>>> > felix.auto.start.1= \ >>>> > file:repository/org.apache.felix.shell-1.0.2.jar \ >>>> > file:repository/myownshell.jar \ >>>> > file:repository/org.apache.felix.shell.tui-1.0.2.jar \ >>>> > file:repository/org.apache.felix.shell.remote-1.0.2.jar >>>> > >>>> > so that TUI and remote get my shell service. >>>> > >>>> > If I do this I see that: >>>> > - 'services' on my install bundle does NOT list the Command or >>>> > ShellService >>>> > class. So my own shell doesn't seem to >>>> > be listed as exported. >>>> > - The Shell TUI module properly gets my own shell implementation >>>> > (though >>>> > it's not listed as exported !) >>>> > - The remote shell TUI doesn't get it - looking at the code, it's using >>>> > a >>>> > listener that seem to assume only one shell is ever registered. >>>> > The 'services -u' command on the remote shell shows that only the felix >>>> > shell service is used. >>>> > >>>> > Now, even stranger, if I register my services in two steps, using: >>>> > mShellReg = mContext.registerService(new String[] { >>>> > ShellService.class.getName()}, this, props); >>>> > mShellReg = mContext.registerService(new String[] { >>>> > Command.class.getName()}, this, props); >>>> > >>>> > Then both ShellTUI and Remote Shell now get my shell service. The >>>> > 'services' >>>> > command works for the ShellService - the >>>> > Command service is still not listed as exported by my own bundle nor >>>> > used by >>>> > the felix shell bundle - but the command is >>>> > there ! I.e. it does work, so the shell bundle must have found it... >>>> > >>>> > Any ideas ? >>>> > Thanks >>>> > /jog >>>> > >>>> >>>> >>>> >>>> -- >>>> Karl Pauls >>>> [email protected] >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Karl Pauls > [email protected] > -- Karl Pauls [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
