oscar-osgi-devel — Discussion of Oscar development issues

[oscar-devel] OT: Invitation to participate in research project

[Ben A. <ben...@st...>]

Hello there

I would greatly appreciate a small amount of your time to assist with
my doctoral research at The University of Newcastle. The research
concerns open source licensing and we're seeking developers working on
Java projects. The research is supervised, ethics-approved, anonymous
and results will be freely available. Participation will also provide a
custom licensing report for your project. To learn more, please visit:

   http://licensing-research.newcastle.edu.au

Thanks for reading this email, and I hope you'll consider participating.

Best regards
Ben Alex

(My apologies for being off-topic; this list will not be emailed again)

Re: [oscar-devel] CLDC-No Reflect, Memory estimations querry

[Stephane F. <ste...@in...>]

Hi,=20
OSGi v3 has a specific section about the java API requirements. It's
called "Execution Environment Specification". That speficication lists
all classes that java VM needs to provide in order to build an OSGi imple=
mentation.
There are two flavors : foundation (which is extracted mainly from CDC
profile) and minimal which is a subset (I think) centered for OSGi
requirements.=20

Both Reflection and Serialisation apis are needed in both flavors.=20

You can find the API lists for both flavors on OSGi web site, as jar
files.=20

The second question is now :=20
  - What is .... to run a java VM compliant to the minimal
    requirements... No idea for the moment.=20

/stephane
On Mon, Jul 05, 2004 at 08:04:14PM +0530, paramjeet chawla wrote:
> Hi,
>=20
> I spent some time to evaluate OSCAR/OSGi on J2ME CLDC. I thought its be=
tter
> to have an experts opinion. As CLDC does not support Reflect Classes an=
d
> Serializable, so what impact does it have on OSGi framework. Do Reflect=
s and
> Serializable have crucial role in implementation of the framework?
>=20
> Another question is, What is amount of RAM & Flash, CPU Hz required to =
run
> minimum version of OSGi ?
> it would be helpful to me if you provide me various break ups of CDC, F=
P,
> Framework size etc.
>=20
> Thanking you in anticipation.
>=20
> Regards
>=20
> Paramjeet
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
> digital self defense, top technical experts, no vendor pitches,=20
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> oscar-osgi-devel mailing list
> osc...@li...
> https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel

--=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
-----------------------------------------------------------------

[oscar-devel] CLDC-No Reflect, Memory estimations querry

[paramjeet c. <par...@pa...>]

Hi,

I spent some time to evaluate OSCAR/OSGi on J2ME CLDC. I thought its better
to have an experts opinion. As CLDC does not support Reflect Classes and
Serializable, so what impact does it have on OSGi framework. Do Reflects and
Serializable have crucial role in implementation of the framework?

Another question is, What is amount of RAM & Flash, CPU Hz required to run
minimum version of OSGi ?
it would be helpful to me if you provide me various break ups of CDC, FP,
Framework size etc.

Thanking you in anticipation.

Regards

Paramjeet

[oscar-devel] Oscar mailing lists

[Richard S. H. <he...@un...>]

Hello everyone.

As part of Oscar's move to forge.objectweb.org, I plan to migrate the 
Source Forge mailing lists to ObjectWeb as well. I have created two 
mailing lists:

    * os...@ob... - this list is for general OSGi, Oscar usage,
      and bundle development discussion.
    * osc...@ob... - this list is for discussion about the
      internal details of Oscar's implementation, i.e., if you are
      interested in knowing how Oscar works or want to have input on
      design decisions.

I will migrate everyone from the Source Forge mailing lists to the 
general "oscar" mailing list, but I won't include anyone by default on 
the "oscar-dev" list.

If you do not want to be migrated, want to be on both lists, or only 
want to be on "oscar-dev", then please respond to this email and let me 
know so that I can do the right thing for you.

In summary, unless you say otherwise, you will be taken off of the 
Source Forge mailing list and added to the new ObjectWeb "oscar" general 
discussion mailing list.

-> richard

p.s. Since the old Oscar site will become the web presence for OBR, I 
will eventually create at least one new mailing list on Source Forge for 
OBR.

Re: [oscar-devel] Re: deadlock issues and a start level one.

[Richard S. H. <he...@un...>]

Manuel Santillan Palencia wrote:

>However, the thing is that the system hangs, even the tui, so you must
>kill oscar. But if I extract the code and put it inside a BundleListener
>which checks that the bundle event corresponds to BundleB.STARTED, then
>it works fine. If I find a bit of time, I shall try to recreate it, for
>the moment I have not been able... 
>  
>

