oscar-osgi-devel — Discussion of Oscar development issues

Re: [oscar-devel] Filter strings

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

Rob Walker wrote:

> Seems to be my day for logging suggestions.


I guess so.  :^)

> Whilst using an OSGi 2.0 bundle, I came across a problem with filter 
> strings whose item names have a "." in them e.g. "service.pid".
>
> I used the following fix, which seems to work:
>
> *public* *class* Parser {
> ...
>  ///FIXME-05 - allow "." in item names in filter strings / *public* * static* 
> *final* String KEYCHARS * =* ".abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"; 


Sounds good, I will include the fix. I didn't write the LDAP parser 
stuff, so I am glad that at least one of us understands it.  :^)

> BTW - I seem to be "noisy" on this list today. If there's a more 
> appropriate way to log suggestions, let me know.


Heck, it's the developer list, so it seems like we should be able to 
discuss these issues on it; these issues are legitimate development 
issues as opposed to user issues.

I didn't see your email address on the developer mailing list though...  :^)

-> richard

Re: [oscar-devel] getDataFile and StorageNode

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

Rob Walker wrote:

>One more suggestion that came to me while looking at 
>implementing getDataFile().
>
>I believe I'm right in saying that File objects can represent either 
>directories or files. So maybe getFile() should either be defined at 
>the StorageNode level, or also included in the StorageDirectory sub-
>interface.
>

You are correct, but I think it is a moot point now. I have essentially 
decided to scrap all of the StorageSystem stuff from Oscar at some point 
in the future. The original goal of the StorageSystem was to eliminate 
the implicit dependency on an actual file system, but because OSGi 
exposes the getDataFile() method, this is not really possible. Further, 
System.loadLibrary() also uses a file (well, a path to a file) from the 
ClassLoader. As a result of these types of dependencies, it is not 
possible to eliminate the file system requirement.

To add insult to injury, the performance hit for this change was 
significant since JarFile requires a File, thus I had to stop using 
JarFile and use JarInputStream instead...this made scanning JAR files 
really slow.

I think I will go with a two-level approach, a local cache (i.e., the 
file system) and an optional remote backing store. In this approach, if 
Oscar is supplied with a remote backing store, then it would be used as 
the main persistent backing store and the local file system really would 
be a cache. If no remote backing store is supplied, then Oscar will only 
use the local cache.

No timeframe on this, but I would hope to include it in the next major 
release...

-> richard

[oscar-devel] Filter strings

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

<color><param>0100,0100,0100</param>Seems to be my day for logging suggestions. Whilst using an OSGi 2.0 bundle, I came across a 
problem with filter strings whose item names have a "." in them e.g. "service.pid".


I used the following fix, which seems to work:


