Quoting Niclas Hedhman <[EMAIL PROTECTED]>: > 1. In our (CodeDragons, now Jayway) opinion the support is "mediocre" at > best, and greater care need to be placed onto the bundlization of JPOX.
Elaborate a bit more what you mean by mediocre and greater care. > > 2. The reliance on the Eclipse Extension Point mechanism is in our opinion > unfortunate as well as unnecessary. > Hmm. Again, you may elaborate a lit bit more here, and give us some suggestions. Of course, we would like to be clean in regard of Eclipse dependencies. > 3. The Classloading strategy seems to cause problems. (can't recall the > details, but think we can dig it up) I've been using JPOX in OSGi environment for about 2 years now. During this time, I also had some bad experiences with ClassLoading. Two or Three months ago I entered a proposal to the JDO expert group to permit easier integration of OSGi and JDO. Recently, I have also proposed a new OSGi Service for the JDO standard to permit dynamic discovery of implementations. Both proposals were welcome and under discussion. JPOX has already been tuned to work better in OSGi environment, and JDO standard is on the way. > The end result of a couple of days of trying to rectifying the problems was > going back to our preferred commercial implementation. > JPOX is currently the only implementation with tigher OSGi integration. You probably mean here using JDO as libraries in the bundle classpath. > For JPOX to be truly successful in OSGi, I think we need to discuss the > use-cases, get rid of the unnecessary extension point support, preferably > introduce the white board pattern and clean up the meta data. I think we can > throw some additional cycles on it, but only if you guys are serious about > it. > Yes, please give us some food for discussion, because JPOX is a serious product, and we welcome your expertise.