If you can find the time to recreate it, I would definitely like to take 
a look at it.

>When a started bundle is updated it is restarted. Then when packages are
>refreshed, it is restarted with the new code.
>  
>

Correct.

>If a bundle is started, and then you change the platform start level to
>be higher than its startlevel, it stops. If you update the bundle and
>refresh and change again the platform start level to be lower than the
>bundle level, it is not started. Should not the service remember which
>bundles were in started state for a given startlevel even if they are
>updated?
>  
>

It sounds like you reversed this, I assume you mean "change the platform 
start level to be lower than its start level..." Or do you mean change 
the bundle start level to be higher?

At any rate, which version of Oscar are you using? I think this was a 
bug that was corrected in the latest betas, so just wait for 1.0.0 to be 
released and your problem should be solved.

Speaking of 1.0.0, what version of Oscar were you getting your deadlock 
against? Perhaps I could convince you to do some testing on the 1.0.0 
beta if you are not already doing so...

-> richard

[oscar-devel] Re: deadlock issues and a start level one.

[Manuel S. P. <san...@di...>]

Hello!


> I think that Michel is correct when he states that it has nothing to do 
> with the STARTING state, however, it could very likely be an Oscar issue 
> in some respects. Oscar has to do some sanity locking so that it can 
> ensure that refreshes don't happen in the middle of other operations, 
> for example.
> 
> It is difficult to explain the approach, but Oscar uses two locks, where 
> one is intended for simple operations and one is intended for 
> adminstrative operations. An administrative operation can ensure 
> complete mutex by getting both locks.
> 
> So what do I guess is happening in your case? Well, I haven't used RMI 
> in a long, long time, but if I remember correctly, it uses threads. Most 
> likely, Oscar calls out to your code, which then calls back into Oscar 
> on a different thread trying to access the other bundle, which creates 
> some sort of cycle.
> 
> My guess is you could recreate the problem without RMI, but by just 
> creating a separate thread that tries to load the class.

> If you can create a small example that demonstrates the problem, I will 
> look into whether/how it is possible to loosen the concurrency control, 
> but this is a very tricky issue. Obviously, Oscar cannot necessarily 
> deal with people grabbing its thread in callbacks and then sending in a 
> new thread.
> 
> 
I'm sorry, but I cannot recreate the problem :(( I've tried, it but it
works correctly. Maybe the problem lies elsewhere. The real architecture
is that bundle A has got a JMX's MBeanServer with a RMI connector
server, which listens for incoming requests.
At startup time, bundle B invokes a method from bundle A (the agent),
through reflection and RMI (ie, a JMX remote connection), which provokes
that: 
1. A file is loaded. This works fine.
2. From that file, it reads which components it must instantiate. This
also works fine. 
3. It tries to instantiate all the stated components. Some of the
components's classes are in bundle B (exported by it).
4. It returns.
5. Bundle B finishes starting

However, the thing is that the system hangs, even the tui, so you must
kill oscar. But if I extract the code and put it inside a BundleListener
which checks that the bundle event corresponds to BundleB.STARTED, then
it works fine. If I find a bit of time, I shall try to recreate it, for
the moment I have not been able... 

Another thing, regarding start level:

When a started bundle is updated it is restarted. Then when packages are
refreshed, it is restarted with the new code.

If a bundle is started, and then you change the platform start level to
be higher than its startlevel, it stops. If you update the bundle and
refresh and change again the platform start level to be lower than the
bundle level, it is not started. Should not the service remember which
bundles were in started state for a given startlevel even if they are
updated?

> -> richard


Regards,

Manuel

Re: [oscar-devel] Instantiation deadlock: A bug?

[Richard S. H. <he...@un...>]

Manuel Santillan Palencia wrote:

>I've already used a similar approach, by extracting all the problematic
>code from bundle B and putting it in a bundle event listener which
>executes itself when the bundle B is already started. 
>
>The thing is that if bundle B is in INSTALLED, RESOLVED OR STARTED
>state, then there is no problem in bundle A accesing a class from bundle
>B. However, if bundle A tries to access a class exported when bundle B
>is STARTING, he won't be able to do it. Is this the correct way of
>acting? Or should bundle A be able to access bundle B classes at any
>time?
>  
>

I think that Michel is correct when he states that it has nothing to do 
with the STARTING state, however, it could very likely be an Oscar issue 
in some respects. Oscar has to do some sanity locking so that it can 
ensure that refreshes don't happen in the middle of other operations, 
for example.