<paraindent><param>left</param><bold><color><param>0000,0000,8000</param><FontFamily><param>Fixedsys</param><smaller>public</bold></color> <bold><color><param>0000,0000,8000</param>class</bold></color> Parser
<color><param>0000,8000,8000</param>{</paraindent>

<paraindent><param>left</param>	...</paraindent>

<paraindent><param>left</param></color>
    <italic><color><param>0000,8000,0000</param>//FIXME-05 - allow "." in item names in filter strings
</italic></color>    <bold><color><param>0000,0000,8000</param>public</bold></color> <bold><color><param>0000,0000,8000</param>static</bold></color> <bold><color><param>0000,0000,8000</param>final</bold></color> String KEYCHARS <bold><color><param>0000,0000,FF00</param>=</bold></color>
        <color><param>8000,0000,0000</param>".abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"</color>;



<color><param>0100,0100,0100</param><FontFamily><param>Arial</param><bigger>Note, there may be other legal "special chars" which I haven't covered.


BTW - I seem to be "noisy" on this list today. If there's a more appropriate way to log 
suggestions, let me know.


Regards


-- Rob

<nofill>
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
 
+44 (20) 7488 3470
www.softsell.com
ro...@so...

[oscar-devel] getDataFile and StorageNode

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

One more suggestion that came to me while looking at 
implementing getDataFile().

I believe I'm right in saying that File objects can represent either 
directories or files. So maybe getFile() should either be defined at 
the StorageNode level, or also included in the StorageDirectory sub-
interface.

Reason I came across this was I wanted Oscar and BundleCache 
to only deal with Storage* objects as per your other code. 
BundleContext could then just do a getFile on the object returned to 
perform the necessary mapping. Problem is that getDataFile can 
return a reference to the bundle root dir if "" is supplied as the 
filename, which means I couldn't just hand a StorageNode around 
everywhere else.

-- Rob

SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
 
+44 (20) 7488 3470
www.softsell.com
ro...@so...

Re: [oscar-devel] Resolving org.osgi.framework

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

Rob Walker wrote:

> Just an FYI.
>
> This is a "quick hack", but it's helping me make progress using OSGi 
> 2.0 compliant bundles, which have an Import-Package of 
> org.osgi.framework that is supposed to be resolved by the system bundle:
>
> Amendment to SystemBundle constructor:


Thanks for the input.  I am in the process of uploading a new minor 
update for Oscar and your modification will be included...this aspect of 
the 2.0 spec still needs some thought on my part.

-> richard

[oscar-devel] Resolving org.osgi.framework

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

<color><param>0100,0100,0100</param>Just an FYI.


This is a "quick hack", but it's helping me make progress using OSGi 2.0 compliant bundles, 
which have an Import-Package of org.osgi.framework that is supposed to be resolved by the 
system bundle:


	Amendment to SystemBundle constructor:


</color><FontFamily><param>Fixedsys</param><smaller>    <bold><color><param>0000,0000,8000</param>protected</bold></color> <bold>SystemBundle</bold>(Oscar oscar, <bold><color><param>0000,0000,8000</param>long</bold></color> id, ArrayList activatorList)
        <bold><color><param>0000,0000,8000</param>throws</bold></color> BundleException
    <color><param>0000,8000,8000</param>{</color>
        <bold><color><param>0000,0000,8000</param>super</bold></color>(oscar, <bold><color><param>0000,0000,8000</param>null</bold></color>, id, <color><param>8000,0000,0000</param>"System Bundle"</color>);
        <bold><color><param>0000,0000,8000</param>this</bold></color>.m_oscar <bold><color><param>0000,0000,FF00</param>=</bold></color> oscar;
        <bold><color><param>0000,0000,8000</param>this</bold></color>.m_activatorList <bold><color><param>0000,0000,FF00</param>=</bold></color> activatorList;

        <italic><color><param>0000,8000,0000</param>//FIXME-02: hack to resolve osgi.org.framework
</italic></color>        <italic><color><param>0000,8000,0000</param>//          (not sure if we should also set m_classloader to ensure
</italic></color>        <italic><color><param>0000,8000,0000</param>//           the resolve actually works!)
</italic></color>        PackageDeclaration pkg <bold><color><param>0000,0000,FF00</param>=</bold></color> <bold><color><param>0000,0000,8000</param>new</bold></color> <bold>PackageDeclaration </bold>(m_oscar, 
                <color><param>8000,0000,0000</param>"org.osgi.framework"</color>, <bold><color><param>0000,0000,8000</param>new</bold></color> <bold><color><param>0000,0000,8000</param>int</bold></color>[] <color><param>0000,8000,8000</param>{</color> <color><param>8000,8000,0000</param>1</color>, <color><param>8000,8000,0000</param>0</color>, <color><param>8000,8000,0000</param>0</color> <color><param>0000,8000,8000</param>}</color>, <bold><color><param>0000,0000,8000</param>this</bold></color>);
        m_oscar.<bold>registerExport</bold>(pkg);
    <color><param>0000,8000,8000</param>}</color>



<color><param>0100,0100,0100</param><FontFamily><param>Arial</param><bigger>I'll try and do a better thought thru amendment for this down the road if I get time.


-- Rob 


<nofill>
SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
 
+44 (20) 7488 3470
www.softsell.com
ro...@so...

Re: [oscar-devel] Quiz question on Exceptions - CANCEL

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

Rob Walker wrote:

>Cancel that (and yep, I also hate people who answer their own 
>questions!). So -ve marks to me today. If I'd looked further I would 
>have noticed that the missing exceptions were unchecked ones.
>

I was just going to write a message to tell you that...  :^)

-> richard

[oscar-devel] Quiz question on Exceptions - CANCEL

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

Cancel that (and yep, I also hate people who answer their own 
questions!). So -ve marks to me today. If I'd looked further I would 
have noticed that the missing exceptions were unchecked ones.
-- Rob

