On 19 avr. 2011, at 03:11, Emmanuel Lecharny wrote: > Hi guys, > > yesterday we tried to deal with some existing issues related to the way we > use OSGi. There are a few that need to be improved or discussed. Here is a > brain dump about those things. > > 1) Currently, we have two modes. The first one is when the API is loaded into > an OSGi enabled application, and the secodn one is when we use the API in an > application which is not using an OSGi container. > > In the second case, we use the StandaloneLdapCodecService to initialize > Felix, if it's not already done otherwie we just do nothing. > > Beside the name (why is it a CodecService ? Because it just deal with the > codec atm, but at some point we will also load schema elements, so we need to > find a better name), one of the main issue is that the bundles are loaded > only when they are put into a directory. > > In shared, it's not an issue, but when we use an application which does not > have an OSGi container started, then we have to copy the bundles that are not > loaded by default into a special directory. I suggest we keep this mode, but > that we also propose a mode in which the list of bundles to load is provided, > with their path, so we won't have to copy the bundles.
+1 but we'll have to see if it possible with Felix to link multiple locations or if a common single-folder location is absolutely mandatory. I don't know about that. > 2) We have a list of packages to load in the StandaloneLdapCodecService > class. If we move, or rename, one of those package, we will get an error. > Plus we will have to remember to update this list if we add some new classes. > > A TODO says that this list has to be generated from the Manifest. Yep. Let's > do that ! +1, I'll try to help in that area. > 3) we have some issues in Eclipse, as we have to set some property in the > command line when running some of the tests. This is not convenient at all, > but unless we find a simple way to do it automatically, we are quite dead. I > would suggest as a bare minimum that we document this in the development > guide. To be more precise, a few system variables need to be appended to the VM arguments of a launch configuration in Eclipse. Here is an example: > -Dcodec.plugin.directory=/Users/pajbam/Development/Apache/trunks/shared/integ/target/pluginDirectory > -Dfelix.cache.rootdir=/Users/pajbam/Development/Apache/trunks/shared/integ/target > -Dfelix.cache.locking=true > -Dorg.osgi.framework.storage.clean=onFirstInit > -Dorg.osgi.framework.storage=osgi-cache Note: I'm not sure all of them are really mandatory. It would be cool to find a way to add this automatically whenever a new launch configuration is created (if that is possible). > 4) We have to start thinking about transforming ApacheDS to be OSGi enbled. > Not having done this job makes things more difficult. We wll have to do it > anyway, the question is : why wasting time trying to workaround the issues we > have, instead of spending this time to do the job completely ? That's a tough work but I guess it would also bring us some benefits. The OSGI-fication of Shared was just a first step... > I would like to get a API 1.0.0-M3 out asap now. A lot of work has been done > since 1.0.0-M2, and before moving to the next step, I think it would be a > good idea to cut a new milestone. Sounds good to me. With the upcoming documentation on the API, we could even start to advertise about it on the MLs. > There is one more thing I think we should provide asap : a Apacheds-2.0.0-M1. > Many users are now complaining about the 1.5.7 bugs, and we have no way to > get them happy, bt telling them to patch the code themselves, something which > is frankly tedious. > This 2.0.0-M1 is not a feature not a code freeze, it's just a clear signal > that we now are ready to move toward to 2.0.0. The configuration has been > completely reviewed, it will depend on the 1.0.0 API, and many bugs have been > fixed. Sounds good to me too. At least it brings a better signal for users. Even if it nowhere near a RC or final version, users can get their hands on some new stuff and see we've not been twiddling our thumbs. > I have no idea about how much time we will have to spend on 2.0.0 before > being able to announce a RC1, but at some point, it's a bit frustrating to > keep going at the current pace. What has been done since January on the API > has been just great. 3 releases have been delivered (I'm including 1.0.0-M3), > with a lot of cleanup, some big features addition, and it was a pleasure to > see things moving that fast. Lets follow the same path for ADS ! Agreed. As soon as a first version of ApacheDS is released we could also follow the same path for Studio (in addition to the proposed 1.5.4 bug fix release of the "stable but old" branch). Regards, Pierre-Arnaud > > Thanks ! > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