It is difficult to explain the approach, but Oscar uses two locks, where 
one is intended for simple operations and one is intended for 
adminstrative operations. An administrative operation can ensure 
complete mutex by getting both locks.

So what do I guess is happening in your case? Well, I haven't used RMI 
in a long, long time, but if I remember correctly, it uses threads. Most 
likely, Oscar calls out to your code, which then calls back into Oscar 
on a different thread trying to access the other bundle, which creates 
some sort of cycle.

My guess is you could recreate the problem without RMI, but by just 
creating a separate thread that tries to load the class.

>I mean, I 've already found workarounds for this problem. But I do not
>know if this is a bug (and therefore should need a fix) or is it just
>the way the spec says it should work. :)
>

If you can create a small example that demonstrates the problem, I will 
look into whether/how it is possible to loosen the concurrency control, 
but this is a very tricky issue. Obviously, Oscar cannot necessarily 
deal with people grabbing its thread in callbacks and then sending in a 
new thread.

-> richard

[oscar-devel] Coming Soon

[Richard S. H. <he...@un...>]

Hello everyone,

I am back from my conference.

I did not receive any feedback from the 1.0.0beta5 release, so that 
means one of two things:

   1. No one looked at it.
   2. No one had any issues.

I certainly hope that it was the latter, so I can finish updating 
documentation and add any final bugs fixes and features.

My goal is to release within the next two weeks.

-> richard

Re: [oscar-devel] Instantiation deadlock: A bug?

[Michel D'H. <mic...@tr...>]

Manuel Santillan Palencia wrote:

>The thing is that if bundle B is in INSTALLED, RESOLVED OR STARTED
>state, then there is no problem in bundle A accesing a class from bundle
>B. However, if bundle A tries to access a class exported when bundle B
>is STARTING, he won't be able to do it. 
>
Is it really because it is in Starting state, or because of what is done 
in the start method? I mean, if you "sleep" for 1 minute in the start 
method of B, and you access a class from A as you do when B is in 
another state (installed, resolved or started), do you still have the 
problem? And the other way round? If  you do what is in the start method 
when the bundle is started, are you still blocked?

>Is this the correct way of acting? Or should bundle A be able to access bundle B classes at any time?
>  
>
I don't have time to look into the source of Oscar, but from what I can 
imagine, the class loader of B is exporting its packages as soon as it 
is installed. So we are back to pure Java, not OSGi, and the state of 
the bundle shall have no influence.

Regards
Michel

Re: [oscar-devel] Instantiation deadlock: A bug?

[Manuel S. P. <san...@di...>]

Hi!

I answer you inside the mail. 

> First and foremost, this sounds like a logic/coding deadlock to me. It 
> seems you have a mutual dependency in your startup logic:
> 
> - Bundle B needs Bundle A to do something before it can finish starting
> - Bundle A needs to load classes from Bundle B before it can finish 
> starting.

Not exactly. Bundle A is already started and works fine. Then I start
bundle B, which tells bundle A to instantiate a class. This class is
exported by bundle B and imported by bundle A.
> 
> If I've understood this correctly, the only way you can break this 
> deadlock is:
> 
> - remove one of the dependencies e.g. let Bundle B start without any 
> dependency on Bundle A. Sort out what Bundle B needs later, such as by 
> using Services and have Bundle B wait for the required services to 
> become available.

I've already used a similar approach, by extracting all the problematic
code from bundle B and putting it in a bundle event listener which
executes itself when the bundle B is already started. 

The thing is that if bundle B is in INSTALLED, RESOLVED OR STARTED
state, then there is no problem in bundle A accesing a class from bundle
B. However, if bundle A tries to access a class exported when bundle B
is STARTING, he won't be able to do it. Is this the correct way of
acting? Or should bundle A be able to access bundle B classes at any
time?

I mean, I 've already found workarounds for this problem. But I do not
know if this is a bug (and therefore should need a fix) or is it just
the way the spec says it should work. :)

Thanks!!

Regards,


Manuel Santillan

[oscar-devel] Instantiation deadlock: A bug?

[Rob W. <ro...@as...>]

Manuel

Excuse me if this has already been answered - I only get the list digests, which come out a little delayed.


>We 've got bundle A and B. Bundle B has got a class C, which he exports,
>and bundle A imports it. 
>
>  
>
That part should be fine, it's the way OSGi is intended to work