------- Forwarded message follows -------
From:           	Rob Walker <ro...@so...>
To:             	osc...@li...
Subject:        	Quiz question on Exceptions
Date sent:      	Thu, 3 Jan 2002 10:48:51 -0000

I noticed that several of the Oscar interface methods for various 
Framework api's don't throw the full set of Exceptions (specifically 
security ones, which Oscar documents as not implemented yet).

This left me a little confused, because external bundles e.g. JES 
ones seem to run fine. My guess was that callers to these methods 
(e.g. BundleContext.getService) would have been coded to catch 
the exceptions, and would be unconcerned with the fact that the 
OSCAR signatures don't actually throw them. Can anyone confirm 
or clarify this?

This also brings up a question when writing my own bundles. If this 
is the case, then presumably I should code for and catch all the 
exceptions (possibly also testing under JES), to ensure I don't have 
problems when moving outside of Oscar to another OSGi 
implementations.

Or am I totally off track here?

Regards

-- Rob
------- End of forwarded message -------

SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
 
+44 (20) 7488 3470
www.softsell.com
ro...@so...

[oscar-devel] Quiz question on Exceptions

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

I noticed that several of the Oscar interface methods for various 
Framework api's don't throw the full set of Exceptions (specifically 
security ones, which Oscar documents as not implemented yet).

This left me a little confused, because external bundles e.g. JES 
ones seem to run fine. My guess was that callers to these methods 
(e.g. BundleContext.getService) would have been coded to catch 
the exceptions, and would be unconcerned with the fact that the 
OSCAR signatures don't actually throw them. Can anyone confirm 
or clarify this?

This also brings up a question when writing my own bundles. If this 
is the case, then presumably I should code for and catch all the 
exceptions (possibly also testing under JES), to ensure I don't have 
problems when moving outside of Oscar to another OSGi 
implementations.

Or am I totally off track here?

Regards

-- Rob

SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
 
+44 (20) 7488 3470
www.softsell.com
ro...@so...

Re: [oscar-devel] OSGI log service

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

Rob Walker wrote:

>Can anyone help me see the light here before I abandon the OSGi 
>Log Service in favour of our own approach?
>

I don't think anyone would argue that the LogService is the best logging 
facility around.  :^)

 From what I understand, the LogService is largely for reporting error 
conditions and to some degree is more of a transient logger, for 
example, it might only keep the last 500 log messages. After that, an 
implementation could persist log messages to a text file or something, 
but that is unspecified.

You are correct, though, that if you tried to persist a LogEntry object, 
then you might end up with a situation where the bundle in the entry no 
longer exists. I doubt the LogService was intended to persistently log 
entries, but in such a scenario you could return null.

I would actually implement the service such that it logged all messages 
to a text file and only kept some configurable number of entries in 
memory. You could then create an applet that allowed you to view the 
text file.

If you want to keep your logging facility, you can easily create an 
extended logging service that has whatever features you want and have it 
also provide a simplified LogService interface too (i.e., merge the 
two), then bundles that don't know about your extensions can use the 
simplified LogService interface and knowledgable bundles can use your 
extended interface. If you actually extend the LogService interface, you 
can just register your service with two "objectClass" properties for 
both interfaces and it would automatically work.

Well, those are my thoughts on the subject...  :^)

-> richard

[oscar-devel] OSGI log service

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

Our app. has a modular framework which we're looking to replace 
with an Oscar/OSGi based one.

We've got quite a nice existing log service based on Log4J which I 
was looking at how best to include in OSGi. One thing I looked at 
was whether we could use the defined OSGi standard log service. 
Not as rich as Log4J, but has the benefit of being standardised.

And I noticed the following:

* The public interface to LogEntry has the following public method 
[p123 of OSGI spec 2.0]:

	public Bundle getBundle()

Now I could be getting confused here, but this seems to indicate 
that any reader of a log service can get references to the Bundle 
which logged it. 

Under the contract for Bundle is the following statement:

* Once the uninstall() method of a Bundle returnst the environment 
must be the same as if bundle had never been installed. [p28 of 
OSGI spec 2.0]

