|
Hi Blaise,
It seems to me like a very non-OSGi way of doing
things. Isn't the point of OSGi that several implementation of the same
API can be delivered, all implementations exporting the same packages, and then,
by default, the framework decides which implementation to use (based on
version numbers or other selectors).
Having the POJOs (in our case, static SDOs) and
implementation in the same classloader is going to be hard in an OSGi world,
isn't it? How is this addressed in your JAXB and JPA
implementations? I had the impression that you want to give a Classloader
as a parameter to HelperProvider, but I'm just having a hard time picturing how
a client is supposed to get the implementation's classloader. Maybe some
sample client code from EclipseLink's JAXB implementation would help
me.
I don't know what
you mean by "serializing DataObjects between implementations". Can you
clarify your requirement here?
Ron
Hi Ron,
Yes we are delivering the API and implementation as
separate bundles, this is also what we do for JAXB and JPA. Ideally an
application server could contain a standard SDO library (as it typically does
for JPA and JAXB), and deployed applications could choose there preferred SDO
implementation (as they do for JPA and JAXB)). Having this shared library
should also make it easier to serialize DataObjects between
implementations.
I did not mean to imply by ranking 7c low on the Oracle
priority list, that I am against it. I just saw that item as a possible
means to an end, and not necessarily an end in itself.
The ClassLoader
argument is the class loader for the domain model (the POJOs used with
JAXB). That ClassLoader is also responsible for instantiating the JAXB
implementation. The JAXB implementation is specified in a jaxb.properties
file that is located in the same package as the domain
classes.
-Blaise
Barack, Ron wrote:
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
|