>Suppose A is already started. Now we start bundle B. In its activator,
>it contacts bundle B via RMI and tells him to instantiate class C (by
>reflection). The problem is that while bundle B is starting, bundle A
>cannot instantiate classes exported by bundle B. Usually, this is not a
>problem, because the call just waits until bundle B finishes starting.
>But in this case, a deadlock occurs, because bundle B won't finish until
>bundle A instantiates that class, and A won't instantiate that class
>until bundle B finishes. 
>
>  
>
First and foremost, this sounds like a logic/coding deadlock to me. It 
seems you have a mutual dependency in your startup logic:

- Bundle B needs Bundle A to do something before it can finish starting
- Bundle A needs to load classes from Bundle B before it can finish 
starting.

If I've understood this correctly, the only way you can break this 
deadlock is:

- remove one of the dependencies e.g. let Bundle B start without any 
dependency on Bundle A. Sort out what Bundle B needs later, such as by 
using Services and have Bundle B wait for the required services to 
become available.

- move the offending Class C (and any other dependent classes) into a 
pure "library" bundle that has no activator or active code, but just 
purely acts as a class library exporting classes for other bundles to 
use. Both Bundle A and Bundle B can then import these classes

-- Rob

Re: [oscar-devel] Instantiation deadlock: A bug?

[Michel D'H. <mic...@tr...>]

Manuel Santillan Palencia wrote:

>We 've got bundle A and B. Bundle B has got a class C, which he exports,
>and bundle A imports it. 
>
>Suppose A is already started. 
>
How does A import class C? Is it through a dynamic-import in the 
manifest? Otherwise, it means that either B is already INSTALLED, or 
package of class C is exported by another bundle.

>Now we start bundle B. In its activator, it contacts bundle B 
>
you mean "it contacts bundle A", I guess!

>via RMI and tells him to instantiate class C (by
>reflection). The problem is that while bundle B is starting, bundle A
>cannot instantiate classes exported by bundle B. 
>
Well, according to me, it could, as explained below.

>Usually, this is not a
>problem, because the call just waits until bundle B finishes starting.
>But in this case, a deadlock occurs, because bundle B won't finish until
>bundle A instantiates that class, and A won't instantiate that class
>until bundle B finishes. 
>
>
>I think it has to do with the fact that while a bundle is STARTING  it
>is not RESOLVED nor INSTALLED, and therefore no classes can be exported.
>Am I right?
>  
>
The sequence is INSTALLED, RESOLVED then STARTING. If you take as an 
example the case of a library bundle, just being INSTALLED is enough to 
export packages, so bundle A could access class C as soon as bundle B is 
installed.

>I mean, is this "my fault" in the sense that the spec states that the
>platform should act in this way, or is it a bug?
>  
>
I am just wondering why you are using RMI between bundles.
Besides, I miss deeper knowledge on how class C is shared.

Regards
Michel

[oscar-devel] Instantiation deadlock: A bug?

[Manuel S. P. <san...@di...>]

Hi 2 everybody!!

I've been squeezing my brains with a deadlock until I've finally found
out why it happened. The code is a bit hard to understand, so I'll
simplify it a bit. 

We 've got bundle A and B. Bundle B has got a class C, which he exports,
and bundle A imports it. 

Suppose A is already started. Now we start bundle B. In its activator,
it contacts bundle B via RMI and tells him to instantiate class C (by
reflection). The problem is that while bundle B is starting, bundle A
cannot instantiate classes exported by bundle B. Usually, this is not a
problem, because the call just waits until bundle B finishes starting.
But in this case, a deadlock occurs, because bundle B won't finish until
bundle A instantiates that class, and A won't instantiate that class
until bundle B finishes. 


I think it has to do with the fact that while a bundle is STARTING  it
is not RESOLVED nor INSTALLED, and therefore no classes can be exported.
Am I right?

I mean, is this "my fault" in the sense that the spec states that the
platform should act in this way, or is it a bug?


Thanks!!


Manuel Santillan

Re: Re: [oscar-devel] CLDC support

[Paramjeet S. <pa...@re...>]

Hi,=0A=0AThanks for ur response, currenlty we are studying fesibility to po=
rt OSCAR on aJile's aJ-100 java processor. The problem is aJ-100 supports C=
LDC runitme, I guess Oscar uses lot of user defined class loaders.Now I'm s=
tuck as to how to make this porting possible. =0A=0AWhere can I get more In=
fo on user defined class loaders & any workarounds to make this possible.=
=0A=0AHav a nice day=0A=0AParamjeet=0A=0A=0A=0A>Today's Topics:=0A>=0A>    =
1. Re: oscar-osgi-devel digest, Vol 1 #116 - 1 msg (Didier Donsez)=0A>    2=
. Re: CLDC support (Michel D'Hooge)=0A>    3. Re: CLDC support (Richard S. =
Hall)=0A>=0A>--__--__--=0A>=0A>Message: 1=0A>Date: Fri, 21 May 2004 09:37:1=
5 +0200=0A> From: Didier Donsez <did...@im...>=0A>To: oscar-osgi-d=
ev...@li...=0A>Subject: [oscar-devel] Re: oscar-osgi-devel d=
igest, Vol 1 #116 - 1 msg=0A>=0A>This main problem of J2ME/CLDC (Connected =
limited device configuration)=0A>is the KVM.=0A>The KVM does not support us=
er-defined class loader loaders such as the=0A>OSCAR class loader=0A>But so=
me VM (J9) proposes the J2ME/CLDC (Connected limited device=0A>configuratio=
n)=0A>and they supports user-defined class loaders=0A>=0A>Didier=0A>=0A>=0A=
>=0A>--__--__--=0A>=0A>Message: 2=0A>Date: Fri, 21 May 2004 11:33:45 +0200=
=0A> From: Michel D'Hooge <mic...@tr...>=0A>To: oscar-devel <o=
sca...@li...>=0A>Subject: Re: [oscar-devel] CLDC s=
upport=0A>=0A>Paramjeet Singh wrote:=0A>=0A> >=0A> >Hi Everybody,=0A> >=0A>=
 >I'm new to this forum and Oscar. Looks like Oscar is build on Jdk1.4. In =
