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