So what happens if the log is large or long running, or even persists 
to disc permanently? To me it seems that if the Bundle which 
originated the LogEntry gets unsinstalled before the logEntry is 
accessed by a reader we'd have a pretty serious problem. Either 
we'd have references lying around to uninstalled Bundles which 
violates the uninstall contract (and probably stuffs up garbage 
collection also). Or we'd need to invalidate all the log entries 
produced by a bundle, which doesn't make sense either.

Can anyone help me see the light here before I abandon the OSGi 
Log Service in favour of our own approach?

Regards

-- Rob Walker 



SoftSell Business Systems, Ltd.
' testing solutions for a changing world '
 
+44 (20) 7488 3470
www.softsell.com
ro...@so...

Re: [oscar-devel] Service Tracker

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

Yann SECQ wrote:

> Why do you say that ServiceTraker doesn't define any methods ? There are
> a lot : open(), close(), getService() ... and the methods inherited from
> the ServiceTrackerCustomizer interface. Do I miss something ? 


Sorry, I wasn't clear.  Yes, it defines method signatures, but it 
provides no implementation.  In other words, they have created an 
interface using a class instead of an interface.

> Concerning the implementation, I don't see any other way to do it. 
> It's sad like you say below that they didn't provide some factory to 
> create
> those objects :-( 


So, it sounds like we are in agreement.

> I don't see any other solution. If we wan't to keep compatibility
> with other containers, it seems that the ServiceTracker class has to
> be implemented in their namespace !


Sometimes I wonder how they reach their conclusions...

Okay, that's what I will do.

Thanks.

-> richard

Re: [oscar-devel] Service Tracker

[Yann S. <Yan...@li...>]

Richard S. Hall wrote:

> I have started to implement the Service Tracker for Oscar.
> I have completed the Filter class, but I wanted to get some quick input 
> from anyone who has read the Service Tracker portion of the 2.0 
> specification.


Hi Richard,

 
> ServiceTracker is a class, but it doesn't have any defined methods nor 
> is it defined as abstract.  The implication is that I should provide an 
> implementation for it directly in the org.osgi.util.tracker package, but 
> this is not specifically stated.  Is that how anyone else interprets it?


Why do you say that ServiceTraker doesn't define any methods ? There are
a lot : open(), close(), getService() ... and the methods inherited from
the ServiceTrackerCustomizer interface. Do I miss something ?

Concerning the implementation, I don't see any other way to do it. It's 
sad like you say below that they didn't provide some factory to create
those objects :-(

> Seems strange if you ask me, but I guess they chose to do it that way so 
> that they could have a standard way to create a ServiceTracker object, 
> but I don't understand why they just didn't use a factory method on 
> BundleContext like they did for creating Filter objects with 
> BundleContext.createFilter().


Totally agree on that point.

 
> So if there is agreement that I should implement it in their package, 
> then I will...

I don't see any other solution. If we wan't to keep compatibility
with other containers, it seems that the ServiceTracker class has to
be implemented in their namespace !

Cheers, yann.

-- 
  / Yann SECQ            Equipe SMAC           se...@li... \
| Multi-Agent Systems Modeling & Agent Oriented Programming |
  \ http://www.lifl.fr/SMAC        http://www.lifl.fr/~secq /

[oscar-devel] Service Tracker

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

I have started to implement the Service Tracker for Oscar.

I have completed the Filter class, but I wanted to get some quick input 
from anyone who has read the Service Tracker portion of the 2.0 
specification.

ServiceTracker is a class, but it doesn't have any defined methods nor 
is it defined as abstract.  The implication is that I should provide an 
implementation for it directly in the org.osgi.util.tracker package, but 
this is not specifically stated.  Is that how anyone else interprets it?

Seems strange if you ask me, but I guess they chose to do it that way so 
that they could have a standard way to create a ServiceTracker object, 
but I don't understand why they just didn't use a factory method on 
BundleContext like they did for creating Filter objects with 
BundleContext.createFilter().

So if there is agreement that I should implement it in their package, 
then I will...

-> richard

[oscar-devel] Oscar pre-release test

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

Hello all,

I am currently on a research trip, but I have the next Oscar release 
almost complete.  I will be unable to update sourceforge until I return 
to Berlin next week, but I wanted to get some volunteers to test the 
next release before I post it to sourceforge anyway.

If anyone has the time and the desire to try out the pre-release, please 
send me email and then I will email the pre-release package to you.

Thanks.

-> richard

[oscar-devel] Update

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

I just wanted to give everyone an update on the status of the next Oscar 
release.

I have been anticipating that Oscar was in need of some redesign work to 
simplify the concurrency control aspects of the current design (the 
current design has really fine-grained control), but I was going to push 
this off until the next-next release.

I originally intended this upcoming release to simply include the 
PackageAdmin service, but after working on it I realized that it was 
becoming too much of a hacked in solution for my liking.  Specifically, 
the refreshPackages() operations as defined in OSGi 2.0 is a 
multi-bundle operation, but the current Oscar was not designed with 
multi-bundle operations in mind -- it has really fine-grained access to 
bundles (e.g., three threads can be in a single bundle at one time). 
 This turns out to be difficult to manage.  :^)

At any rate, I decided that I could not put off the redesign effort.  I 
spent Thursday/Friday working on the redesign and got everything back up 
and running with a (hopefully) better concurrency scheme.  And yesterday 
I performed the first successful test of updating a bundle and 
refreshing using PackageAdmin service.

There are still some kinks to work out in both the new design and the 
PackageAdmin service, but I expect to have a release of some sort next 
week (if only a beta release for some extended testing of the new 
implementation by everyone).

-> richard

Re: [oscar-devel] Test framework...

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

Marcel Offermans wrote:

>I am currently developing a more complete implementation of the
>HttpService and I was wondering if anybody has some kind of test
>framework so I can verify it.
>

I tend to use the JES bundles as tests, such as the JES management 
panel, but nothing more formal than that at this point.

-> richard

p.s.  You didn't say if you wanted me to take a look at your driver issue...

Re: [oscar-devel] Test framework...

[Yann S. <Yan...@li...>]

Marcel Offermans wrote:

> I am currently developing a more complete implementation of the
> HttpService and I was wondering if anybody has some kind of test
> framework so I can verify it.

Hi, this is an important problem. For the moment I don't think
that there is such a framework. I was thinking about writing
some adapters to be able to use jUnit (www.junit.org) to ease
the development of regression tests, but I haven't start yet.

One solution (and I know this one won't be the best for you :) could
be that bundle developpers do their own testing. But, as with
others projects like Classpath, it would be nice to have some
regression tests.

Cheers, yann.

PS: Which HTTP server are you embedding ? Tomcat, Jetty ?

-- 
  / Yann SECQ            Equipe SMAC           se...@li... \
| Multi-Agent Systems Modeling & Agent Oriented Programming |
  \ http://www.lifl.fr/SMAC        http://www.lifl.fr/~secq /

[oscar-devel] Test framework...

[Marcel O. <mar...@es...>]

I am currently developing a more complete implementation of the
HttpService and I was wondering if anybody has some kind of test
framework so I can verify it.

Re: [oscar-devel] Resolving/exporting packages

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

Richard S. Hall wrote:

> One approach, which would be simpler than creating the graph from 
> above, would be eager resolving of bundles.  In this approach Oscar 
> would look at non-resolved bundles as well as resolved bundles when 
> looking for an export package.  When Oscar found the best export 
> package, it would first resolve the bundle if necessary, then use the 
> best export package to resolve the package dependencies.
>
> This approach, still does not help the ad-hoc situation, though.  Do 
> we just say "tough luck" to the ad-hoc case?


So, after I wrote this, I realized that this approach DOES address the 
ad-hoc situation of which I was thinking; if a user installed (but not 
started) a bunch of bundles, this approach would allow him to start them 
in any arbitrary order and everything would be fine.  That's what 
happens when I post before thinking...

So this is the approach I will use.  The only other issue I can think of 
is that when you try to eagerly resolve a bundle, it may not be 
resolvable, so then Oscar would have to try to resolve the next best 
bundle that offers the package.  This could lead to some confusion if 
someone wasn't expecting it, but it is the only thing that makes sense.

-> richard

[oscar-devel] Resolving/exporting packages

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

So, I have been updating how Oscar handles exporting packages in 
preparation for bundle updates and the new PackageAdmin service.

A few messages ago, there was some discussion about how OSGi now 
specifically says that exported packages are available only after a 
bundle has been "resolved."

OSGi also says that a bundle may be resolved at the discretion of the 
implementation; up until now, Oscar delayed resolving until the bundle 
was started.  Conceptually, there is a connection between resolving a 
bundle and resolving a package; what I mean by this, is that the 
framework must guarantee that the same package is used for all bundles, 
even if many bundles export the same package, but the framework can only 
use the packages of bundles that have been resolved (per the spec). 
 Thus, in order to resolve a package, the bundle must be resolved.

This has some implications, such as, a bundle may not be resolvable 
because bundles that it depends on have not yet been resolved (as was 
mentioned in the previous message).  Or worse, a bundle might not be 
resolvable depending on the order in which other bundles are resolved; 
this might happen because the framework has to make a commitment to 
"one" package version and it can only choose from the bundles that have 
been resolved so far, it cannot use ones (with higher versions, for 
example) that have not been resolved.

Of course, it is possible to deal with this issue during the framework 
start-up by essentially creating a complete graph of bundle/package 
relationships and then resolving them in the correct order so that the 
bundle with the highest package version is always resolved before the 
framework needs it.  This does not, however, address the more ad-hoc 
situation where the user (or a bundle) is installing bundles and doesn't 
fully realize the underlying dependencies.

Considering that OSGi advocates including copies of packages with your 
bundles, it is very likely that multiple bundles will offer the same 
package with potentially different versions.

So, any ideas for a simple, elegant solution to this situation?

One approach, which would be simpler than creating the graph from above, 
would be eager resolving of bundles.  In this approach Oscar would look 
at non-resolved bundles as well as resolved bundles when looking for an 
export package.  When Oscar found the best export package, it would 
first resolve the bundle if necessary, then use the best export package 
to resolve the package dependencies.

This approach, still does not help the ad-hoc situation, though.  Do we 
just say "tough luck" to the ad-hoc case?

-> richard

Re: [oscar-devel] OSGi 2.0 Spec Released

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

Yann SECQ wrote:

> Ok, you're right. I made a confusion between the notion of profile as
> you define it and the notion of user. 


I removed the word "user" from the next release...

> One way to reach more users would be to make an annoucement on
> Freshmeat, when the new release will be ready :)


We'll see...if we think it's good enough...

-> richard

Re: [oscar-devel] Gatespace Releases GDSP 3.1

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

Yann SECQ wrote:

> The first OSGi 2.0 compliant framework ? 


I was under the impression that Gatespace was responsible for making the 
reference implementation of the framework for OSGi, so it makes sense 
that they would be first.  :^)