my application I want to use Oscar on J2ME based CLDC (Connected limited de=
vice configuration). Is it possible to do this?=0A> >=0A> >=0A>I don't thin=
k that the limitations in CLDC (I didn't find the exact=0A>list) could prev=
ent you to use OSGi/Oscar. You need multiple class=0A>loaders but besides t=
his OSGi is quite "standard" in the classes it uses.=0A>=0A>I know it has b=
een used with Personal Java. You can look there:=0A>http://www-adele.imag.f=
r/~chomats/poscar/OSCAR_porting_on_PersonalJava.html=0A>Unfortunately, Osca=
r has quite changed since that time. I tried to adapt=0A>the changes to the=
 last version of Oscar, but I lacked of time and then=0A>I will wait for th=
e 1.0 release...=0A>=0A>Finally Richard wrote that he ran Oscar unchanged o=
n the experimental=0A>J2ME Personal Profile for the Sharp Zaurus...=0A>(I d=
on't know why but the May emails archive is not available on=0A>sourceforge=
, so I have no URL to provide)=0A>=0A>--=0A>Michel D'Hooge=0A>=0A>=0A>=0A>=
=0A>--__--__--=0A>=0A>Message: 3=0A>Date: Fri, 21 May 2004 11:48:48 +0200=
=0A> From: "Richard S. Hall" <he...@un...>=0A>To: oscar-devel <osc=
ar-...@li...>=0A>Subject: Re: [oscar-devel] CLDC sup=
port=0A>=0A>Michel D'Hooge wrote:=0A>=0A> > Finally Richard wrote that he r=
an Oscar unchanged on the experimental=0A> > J2ME Personal Profile for the =
Sharp Zaurus...=0A> > (I don't know why but the May emails archive is not a=
vailable on=0A> > sourceforge, so I have no URL to provide)=0A>=0A>=0A>This=
 is correct and was recently re-verified. I will make sure that the=0A>1.0.=
0 release also works on my Zaurus.=0A>=0A>NOTE: Not all of the example bund=
les work on Personal Profile, I am only=0A>talking about the core framework=
 and command shell bundles. Other=0A>bundles may or may not work.=0A>=0A>->=
 richard=0A>=0A>=0A>=0A>--__--__--=0A>=0A>_________________________________=
______________=0A>oscar-osgi-devel mailing list=0A>oscar-osgi-devel@lists.s=
ourceforge.net=0A>https://lists.sourceforge.net/lists/listinfo/oscar-osgi-d=
evel=0A>=0A>=0A>End of oscar-osgi-devel Digest=0A=0A=0A =A0=0A

Re: [oscar-devel] CLDC support

[Richard S. H. <he...@un...>]

Michel D'Hooge wrote:

> Finally Richard wrote that he ran Oscar unchanged on the experimental
> J2ME Personal Profile for the Sharp Zaurus...
> (I don't know why but the May emails archive is not available on
> sourceforge, so I have no URL to provide)


This is correct and was recently re-verified. I will make sure that the 
1.0.0 release also works on my Zaurus.

NOTE: Not all of the example bundles work on Personal Profile, I am only 
talking about the core framework and command shell bundles. Other 
bundles may or may not work.

-> richard

Re: [oscar-devel] CLDC support

[Michel D'H. <mic...@tr...>]

Paramjeet Singh wrote:

>  
>Hi Everybody,
>
>I'm new to this forum and Oscar. Looks like Oscar is build on Jdk1.4. In my application I want to use Oscar on J2ME based CLDC (Connected limited device configuration). Is it possible to do this? 
>  
>
I don't think that the limitations in CLDC (I didn't find the exact
list) could prevent you to use OSGi/Oscar. You need multiple class
loaders but besides this OSGi is quite "standard" in the classes it uses.

I know it has been used with Personal Java. You can look there:
http://www-adele.imag.fr/~chomats/poscar/OSCAR_porting_on_PersonalJava.html
Unfortunately, Oscar has quite changed since that time. I tried to adapt
the changes to the last version of Oscar, but I lacked of time and then
I will wait for the 1.0 release...

Finally Richard wrote that he ran Oscar unchanged on the experimental
J2ME Personal Profile for the Sharp Zaurus...
(I don't know why but the May emails archive is not available on
sourceforge, so I have no URL to provide)

-- 
Michel D'Hooge

[oscar-devel] Re: oscar-osgi-devel digest, Vol 1 #116 - 1 msg

[Didier D. <did...@im...>]

This main problem of J2ME/CLDC (Connected limited device configuration) 
is the KVM.
The KVM does not support user-defined class loader loaders such as the 
OSCAR class loader
But some VM (J9) proposes the J2ME/CLDC (Connected limited device 
configuration)
and they supports user-defined class loaders

Didier

[oscar-devel] CLDC support

[Paramjeet S. <pa...@re...>]

 =A0=0AHi Everybody,=0A=0AI'm new to this forum and Oscar. Looks like Oscar=
 is build on Jdk1.4. In my application I want to use Oscar on J2ME based CL=
DC (Connected limited device configuration). Is it possible to do this? =0A=
=0AWhat should be the approach to make this possible, as I'm terribly stuck=
. Any pointers in this direction would be really appreciated.=0A=0AHave a n=
ice day!!=0AParamjeet=20

[oscar-devel] Another Beta Release

[Richard S. H. <he...@un...>]

Okay, I wanted to get another beta release out the door because I am 
leaving for ten days and I didn't want you guys to think there was no 
progress being made!  :-)

