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: Nektarios K. P. <npa...@in...> - 2004-05-07 12:38:52
|
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 |
From: Richard S. H. <he...@un...> - 2004-05-07 09:40:55
|
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... |
From: Eric S. <eri...@at...> - 2004-05-06 22:10:01
|
On Thursday 06 May 2004 12:02, Richard S. Hall wrote: > Regardless, we have to have some unique identifier for OBR. It seems > like there are two options: > > 1. Require that bundle names are always unique and just be done with= it. > 2. Add a new "OBR unique name" manifest entry to all bundles hosted > in OBR. > > Some opinions would be appreciated... I currently use two types of keys to identify bundles. One is referred t= o as=20 a 'plugin bundle key' manifest entry, which has a value that is unique am= ong=20 all my bundles. For other bundles which don't have the key, I use their=20 location, and if a bundle already exists with that location in an Oscar=20 instance, then I add a unique number to it. Another manifest entry I use= is=20 called a 'plugin key', which represents a plugin. This concept of a 'plu= gin'=20 is more virtual, in that one or more actual bundles comprise the plugin. = The=20 plugin bundle key also has the plugin key embedded in it, e.g.: Plugin-Key: reef Plugin-Bundle-Key: reef.db=20 So a unique key can be useful for organizing bundles. As you mentioned, = there=20 may be multiple versions of a bundle, and other bundles may depend on old= er=20 versions, so they might likely remain in the repository. Some issues wit= h=20 this related to OBR would be the format of the key and how the key is iss= ued. If the motivation for bundle uniqueness is driven by the ability to uniqu= ely=20 identify bundles for their replication from server to locale repositories= ,=20 the bundle name and version number could form a unique key. You could ad= d=20 this as a separate manifest entry, but then again, it could easily be=20 constructed from Bundle-Name and Bundle-Version. =20 Such keys could also be used to provide limited bundle version dependency= =20 management, where one bundle could list it's dependent bundle keys for OB= R=20 purposes. OSGi provides package versioning in the import/export entries,= but=20 these assume backward compatibility. Chances are, you're going to test y= our=20 bundles against specific dependent bundles so that these dependent bundle= =20 implementations are sort of 'certified' as interoperable without ill=20 consequences anyway. Note that I'm not necessarily advocating bundle to bundle version depende= ncy=20 management as the ideal approach. Ideally, you'd have the flexibility of= =20 managing this at the package level. However, isn't OSGi's versioning bas= ed=20 on the 'specification version', and excludes any consideration of an=20 'implementation version' or 'service provider'? Sorry, I'm off topic her= e :) Eric |
From: Richard S. H. <he...@un...> - 2004-05-06 17:02:30
|
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. One might initially assume that you could use the URL (i.e., location) to determine a correspondence, but this is not always true. For example, bundles that are installed locally, such as the shell or OBR, have a URL like "file:bundle/shell.jar", whereas the URL on OBR will be something like "http://oscar-osgi.sf.net/br/shell.jar". Thus, it is not possible to use the location to determine the correspondence between local and remote bundles. The other possibility is to use bundle name. Currently, OBR assumes bundle names are unique, so this would work. However, for various reasons people may not want bundle names to be unique. For example, maybe someone wants to package two different versions of their bundle, one with native libraries for windows and one with native libraries for linux. In this case, they may want the name to be the same. I don't know. Since the bundle name is meant to be human readable, there may be valid reasons. Regardless, we have to have some unique identifier for OBR. It seems like there are two options: 1. Require that bundle names are always unique and just be done with it. 2. Add a new "OBR unique name" manifest entry to all bundles hosted in OBR. Some opinions would be appreciated... -> richard |
From: Humberto C. <Hum...@im...> - 2004-05-06 16:51:03
|
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. Of course, these are just subjective arguments, but as this is some kind of poll, I emit my vote for the 1st option... Humberto -- ----------------------------------------------- Humberto Cervantes <Hum...@im...> Web: http://www-adele.imag.fr/~cervante/ LSR-Adele, 220 rue de la Chimie, Domaine Universitaire, B.P. 53, 38041 Grenoble Cedex 9, France Tel: (33)4 76 63 55 74 ----------------------------------------------- |
From: Eric S. <eri...@at...> - 2004-05-06 16:45:28
|
On Thursday 06 May 2004 08:03, Michel D'Hooge wrote: > BTW, I am looking for the best solution to put these modifications in > Oscar. As Stephane Chomat pointed out, since there is no preprocessor i= n > java, it is quite boring. I was considering using the GNU patch tool to > apply the changes to a given version of Oscar. You might check out the hsqldb project at sf.net. They use what they cal= l=20 'Code Switcher' which manages different versions of Java source code, and= is=20 used to create different builds for different JDKs. It acts as a=20 pre-processor. In this manner, you would have one build script for Oscar= ,=20 which could be used to create builds for multiple JDKs and platforms. Eric |
From: Eric S. <eri...@at...> - 2004-05-06 16:31:49
|
On Thursday 06 May 2004 08:38, Richard S. Hall wrote: > But how would this work for embedded libraries that are not part of > bundlized. For example, the new version of OBR will embed kXML for > private use. Thus, people will not be able to compile OBR unless they g= o > out and find a version (the right version) of kXML. The key word here is 'version'. Bundle object code and source code might merit different approaches here. Finding the right version of a dependen= t library source which was used to originally compile the bundle can someti= mes be problematic. I would think that option 1 would be appropriate for sou= rces since it would reduce/eliminate bundle compilation issues. Simply run th= e build.xml and you're done. Otherwise, seek and hopefully ye shall find a= ll the correct source versions originally used to compile the bundle. I gue= ss you have to weigh the risk versus the cost benefit. I see a strong benef= it at minimal cost, but also a definite risk which can be mitigated. One other method which I think someone already mentioned is if the reposi= tory could contain bundlized dependent libraries, which would be downloaded automagically as well, in the same manner that the binary installs are do= ne. The versioning issue doesn't completely go away however, as OSGi's concep= t of versioning assumes backward compatibility. So unless we can also have th= e repository download the specific dependent library versions ( not OSGi considered 'compatible' versions ), then I'd prefer option 1. Eric |
From: Richard S. H. <he...@un...> - 2004-05-06 13:53:41
|
Michel D'Hooge wrote: >> for example, I have run it on J2ME Personal Profile, > > > Did you manage recently to run Oscar on J2ME? Because I tried with > Jbed from Esmertec and it complained because Oscar is using J2SE > classes that were not found. > So I dug "pOscar" and... had no time any more to update the 1-year-old > modifications to the latest version of Oscar. I ran Oscar unchanged on the experimental J2ME Personal Profile for the Sharp Zaurus... > BTW, I am looking for the best solution to put these modifications in > Oscar. As Stephane Chomat pointed out, since there is no preprocessor > in java, it is quite boring. I was considering using the GNU patch > tool to apply the changes to a given version of Oscar. This is difficult it you want JDK 1.1 compatibility, but J2ME Personal Profile supports a subset of the JDK 2 API and Oscar works fine on this. -> richard |
From: Richard S. H. <he...@un...> - 2004-05-06 13:38:17
|
Michel D'Hooge wrote: > I also prefer the 2nd solution. And I think that Nektarios K. > Papadopoulos argument is quite convincing. > > If the dependencies are on other bundles, then OBR should be able to > also download them, as it does for binary download. Even though it > would more tricky to guess what is already available... > > For other dependencies, like OSGi framework location, I use this in my > ANT build files: > <property file="../osgi.ant.properties"/> But how would this work for embedded libraries that are not part of bundlized. For example, the new version of OBR will embed kXML for private use. Thus, people will not be able to compile OBR unless they go out and find a version (the right version) of kXML. I agree with that we could probably use a property for osgi.jar... -> richard > |
From: Richard S. H. <he...@un...> - 2004-05-06 13:34:56
|
Michel D'Hooge wrote: > And (last?) point to address is the bundlerepository file. How will it > be updated with locally available bundles? It won't be. Your previous changes to OBR that allow you to specify multiple URLs will still be available, so you just put your local bundle repository file URL first on your list of repository URLs. -> richard |
From: Michel D'H. <mic...@tr...> - 2004-05-06 13:04:44
|
Richard S. Hall wrote: > for example, I have run it on J2ME Personal Profile, Did you manage recently to run Oscar on J2ME? Because I tried with Jbed from Esmertec and it complained because Oscar is using J2SE classes that were not found. So I dug "pOscar" and... had no time any more to update the 1-year-old modifications to the latest version of Oscar. BTW, I am looking for the best solution to put these modifications in Oscar. As Stephane Chomat pointed out, since there is no preprocessor in java, it is quite boring. I was considering using the GNU patch tool to apply the changes to a given version of Oscar. Michel |
From: Michel D'H. <mic...@tr...> - 2004-05-06 12:14:27
|
I also prefer the 2nd solution. And I think that Nektarios K. Papadopoulos argument is quite convincing. If the dependencies are on other bundles, then OBR should be able to also download them, as it does for binary download. Even though it would more tricky to guess what is already available... For other dependencies, like OSGi framework location, I use this in my ANT build files: <property file="../osgi.ant.properties"/> with the associated files: Oscar.dir = P:/OSGi/Oscar/0.9.4a/ OSGi.delivery.dir = P:/OSGi/Oscar/bundle-T/ OSGi.interfaces.urls = P:/OSGi/Oscar/0.9.4a/lib/osgi.jar;P:/OSGi/Oscar/0.9.4a/lib/javax.servlet.jar;P:/OSGi/Oscar/0.9.4a/bundle/osgi-service.jar;P:/OSGi/Oscar/0.9.4a/bundle/osgi-util.jar And (last?) point to address is the bundlerepository file. How will it be updated with locally available bundles? -- Michel |
From: Nektarios K. P. <npa...@in...> - 2004-05-06 07:02:13
|
Winter Andreas wrote: > I usually prefer alternative 2 together with detailed docs about > what version of which jar is needed I second that. Besides I think that alternative 2 is in line with the concept of OSGi bundles Import/Export Headers (+specification-version=x.x.x). Non-source bundles should not contain all needed packages but rather try to declare what package/specification-version they need to import. Right ? If so, would not it be awkward for a bundle developer to - include in the source distribution the required library packages -BUT NOT including them in the binary distribution ? --- nek |
From: Nektarios K. P. <npa...@in...> - 2004-05-06 07:01:44
|
Hi, At the moment I am using the latest CVS Kaffe and it has no problem with either System.setProperty() or the java.security package. These features should be alright in the latest development release too i.e. 1.1.4. Kaffe is also about to make the 1.1.5 release so you might as well wait for that. cheers nek |
From: Winter A. <and...@wi...> - 2004-05-06 04:58:25
|
I usually prefer alternative 2 together with detailed docs about=20 what version of which jar is needed (maybe = http://krysalis.org/version/index.html can help), because I manage my own jar setup in Eclipse. But if you think of bundles as self-contained entities (more or less)=20 alternative 1 would be a good approach.=20 So I would suggest alternative 1 plus some docs about needed jar = versions for those who manage there own jar setup. - andreas > -----Urspr=FCngliche Nachricht----- > Von: Richard S. Hall [mailto:he...@un...] > Gesendet: Mittwoch, 5. Mai 2004 21:11 > An: oscar-devel > Betreff: [oscar-devel] Packaging Bundles >=20 >=20 > As I mentioned previously, I am separating the bundles from Oscar and = > OBR will become the official way to get bundle source code and the=20 > existing Oscar web site will become a bundle repository site. >=20 > This raises the question of how should bundle source code be=20 > packaged. I=20 > see at least three alternatives: >=20 > 1. Completely self-contained with everything it needs to=20 > compile with > build file. > 2. Containing only the bundle source code with build file and the > assumption that you will get needed libraries elsewhere (i.e., > osgi.jar, osgi-service.jar, osgi-util.jar, servlet.jar). > 3. Containing only the bundle source code with build file that > assumes it is installed into the Oscar install directory so = that > it can find needed libraries in the lib/ directory. >=20 > Personally, I like the first alternative, even if it means that each=20 > bundle includes its own copy of osgi.jar (for example). Somehow it is = > cleaner to have them self-contained and it makes it easier to=20 > use them=20 > not only with Oscar. >=20 > Any other opinions on this matter? >=20 > -> richard >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent=20 > use to deliver > higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3 > _______________________________________________ > oscar-osgi-devel mailing list > osc...@li... > https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel >=20 |
From: Richard S. H. <he...@un...> - 2004-05-05 21:19:42
|
Stephane Frenot wrote: >I'm not sure its an issue. >Each bundle provider should have its own policy. > > I agree, but it would be nice if we had a recommendation, otherwise every will be practically forced to have their own policy since there is no suggested policy. >The first one is more independant of oscar evolution (version >modification), whereas the third relies on current releases, and should >fail to compile on different oscar releases. > > Yep, these are some reasons why I like the first approach best. >One issue I can't see is the sources packaging model... >- jar/tar/zip ? (jar is cool but generates META-INF directory with jar > tool, or you use your inner unjarrer) > > Well, we could do the extract for them automagically...or just use zip. I am flexible here. No tar or gzip, we don't want to freak any Windows people out. ;-) >Do you rely on a standard build.xml skeleton ? >(clean/compile/bundles) > > Again, I think we should suggest it, but people will be free to do what they want. >Do you extract sources inside oscar install ? > > No, but I do extract JAR files inside of it, so that is not a problem. >So you need some kinds of bundle/package/services namespaces. >Initial namespaces were provided by both osgi and you, but what will >appened when billion of bundles will be available :) ? > > Gee, I never thought about what would happen when a billion bundles became available! ;-) I don't see this being a problem. I assume that people will either use their own domain for package naming or if they don't have one they can ask me for a name in my bundle hierarchy. >Il like the gentoo portage tree (or freebsd port) which should be >reproduced. > Well, I wasn't trying to make a build tree. This sounds like a nice service for someone to create on top of OBR! :-) -> richard |
From: Stephane F. <ste...@in...> - 2004-05-05 21:07:49
|
On Wed, May 05, 2004 at 09:10:31PM +0200, Richard S. Hall wrote: > As I mentioned previously, I am separating the bundles from Oscar and=20 > OBR will become the official way to get bundle source code and the=20 > existing Oscar web site will become a bundle repository site. >=20 > This raises the question of how should bundle source code be packaged. = I=20 > see at least three alternatives: >=20 > 1. Completely self-contained with everything it needs to compile with > build file. > 2. Containing only the bundle source code with build file and the > assumption that you will get needed libraries elsewhere (i.e., > osgi.jar, osgi-service.jar, osgi-util.jar, servlet.jar). > 3. Containing only the bundle source code with build file that > assumes it is installed into the Oscar install directory so that > it can find needed libraries in the lib/ directory. >=20 > Personally, I like the first alternative, even if it means that each=20 > bundle includes its own copy of osgi.jar (for example). Somehow it is=20 > cleaner to have them self-contained and it makes it easier to use them=20 > not only with Oscar. I'm not sure its an issue.=20 Each bundle provider should have its own policy.=20 The first one is more independant of oscar evolution (version modification), whereas the third relies on current releases, and should fail to compile on different oscar releases. One issue I can't see is the sources packaging model... - jar/tar/zip ? (jar is cool but generates META-INF directory with jar tool, or you use your inner unjarrer) Do you rely on a standard build.xml skeleton ? (clean/compile/bundles) Do you extract sources inside oscar install ? So you need some kinds of bundle/package/services namespaces. Initial namespaces were provided by both osgi and you, but what will appened when billion of bundles will be available :) ? Il like the gentoo portage tree (or freebsd port) which should be reproduced. /stephane --=20 Stephane Frenot - Associate professor CITI/ARES - INSA lyon - Bat. L=E9onard de Vinci 20, av. A. Einstein - 69621 Villeurbanne Cedex Email: mailto:ste...@in... Web : http://ares.insa-lyon.fr/~sfrenot/ ICQ : 643346 (et oui !) Tel : +33 472 436 422 / +33 617 671 714 ----------------------------------------------------------------- |
From: Richard S. H. <he...@un...> - 2004-05-05 19:54:41
|
Okay, I messed with Kaffe a bit...it seems like it will be a pain to get Oscar running on it, since it doesn't support even the JDK 1.2 API. It doesn't support System.setProperty() and I think I have determined that this is the root of your problem (probably). The reason why you are getting the "deadlock" message is because the "main" thread is exiting and there are no other "non-blocked" threads, so it thinks it has a deadlock. The "main" thread exits after starting/installing the autostart bundles. Normally, the "shelltui" bundle starts a thread to read from stardard input to accept shell commands. Since none of the bundles start this thread never gets created, thus, when the main thread exits there are no active threads. Oscar uses System.setProperty() to set the system properties, which cannot be set since this method doesn't exist. So, I tried the alternative in Main.java, which is passing them into the constructor: Properties map = new Properties(); map.put(OscarConstants.PROFILE_NAME_PROP, profileName); map.put("oscar.auto.start.1", "file:bundle/shell.jar file:bundle/shelltui.jar file:bundle/bundlerepository.jar"); m_oscar = new Oscar(map); This got me farther, but I ended up with this instead: java.lang.NoSuchMethodError: java/security/CodeSource.<init>(Ljava/net/URL;[Ljava/security/cert/Certificate;)V at org.ungoverned.oscar.Oscar$CheckImportsPrivileged.run(Oscar.java:4206) at java.security.AccessController.doPrivileged(AccessController.java:37) at org.ungoverned.oscar.Oscar.resolveBundle(Oscar.java:3196) at org.ungoverned.oscar.Oscar.startBundleWithStartLevel(Oscar.java:1731) at org.ungoverned.oscar.Oscar.setStartLevelInternal(Oscar.java:783) at org.ungoverned.oscar.Oscar.setStartLevel(Oscar.java:700) at org.ungoverned.oscar.Oscar.initialize(Oscar.java:572) at org.ungoverned.oscar.Oscar.<init>(Oscar.java:344) at org.ungoverned.oscar.Oscar.<init>(Oscar.java:276) at org.ungoverned.oscar.Main.main(Main.java:100) Oscar: Error starting file:bundle/shell.jar So it looks like the security stuff will have to be hacked a little bit too. So, perhaps you can take it from there and let me know what you find out. Good luck. -> richard p.s. If you really want to hack the source of Oscar, I would recommend grabbing the latest beta version, since the 1.0.0 release has quite a few changes. Gaurav Ganeriwal wrote: >Greetings, > >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. 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? > >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. > >Thanks and Regards, >Gaurav Ganeriwal > > > |
From: Richard S. H. <he...@un...> - 2004-05-05 19:44:14
|
Stephane Frenot wrote: >I don't understand something... obr currently delivers startable >bundles, not sources... > > Correct. And it still will deliver startable bundles, it will just deliver sources too. Of course, you will still be able to get the sources from a web page... >Do you mean that installable bundles won't be anymore provided by obr ? > > No, I do not mean that. >Or do you mean that you should have a specific obr command (obr source >logReader) that should install sources ? > Exactly! :-) -> richard |
From: Stephane F. <ste...@in...> - 2004-05-05 19:41:01
|
On Wed, May 05, 2004 at 09:10:31PM +0200, Richard S. Hall wrote: > As I mentioned previously, I am separating the bundles from Oscar and=20 > OBR will become the official way to get bundle source code and the=20 > existing Oscar web site will become a bundle repository sit I don't understand something... obr currently delivers startable bundles, not sources... Do you mean that installable bundles won't be anymore provided by obr ? Or do you mean that you should have a specific obr command (obr source logReader) that should install sources ? /stephane >=20 --=20 Stephane Frenot - Associate professor CITI/ARES - INSA lyon - Bat. L=E9onard de Vinci 20, av. A. Einstein - 69621 Villeurbanne Cedex Email: mailto:ste...@in... Web : http://ares.insa-lyon.fr/~sfrenot/ ICQ : 643346 (et oui !) Tel : +33 472 436 422 / +33 617 671 714 ----------------------------------------------------------------- |
From: Richard S. H. <he...@un...> - 2004-05-05 19:10:30
|
As I mentioned previously, I am separating the bundles from Oscar and OBR will become the official way to get bundle source code and the existing Oscar web site will become a bundle repository site. This raises the question of how should bundle source code be packaged. I see at least three alternatives: 1. Completely self-contained with everything it needs to compile with build file. 2. Containing only the bundle source code with build file and the assumption that you will get needed libraries elsewhere (i.e., osgi.jar, osgi-service.jar, osgi-util.jar, servlet.jar). 3. Containing only the bundle source code with build file that assumes it is installed into the Oscar install directory so that it can find needed libraries in the lib/ directory. Personally, I like the first alternative, even if it means that each bundle includes its own copy of osgi.jar (for example). Somehow it is cleaner to have them self-contained and it makes it easier to use them not only with Oscar. Any other opinions on this matter? -> richard |
From: Richard S. H. <he...@un...> - 2004-05-05 18:55:05
|
>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 |
From: Gaurav G. <gan...@re...> - 2004-05-05 15:47:29
|
=0AGreetings,=0A=0AI am trying to port OSCAR on KAFFE-1.0.7 (http://wwww.ka= ffe.org).=0AAs kaffe donot have swing package support, i decided to use Swi= ngWT package. I have made necessary changes in the OSCAR source code. I hav= e also added various bundles required to run oscar. With this set up i am a= ble to build oscar.jar through ant, but when i try to run oscar it gives me= following error:=0A=0AWelcome to Oscar.=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=0A =0AEnter profile name: my_profile=0A =0AOscar: Err= or starting file:bundle/shell.jar=0AOscar: Error starting file:bundle/shell= tui.jar=0AOscar: Error starting file:bundle/bundlerepository.jar=0ADumping = live threads:=0A`OscarStartLevel' tid 0x8419010, status SUSPENDED flags=0A = blocked@0x8400fa8 (0x8419010->|)=0A`OscarPackageAdmin' tid 0x840e010, statu= s SUSPENDED flags=0A blocked@0x8400b88 (0x840e010->|)=0A`OscarDispatchQueue= ' tid 0x83c9010, status SUSPENDED flags=0A blocked@0x83beac8 (0x83c9010->|)= =0A`gc' tid 0x828e010, status SUSPENDED flags DONTSTOP=0A blocked@0x827ea98= (0x828e010->|)=0A`finaliser' tid 0x8285010, status SUSPENDED flags DONTSTO= P=0A blocked@0x81ac3c0 (0x8285010->|)=0ADeadlock: all threads blocked on in= ternal events=0AAborted=0A=0A=0AWhat can be the reason for this error?=0A= =0AFor building oscar i unjar oscar_20031127.jar and bundlesrc.jar added ja= r files according to build.xml. I am using default system.properties file a= nd example.poilcy file.=0A=0AThanks and Regards,=0AGaurav Ganeriwal =0A |
From: Nektarios K. P. <npa...@in...> - 2004-05-05 12:25:25
|
> How? A service factory is called using Bundle as argument, not a > BundleContext. > You are absolutely right. Sorry for the misleading comment. nek |
From: Erik W. <er...@wi...> - 2004-05-05 12:04:08
|
Michel D'Hooge wrote: >> Nektarios K. Papadopoulos wrote: >> 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) How? A service factory is called using Bundle as argument, not a BundleContext. /Erik W -- Erik Wistrand, er...@wi... |