-> richard

Re: [oscar-devel] OSGi 2.0 Spec Released

[Yann S. <Yan...@li...>]

Richard S. Hall wrote:

> Make sense.  I was thinking about looking at the ServiceTracker service 
> after the next release (which should include the PackageAdmin service).


You'll find in attachment the interfaces, I have not start the
implementation yet.


> This is actually where we disagree.  The container doesn't need access 
> to the file system, it needs access to some sort of storage system that 
> will give it access to its previously saved state.  I call this 
> previously saved state a profile and a container must have a profile 
> (i.e., saved state) otherwise it would not know what to load.

 > [....]
 > I agree that we need some different mechanism for user management.
 > Don't get confused with the profile stuff, that really doesn't have
 > anything to do with "users" per se.  One user could start a dozen
 > Oscars each with its own profile...

Ok, you're right. I made a confusion between the notion of profile as
you define it and the notion of user.


> More generic than what?  Oscar currently allows you to populate the 
> container with a config file...I think that this is just as generic.  :^)
> But this doesn't really have anything to do with the profile stuff, 
> correct?  Profiles are persisted state and how container state is 
> handled is pretty clearly defined by the spec.


One point for you. I was induced in error with the notion of
user/profile.


> Thanks for the input...for now it's just you and i...  ;^)

One way to reach more users would be to make an annoucement on
Freshmeat, when the new release will be ready :)

Cheers, yann.

-- 
  / Yann SECQ            Equipe SMAC           se...@li... \
| Multi-Agent Systems Modeling & Agent Oriented Programming |
  \ http://www.lifl.fr/SMAC        http://www.lifl.fr/~secq /

[oscar-devel] Gatespace Releases GDSP 3.1

[Yann S. <Yan...@li...>]

The first OSGi 2.0 compliant framework ?

-- 
  / Yann SECQ            Equipe SMAC           se...@li... \
| Multi-Agent Systems Modeling & Agent Oriented Programming |
  \ http://www.lifl.fr/SMAC        http://www.lifl.fr/~secq /