I will be at a multiple conferences and will largely be out of email 
contact, so if someone posts a message to the mailing list, I hope that 
it can wait or others try to help out.

The new beta is "1.0.0beta5" and is available from the previous beta URL 
for all of those who requested to beta test. You can use the Oscar 
installer to download user and API documention...as always, please read 
the changes.

I hope this beta release represents the last major changes before the 
final release of 1.0.0. In particular, I have separated the example 
bundle and Oscar services from the "org.ungoverned.oscar" package 
hierarchy, put them under "org.ungoverned.osgi.bundle" and 
"org.ungoverned.osgi.service", respectively. The major impact here will 
be if you were using Oscar's services in your bundles, for example, if 
you were creating custom shell commands. If that is the case, you will 
need to modify your bundles to use the new service names.

In the end, I think this will be much better and more sustainable that 
the old approach. Now the Oscar package is purely for the OSGi framework 
implementation. Eventually, all bundles will be available via OBR and 
the bundle repository Web page. All bundles become separate projects 
into themselves, although I have crafted the build files so that they 
easily integrate into Oscar's build file (Ant 1.6 is now required)...I 
will document this more later. For now, you can access all bundles via 
OBR or the web. Web access is available here:

    http://oscar-osgi.sf.net/repo/

And for source here:

    http://oscar-osgi.sf.net/repo-src/

Regarding OBR, I have re-implemented most of it, although I didn't have 
time to implement the new "update" feature or "download source" feature, 
but it now use XML and has the new (and much improved) syntax. So, 
please check it out. I like it much better!

It is quite possible that some of the bundles might be broken due to the 
above mentioned package renaming...I have not tested them all 
thoroughly. Please let me know if you run into any problems.

