You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jacques-Olivier Goussard <jo...@gmail.com> on 2009/04/01 02:07:01 UTC
Re: BundleContext.registerService
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 <ka...@gmail.com> 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 <ka...@gmail.com> 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
> > <jo...@gmail.com> 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
> >> <jo...@gmail.com> 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 <ka...@gmail.com>
> 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
> >>>> <jo...@gmail.com> 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
> >>>> karlpauls@gmail.com
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >
> >
> >
> > --
> > Karl Pauls
> > karlpauls@gmail.com
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: BundleContext.registerService
Posted by Karl Pauls <ka...@gmail.com>.
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
<jo...@gmail.com> 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 <ka...@gmail.com> 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
>> <jo...@gmail.com> 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 <ka...@gmail.com> 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 <ka...@gmail.com>
>> 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
>> >> > <jo...@gmail.com> 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
>> >> >> <jo...@gmail.com> 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 <ka...@gmail.com>
>> >> 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
>> >> >>>> <jo...@gmail.com> 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
>> >> >>>> karlpauls@gmail.com
>> >> >>>>
>> >> >>>>
>> ---------------------------------------------------------------------
>> >> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> >>>> For additional commands, e-mail: users-help@felix.apache.org
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> >> For additional commands, e-mail: users-help@felix.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Karl Pauls
>> >> > karlpauls@gmail.com
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Karl Pauls
>> >> karlpauls@gmail.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: BundleContext.registerService
Posted by "Richard S. Hall" <he...@ungoverned.org>.
I think it is the same issue, we are filtering all "Command" services to
avoid cluttering output. Since your service implements both ShellService
and Command, it always gets filtered. If you do "services -u -a 3" it
should work:
-> services -u -a 3
Apache Felix Shell TUI (3) uses:
--------------------------------
objectClass = org.apache.felix.shell.ShellService,
org.apache.felix.shell.Command
service.id = 24
service.ranking = 2147483647
-> richard
On 4/3/09 2:46 PM, Jacques-Olivier Goussard wrote:
> This means your Shell TUI is actually seeing the felix shell, not mine. Are
> you sure you have
> [ 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)
> in this order ?
> /jog
>
> 2009/4/2 Richard S. Hall<he...@ungoverned.org>
>
>
>> On 4/1/09 8:59 AM, Jacques-Olivier Goussard wrote:
>>
>>
>>> but why can't I see my shell being used by shell TUI ?
>>> -> services -u 3
>>>
>>> Apache Felix Shell TUI (3) uses:
>>> --------------------------------
>>>
>>>
>>>
>>>
>> Strange. For me, I see:
>>
>> Apache Felix Shell TUI (2) uses:
>> --------------------------------
>> objectClass = org.apache.felix.shell.ShellService,
>> org.ungoverned.osgi.service.shell.ShellService
>> service.id = 3
>>
>>
>> -> richard
>>
>>
>>
>>
>
>
Re: BundleContext.registerService
Posted by Jacques-Olivier Goussard <jo...@gmail.com>.
This means your Shell TUI is actually seeing the felix shell, not mine. Are
you sure you have
[ 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)
in this order ?
/jog
2009/4/2 Richard S. Hall <he...@ungoverned.org>
> On 4/1/09 8:59 AM, Jacques-Olivier Goussard wrote:
>
>> but why can't I see my shell being used by shell TUI ?
>> -> services -u 3
>>
>> Apache Felix Shell TUI (3) uses:
>> --------------------------------
>>
>>
>>
>
> Strange. For me, I see:
>
> Apache Felix Shell TUI (2) uses:
> --------------------------------
> objectClass = org.apache.felix.shell.ShellService,
> org.ungoverned.osgi.service.shell.ShellService
> service.id = 3
>
>
> -> richard
>
>
>
Re: BundleContext.registerService
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/1/09 8:59 AM, Jacques-Olivier Goussard wrote:
> but why can't I see my shell being used by shell TUI ?
> -> services -u 3
>
> Apache Felix Shell TUI (3) uses:
> --------------------------------
>
>
Strange. For me, I see:
Apache Felix Shell TUI (2) uses:
--------------------------------
objectClass = org.apache.felix.shell.ShellService,
org.ungoverned.osgi.service.shell.ShellService
service.id = 3
-> richard
> 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<ka...@gmail.com> 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
>> <jo...@gmail.com> 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<ka...@gmail.com> 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<ka...@gmail.com>
>>>>
>> 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
>>>>> <jo...@gmail.com> 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
>>>>>> <jo...@gmail.com> 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<ka...@gmail.com>
>>>>>>>
>>>> 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
>>>>>>>> <jo...@gmail.com> 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
>>>>>>>> karlpauls@gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
Re: BundleContext.registerService
Posted by Jacques-Olivier Goussard <jo...@gmail.com>.
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 <ka...@gmail.com> 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
> <jo...@gmail.com> 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 <ka...@gmail.com> 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 <ka...@gmail.com>
> 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
> >> > <jo...@gmail.com> 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
> >> >> <jo...@gmail.com> 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 <ka...@gmail.com>
> >> 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
> >> >>>> <jo...@gmail.com> 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
> >> >>>> karlpauls@gmail.com
> >> >>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> >> For additional commands, e-mail: users-help@felix.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Karl Pauls
> >> > karlpauls@gmail.com
> >> >
> >>
> >>
> >>
> >> --
> >> Karl Pauls
> >> karlpauls@gmail.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: BundleContext.registerService
Posted by Karl Pauls <ka...@gmail.com>.
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
<jo...@gmail.com> 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 <ka...@gmail.com> 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 <ka...@gmail.com> 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
>> > <jo...@gmail.com> 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
>> >> <jo...@gmail.com> 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 <ka...@gmail.com>
>> 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
>> >>>> <jo...@gmail.com> 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
>> >>>> karlpauls@gmail.com
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Karl Pauls
>> > karlpauls@gmail.com
>> >
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org