tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bert.rob...@agfa.com
Subject Re: [Java SDO] What should we be attacking?
Date Thu, 22 Nov 2007 12:53:25 GMT
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" <rajinisivaram@googlemail.com> 
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, bert.robben@agfa.com <bert.robben@agfa.com> 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" <kelvin@thegoodsons.org.uk>
> Sent by: kelvingoodson@gmail.com
> 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 <rajinisivaram@googlemail.com> 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 <kelvin@thegoodsons.org.uk> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message