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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