I am really pleased with how the 1.0.0 release is shaping up.

I think that is everything I wanted to say, I hope that I didn't 
introduce any major bugs just before I leave for ten days, but I am sure 
I will find out when I get to check my email. :-)

Thanks. Have fun.

-> richard

Re: [oscar-devel] Re: oscar-osgi-devel digest, Vol 1 #113 - 1 msg

[Richard S. H. <he...@un...>]

Didier Donsez wrote:

>
> A additional syntax could use a LDAP filter
>
> obr install "Service Binder" 
> (&(bundle-version>=1.0.0)(!(bundle-state=alpha))(signature=*))


Interesting idea, but I think I will pass on that for the time being. :-)

Actually, the possibility of a "-filter" switch might not be bad, but 
for standard syntax it is probably overkill.

-> richard

[oscar-devel] Re: oscar-osgi-devel digest, Vol 1 #113 - 1 msg

[Didier D. <did...@im...>]

A additional syntax could use a LDAP filter

obr install "Service Binder" (&(bundle-version>=3D1.0.0)(!(bundle-state=3D=
alpha))(signature=3D*))



osc...@li... a =E9crit:

>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: Proposed OBR command syntax (Richard S. Hall)
>
>--__--__--
>
>Message: 1
>Date: Wed, 12 May 2004 19:59:14 +0200
>From: "Richard S. Hall" <he...@un...>
>To: oscar-devel <osc...@li...>
>Subject: Re: [oscar-devel] Proposed OBR command syntax
>
>Stephane Frenot wrote:
>
> =20
>
>>Yes, I already have such problems on my inner applications.
>>All bundle managing scheme (rpm, deb, ebuilds) map version to archive
>>names... obr should also do that. I think the earlier the better...
>>=20
>>
>>   =20
>>
>
>There are many issues here:
>
>   1. OBR is just intended to be simple.
>   2. OBR meta-data is exactly the bundle meta-data (modulo some additio=
ns).
>   3. Something that solved every problem would be great, but I don't
>      have the time to do it.
>
>Related to this, while working out at the gym, I began to start to think=
=20
>about the fact that OBR meta-data is simply bundle meta-data, thus this=20
>means that we must probably allow spaces in bundle name. OBR "bundle=20
>name" is just the manifest "Bundle-Name", which is intended to be a=20
>human readable string.
>
>And more to the point, we have to realize that what we are debating is=20
>the command-line syntax to the bundle repository service. If you use the=
=20
>new OBR panel for the GUI shell, then these issues sort of go away,=20
>because the user just clicks on the one they want. Thus, if there are=20
>(eventually) multiple versions, they can easily select the one they want=
=20
>with the GUI and afterwards Bundle-UpdateLocation is automatically used=20
>to update that installed branch.
>
>The [proposed] meta-data for the new OBR probably covers most of the=20
>scenarios and it doesn't seem like command-line syntax should dictate=20
>design.
>
>So, while syntax like...
>
>    obr install "Service Binder";1.2.0
>
>    or for non-space bundles:
>
>    obr install log;1.1.0
>
>...may seem a little verbose, is it really a problem?
>
>-> richard
>
>p.s. Most people do not really realize the fine level of decision making=
=20
>that goes into project management, huh?  :-)
>
>
>
>--__--__--
>
>_______________________________________________
>oscar-osgi-devel mailing list
>osc...@li...
>https://lists.sourceforge.net/lists/listinfo/oscar-osgi-devel
>
>
>End of oscar-osgi-devel Digest
>
> =20
>

--=20
---------------------------------------------------------
Didier DONSEZ
Laboratoire LSR, Institut Imag, Universite Joseph Fourier
Bat. C, 220 rue de la Chimie, Domaine Universitaire
BP 53, 38041 Grenoble Cedex 9, France
GPS : lat 45=B011'37"N, lon 05=B046'15"E
Tel : +33 4 76 63 55 49           Fax : +33 4 76 63 55 50
mailto:Did...@im...
URL: http://www-adele.imag.fr/~donsez
---------------------------------------------------------

Re: [oscar-devel] Proposed OBR command syntax

[Richard S. H. <he...@un...>]

Stephane Frenot wrote:

>Yes, I already have such problems on my inner applications.
>All bundle managing scheme (rpm, deb, ebuilds) map version to archive
>names... obr should also do that. I think the earlier the better...
>  
>

There are many issues here:

   1. OBR is just intended to be simple.
   2. OBR meta-data is exactly the bundle meta-data (modulo some additions).
   3. Something that solved every problem would be great, but I don't
      have the time to do it.

