Could you have them retry using Felix 1.0.3? This might be related to some of the concurrency things we fixed.
In case they can not be bothered retrying on Felix 1.0.3 then maybe they can provide a minimal config file that only uses publicly available bundles and has this issue (then I can look into it). regards, Karl > Hi, > > I have been away for a while and don't really know if this has been looked at. > > The story can be found at [1], but goes roughly like this; > > The guy is starting a bunch of bundles on Felix, incl Pax Logging and Felix > Configuration Admin. > The Felix internals will find the LogService implementation and use it for its > own logging needs. > At the same time, the Configuration Admin gives Pax Logging a new > Configuration, which triggers loading of classes. > > Now, the StartLevel thread locks a o.a.f.module.ModuleFactoryImpl and blocks > on the o.a.log4j.spi.RootLogger. The Configuration thread will do the > opposite... > > The immediate question; Any good ideas on how to get around this? > The only one I can think of is to start a new thread and delay the > Configuration update() X milliseconds, but that sounds fairly britle. > > The larger question is more like; Isn't it necessary for the framework to be > lock-free when calling out to code outside its control?? > (that was something I concluded with my own similar framework back in 1999) > > > [1] http://issues.ops4j.org/jira/browse/PAXLOGGING-20 > > > Cheers > -- > Niclas Hedhman, Software Developer > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug > -- Karl Pauls [EMAIL PROTECTED]
