Kelvin, in our sdo implementation (see TUSCANY-1527 and TUSCANY-1493) we do actively support OSGi. We had similar issues, in our case where the data factory instantiates new instances of data object classes. As these data object classes (model classes) can be user-defined and as such reside in any OSGi bundle, we ran into trouble with the OSGi class loaders. We then developed a solution that works both with and without osgi. Doing so, we tried to have as little as possible code that depends on OSGi.
Have a look at the SDOActivator class to get started. Bert "kelvin goodson" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 21/11/2007 12:49 Please respond to [email protected] To [email protected] cc Subject Re: [Java SDO] What should we be attacking? Rajini, Many thanks for your offer of help here!. We don't have documentation on this, but I hope as a community we can develop it. I have created a page in the wiki to begin organising our thoughts [0]. My problem is I don't have sufficient feel for the issues in OSGi to understand how best to approach documenting SDO's class loader usage. I imagine it's a reasonable assumption that the only place where we could violate constraints imposed by working in an OSGi environment would be the places where SDO touches the ClassLoader interface. I'll put some words around what seems to be happening in each of those places in the SDO code. We only have 3 relevant places where the ClassLoader interface is imported in the SDO code (+1 test case which may add to our understanding) DefaultHelperContextImpl [1] XSDHelperImpl [2] DataObjectUtil [3] ByteCodeInterfaceGeneratorTestCase [4] (Note: I'm part way through my investigation here, but in the interests of responding in a timely manner and paving the way for people to chip in and save me the trouble of researching the issues, I'm going to post this without having completed the researches, and then continue to research it) ...... more to investigate ... The ClassLoader code that is currently in DataObjectUtil (which originates from Tuscany-1110 and was originally in TypeHelperImpl). It is there to support the retrieval of the SDO type represented by a generated Java interface/class, and this is performed by introspection of the supplied interface/class. Kelvin. [0] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Documentation+in+Preparation [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/helper/DefaultHelperContextImpl.java [2] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/helper/XSDHelperImpl.java [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/util/DataObjectUtil.java [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/test/java/org/apache/tuscany/sdo/codegen/BytecodeInterfaceGeneratorTestCase.java On 21/11/2007, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > Kelvin, > > I ran into the same NPE as TUSCANY-1293 yesterday when running Tuscany SCA > under OSGi. I would be very keen to see this fixed so that SCA > databinding-sdo can be used under OSGi. I will be happy to help with the > classloading/OSGi issues, but I have no understanding of the architecture of > SDO. If there is some documentation on the classloading architecture for > SDO, I can take a look. > > The classloading hierarchy that is causing the problem in SDO is the same as > the one we had with SCA, but unless I understand the classloading in SDO, I > can't be sure if we can adopt a similar solution as the one used now in SCA. > > > Thank you... > > Regards, > > Rajini > > > On 11/20/07, kelvin goodson <[EMAIL PROTECTED]> wrote: > > > > What should we be concentrating our efforts on in SDO Java. I posted > > a while back to suggest we think about the content of a next release. > > We've had a few fixes go in recently, but I'd like to see more > > consideration of release content before we crank the handle. It would > > be great to see a balance of new features and bug fixes. > > > > > > For my part I want to get back to ... > > TUSCANY-1527 Allow for custom data binding of DataObjects in a Swing UI > > TUSCANY-1493 Snapshot mapping framework to convert DataObjects to and > > from Java objects > > as soon as I can. And I believe that at least 1527 can move beyond > > proof of concept in my sandbox, and become part of the trunk. > > > > I've been taking a pass through the SDO java JIRA backlog, and seeing > > from my perspective what's simple / tricky / big / high priority etc, > > etc. Of course simplicity is in the eye of the beholder, for > > example, I don't view the OSGi topic as simple as I don't have > > experience there, but someone out there may find it so; if so please > > speak up. The same goes for priority, etc. As you might imagine, in my > > estimation there are no simple high priority JIRAs left, but there > > are a few simple medium priority ones, or simple low priority ones > > that would be good to just get out of the way. > > > > These are .... > > > > Simple Starters > > =========== > > TUSCANY-1360 New SDOUtil: Getting the enumeration facet > > TUSCANY-1178 DynamicTypesFromSchemaTestCase expecting *Object types to > > be created > > TUSCANY-1263 XMLEqualityChecker too strict > > TUSCANY-1359 New SDOUtil: Upper and lower bound on properties where > > 'isMany' is true > > TUSCANY-1384 SequenceAddOpenTest.setUp() needs to check if type exists > > before creating it > > TUSCANY-1545 Change default XML encoding to "UTF-8". > > TUSCANY-1659 SDO DateConversion test cases fail under linux > > > > > > Particular Skills JIRAs > > ================= > > For anyone with JavaJet experience there's > > > > TUSCANY-1483 Static SDO generator: problem with elements named > > internal* > > which would be simple > > > > For someone with maven build experience there > > TUSCANY-257 recently added file Interface2JavaGenerator.java is not > > compatible with JDK 1.4 > > > > For someone with Grobu-Utils and maven skills there's ... > > TUSCANY-1182 Add multi-threaded test case for data object creation > > > > Someone with Axis2 skills > > TUSCANY-1038 SDO databinding for Axis2 > > (This may be better done within the Axis2 project) > > > > OSGi Skills > > TUSCANY-1293 SDO does not work with OSGi > > > > > > Biting off something a bit Bigger > > ======================== > > For somebody wanting something a bit bigger to take on there's > > > > TUSCANY-1192 Preserve demand created global properties > > TUSCANY-1361 New Util: Validation > > TUSCANY-1021 CopyHelper and EqualityHelper should handle ChangeSummary > > TUSCANY-1817 Improve SDO test infrastructure to re-use/re-execute most > > dynamic tests as static tests > > > > > > This isn't a full list, and I may post more soon. Please feel free to > > disagree with my assessment and speak up with your own priorities. > > Better still step forward to help fix something. I'd be only too > > pleased to help you understand what's required. > > > > Kelvin. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