Related to this, while working out at the gym, I began to start to think 
about the fact that OBR meta-data is simply bundle meta-data, thus this 
means that we must probably allow spaces in bundle name. OBR "bundle 
name" is just the manifest "Bundle-Name", which is intended to be a 
human readable string.

And more to the point, we have to realize that what we are debating is 
the command-line syntax to the bundle repository service. If you use the 
new OBR panel for the GUI shell, then these issues sort of go away, 
because the user just clicks on the one they want. Thus, if there are 
(eventually) multiple versions, they can easily select the one they want 
with the GUI and afterwards Bundle-UpdateLocation is automatically used 
to update that installed branch.

The [proposed] meta-data for the new OBR probably covers most of the 
scenarios and it doesn't seem like command-line syntax should dictate 
design.

So, while syntax like...

    obr install "Service Binder";1.2.0

    or for non-space bundles:

    obr install log;1.1.0

...may seem a little verbose, is it really a problem?

-> richard

p.s. Most people do not really realize the fine level of decision making 
that goes into project management, huh?  :-)

Re: [oscar-devel] Proposed OBR command syntax

[Michel D'H. <mic...@tr...>]

Erik Wistrand wrote:

> Granted, this makes some bootstrapping sensitive to version changes, 

Well, not that much. If you compare to a debian installation (from a CD, 
let's say), you start with packages (OSGi=bundles) from the CD, and then 
you can upgrade through the network (Oscar=OBR). So unless you remove 
the initial bundles AND you want to start a new framework (by providing 
a different name when Oscar starts), it should be ok.

I think if we want to improve OBR, we need to consider what is used in 
other big projects in order not to reinvent the wheel and waste 
resources. It would be very nice to have something as powerful as the 
debian apt/dpkg tools. But who can afford to develop it? Maybe someone 
knows of something quite similar already in Java... in the jakarta world?

> PS. I also dislike spaces, but it's kind of hard to forbid them.

Well, it is just a bundle name for OBR... In debian (sorry, this is MY 
reference ;-) , you can't use space in package name and the underscore 
is reserved to separate the name from the version. So you can't even you 
it ;-)

Michel

Re: [oscar-devel] Proposed OBR command syntax

[Erik W. <er...@wi...>]

Stephane Frenot wrote:
> All bundle managing scheme (rpm, deb, ebuilds) map version to archive
> names... obr should also do that. I think the earlier the better...

I second that. I've got several request from developers needing version 
number on individual bundle files, just because they use an external 
repository for bundles (read: Maven). That's why the KF build system 
nowadays generates bundles on the form

  name-<version>.jar

where version is the exakt string as in the manifest attribute 
Bundle-Version.

Granted, this makes some bootstrapping sensitive to version changes, but 
you do catch the cases where APIs or important functionality actually 
change from one version to another. Even if obr names != bundle jar file 
names, I think it makes sense to handle the version number in both 
places to reduce errors.

/Erik W

PS. I also dislike spaces, but it's kind of hard to forbid them.

-- 
Erik Wistrand, wis...@kn...

Re: [oscar-devel] Proposed OBR command syntax

[Stephane F. <ste...@in...>]

On Wed, May 12, 2004 at 03:46:35PM +0200, Michel D'Hooge wrote:
> Richard S. Hall wrote:
>=20
> >> obr -start Logger_0.1
> >> obr -start Logger
> >
> We can use another character to identify version number (i.e. ; or : or=
=20
> whatever sounds nice).
>=20
> >I don't really like to encode additional information into the name,=20
> >since we have a separate version attribute. Perhaps in the future when=
=20
> >the bundle repository has multiple versions we make this a parameter=20
> >that can be passed in or we require the bundles to have different=20
> >names, like "Log" and "Log Devel".
It's a too simplified view of the problem. I have two examples:
- I have two identical bundles but they embedded two version of JMX (1.0 =
and 2.0).
- You send me two different versions of obr... Both are called obr, but
  interface methods signatures are differents, and it breaks only at run-=
time...

Of course I can name them differently, but it should be simpler to
manage that immediatly.
>=20
> I believe that Debian package naming policy is quite complete and well=20
> tested. But we are not that far that we need such a naming tool...
Yes, I already have such problems on my inner applications.
All bundle managing scheme (rpm, deb, ebuilds) map version to archive
names... obr should also do that. I think the earlier the better...

/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
-----------------------------------------------------------------