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: Richard S. H. <he...@un...> - 2004-05-12 13:56:54
|
Michel D'Hooge wrote: > Richard S. Hall wrote: > >>> obr -start Logger_0.1 >>> obr -start Logger >> >> > We can use another character to identify version number (i.e. ; or : > or whatever sounds nice). > >> I don't really like to encode additional information into the name, >> since we have a separate version attribute. Perhaps in the future >> when the bundle repository has multiple versions we make this a >> parameter that can be passed in or we require the bundles to have >> different names, like "Log" and "Log Devel". > > > I believe that Debian package naming policy is quite complete and well > tested. But we are not that far that we need such a naming tool... I like the idea of using the semicolon introduce the version, but as you say, it is probably not completely necessary right now and I really do want [need] to keep things simple if I am ever going to get this out the door. But do we agree then, that there should be no spaces? -> richard |
From: Michel D'H. <mic...@tr...> - 2004-05-12 13:47:21
|
Richard S. Hall wrote: >> obr -start Logger_0.1 >> obr -start Logger > We can use another character to identify version number (i.e. ; or : or whatever sounds nice). > I don't really like to encode additional information into the name, > since we have a separate version attribute. Perhaps in the future when > the bundle repository has multiple versions we make this a parameter > that can be passed in or we require the bundles to have different > names, like "Log" and "Log Devel". I believe that Debian package naming policy is quite complete and well tested. But we are not that far that we need such a naming tool... Michel |
From: Richard S. H. <he...@un...> - 2004-05-12 13:23:42
|
Stephane Frenot wrote: >I think it should be interseting to insist on some kind of version >numbering pattern mandatory for OBR... >Just to know exactly which bundles are installed... > >For instance : > obr -start Logger_0.1 > obr -start Logger > >all works, but the real name contains the version number. > > I don't really like to encode additional information into the name, since we have a separate version attribute. Perhaps in the future when the bundle repository has multiple versions we make this a parameter that can be passed in or we require the bundles to have different names, like "Log" and "Log Devel". -> richard |
From: Richard S. H. <he...@un...> - 2004-05-12 12:55:28
|
> And then, we would be able to put more than one name on a single line > obr install -start my_favorite_bundle another_nice_bundle > not_so_nice_but_needed Actually, that is one option I thought about too, although I am not sure that it is necessary. At a minimum, it opens up the possibility of a future enhancement. -> richard |
From: Michel D'H. <mic...@tr...> - 2004-05-12 12:41:51
|
Richard S. Hall wrote: > So, my thought was that I eliminate all spaces and use underscores if > necessary. And then, we would be able to put more than one name on a single line obr install -start my_favorite_bundle another_nice_bundle not_so_nice_but_needed Michel |
From: Richard S. H. <he...@un...> - 2004-05-12 12:33:37
|
Stephane Frenot wrote: >On Wed, May 12, 2004 at 02:02:30PM +0200, Richard S. Hall wrote: > > >>One thing that I forgot to mention about the changes, is that it seems >>that using bundle names with space characters is probably a bad idea, >>witness that yum, rpm, etc. generally don't use spaces in their package >>names. >> >>So, my thought was that I eliminate all spaces and use underscores if >>necessary. >> >> >What about package version in the name... > > I don't understand what you mean. I am only referring to the name of the bundle in OBR. For example, now you type "obr Service Binder", in the future I was saying you should type "obr Service_Binder" to simplify parsing. The alternative is we keep spaces, but require quoted strings. -> richard |
From: Richard S. H. <he...@un...> - 2004-05-12 12:02:29
|
One thing that I forgot to mention about the changes, is that it seems that using bundle names with space characters is probably a bad idea, witness that yum, rpm, etc. generally don't use spaces in their package names. So, my thought was that I eliminate all spaces and use underscores if necessary. -> richard |
From: Richard S. H. <he...@un...> - 2004-05-12 11:13:51
|
Michel D'Hooge wrote: > I always start my bundles together with the installation, so I'd > appreciate an "obr start" command. Personally, I am not a fan of "start" at all, because it ends up starting all library bundles, which is unnecessary, but other than that, I suppose it could be separated. > And being lazy, I'd like 1-letter shortcuts for commands... Well, eliminating "-start" only leaves "-nodep", actually I guess that should be "-nodeps", which I figure is reasonably standard from RPM. It probably doesn't make the need for 1-letter shortcuts so pressing. -> richard |
From: Michel D'H. <mic...@tr...> - 2004-05-12 10:51:25
|
Richard S. Hall wrote: > [...]This covers all of the current functionality plus adds update and > source retrieval functionality. Comments, are welcome, just keep in > mind that I am not looking for extra functionality, just good syntax. I always start my bundles together with the installation, so I'd appreciate an "obr start" command. And being lazy, I'd like 1-letter shortcuts for commands... Besides this, it is ok for me :-) Michel |
From: Richard S. H. <he...@un...> - 2004-05-12 09:36:08
|
Okay, right now OBR is the main hold-up for the next release, so I am trying to work feverishly on it to get another beta release done before I take off for some conferences next week for ten days! I want to change the OBR command syntax to be more yum-like, since I think it provides more room to grow and is easier to remember. Here is my proposed syntax: * obr urls [space delimited list of URLs] = if no urls are specified it prints the current repository urls, otherwise sets the repository urls. * obr list [sub-string] = list all bundles if sub-string is not present, otherwise filters bundles based on sub-string of bundle name. * obr info <bundle-name> = return the meta-data associated with the bundle. * obr install [-start] [-nodep] <bundle-name> = installs (-start starts) with (-nodep without) dependencies the specified bundle. * obr update [-nodep] <bundle-name> | <bundle-id> = updates the specified bundle with (-nodep without) dependencies. * obr source [-x] <bundle-name> <local-dir> = retrieves (-x and extracts) the bundle source to the specified local directory. I am not exactly sure if the update with/without dependencies makes 100% sense, but I will see how it falls out during the implementation. This covers all of the current functionality plus adds update and source retrieval functionality. Comments, are welcome, just keep in mind that I am not looking for extra functionality, just good syntax. -> richard |
From: Richard S. H. <he...@un...> - 2004-05-12 08:26:27
|
Manuel Santillan Palencia wrote: >1. In classes OSGiSelectionPolicy, Oscar and ModuleClassLoader, there is >a call to the constructor of java.security.CodeSource. However, the >second argument(the Certificate[]) is null. The problem with 1.5 is that >it defines a new constructor of two params. Therefore the constructor >call is ambiguous. I have fixed it by just casting the null to a >Certificate[] before passing the argument. > > Okay, I will add this to the code. This will probably change in the future any way, because after 1.0.0 is released, I will probably re-work the Oscar security approach to use ProtectionDomains when I try to implement the Permission Admin service...but we have to get 1.0.0 done first! >2. This is not an OSCAR issue, but an Eclipse one. For those who do not >work with eclipse, don't worry :) The thing is that there is a problem >with eclipse's compiler (not adapted to the 1.5 jvm yet) which causes it >to think that the java.lang.StringBuffer.append(char c) should throw an >IOException, which is not true. This affects to two OSGi spec's classes >(ServicePermission and PackagePermission). It also affects to some oscar >classes: I remember Parser class in ldap package to be affected. I do >not know if some other class is affected, but I suppose that some >bundles might have the same problem. > Well, we will have to wait until Eclipse offers better support for JDK 1.5... -> richard |
From: Andreas W. <and...@gm...> - 2004-05-11 11:56:24
|
Hi Manuel, there is a Eclipse-JDT Preview for JDK 1.5. See http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core-home/r3.0/main.html#updates - Andreas > Hi all! > > I am beginning to work with the j2sdk 1.5 and I 've found only two small > issues: > > 1. In classes OSGiSelectionPolicy, Oscar and ModuleClassLoader, there is > a call to the constructor of java.security.CodeSource. However, the > second argument(the Certificate[]) is null. The problem with 1.5 is that > it defines a new constructor of two params. Therefore the constructor > call is ambiguous. I have fixed it by just casting the null to a > Certificate[] before passing the argument. > > 2. This is not an OSCAR issue, but an Eclipse one. For those who do not > work with eclipse, don't worry :) The thing is that there is a problem > with eclipse's compiler (not adapted to the 1.5 jvm yet) which causes it > to think that the java.lang.StringBuffer.append(char c) should throw an > IOException, which is not true. This affects to two OSGi spec's classes > (ServicePermission and PackagePermission). It also affects to some oscar > classes: I remem ber Parser class in ldap package to be affected. I do > not know if some other class is affected, but I suppose that some > bundles might have the same problem. > > > > Regards, > > Manuel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver > higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > oscar-osgi-devel mailing list > osc...@li... > https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel > |
From: Manuel S. P. <san...@di...> - 2004-05-11 11:47:21
|
Hi all! I am beginning to work with the j2sdk 1.5 and I 've found only two small issues: 1. In classes OSGiSelectionPolicy, Oscar and ModuleClassLoader, there is a call to the constructor of java.security.CodeSource. However, the second argument(the Certificate[]) is null. The problem with 1.5 is that it defines a new constructor of two params. Therefore the constructor call is ambiguous. I have fixed it by just casting the null to a Certificate[] before passing the argument. 2. This is not an OSCAR issue, but an Eclipse one. For those who do not work with eclipse, don't worry :) The thing is that there is a problem with eclipse's compiler (not adapted to the 1.5 jvm yet) which causes it to think that the java.lang.StringBuffer.append(char c) should throw an IOException, which is not true. This affects to two OSGi spec's classes (ServicePermission and PackagePermission). It also affects to some oscar classes: I remember Parser class in ldap package to be affected. I do not know if some other class is affected, but I suppose that some bundles might have the same problem. Regards, Manuel |
From: Richard S. H. <he...@un...> - 2004-05-10 11:02:31
|
I think I like the idea of using "update location", because this will better support a future where the bundle repository contains two separate branches of development (i.e., stable and developmental), thus when you check for an update, only the corresponding development branch that is already installed is checked. If you use a package name, then the different branches would have to have different package names. -> richard Robert Huitema wrote: >Just a suggestion here but Eclipse has the same potential problem with plugins >its quite feasible that more than one person will create an DbAppBundle for >instance. > >You can solve it by the use of a name which contains the full java package >name so in the above case we would have: > "nz.co.42.eclipse.DbAppBundle >and > "com.yourdomain.eclipse.DbAppBundle >Use this just as a text string, not an actual java path, for the name at >least. For prettyness and backwards compatibility you could probably shorten >this programatically when displaying or accessing bundles to the nearest >unique substring, eg "..tasman.eclipse.DbPlugin" > >This may be a solution to bundle uniqueness, especially when combined with the >version number > >Robert > >On Saturday 08 May 2004 15:13, osc...@li... >wrote: > > >>Send oscar-osgi-devel mailing list submissions to >> osc...@li... >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel >>or, via email, send a message with subject or body 'help' to >> osc...@li... >> >>You can reach the person managing the list at >> osc...@li... >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of oscar-osgi-devel digest..." >> >> >>Today's Topics: >> >> 1. Re: Another OBR issue (Richard S. Hall) >> 2. Re: Packaging Bundles (Nektarios K. Papadopoulos) >> 3. Re: Another OBR issue (Michel D'Hooge) >> 4. Re: Another OBR issue (Nektarios K. Papadopoulos) >> 5. Re: Another OBR issue (Richard S. Hall) >> 6. Re: Another OBR issue (Richard S. Hall) >> 7. Re: Packaging Bundles (Richard S. Hall) >> 8. Re: Packaging Bundles (Nektarios K. Papadopoulos) >> 9. Re: Packaging Bundles (Richard S. Hall) >> >>--__--__-- >> >>Message: 1 >>Date: Fri, 07 May 2004 11:40:55 +0200 >>From: "Richard S. Hall" <he...@un...> >>To: eri...@at... >>CC: oscar-devel <osc...@li...> >>Subject: Re: [oscar-devel] Another OBR issue >> >>Eric Swindell wrote: >> >> >>>If the motivation for bundle uniqueness is driven by the ability to >>>uniquely identify bundles for their replication from server to locale >>>repositories, the bundle name and version number could form a unique key. >>> You could add this as a separate manifest entry, but then again, it >>>could easily be constructed from Bundle-Name and Bundle-Version. >>> >>> >>I hadn't thought of this, but yes, that could be one way to get a unique >>ID. Of course, this still requires that Bundle-Name is unique too. For >>example, I might release a Wire Admin implementation and so might you. >>We can't both call our bundles "Wire Admin", otherwise we could suffer >>name clashes. I would have to call mine "Richard's Wire Admin" and you >>would have to call yours "Eric's Wire Admin" or we could use something >>less dorky. :-) >> >>If we had a separate unique ID, then both could be called Wire Admin. Of >>course, we could just ignore this issue, since we don't have many >>duplicate bundles yet. >> >> >> >>>Such keys could also be used to provide limited bundle version dependency >>>management, where one bundle could list it's dependent bundle keys for OBR >>>purposes. OSGi provides package versioning in the import/export entries, >>>but these assume backward compatibility. Chances are, you're going to >>>test your bundles against specific dependent bundles so that these >>>dependent bundle implementations are sort of 'certified' as interoperable >>>without ill consequences anyway. >>> >>> >>I don't think I want to open this can of worms just yet. >> >> >> >>>However, isn't OSGi's versioning based >>>on the 'specification version', and excludes any consideration of an >>>'implementation version' or 'service provider'? Sorry, I'm off topic here >>>:) >>> >>> >>You are precisely correct on this issue. This topic actually came up at >>the OSGi meeting last week. >> >>-> richard >> >>p.s. The OSGi meeting was really, really interesting by the way... >> >> >> >>--__--__-- >> >>Message: 2 >>Date: Fri, 07 May 2004 15:37:38 +0300 >>From: "Nektarios K. Papadopoulos" <npa...@in...> >>To: oscar-devel <osc...@li...> >>Subject: Re: [oscar-devel] Packaging Bundles >> >>Humberto Cervantes wrote: >> >> >>>In my point of view, I think the 1st solution is better since: >>> >>>- It's less discouraging for somebody who wants to begin to explore a >>>new project to just download the source, type 'ant' and see that it >>>compiles directly. Just think about your own reactions when you download >>>some tar file in Linux, type ./configure and see a bunch of errors, you >>>just go and grab the rpm ! >>> >>>- The cost of including libraries is rather negligible. In particular >>>because today we have more and more high speed internet access plus >>>gigabytes of hard drive. >>> >>> >>I am afraid that we are facing the problem of two quite different use >>scenarios that OSCAR / OSGi is trying to satisfy. What you are saying is >>true for the desktop environment of a home-user, >> >>We are talking about source-bundle and indeed the download/compile phase >>is, in most cases, going to happen on a host with high speed internet >>access and gigabytes of hard drive. But the situation for embedded >>devices is different. Both download time and storage space have to be >>considered. >> >>A feature I would like to see in those source-bundles is a build option >>like say 'ant strip' that produce multitpl bundles. The main bundle and >>one bundle for each required library. >> >>Example: >>The source bundle for application app-foo1 contains: >> -the source >> -required library lib-bar-1.jar >> that provides com.acme.bar1 var1.0 >> -required library lib-bar-2.jar >> that provides com.acme.bar2 ver1.0 >> -the build script >> >>If you type `ant`, you get a single bundle app-foo1-all.jar, which >>contains the compiled application and the embedded libraries >>lib-bar-1.jar and lib-bar-2.jar. >> >>if you type ant strip, you get three bundles: >> app-foo1.jar >> with Import-Package headers requesting >> com.acme.bar1;specification-version=1.0 >> and com.acme.bar2;specification-version=1.0 >> lib-bar1.jar >> with Export-Package header >> com.acme.bar1;specification-version=1.0 >> lib-bar2.jar >> with Export-Package header >> com.acme.bar2;specification-version=1.0 >> >> >>But this is only my point of view, and whatever would be the result of >>this discussion would be a "Recommendation" >> >> >>--- >>nek >> >> >>--__--__-- >> >>Message: 3 >>Date: Fri, 07 May 2004 14:39:43 +0200 >>From: Michel D'Hooge <mic...@tr...> >>To: oscar-devel <osc...@li...> >>Subject: Re: [oscar-devel] Another OBR issue >> >>Eric Swindell wrote: >> >> >>>If the motivation for bundle uniqueness is driven by the ability to >>>uniquely identify bundles for their replication from server to locale >>>repositories, the bundle name and version number could form a unique key. >>> >>> >>But when updating a bundle you will only have the version of the bundle >>you downloaded, not the current version of a bundle with a similar name. >>To be sure that a local bundle is an old version of an OBR one, we could >>use a hash value of some properties like name, vendor and category - >>which are unlikely to change. Note that I propose a hash but just >>concatenating could suffice; it could even be better if we want to >>compute the mathematical distance between the local bundle and "similar" >>bundles in the repository, when 10 bundles with the same name will be >>available ;-) >> >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by Sleepycat Software >Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver >higher performing products faster, at low TCO. >http://www.sleepycat.com/telcomwpreg.php?From=dnemail3 >_______________________________________________ >oscar-osgi-devel mailing list >osc...@li... >https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel > > > > |
From: Robert H. <ro...@42...> - 2004-05-08 22:03:31
|
Just a suggestion here but Eclipse has the same potential problem with pl= ugins=20 its quite feasible that more than one person will create an DbAppBundle f= or=20 instance. You can solve it by the use of a name which contains the full java packag= e=20 name so in the above case we would have: =09"nz.co.42.eclipse.DbAppBundle=20 and =09"com.yourdomain.eclipse.DbAppBundle=20 Use this just as a text string, not an actual java path, for the name at=20 least. For prettyness and backwards compatibility you could probably shor= ten=20 this programatically when displaying or accessing bundles to the nearest=20 unique substring, eg "..tasman.eclipse.DbPlugin" This may be a solution to bundle uniqueness, especially when combined wit= h the=20 version number Robert On Saturday 08 May 2004 15:13, osc...@li...urceforge= =2Enet=20 wrote: > Send oscar-osgi-devel mailing list submissions to > =09o...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > =09https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel > or, via email, send a message with subject or body 'help' to > =09o...@li... > > You can reach the person managing the list at > =09o...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of oscar-osgi-devel digest..." > > > Today's Topics: > > 1. Re: Another OBR issue (Richard S. Hall) > 2. Re: Packaging Bundles (Nektarios K. Papadopoulos) > 3. Re: Another OBR issue (Michel D'Hooge) > 4. Re: Another OBR issue (Nektarios K. Papadopoulos) > 5. Re: Another OBR issue (Richard S. Hall) > 6. Re: Another OBR issue (Richard S. Hall) > 7. Re: Packaging Bundles (Richard S. Hall) > 8. Re: Packaging Bundles (Nektarios K. Papadopoulos) > 9. Re: Packaging Bundles (Richard S. Hall) > > --__--__-- > > Message: 1 > Date: Fri, 07 May 2004 11:40:55 +0200 > From: "Richard S. Hall" <he...@un...> > To: eri...@at... > CC: oscar-devel <osc...@li...> > Subject: Re: [oscar-devel] Another OBR issue > > Eric Swindell wrote: > >If the motivation for bundle uniqueness is driven by the ability to > > uniquely identify bundles for their replication from server to locale > > repositories, the bundle name and version number could form a unique = key. > > You could add this as a separate manifest entry, but then again, it > > could easily be constructed from Bundle-Name and Bundle-Version. > > I hadn't thought of this, but yes, that could be one way to get a uniqu= e > ID. Of course, this still requires that Bundle-Name is unique too. For > example, I might release a Wire Admin implementation and so might you. > We can't both call our bundles "Wire Admin", otherwise we could suffer > name clashes. I would have to call mine "Richard's Wire Admin" and you > would have to call yours "Eric's Wire Admin" or we could use something > less dorky. :-) > > If we had a separate unique ID, then both could be called Wire Admin. O= f > course, we could just ignore this issue, since we don't have many > duplicate bundles yet. > > >Such keys could also be used to provide limited bundle version depende= ncy > >management, where one bundle could list it's dependent bundle keys for= OBR > >purposes. OSGi provides package versioning in the import/export entri= es, > > but these assume backward compatibility. Chances are, you're going t= o > > test your bundles against specific dependent bundles so that these > > dependent bundle implementations are sort of 'certified' as interoper= able > > without ill consequences anyway. > > I don't think I want to open this can of worms just yet. > > >However, isn't OSGi's versioning based > >on the 'specification version', and excludes any consideration of an > >'implementation version' or 'service provider'? Sorry, I'm off topic = here > > :) > > You are precisely correct on this issue. This topic actually came up at > the OSGi meeting last week. > > -> richard > > p.s. The OSGi meeting was really, really interesting by the way... > > > > --__--__-- > > Message: 2 > Date: Fri, 07 May 2004 15:37:38 +0300 > From: "Nektarios K. Papadopoulos" <npa...@in...> > To: oscar-devel <osc...@li...> > Subject: Re: [oscar-devel] Packaging Bundles > > Humberto Cervantes wrote: > > In my point of view, I think the 1st solution is better since: > > > > - It's less discouraging for somebody who wants to begin to explore a > > new project to just download the source, type 'ant' and see that it > > compiles directly. Just think about your own reactions when you downl= oad > > some tar file in Linux, type ./configure and see a bunch of errors, y= ou > > just go and grab the rpm ! > > > > - The cost of including libraries is rather negligible. In particular > > because today we have more and more high speed internet access plus > > gigabytes of hard drive. > > I am afraid that we are facing the problem of two quite different use > scenarios that OSCAR / OSGi is trying to satisfy. What you are saying i= s > true for the desktop environment of a home-user, > > We are talking about source-bundle and indeed the download/compile phas= e > is, in most cases, going to happen on a host with high speed internet > access and gigabytes of hard drive. But the situation for embedded > devices is different. Both download time and storage space have to be > considered. > > A feature I would like to see in those source-bundles is a build option > like say 'ant strip' that produce multitpl bundles. The main bundle and > one bundle for each required library. > > Example: > The source bundle for application app-foo1 contains: > =09-the source > =09-required library lib-bar-1.jar > =09=09that provides com.acme.bar1 var1.0 > =09-required library lib-bar-2.jar > =09=09that provides com.acme.bar2 ver1.0 > =09-the build script > > If you type `ant`, you get a single bundle app-foo1-all.jar, which > contains the compiled application and the embedded libraries > lib-bar-1.jar and lib-bar-2.jar. > > if you type ant strip, you get three bundles: > =09app-foo1.jar > =09=09with Import-Package headers requesting > =09=09com.acme.bar1;specification-version=3D1.0 > =09=09and com.acme.bar2;specification-version=3D1.0 > =09lib-bar1.jar > =09=09with Export-Package header > =09=09com.acme.bar1;specification-version=3D1.0 > =09lib-bar2.jar > =09=09with Export-Package header > =09=09com.acme.bar2;specification-version=3D1.0 > > > But this is only my point of view, and whatever would be the result of > this discussion would be a "Recommendation" > > > --- > nek > > > --__--__-- > > Message: 3 > Date: Fri, 07 May 2004 14:39:43 +0200 > From: Michel D'Hooge <mic...@tr...> > To: oscar-devel <osc...@li...> > Subject: Re: [oscar-devel] Another OBR issue > > Eric Swindell wrote: > >If the motivation for bundle uniqueness is driven by the ability to > > uniquely identify bundles for their replication from server to locale > > repositories, the bundle name and version number could form a unique = key. > > But when updating a bundle you will only have the version of the bundle > you downloaded, not the current version of a bundle with a similar name= =2E > To be sure that a local bundle is an old version of an OBR one, we coul= d > use a hash value of some properties like name, vendor and category - > which are unlikely to change. Note that I propose a hash but just > concatenating could suffice; it could even be better if we want to > compute the mathematical distance between the local bundle and "similar= " > bundles in the repository, when 10 bundles with the same name will be > available ;-) |
From: Richard S. H. <he...@un...> - 2004-05-08 21:00:18
|
Guarav, I am not aware of any problems with startLevel... The reason why you are not getting a deadlock anymore and are getting "OutOfMemory" and "stackOverFlow" errors is because you have created an infinite loop. You cannot call "setStartLevelInternal()" from inside "setStartLevelInternal()", this creates an infinite loop. As I said to you previously. Your deadlock is resulting from the fact that none of your bundles are starting. If no bundles start, then the shelltui bundle never starts its thread to read from standard input, thus there are no unblocked threads and Kaffe thinks you have a deadlock. Again, look at your thread dump below, there is no main thread, because it exited after trying to start the bundles, like normal, but the shelltui thread wasn't created to start the new active thread. You have to find out why your bundles aren't starting. Someone else suggested that perhaps you are trying to start Oscar from a directory other than the Oscar install directory...that would cause problems unless you change the paths in system.properties. As you know from my previous message, when I tried to run Oscar on Kaffe for you, I was able to get the bundles to initially start, but I immediately got some error about a class not being found...it looked like Kaffe was missing some of the security classes or something. At any rate, I think you are looking up the wrong tree with the start level stuff. Focus on why the bundles are not starting. -> richard Gaurav Ganeriwal wrote: >Greetings, > >I was trying to debug oscar code running on kaffe. > >I found, variable startLevel is always zero (which is a not expected) as in shutdown routine startlevel is set 0 to stop bundles. > >In Oscar.java/setStartLevelInternal() routine just before > > startBundleForStartLevel(impl); //line number 724 > >i inserted > setStartLevelInternal(1); > >to set startlevel to 1. > >With this modification it is not giving me DEADLOCK error( i don't know why startlevel was always zero) > >But now it is giving me stackOverFlowError. > >I tried to increase stack size with > > java -jar -ss 64M lib/oscar.jar > >but then is gives me OutOfMemoryError. > >I tried with > > java -jar -ss 64M -ms32M -mx 256[512]M lib/oscar.jar > >but again same OutOfMemoryError. > >May be i should look forward to upgrade my system, but i just wanted to give feedback on startLevel problem. > >Any Suggestions ? > >Thanks & Regards, >Gaurav Ganeriwal > > >On Thu, 06 May 2004 Richard S. Hall wrote : > > >>>I am trying to port OSCAR on KAFFE-1.0.7 (http://wwww.kaffe.org). >>>As kaffe donot have swing package support, i decided to use SwingWT package. I have made necessary changes in the OSCAR source code. >>> >>> >>> >>Oscar does not require Swing, although some bundles may. You should be able to run Oscar unchanged; for example, I have run it on J2ME Personal Profile, which doesn't have Swing either. >> >> >> >>>I have also added various bundles required to run oscar. With this set up i am able to build oscar.jar through ant, but when i try to run oscar it gives me following error: >>> >>>Welcome to Oscar. >>>================= >>> >>>Enter profile name: my_profile >>> >>>Oscar: Error starting file:bundle/shell.jar >>>Oscar: Error starting file:bundle/shelltui.jar >>>Oscar: Error starting file:bundle/bundlerepository.jar >>>Dumping live threads: >>>`OscarStartLevel' tid 0x8419010, status SUSPENDED flags >>>blocked@0x8400fa8 (0x8419010->|) >>>`OscarPackageAdmin' tid 0x840e010, status SUSPENDED flags >>>blocked@0x8400b88 (0x840e010->|) >>>`OscarDispatchQueue' tid 0x83c9010, status SUSPENDED flags >>>blocked@0x83beac8 (0x83c9010->|) >>>`gc' tid 0x828e010, status SUSPENDED flags DONTSTOP >>>blocked@0x827ea98 (0x828e010->|) >>>`finaliser' tid 0x8285010, status SUSPENDED flags DONTSTOP >>>blocked@0x81ac3c0 (0x8285010->|) >>>Deadlock: all threads blocked on internal events >>>Aborted >>> >>> >>>What can be the reason for this error? >>> >>> >>> >>I don't know, I have never seen it before. All Oscar internal threads should be blocked (i.e., waiting), since there isn't any work for them to do. The only thread that should be doing anything is the main thread used to call the static main. Since there were errors starting all of the bundles, you will never get a shell. >> >>I would be willing to take a quick look at this, if it doesn't take too much effort to work with Kaffe...this doesn't necessarily sound like an Oscar problem, since it runs on many JVMs. >> >> >> >>>For building oscar i unjar oscar_20031127.jar and bundlesrc.jar added jar files according to build.xml. I am using default system.properties file and example.poilcy file. >>> >>> >>> >>If you are using the policy file, try to run without the security manager. >> >>-> richard >> >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Sleepycat Software >>Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver >>higher performing products faster, at low TCO. >>http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 >>_______________________________________________ >>oscar-osgi-devel mailing list >>osc...@li... >>https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel >> >> > > > |
From: Gaurav G. <gan...@re...> - 2004-05-08 18:50:29
|
=0AGreetings,=0A=0AI was trying to debug oscar code running on kaffe.=0A=0A= I found, variable startLevel is always zero (which is a not expected) as i= n shutdown routine startlevel is set 0 to stop bundles.=0A=0AIn Oscar.java/= setStartLevelInternal() routine just before =0A=0A startB= undleForStartLevel(impl); //line number 724=0A=0Ai inserted =0A = setStartLevelInternal(1); =0A=0Ato set startlevel to 1.=0A=0AWith thi= s modification it is not giving me DEADLOCK error( i don't know why startle= vel was always zero)=0A=0ABut now it is giving me stackOverFlowError.=0A=0A= I tried to increase stack size with =0A=0A java -jar -ss 64M lib/= oscar.jar=0A=0Abut then is gives me OutOfMemoryError. =0A=0AI tried with = =0A=0A java -jar -ss 64M -ms32M -mx 256[512]M lib/oscar.jar=0A=0A= but again same OutOfMemoryError.=0A=0AMay be i should look forward to upgra= de my system, but i just wanted to give feedback on startLevel problem.=0A= =0AAny Suggestions ? =0A=0AThanks & Regards,=0AGaurav Ganeriwal =0A=0A=0AOn= Thu, 06 May 2004 Richard S. Hall wrote :=0A>>I am trying to port OSCAR on = KAFFE-1.0.7 (http://wwww.kaffe.org).=0A>>As kaffe donot have swing package = support, i decided to use SwingWT package. I have made necessary changes in= the OSCAR source code.=0A>>=0A>=0A>Oscar does not require Swing, although = some bundles may. You should be able to run Oscar unchanged; for example, I= have run it on J2ME Personal Profile, which doesn't have Swing either.=0A>= =0A>>I have also added various bundles required to run oscar. With this set= up i am able to build oscar.jar through ant, but when i try to run oscar i= t gives me following error:=0A>>=0A>>Welcome to Oscar.=0A>>=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>>=0A>>Enter profile name: my_profil= e=0A>>=0A>>Oscar: Error starting file:bundle/shell.jar=0A>>Oscar: Error sta= rting file:bundle/shelltui.jar=0A>>Oscar: Error starting file:bundle/bundle= repository.jar=0A>>Dumping live threads:=0A>>`OscarStartLevel' tid 0x841901= 0, status SUSPENDED flags=0A>>blocked@0x8400fa8 (0x8419010->|)=0A>>`OscarPa= ckageAdmin' tid 0x840e010, status SUSPENDED flags=0A>>blocked@0x8400b88 (0x= 840e010->|)=0A>>`OscarDispatchQueue' tid 0x83c9010, status SUSPENDED flags= =0A>>blocked@0x83beac8 (0x83c9010->|)=0A>>`gc' tid 0x828e010, status SUSPEN= DED flags DONTSTOP=0A>>blocked@0x827ea98 (0x828e010->|)=0A>>`finaliser' tid= 0x8285010, status SUSPENDED flags DONTSTOP=0A>>blocked@0x81ac3c0 (0x828501= 0->|)=0A>>Deadlock: all threads blocked on internal events=0A>>Aborted=0A>>= =0A>>=0A>>What can be the reason for this error?=0A>> =0A>=0A>I don't know= , I have never seen it before. All Oscar internal threads should be blocked= (i.e., waiting), since there isn't any work for them to do. The only threa= d that should be doing anything is the main thread used to call the static = main. Since there were errors starting all of the bundles, you will never g= et a shell.=0A>=0A>I would be willing to take a quick look at this, if it d= oesn't take too much effort to work with Kaffe...this doesn't necessarily s= ound like an Oscar problem, since it runs on many JVMs.=0A>=0A>>For buildin= g oscar i unjar oscar_20031127.jar and bundlesrc.jar added jar files accord= ing to build.xml. I am using default system.properties file and example.poi= lcy file.=0A>>=0A>=0A>If you are using the policy file, try to run without = the security manager.=0A>=0A>-> richard=0A>=0A>=0A>=0A>=0A>----------------= ---------------------------------------=0A>This SF.Net email is sponsored b= y Sleepycat Software=0A>Learn developer strategies Cisco, Motorola, Ericsso= n & Lucent use to deliver=0A>higher performing products faster, at low TCO.= =0A>http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3=0A>_________= ______________________________________=0A>oscar-osgi-devel mailing list=0A>= osc...@li...=0A>https://lists.sourceforge.net/lis= ts/listinfo/oscar-osgi-devel=0A |
From: Ravishankar H. <rav...@re...> - 2004-05-08 15:09:03
|
=A0=0AHey Gaurav,=0AI think u r not starting Oscar from the $HOME/Oscar di= rectory.=0AYou can do one of these two options to get rid of your problem.= =0A1. try starting Oscar from the directory where u have installed Oscar (f= or eg $HOME/Oscar)=0AOR=0A2. In the system.properties file specify absolute= path name for all the bundles that u r starting in the beginning. ( for eg= . specify=0Afile:/home/ravi/Oscar/bundle/shell.jar )=0A=0ACheers,=0ARavi=0A= =0A=0AOn Wed, 05 May 2004 Gaurav Ganeriwal wrote :=0A>=0A>Greetings,=0A>= =0A>I am trying to port OSCAR on KAFFE-1.0.7 (http://wwww.kaffe.org).=0A>As= kaffe donot have swing package support, i decided to use SwingWT package. = I have made necessary changes in the OSCAR source code. I have also added v= arious bundles required to run oscar. With this set up i am able to build o= scar.jar through ant, but when i try to run oscar it gives me following err= or:=0A>=0A>Welcome to Oscar.=0A>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=0A>=0A>Enter profile name: my_profile=0A>=0A>Oscar: Error startin= g file:bundle/shell.jar=0A>Oscar: Error starting file:bundle/shelltui.jar= =0A>Oscar: Error starting file:bundle/bundlerepository.jar=0A>Dumping live = threads:=0A>`OscarStartLevel' tid 0x8419010, status SUSPENDED flags=0A> bl= ocked@0x8400fa8 (0x8419010->|)=0A>`OscarPackageAdmin' tid 0x840e010, status= SUSPENDED flags=0A> blocked@0x8400b88 (0x840e010->|)=0A>`OscarDispatchQue= ue' tid 0x83c9010, status SUSPENDED flags=0A> blocked@0x83beac8 (0x83c9010= ->|)=0A>`gc' tid 0x828e010, status SUSPENDED flags DONTSTOP=0A> blocked@0x= 827ea98 (0x828e010->|)=0A>`finaliser' tid 0x8285010, status SUSPENDED flags= DONTSTOP=0A> blocked@0x81ac3c0 (0x8285010->|)=0A>Deadlock: all threads bl= ocked on internal events=0A>Aborted=0A>=0A>=0A>What can be the reason for t= his error?=0A>=0A>For building oscar i unjar oscar_20031127.jar and bundles= rc.jar added jar files according to build.xml. I am using default system.pr= operties file and example.poilcy file.=0A>=0A>Thanks and Regards,=0A>Gaurav= Ganeriwal=0A |
From: Richard S. H. <he...@un...> - 2004-05-07 14:03:43
|
Nektarios K. Papadopoulos wrote: > I realize the implications as well as those pointed out by others. I > am certainly not in position to describe a bullet-proof versioning - > dependencies resolving system. > I guess I was 'too' focused in my use scenario, i.e. embedded. So, > I'll say no more and when I come across two bundles with the same > library embedded inside them, I'll re-bundlize them myself to save space. This is probably best for now, but there is some possibility that these types of issues will be addressed by the spec in the future, so don't give up hope! :-) -> richard |
From: Nektarios K. P. <npa...@in...> - 2004-05-07 14:00:07
|
Richard S. Hall wrote: > While I agree with your point, your initial comment is more important. I > don't expect that people will be downloading the source code to a PDA or > cell phone, so the source packaging structure is not for that purpose. I agree > The whole point is this: bundle source code will no longer be included > with Oscar, each bundle will be treated as a separate subproject at > Oscar's old site and I wanted some simple way for people to be able to > get the source code. > > In truth, we don't need OBR to provide access to the source at all, but > since the source for each bundle will need to be URL accessible anyway, > I thought it would be nice to include that meta-data in OBR with a > simple command to download it. > I understand > An interesting idea, but I am not sure it is a good one, because this > means that the bundle may end up getting versions that it didn't expect > and in the case of libraries, this is not a good thing, since they are > not always backwards compatible. > I realize the implications as well as those pointed out by others. I am certainly not in position to describe a bullet-proof versioning - dependencies resolving system. I guess I was 'too' focused in my use scenario, i.e. embedded. So, I'll say no more and when I come across two bundles with the same library embedded inside them, I'll re-bundlize them myself to save space. cheers --- nek |
From: Richard S. H. <he...@un...> - 2004-05-07 13:11:02
|
Nektarios K. Papadopoulos wrote: > We are talking about source-bundle and indeed the download/compile > phase is, in most cases, going to happen on a host with high speed > internet access and gigabytes of hard drive. But the situation for > embedded devices is different. Both download time and storage space > have to be considered. While I agree with your point, your initial comment is more important. I don't expect that people will be downloading the source code to a PDA or cell phone, so the source packaging structure is not for that purpose. The whole point is this: bundle source code will no longer be included with Oscar, each bundle will be treated as a separate subproject at Oscar's old site and I wanted some simple way for people to be able to get the source code. In truth, we don't need OBR to provide access to the source at all, but since the source for each bundle will need to be URL accessible anyway, I thought it would be nice to include that meta-data in OBR with a simple command to download it. > A feature I would like to see in those source-bundles is a build > option like say 'ant strip' that produce multitpl bundles. The main > bundle and one bundle for each required library. An interesting idea, but I am not sure it is a good one, because this means that the bundle may end up getting versions that it didn't expect and in the case of libraries, this is not a good thing, since they are not always backwards compatible. -> richard |
From: Richard S. H. <he...@un...> - 2004-05-07 13:03:38
|
Nektarios K. Papadopoulos wrote: > How about the Bundle-UpdateLocation manifest header ? Yes, that would possibly work. Of course, this gets tricky if we eventually allow multiple versions of a bundle in the repository. For example, you could archive old versions as well as having current stable and development versions. This that whatever version you installed, you would only be able to get updates for the same update location, i.e., if they installed the stable version, then they would only ever be able to update to newer version of the stable version. If they wanted to use the development version, they would have to uninstall the stable version, then install the development version, which would from then on check for updates on the development update location. -> richard |
From: Richard S. H. <he...@un...> - 2004-05-07 12:52:12
|
Michel D'Hooge wrote: > But when updating a bundle you will only have the version of the > bundle you downloaded, not the current version of a bundle with a > similar name. Good point, so that would not work. -> richard > |
From: Nektarios K. P. <npa...@in...> - 2004-05-07 12:45:57
|
Richard S. Hall wrote: > I was planning on having the next version of OBR support updating, so > you can automatically update installed bundles. There is a difficult > with this approach in knowing which locally installed bundles correspond > to the remotely available bundles. How about the Bundle-UpdateLocation manifest header ? --- nek |
From: Michel D'H. <mic...@tr...> - 2004-05-07 12:40:24
|
Eric Swindell wrote: >If the motivation for bundle uniqueness is driven by the ability to uniquely >identify bundles for their replication from server to locale repositories, >the bundle name and version number could form a unique key. > But when updating a bundle you will only have the version of the bundle you downloaded, not the current version of a bundle with a similar name. To be sure that a local bundle is an old version of an OBR one, we could use a hash value of some properties like name, vendor and category - which are unlikely to change. Note that I propose a hash but just concatenating could suffice; it could even be better if we want to compute the mathematical distance between the local bundle and "similar" bundles in the repository, when 10 bundles with the same name will be available ;-) -- Michel |