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