Again, it just filter services with a command interface. So in case of your double registration it doesn't filter. For the usage you need to still use the -a switch as well. Then it should work.
regards, Karl On Wed, Apr 1, 2009 at 2:59 PM, Jacques-Olivier Goussard <[email protected]> wrote: > Thanks for the help. > So, ok, now I can see my services beeing published with 'services -a' > -> 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 -a 2 > > Jog Shell (2) provides: > ----------------------- > objectClass = org.apache.felix.shell.ShellService, > org.apache.felix.shell.Comman > d > service.id = 21 > service.ranking = 2147483647 > > but why can't I see my shell being used by shell TUI ? > -> services -u 3 > > Apache Felix Shell TUI (3) uses: > -------------------------------- > > also, why do I have a different behavior when using a double registration > (i.e. when I register my Command and > my ShellSevrice implementation in two registerService calls) ? > If I use the double registration, here's the output: > 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 -a 2 > > Jog Shell (2) provides: > ----------------------- > objectClass = org.apache.felix.shell.ShellService > service.id = 21 > service.ranking = 2147483647 > ---- > objectClass = org.apache.felix.shell.Command > service.id = 22 > service.ranking = 2147483647 > -> services -u 3 > > Apache Felix Shell TUI (3) uses: > -------------------------------- > objectClass = org.apache.felix.shell.ShellService > service.id = 21 > service.ranking = 2147483647 > > /jog > > > On Tue, Mar 31, 2009 at 8:39 PM, Karl Pauls <[email protected]> wrote: > >> Don't bother. You need to use the -a switch to see your services as in: >> >> -> services -a >> >> See my comment on the jira issue for more. Still, the shell.remote has a >> bug. >> >> regards, >> >> Karl >> >> On Wed, Apr 1, 2009 at 2:07 AM, Jacques-Olivier Goussard >> <[email protected]> wrote: >> > Created JIRA issue Felix-1018 with the files. >> > The remote shell has definitely a problem regarding multiple >> ShellServices >> > running (basically it will grab the latest one published, >> > as far as I understood the code), but this doesn't explain the 'services' >> > output I got. Could be my environment though, I'll download >> > a fresh copy of felix tomorrow and test. >> > >> > /jog >> > >> > On Tue, Mar 31, 2009 at 4:38 PM, Karl Pauls <[email protected]> wrote: >> > >> >> 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] >> >> >> >> >> > >> >> >> >> -- >> Karl Pauls >> [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]
