Re: [Java SDO] What should we be attacking?
Have a couple of question about release - What will be the name of the Java SDO release? After checking Java-SDO-Next and Java-SDO-CTS-Next from ASF-JIRA and referring to http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html I have tried to gather a list of all JIRAs (Fixed, Open,...) at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project Also, referring again to - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html, Below are in-progress JIRAs- TUSCANY-1360 TUSCANY-1483 TUSCANY-1293 Are there any other in-progress JIRAs? So we are left with below ones - Simple Starters === TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests Is anybody working on any from the above list? Also please take a look at the cwiki link above to see if any other JIRAs from there are of interest and can be made part of the release. Any other issues/features missed so far in above which can be included? === Regards, Amita On Jan 16, 2008 1:47 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hey Amita, that's great! I guess collating the state of the fixed and unfixed JIRAs, and producing a definitive list of what's going to be in and out is the first step. I think the states and marked fix levels on the JIRAs are all as they should be, so that should be a relatively smooth operation. I'll try to find pointers to the best reference information later in the day and post them. Kelvin. On 16/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I would like to do Release Management activities for this SDO release. It will be a good learning for me. Appreciate your help. Regards, Amita On Jan 15, 2008 6:42 PM, kelvin goodson [EMAIL PROTECTED] wrote: It's high time we spun this release. There are various patches still to apply I know, although I haven't done the ground work recently to collate all the info. Is there anyone out there who might be prepared to be release manager for this? I'd be happy to provide guidance. Kelvin. On 20/11/2007, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil:
Re: [Java SDO] What should we be attacking?
Hi Amita, looking at the size of the list of fixed JIRAs and the balance of improvements/New features to bug fixes I would have thought this would warrant a title of Tuscany SDO Java 1.1-incubating I'll respond about the pending JIRAs a bit later. Kelvin. On 16/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Have a couple of question about release - What will be the name of the Java SDO release? After checking Java-SDO-Next and Java-SDO-CTS-Next from ASF-JIRA and referring to http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html I have tried to gather a list of all JIRAs (Fixed, Open,...) at - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SDO+Java+Project Also, referring again to - http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25868.html, Below are in-progress JIRAs- TUSCANY-1360 TUSCANY-1483 TUSCANY-1293 Are there any other in-progress JIRAs? So we are left with below ones - Simple Starters === TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests Is anybody working on any from the above list? Also please take a look at the cwiki link above to see if any other JIRAs from there are of interest and can be made part of the release. Any other issues/features missed so far in above which can be included? === Regards, Amita On Jan 16, 2008 1:47 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hey Amita, that's great! I guess collating the state of the fixed and unfixed JIRAs, and producing a definitive list of what's going to be in and out is the first step. I think the states and marked fix levels on the JIRAs are all as they should be, so that should be a relatively smooth operation. I'll try to find pointers to the best reference information later in the day and post them. Kelvin. On 16/01/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi, I would like to do Release Management activities for this SDO release. It will be a good learning for me. Appreciate your help. Regards, Amita On Jan 15, 2008 6:42 PM, kelvin goodson [EMAIL PROTECTED] wrote: It's high time we spun this release. There are various patches still to apply I know, although I haven't done the ground work recently to collate all the info. Is there anyone out there who might be prepared to be release manager for this? I'd be happy to provide guidance. Kelvin. On 20/11/2007, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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
Re: [Java SDO] What should we be attacking?
It's high time we spun this release. There are various patches still to apply I know, although I haven't done the ground work recently to collate all the info. Is there anyone out there who might be prepared to be release manager for this? I'd be happy to provide guidance. Kelvin. On 20/11/2007, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve 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.
Re: [Java SDO] What should we be attacking?
Hi, I would like to do Release Management activities for this SDO release. It will be a good learning for me. Appreciate your help. Regards, Amita On Jan 15, 2008 6:42 PM, kelvin goodson [EMAIL PROTECTED] wrote: It's high time we spun this release. There are various patches still to apply I know, although I haven't done the ground work recently to collate all the info. Is there anyone out there who might be prepared to be release manager for this? I'd be happy to provide guidance. Kelvin. On 20/11/2007, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve 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.
Re: [Java SDO] What should we be attacking?
Hi Rajini, thanks for this. Our problem is that because the SDO spec says we must support Java 1.4, and versions of EMF from 2.3 and beyond require Java 5, we are blocked from advancing beyond EMF 2.2.3. Your Bugzilla doesn't mention the version of EMF, but sadly I'm pretty sure there's no scope for us getting a fix on top of 2.2.3, so I think we will have to go on with the solution you have provided indefinitely. Kelvin. On 11/01/2008, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, Following on from the notes from John Conlon ( http://www.eclipse.org/newsportal/article.php?id=29577group=eclipse.tools.emf#29577 ) and Jeff McAffer ( http://www.mail-archive.com/[EMAIL PROTECTED]/msg00673.html), I have opened an EMF Bugzilla ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=215010) to remove the dependency of EMF on the Eclipse runtime. You could apply the patch as is, and remove the code that modifies the manifest entries in the EMF jars when the issue is resolved. Thank you... Regards, Rajini On 1/9/08, kelvin goodson [EMAIL PROTECTED] wrote: Rajini, I think you are right. I'll apply the patch as is, and we can tackle the issue of Felix as a community if and when specific the need arises. Regards, Kelvin. On 08/01/2008, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, http://issues.apache.org/jira/browse/TUSCANY-1293 contains the patch that enables SDO to run under OSGi. At the moment, the OSGi manifest entries in EMF jars and the OSGi bundle activator have a dependency on Eclipse runtime (and hence on Equinox). Since Tuscany SCA is tested under Apache Felix OSGi runtime (and Felix is easily available from a public maven repository), the tests in the patch for TUSCANY-1293 are also run under Apache Felix. These tests modify the manifest entries of the EMF jars before installing them under Felix. The patch should work for Equinox without any changes to EMF. It would be good if a cleaner solution could be implemented for SDO to run under Felix without modifying EMF. This is the response I got from Ed Merks on the EMF newsgroup: *This question probably really should be directed to the Apache folks. At Eclipse I can just provide a version intended to run with the Equinox runtime so the Tuscany folks probably ought to make a version that works well with Felix. Have you asked them about this? I'd be curious what they say... * For now, it may be best to apply the patch which enables SDO to run under Equinox without modifying EMF, and with Felix with modified EMF jars. If there is a wider interest in running SDO under Felix, an alternative may be needed. Redistributing EMF with SDO with different manifest entries doesn't seem a good option. Suggestions? Thank you... Regards, Rajini On 1/4/08, kelvin goodson [EMAIL PROTECTED] wrote: Hi Rajini, Now that the New Year has arrived, do you think you'll be able to take a look at this? Thanks, Kelvin. On 11/12/2007, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, I am busy until Christmas with the SCA-OSGi work, but I will try and look at the OSGi-enablement of SDO early in the new year. At the moment I can't promise anything, but from the notes that you produced about classloading, and the code and comments from Bert, I think there is enough information to prototype an implementation. I will update the list in the new year after I take a more detailed look. Thank you... Regards, Rajini On 12/10/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin,
Re: [Java SDO] What should we be attacking?
Kelvin, Following on from the notes from John Conlon ( http://www.eclipse.org/newsportal/article.php?id=29577group=eclipse.tools.emf#29577) and Jeff McAffer ( http://www.mail-archive.com/[EMAIL PROTECTED]/msg00673.html), I have opened an EMF Bugzilla (https://bugs.eclipse.org/bugs/show_bug.cgi?id=215010) to remove the dependency of EMF on the Eclipse runtime. You could apply the patch as is, and remove the code that modifies the manifest entries in the EMF jars when the issue is resolved. Thank you... Regards, Rajini On 1/9/08, kelvin goodson [EMAIL PROTECTED] wrote: Rajini, I think you are right. I'll apply the patch as is, and we can tackle the issue of Felix as a community if and when specific the need arises. Regards, Kelvin. On 08/01/2008, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, http://issues.apache.org/jira/browse/TUSCANY-1293 contains the patch that enables SDO to run under OSGi. At the moment, the OSGi manifest entries in EMF jars and the OSGi bundle activator have a dependency on Eclipse runtime (and hence on Equinox). Since Tuscany SCA is tested under Apache Felix OSGi runtime (and Felix is easily available from a public maven repository), the tests in the patch for TUSCANY-1293 are also run under Apache Felix. These tests modify the manifest entries of the EMF jars before installing them under Felix. The patch should work for Equinox without any changes to EMF. It would be good if a cleaner solution could be implemented for SDO to run under Felix without modifying EMF. This is the response I got from Ed Merks on the EMF newsgroup: *This question probably really should be directed to the Apache folks. At Eclipse I can just provide a version intended to run with the Equinox runtime so the Tuscany folks probably ought to make a version that works well with Felix. Have you asked them about this? I'd be curious what they say... * For now, it may be best to apply the patch which enables SDO to run under Equinox without modifying EMF, and with Felix with modified EMF jars. If there is a wider interest in running SDO under Felix, an alternative may be needed. Redistributing EMF with SDO with different manifest entries doesn't seem a good option. Suggestions? Thank you... Regards, Rajini On 1/4/08, kelvin goodson [EMAIL PROTECTED] wrote: Hi Rajini, Now that the New Year has arrived, do you think you'll be able to take a look at this? Thanks, Kelvin. On 11/12/2007, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, I am busy until Christmas with the SCA-OSGi work, but I will try and look at the OSGi-enablement of SDO early in the new year. At the moment I can't promise anything, but from the notes that you produced about classloading, and the code and comments from Bert, I think there is enough information to prototype an implementation. I will update the list in the new year after I take a more detailed look. Thank you... Regards, Rajini On 12/10/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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
Re: [Java SDO] What should we be attacking?
Rajini, I think you are right. I'll apply the patch as is, and we can tackle the issue of Felix as a community if and when specific the need arises. Regards, Kelvin. On 08/01/2008, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, http://issues.apache.org/jira/browse/TUSCANY-1293 contains the patch that enables SDO to run under OSGi. At the moment, the OSGi manifest entries in EMF jars and the OSGi bundle activator have a dependency on Eclipse runtime (and hence on Equinox). Since Tuscany SCA is tested under Apache Felix OSGi runtime (and Felix is easily available from a public maven repository), the tests in the patch for TUSCANY-1293 are also run under Apache Felix. These tests modify the manifest entries of the EMF jars before installing them under Felix. The patch should work for Equinox without any changes to EMF. It would be good if a cleaner solution could be implemented for SDO to run under Felix without modifying EMF. This is the response I got from Ed Merks on the EMF newsgroup: *This question probably really should be directed to the Apache folks. At Eclipse I can just provide a version intended to run with the Equinox runtime so the Tuscany folks probably ought to make a version that works well with Felix. Have you asked them about this? I'd be curious what they say... * For now, it may be best to apply the patch which enables SDO to run under Equinox without modifying EMF, and with Felix with modified EMF jars. If there is a wider interest in running SDO under Felix, an alternative may be needed. Redistributing EMF with SDO with different manifest entries doesn't seem a good option. Suggestions? Thank you... Regards, Rajini On 1/4/08, kelvin goodson [EMAIL PROTECTED] wrote: Hi Rajini, Now that the New Year has arrived, do you think you'll be able to take a look at this? Thanks, Kelvin. On 11/12/2007, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, I am busy until Christmas with the SCA-OSGi work, but I will try and look at the OSGi-enablement of SDO early in the new year. At the moment I can't promise anything, but from the notes that you produced about classloading, and the code and comments from Bert, I think there is enough information to prototype an implementation. I will update the list in the new year after I take a more detailed look. Thank you... Regards, Rajini On 12/10/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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
Re: [Java SDO] What should we be attacking?
Hi Rajini, Now that the New Year has arrived, do you think you'll be able to take a look at this? Thanks, Kelvin. On 11/12/2007, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, I am busy until Christmas with the SCA-OSGi work, but I will try and look at the OSGi-enablement of SDO early in the new year. At the moment I can't promise anything, but from the notes that you produced about classloading, and the code and comments from Bert, I think there is enough information to prototype an implementation. I will update the list in the new year after I take a more detailed look. Thank you... Regards, Rajini On 12/10/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static SDO generator: problem with elements named internal* which would be simple For someone with maven build experience there TUSCANY-257 recently added file Interface2JavaGenerator.javais not compatible with JDK 1.4 For someone with Grobu-Utils and maven skills there's ... TUSCANY-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties
Re: [Java SDO] What should we be attacking?
Kelvin, Yes, I have been looking at this for the last couple of days as promised. I will attach a patch to the JIRA later today. Here is a summary of the changes: - Since HelperProvider API and HelperProviderImpl are in two different OSGi bundles, loaded by different classloaders, HelperProvider doesn't find a default implementation when run under OSGi. I have added a method in HelperProvider to set a default implementation if it has not been already set. I added a bundle activator for the SDO implementation bundle which sets this default implementation for HelperProvider. - I modified some of the OSGi manifest entries for the SDO bundles since they look slightly out of date. - I added two tests, one to run the SDO implementation test suite in a multi-classloader environment, and another to run the SDO implementation test suite inside an OSGi container. SDO continues to use the thread context classloader. When running inside an OSGi container, it will be upto the application bundles to add their bundle classloaders to the TCCL if the application classes/resources should be found by SDO implementation. SDOXMLResourceImpl for instance loads resources using TCCL. The alternative would be for SDO to add all bundles to the TCCL using a bundle listener, or use an alternative resource loading mechanism when running under OSGi, both of which are not very satisfactory. There were no other classloading issues with SDO when running under OSGi (at least as far as I can tell). The OSGi testcase runs the sdo.impl test suite with around 180 tests under OSGi - hopefully these tests exercise most of the code. I had a lot of trouble getting SDO and its dependent bundles (EMF etc.) to run under Apache Felix, since EMF bundles use Require-Bundle of the Eclipse runtime, and these in turn bring in Equinox. At the moment, the SDO implementation bundle is created for the OSGi test with a different manifest than the one which is used by the regular build, since I was not sure if the changes would break SDO running under Equinox. And the tests modify the manifest entries in the EMF jars to remove the dependency on Eclipse. These changes are restricted to the test case, and are specific to running SDO in an OSGi runtime other than Equinox. On 1/4/08, kelvin goodson [EMAIL PROTECTED] wrote: Hi Rajini, Now that the New Year has arrived, do you think you'll be able to take a look at this? Thanks, Kelvin. On 11/12/2007, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, I am busy until Christmas with the SCA-OSGi work, but I will try and look at the OSGi-enablement of SDO early in the new year. At the moment I can't promise anything, but from the notes that you produced about classloading, and the code and comments from Bert, I think there is enough information to prototype an implementation. I will update the list in the new year after I take a more detailed look. Thank you... Regards, Rajini On 12/10/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot mapping framework to
Re: [Java SDO] What should we be attacking?
Thanks Rajini, I propose we hold on until January in the hope that you will be able to tackle this. Many thanks, Kelvin. On 11/12/2007, Rajini Sivaram [EMAIL PROTECTED] wrote: Kelvin, I am busy until Christmas with the SCA-OSGi work, but I will try and look at the OSGi-enablement of SDO early in the new year. At the moment I can't promise anything, but from the notes that you produced about classloading, and the code and comments from Bert, I think there is enough information to prototype an implementation. I will update the list in the new year after I take a more detailed look. Thank you... Regards, Rajini On 12/10/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static SDO generator: problem with elements named internal* which would be simple For someone with maven build experience there TUSCANY-257 recently added file Interface2JavaGenerator.javais not compatible with JDK 1.4 For someone with Grobu-Utils and maven skills there's ... TUSCANY-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties
Re: [Java SDO] What should we be attacking?
Kelvin, I am busy until Christmas with the SCA-OSGi work, but I will try and look at the OSGi-enablement of SDO early in the new year. At the moment I can't promise anything, but from the notes that you produced about classloading, and the code and comments from Bert, I think there is enough information to prototype an implementation. I will update the list in the new year after I take a more detailed look. Thank you... Regards, Rajini On 12/10/07, kelvin goodson [EMAIL PROTECTED] wrote: I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve 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
Re: [Java SDO] What should we be attacking?
I'd kind of hoped to be in a position to have a release before the end of the year. The JIRA query [1] shows that we have 34 JIRAs in resolved state with a fix version of SDO-Next, but I think it would be good to get the OSGi issues dealt with before a release. Thoughts? Kelvin. [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310210status=5status=6component=12311542component=12310660component=12310973component=12310802fixfor=12312262resolution=1sorter/field=issuekeysorter/order=DESCsorter/field=componentssorter/order=ASCsorter/field=updatedsorter/order=DESC On 29/11/2007, kelvin goodson [EMAIL PROTECTED] wrote: David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve 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]
Re: [Java SDO] What should we be attacking?
Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve 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]
Re: [Java SDO] What should we be attacking?
David, thanks for the fixes. I'll apply them as soon as I can get to them. I've been away unwell for most of the last weeks so I have some catching up to do. Anything you can do to reduce the JIRA backlog further would be great, thanks. Kelvin. On 29/11/2007, David Adcox [EMAIL PROTECTED] wrote: Kelvin, I have some free cycles, so I'd like to help knock some things off this list for you. I've gone ahead and contributed a patch for 1483. I'll address 1545 as well. I believe that 1384 is already done. On Nov 20, 2007 6:36 AM, 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve 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]
Re: [Java SDO] What should we be attacking?
Bert, Thank you for your note. I had a look at SDOActivator from the patches you listed, and it uses eclipse plugin API to find the bundles. We are currently using Apache Felix to run Tuscany SCA, and would like to have an activator which finds classes for any OSGi runtime. For the SCA runtime itself, we use a bundle listener to find the SCA bundles, and I think we should be able to do the same for SDO (and that should work for Eclipse plugins as well). Were there any other changes you had to make in SDO to get it to work under OSGi, apart from the code in the activator? Did any of the classloading code that Kelvin listed need to be changed to work in a multi-classloader/OSGi environment? For instance, did you change the code which relies on thread context classloader? Thank you... Regards, Rajini On 11/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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 tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org 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
Re: [Java SDO] What should we be attacking?
Rajini,
Yes, BundleListeners are probably better than extension points for this. I
didn't know about them at the time I implemented the Activator. And as we
have lots of other extension points we don't mind depending on eclipse
osgi.
We needed to do changes on the same places that Kelvin mentioned.
(1) Somewhere around DefaultHelperContextImpl to find the correct
implementation class for the interfaces. The normal implementation does a
Class.forName(). Under OSGi we fixed this by creating an extension point
that can be used to supply appropriate implementation classes. That's done
by the Activator.
(2) In XSDHelperImpl we have an unsolved issue. It's possible to specify
an instanceClass in an XSD. There is no place however to specify the name
of a bundle. One solution could be to rely on context class loader. We
don't do that at the moment -- probably a bug :-).
Currently, we use instanceClass very little. Main reason is that we want
to reuse the same xsd in multiple environments where we don't necessarily
want to have the same instance classes.
(3) To associate a given implementation class with a Type we defined a
property file (implementationclasses.properties) that maps types on
implementation classes. Each bundle can have such a property file and we
use extensions to indicate that a bundle has such a property file.
In the mapping framework there is also one place where we need to do a
Class.forName() [see ExtendablePropertyAccessor]. But this is not a part
of Tuscany SDO (yet :-).
The problem there is very similar to the problem in (3). Basically we want
to allow everyone to provide implementation classes.
In a standard classpath environment, we implemented this by scanning the
classpath for property files
private void initializeClassPropertyAccessorMap() {
try {
EnumerationURL props =
this.getClass().getClassLoader().getResources(SDOPROPERTYACCESSORS);
while (props.hasMoreElements()) {
specialPropertyAccessors.load(props.nextElement().openStream());
}
} catch (IOException e) {
throw new RuntimeException(e);
}
}
I'd better refactor this into a repository where we keep track of the
classloader that is able to find the property file. Then we can use that
classloader to load the implementation classes.
Bert
Rajini Sivaram [EMAIL PROTECTED]
22/11/2007 12:57
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: [Java SDO] What should we be attacking?
Bert,
Thank you for your note.
I had a look at SDOActivator from the patches you listed, and it uses
eclipse plugin API to find the bundles. We are currently using Apache
Felix
to run Tuscany SCA, and would like to have an activator which finds
classes
for any OSGi runtime. For the SCA runtime itself, we use a bundle listener
to find the SCA bundles, and I think we should be able to do the same for
SDO (and that should work for Eclipse plugins as well). Were there any
other
changes you had to make in SDO to get it to work under OSGi, apart from
the
code in the activator? Did any of the classloading code that Kelvin listed
need to be changed to work in a multi-classloader/OSGi environment? For
instance, did you change the code which relies on thread context
classloader?
Thank you...
Regards,
Rajini
On 11/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
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
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
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
Re: [Java SDO] What should we be attacking?
Bert,
Thank you very much for the details. I will take a look at the code that
Kelvin mentioned and your changes in those areas. I am not very familiar
with the SDO codebase, so your note has been very helpful.
Thank you...
Regards,
Rajini
On 11/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Rajini,
Yes, BundleListeners are probably better than extension points for this. I
didn't know about them at the time I implemented the Activator. And as we
have lots of other extension points we don't mind depending on eclipse
osgi.
We needed to do changes on the same places that Kelvin mentioned.
(1) Somewhere around DefaultHelperContextImpl to find the correct
implementation class for the interfaces. The normal implementation does a
Class.forName(). Under OSGi we fixed this by creating an extension point
that can be used to supply appropriate implementation classes. That's done
by the Activator.
(2) In XSDHelperImpl we have an unsolved issue. It's possible to specify
an instanceClass in an XSD. There is no place however to specify the name
of a bundle. One solution could be to rely on context class loader. We
don't do that at the moment -- probably a bug :-).
Currently, we use instanceClass very little. Main reason is that we want
to reuse the same xsd in multiple environments where we don't necessarily
want to have the same instance classes.
(3) To associate a given implementation class with a Type we defined a
property file (implementationclasses.properties) that maps types on
implementation classes. Each bundle can have such a property file and we
use extensions to indicate that a bundle has such a property file.
In the mapping framework there is also one place where we need to do a
Class.forName() [see ExtendablePropertyAccessor]. But this is not a part
of Tuscany SDO (yet :-).
The problem there is very similar to the problem in (3). Basically we want
to allow everyone to provide implementation classes.
In a standard classpath environment, we implemented this by scanning the
classpath for property files
private void initializeClassPropertyAccessorMap() {
try {
EnumerationURL props =
this.getClass().getClassLoader().getResources(SDOPROPERTYACCESSORS);
while (props.hasMoreElements()) {
specialPropertyAccessors.load(props.nextElement().openStream());
}
} catch (IOException e) {
throw new RuntimeException(e);
}
}
I'd better refactor this into a repository where we keep track of the
classloader that is able to find the property file. Then we can use that
classloader to load the implementation classes.
Bert
Rajini Sivaram [EMAIL PROTECTED]
22/11/2007 12:57
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Re: [Java SDO] What should we be attacking?
Bert,
Thank you for your note.
I had a look at SDOActivator from the patches you listed, and it uses
eclipse plugin API to find the bundles. We are currently using Apache
Felix
to run Tuscany SCA, and would like to have an activator which finds
classes
for any OSGi runtime. For the SCA runtime itself, we use a bundle listener
to find the SCA bundles, and I think we should be able to do the same for
SDO (and that should work for Eclipse plugins as well). Were there any
other
changes you had to make in SDO to get it to work under OSGi, apart from
the
code in the activator? Did any of the classloading code that Kelvin listed
need to be changed to work in a multi-classloader/OSGi environment? For
instance, did you change the code which relies on thread context
classloader?
Thank you...
Regards,
Rajini
On 11/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
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
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
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
Re: [Java SDO] What should we be attacking?
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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static 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-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve 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]
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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to UTF-8. TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static SDO generator:
Re: [Java SDO] What should we be attacking?
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 tuscany-dev@ws.apache.org To tuscany-dev@ws.apache.org 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-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot 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
