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]
>
>
