Menu
▾
▴
oscar-osgi-devel — Discussion of Oscar development issues
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(23) |
Nov
(5) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(28) |
Feb
(35) |
Mar
(25) |
Apr
(2) |
May
(8) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(32) |
Dec
|
| 2003 |
Jan
(4) |
Feb
|
Mar
|
Apr
(6) |
May
(5) |
Jun
(4) |
Jul
|
Aug
|
Sep
(2) |
Oct
(10) |
Nov
(4) |
Dec
(6) |
| 2004 |
Jan
(8) |
Feb
(21) |
Mar
(15) |
Apr
(17) |
May
(89) |
Jun
(5) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michel D'H. <mic...@tr...> - 2004-05-05 11:54:57
|
> This way, when need it can obtain a log service using the bundle > context of the offending bundle. This is an interesting security issue: A malicious service using a service factory can collect the contexts of other bundles and do (bad) actions using other bundles credentials (if they are better than its own). Sadly, I have no more time for "OSGi break" for today so I can't dig in the standard. But this sounds interesting and I will think about it tomorrow... ;-) Michel |
|
From: Richard S. H. <he...@un...> - 2004-05-05 11:35:20
|
Nektarios K. Papadopoulos wrote: > I think that the point made by Michel is exectly where Service > Factories can be handy. In the getService method of a Service Factory > the Bundle object of the caller is also passed. A reference can be > forwarded to the wrapping object. This way, when need it can obtain a > log service using the bundle context of the offending bundle. In that regard, yes, that is handy, but it puts the burden on the service provider to deal with faulty service users. I am going to be experimenting with something that could potentially help us with this issue (although I intended to use it for something else), so I will get back with you both on this topic. -> richard |
|
From: Nektarios K. P. <npa...@in...> - 2004-05-05 11:24:51
|
Michel, Richard Sorry for replying to both at the same time... Michel D'Hooge wrote: > So my concern is that the wrapper is normally in the same bundle and it > should also be stopped (at the OSGi level). Only remain "zombie" > instances pointed to by badly implemented bundles. So the bundle context > of the wrapper is no longer available and it will be really difficult to > obtain a log service. > Richard S. Hall wrote: > From my perspective, this doesn't seem to be a good use for service > factories. Service factories are necessary when you want to keep track > of per bundle services, such as when there are resources associated with > each bundle using the service. I don't see how service factories are > particularly wellsuited for dealing with stale references...really only > wrapping/indirection of the service object can do this and factories do > not impose wrapping/indirection of the service object. > I think that the point made by Michel is exectly where Service Factories can be handy. In the getService method of a Service Factory the Bundle object of the caller is also passed. A reference can be forwarded to the wrapping object. This way, when need it can obtain a log service using the bundle context of the offending bundle. nek |
|
From: Michel D'H. <mic...@tr...> - 2004-05-05 11:04:04
|
Nektarios K. Papadopoulos wrote: > If I understand correctly, the user of the service still holds a > reference to the wrapper object, and attempts to call a method. The > wrapper object is in position to log the error (assuming tha a log > service is available ;-) i.e. we are not talking for the log service > being stopped/uninstalled). Exactly. In fact the whole problem is between what the OSGi framework "sees" of a bundle (i.e. in our case it is stopped, and the instances of implemented services should be ready for garbage collect) and the java "reality". So my concern is that the wrapper is normally in the same bundle and it should also be stopped (at the OSGi level). Only remain "zombie" instances pointed to by badly implemented bundles. So the bundle context of the wrapper is no longer available and it will be really difficult to obtain a log service. To prevent all this, we would need a way to certify bundles... Michel BTW: A question for SF geeks: is it possible to configure the mailing list to add a reply-to field to reply to the list instead of the sender? |
|
From: Richard S. H. <he...@un...> - 2004-05-05 10:48:13
|
Nektarios K. Papadopoulos wrote: > OK I didn't mean Service Factories are "required". > > At bottom of page 72 in release 3: > > Service developers can minimize the consequences (but not completely > prevent) of stale references by using the following mechanisms: > - Implement service objects using the S e r v i c e F a c t o r y > interface... > ... ... > - Use indirection in the service object implementations. ... > ... ... From my perspective, this doesn't seem to be a good use for service factories. Service factories are necessary when you want to keep track of per bundle services, such as when there are resources associated with each bundle using the service. I don't see how service factories are particularly wellsuited for dealing with stale references...really only wrapping/indirection of the service object can do this and factories do not impose wrapping/indirection of the service object. Regardless, we are in agreement and who am I to argue with the spec? :-) -> richard |
|
From: Richard S. H. <he...@un...> - 2004-05-05 10:43:12
|
Michel D'Hooge wrote: > Yes, this is why I ask. Because as I already quoted, at top of page 73 > in release 3, you can read: > "The behavior of a service that becomes unregistered is undefined. > Such services may continue to work properly or throw an exception at > their discretion. *This type of error should be logged*." > > But only a print to console would be possible, I fear... Okay, I understand now. I don't think it is necessary to log this, but you could as Nek suggests if it is not the logging service itself. These issues are tricky, since they really deal with faulty bundles. -> richard |
|
From: Nektarios K. P. <npa...@in...> - 2004-05-05 09:30:05
|
Michel D'Hooge wrote: > Richard S. Hall wrote: > >> That doesn't require Service Factories, you just need to register a >> wrapper for your service, instead of directly registering the service >> object. You wrapper implements the same interfaces and has a reference >> to the service object. When you unregister the service, just null the >> reference to the service object in the wrapper and no one will be able >> to access the service any longer. The spec mentions this approach. > > > Yes, I was too busy and lazy yesterday to open the OSGi standard book > (in PDF, I didn't print it ;-) > > At top of page 73 in release 3, you can read: > "The behavior of a service that becomes unregistered is undefined. Such > services may continue to work properly or throw an exception at their > discretion. This type of error should be logged." > OK I didn't mean Service Factories are "required". At bottom of page 72 in release 3: Service developers can minimize the consequences (but not completely prevent) of stale references by using the following mechanisms: - Implement service objects using the S e r v i c e F a c t o r y interface... ... ... - Use indirection in the service object implementations. ... ... ... nek |
|
From: Nektarios K. P. <npa...@in...> - 2004-05-05 09:25:36
|
Michel D'Hooge wrote: > Richard S. Hall wrote: > >> I am not sure I understand. If you are stopped/uninstalled then you >> can't log anything. > > > Yes, this is why I ask. Because as I already quoted, at top of page 73 > in release 3, you can read: > "The behavior of a service that becomes unregistered is undefined. Such > services may continue to work properly or throw an exception at their > discretion. *This type of error should be logged*." > > But only a print to console would be possible, I fear... > > Michel If I understand correctly, the user of the service still holds a reference to the wrapper object, and attempts to call a method. The wrapper object is in position to log the error (assuming tha a log service is available ;-) i.e. we are not talking for the log service being stopped/uninstalled). nek |
|
From: Michel D'H. <mic...@tr...> - 2004-05-05 08:58:34
|
Richard S. Hall wrote: > I am not sure I understand. If you are stopped/uninstalled then you > can't log anything. Yes, this is why I ask. Because as I already quoted, at top of page 73 in release 3, you can read: "The behavior of a service that becomes unregistered is undefined. Such services may continue to work properly or throw an exception at their discretion. *This type of error should be logged*." But only a print to console would be possible, I fear... Michel |
|
From: Richard S. H. <he...@un...> - 2004-05-05 08:33:25
|
I was informed that Knopflerfish has an almost complete Jini service implementation and also some work on the UPnP stuff too...so those that are interested should check it out and make sure they work under Oscar. -> richard |
|
From: Richard S. H. <he...@un...> - 2004-05-05 08:11:43
|
Michel D'Hooge wrote: > Finally, I have a last question: how to log this type of error when > you are stopped/uninstalled? I am not sure I understand. If you are stopped/uninstalled then you can't log anything. -> richard |
|
From: Richard S. H. <he...@un...> - 2004-05-05 08:03:09
|
jacques lemordant wrote: > yes. it's in a recommanded section but with a version number 1.0 > (strange number for something not official) Yeah, it is confusing. That section of the spec says that it is included for feedback and is likely to change. > With CDC smartphones and mobile gateways arriving this year on the > market, there will be a new interest in Jini-OSGI I hope so, it would be nice to see Jini do something. > We will try to understand the spec and evaluate the amount of work Great. -> richard |
|
From: jacques l. <jac...@in...> - 2004-05-05 07:56:51
|
On May 4, 2004, at 9:22 PM, Richard S. Hall wrote: > Oscar is an OSGi framework implementation, not an implementation of > the entire OSGi service platform (i.e., framework + services). In the > next release of Oscar, this will become more clear, because all > bundles except an example bundle will be distributed separately. > > Having said that, I believe the Jini stuff is part of the OSGi > "recommendations" and not completely official yet. yes. it's in a recommanded section but with a version number 1.0 (strange number for something not official) > These would be great projects for people to contribute, especially > after we set up our bundle repository...coming soon... With CDC smartphones and mobile gateways arriving this year on the market, there will be a new interest in Jini-OSGI We will try to understand the spec and evaluate the amount of work thanks jacques |
|
From: Michel D'H. <mic...@tr...> - 2004-05-05 07:42:52
|
Richard S. Hall wrote: > That doesn't require Service Factories, you just need to register a > wrapper for your service, instead of directly registering the service > object. You wrapper implements the same interfaces and has a reference > to the service object. When you unregister the service, just null the > reference to the service object in the wrapper and no one will be able > to access the service any longer. The spec mentions this approach. Yes, I was too busy and lazy yesterday to open the OSGi standard book (in PDF, I didn't print it ;-) At top of page 73 in release 3, you can read: "The behavior of a service that becomes unregistered is undefined. Such services may continue to work properly or throw an exception at their discretion. This type of error should be logged." According to me, a "good" implementation must do its best to remove itself completely from memory when it is unregistered. This sounds mandatory if you want your service to be deployable in thousands of gateways and not mess everything in less than a week. So I vote for the exception :-) If the wrapper is really stupid, it will simply throw a Null Pointer Ex. But in any case, we need a RunTime Ex. Illegal State Ex would be nice (since it is already mentioned by OSGi), or maybe also Unsupported Operation Ex... Finally, I have a last question: how to log this type of error when you are stopped/uninstalled? Michel |
|
From: Richard S. H. <he...@un...> - 2004-05-04 19:22:08
|
Oscar is an OSGi framework implementation, not an implementation of the entire OSGi service platform (i.e., framework + services). In the next release of Oscar, this will become more clear, because all bundles except an example bundle will be distributed separately. Having said that, I believe the Jini stuff is part of the OSGi "recommendations" and not completely official yet. I am not aware of anyone working on it, although it seems like people occasionally ask about Jini (and UPnP). These would be great projects for people to contribute, especially after we set up our bundle repository...coming soon... -> richard jacques lemordant wrote: > hello, > seems that jini is back with Jini clients on j2me. > with respect to that comeback, I have two questions: > 1. Seems that the JiniDriver is not implemented in the last oscar > distribution. > has anybody implemented it or try to implement it or has any thoughts on > how to implemented it ? > > 2. This driver is implemented by osgi-prosyst: > www.*prosyst*.com/Datasheets/mBS_5.2/mBS_5.2_Jini.pdf > has anybody try it ? > > thanks > jacques |
|
From: Richard S. H. <he...@un...> - 2004-05-04 19:06:52
|
Nektarios K. Papadopoulos wrote: > I think that the solution, in the case of stopped services, is not > listening to framework events. I think that services should be > implemented as Service Factories. The Service objects returned to > bundles should be aware of the state of the Service (started or > stopped) and should throw some exception when someone tries to use the > service after it is stopped. That doesn't require Service Factories, you just need to register a wrapper for your service, instead of directly registering the service object. You wrapper implements the same interfaces and has a reference to the service object. When you unregister the service, just null the reference to the service object in the wrapper and no one will be able to access the service any longer. The spec mentions this approach. -> richard |
|
From: Richard S. H. <he...@un...> - 2004-05-04 19:03:43
|
Michel D'Hooge wrote: > The line > this.stopped = false; > should read > this.stopped = true; I fixed this. > BTW, given what is left of the add function modified by nek, I think > we can remove everything... And did delete the whole method... > Question to Richard: Will you "commit" these changes into Oscar, or do > you need some kind of help? Yes, these changes will be included in the final 1.0 release when it happens... Thanks, to both of you. -> richard |
|
From: Richard S. H. <he...@un...> - 2004-05-04 19:01:26
|
I have incorporated these changes.
-> richard
Nektarios K. Papadopoulos wrote:
> The specification states:
>
> "A LogReader Service implementation must not filter entries to
> the LogListener interface as it is allowed to do for its log. A
> LogListener object should see all LogEntry objects that are created."
>
> rel-2 sec. 6.4 p.120
> rel-3 sec. 9.4 p.172
>
> Current implementation is filtering both log and LogListener.
> The attached patch corrects the issue.
>
> cheers
> nek
>
>
>
>
>------------------------------------------------------------------------
>
>diff -u origsrc/src/com/softsell/open/osgi/log/LogList.java iansrc/src/com/softsell/open/osgi/log/LogList.java
>--- origsrc/src/com/softsell/open/osgi/log/LogList.java 2004-04-29 17:37:35.000000000 +0300
>+++ iansrc/src/com/softsell/open/osgi/log/LogList.java 2004-04-29 17:36:30.000000000 +0300
>@@ -115,13 +115,13 @@
> public void log(Bundle bundle, int level, String msg,
> Throwable ex, ServiceReference sr)
> {
>+ LogEntry ent = LogEntryImpl.createInstance(bundle, level, msg, ex, sr);
> // ignore if above threshold
> if (level <= this.threshold)
> {
>- LogEntry ent = LogEntryImpl.createInstance(bundle, level, msg, ex,
>- sr);
> this.add(ent);
> }
>+ this.fireLoggedEvent(ent);
> }
>
>
>@@ -133,7 +133,6 @@
> public void add(LogEntry ent)
> {
> super.add(ent);
>- this.fireLoggedEvent(ent);
> }
>
>
>
>
|
|
From: Michel D'H. <mic...@tr...> - 2004-05-04 13:48:43
|
> Nice catch. Does this now prevent your Log producer from working ? Well, now it is no longer able to distribute its log and if you restart the Log Service it is still blocked. Thus it is ok for me, since I only wanted to show that something like the service tracker is beneficial. > I think that the solution, in the case of stopped services, is not > listening to framework events. I think that services should be > implemented as Service Factories. I don't understand what you mean, the factory doesn't help for this problem. > The Service objects returned to bundles should be aware of the state > of the Service (started or stopped) and should throw some exception > when someone tries to use the service after it is stopped. This is a tough point. What shall we do when a bundle is not following the OSGi guidelines (in this case, not releasing a service that has been stopped)? From the whole system point of view, it would be better to get rid of badly coded bundle as soon as possible (and let the garbage collect free memory - maybe). From the poor bundle developper... ;-) So you suggest to add a test in the log function to send an exception when stopped is true? I vote for it. cheers -- Michel D'Hooge |
|
From: Nektarios K. P. <npa...@in...> - 2004-05-04 13:11:24
|
Michel D'Hooge wrote:
> Hello,
Hi,
>
> This is not fully related to what Nektarios K. Papadopoulos wrote, but I
> have another issue with the Log Service.
> I wanted to show in a small example that if a bundle doesn't listen to
> framework events, when a service is stopped, it has some problems. Not
> an exciting example, and even less exciting since stopping the Log
> Service didn't prevent my Log producer to work perfectly :-(
>
> The bug is in com.softsell.open.osgi.log. LogList . shutdown ( ).
> The line
> this.stopped = false;
> should read
> this.stopped = true;
>
Nice catch. Does this now prevent your Log producer from working ?
I think that the solution, in the case of stopped services, is not
listening to framework events. I think that services should be
implemented as Service Factories. The Service objects returned to
bundles should be aware of the state of the Service (started or stopped)
and should throw some exception when someone tries to use the service
after it is stopped.
>
> BTW, given what is left of the add function modified by nek, I think we
> can remove everything...
>
>> @@ -133,7 +133,6 @@
>> public void add(LogEntry ent)
>> {
>> super.add(ent);
>> - this.fireLoggedEvent(ent);
>> }
>>
>>
Yes. I missed that.
>
> Question to Richard: Will you "commit" these changes into Oscar, or do
> you need some kind of help?
>
> Cheers
>
cheers
nek
|
|
From: Michel D'H. <mic...@tr...> - 2004-05-04 11:49:09
|
Hello,
This is not fully related to what Nektarios K. Papadopoulos wrote, but I
have another issue with the Log Service.
I wanted to show in a small example that if a bundle doesn't listen to
framework events, when a service is stopped, it has some problems. Not
an exciting example, and even less exciting since stopping the Log
Service didn't prevent my Log producer to work perfectly :-(
The bug is in com.softsell.open.osgi.log. LogList . shutdown ( ).
The line
this.stopped = false;
should read
this.stopped = true;
BTW, given what is left of the add function modified by nek, I think we
can remove everything...
>@@ -133,7 +133,6 @@
> public void add(LogEntry ent)
> {
> super.add(ent);
>- this.fireLoggedEvent(ent);
> }
>
>
Question to Richard: Will you "commit" these changes into Oscar, or do
you need some kind of help?
Cheers
--
Michel D'Hooge
|
|
From: Nektarios K. P. <npa...@in...> - 2004-04-29 15:04:30
|
The specification states: "A LogReader Service implementation must not filter entries to the LogListener interface as it is allowed to do for its log. A LogListener object should see all LogEntry objects that are created." rel-2 sec. 6.4 p.120 rel-3 sec. 9.4 p.172 Current implementation is filtering both log and LogListener. The attached patch corrects the issue. cheers nek |
|
From: jacques l. <jac...@in...> - 2004-04-29 07:16:47
|
hello, seems that jini is back with Jini clients on j2me. with respect to that comeback, I have two questions: 1. Seems that the JiniDriver is not implemented in the last oscar distribution. has anybody implemented it or try to implement it or has any thoughts on how to implemented it ? 2. This driver is implemented by osgi-prosyst: www.prosyst.com/Datasheets/mBS_5.2/mBS_5.2_Jini.pdf has anybody try it ? thanks jacques |
|
From: Richard S. H. <he...@un...> - 2004-04-25 20:00:45
|
I will be gone for the next week, so I am releasing a new beta (1.0.0beta4) that has some bug fixes and minor new features. Also, not that anyone will truly care (especially since it still looks the same), I have majorly improved the design of Oscar's installer. As a result, it is now possible to specify if you want to use Oscar with a text-based or GUI-based shell. I have also added (with the help of Stephane Frenot) a new OBR panel to the GUI shell. The OBR service interface has slightly changed in this release, so you need to use the included OBR bundle. These are only initial changes, OBR will likely see more changes. Finally, I have also made available from the installer (but they can be downloaded too) the bundle source and api documentation...you can install it all, like normal, by just downloading the main Oscar beta release JAR file and doing "java -jar ..." -> richard p.s. Since it is now official, I can tell everyone that I have recently become an invited individual member of the OSGi Alliance. I attend my first OSGi meeting this week, which is why I will be gone. So take heart in the fact that the work in our community has been noticed! :-) |
|
From: Richard S. H. <he...@un...> - 2004-04-23 15:58:57
|
Nektarios K. Papadopoulos wrote: > I personally prefer the DTD version, so I also suggest something > similar about the import/export elements (see the patch); i.e. single > import, dynamicimport, export elements that have zero or any number of > package > child nodes. One issue with your DTD, it would allow you to specify spec versions for dynamic imports, which is not allowed. -> richard |
5 messages has been excluded from this view by a project administrator.