7C3EF93EEBC6EB4A8B4470853DE8656651FF89@dewdfe18.wdf.sap.corp"
type="cite">
Hi Blaise,
We had a few issues with getting
our implementation to run on eclipse, but I don't remember anything to
do with instanciating HelperContexts or HelperProviderImpl. I was a
little unsure of whether the Class.forName() in HelperProvider would
work, but it resolves the class using the exporting bundle's
classloader, so this is exactly what we want. I'm assuming that the
implementation bundle exports the packages defined in the SDO API
(commonj.sdo, etc). I'm wondering why you are running into problems
here... are you trying to deliver the API and Implementation is
seperate bundles?
The problems we did have (as far
as I can remember) had to do with instanciating static SDOs (eg, when
parsing XML). Since this code is in the SDO implementation bundle, it
does not have access to any classes in the client's bundle. It's one
reason why I think it's important to associate HelperContexts with
ClassLoaders... 7c on your low priority list.
In other words, our problems
weren't that the API and Impl needed to be in seperate classloaders,
but that the client and implementation were in seperate classloaders.
By the way, I'm not so clear how
the classloader argument in JAXBContext.createContext() works... is
this the classloader where the provider implementation is located, or
the classloader where the client JAXB's are located?
Best Regards,
Ron
Hi Ron,
I'm assuming you mean in reference to the OSGi aspect. More and more
of our customers are using OSGi environments such as Eclipse Equinox,
and we want to allow SDO to be used here. JAXB and JPA work fine in an
OSGi environment, but standard SDO 2.1/2.1.1 does not.
The basic requirement would be the ability to instantiate a
HelperContext impl that is not in the same class loader as the public
SDO API.
For more information on OSGi see:
http://www.osgi.org/
For more information on Eclipse Equinox see:
http://www.eclipse.org/equinox/
-Blaise
Barack, Ron wrote:
7C3EF93EEBC6EB4A8B4470853DE865664CEA0B@dewdfe18.wdf.sap.corp"
type="cite">
Hi Radu and Blaise,
Quick question:
a) Define standard ways to create HelperContexts. (We would like to see this be compatible with OSGi)
Could you give me an idea what you mean by this?
Ron
-----Ursprüngliche Nachricht-----
Von: Radu Preotiuc-Pietro [mailto:radu.preotiuc-pietro@oracle.com]
Gesendet: Dienstag, 13. Januar 2009 18:15
An: sdo@lists.oasis-open.org
Betreff: [sdo] Oracle SDO 3.0 Issue Rankings
Hello everyone,
Blaise and I and our teams worked out the list of priorities for Oracle and we are mostly in agreement with what has been discussed so far. This is our list of priorities:
High Priority Items
5. Improved XML/XSD Support
7. Organization of SDO Type System and Helpers
a) Define standard ways to create HelperContexts. (We would like to see this be compatible with OSGi)
3. Features related to the Data Access Services (DAS) Specification
In particular the ChangeSummary
Medium Priority Items
1. Enhancements to Static SDOs:
a) Their use as a source of SDO Metadata.
c) Defining name mangling and package to namespace mappings (For Java we propose using JAXB name mangling rules).
d) Consolidation with data objects from standard frameworks, e.g. JAX-B.
2. Service Level Programming API
4. SDO XML Path Support
6. Cleaning up/ Enhancing the SDO API
Low Priority Items
7. Organization of SDO Type System and Helpers
b) Define the organization and relationship between HelperContexts.
c) Define the relationship of HelperContexts to other system entities, such as class loaders.
d) Clarify if Type and Property objects should be DataObjects.
8. Enhancements to SDO Metadata
Not Required
1. Enhancements to Static SDOs:
b) Defining an API for their generation
9. Interoperability with .Net
11. Notification Support
12. Programming Language Support
Completed
10. Relaxing Containment Requirements
Thanks,
Radu
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php