On 4/20/07, Snehit Prabhu <[EMAIL PROTECTED]> wrote:
Hi, Is there an updated version of this document (Extending Tuscany) that reflects the current state of the trunk? Most of the classes in the models shown are nonexistent today. Is the whole programming model depicted here irrelevant? thanks snehit On 4/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Pamela Fong wrote: > > If I choose to use EMF to generate a model to represent my extended SCDL > > schema, I would also need to generate EMF model to represent > > sca-core.xsdsince the binding schema extends from the core schema. So > > I would end up > > packaging two generated packages within one binding extension. Someone > > else > > comes along adding extension to sca-core and using EMF to generate the > > model > > code, also needs to package the core and the extended packages. How do > > things co-exist in the long run? Or do we just assume all generated core > > packages should be identical and thus it's ok to have it multiple > > times in > > the classpath? > > > > On 4/10/07, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > >> > >> Pamela Fong wrote: > >> > Hi, > >> > > >> > I read the article "Extending Tuscany by contributing a new > >> > implementation / > >> > binding type" by Raymond and Jeremy. Got a question about the > >> > definition of > >> > ModelObject. The example in the article is a very simple java > >> bean-like > >> > object. This is fine if all we have to deal with is some simple > >> > attributes > >> > in the extension. If the binding requires complex SCDL model > >> extension, > >> > defining the ModelObject by hand may not be the best choice (let's > say > >> > one > >> > could have mulitple layers of nested elements and arrays etc.). One > >> > obvious > >> > alternative would be to generate some model code based on the > >> extension > >> > xsd using EMF. However, since the binding's xsd extends from > >> > sca-core.xsd, > >> > generating model code would require the core model, which doesn't > >> > exist in > >> > Tuscany. What would be the recommended mechanism to define the > >> > ModelObject > >> > in this case? > >> > > >> > -pam > >> > > >> > >> Hi, > >> > >> ModelObject does not exist anymore in the latest assembly model in > trunk > >> (now under java/sca/modules/assembly). The assembly model is now > >> represented by a set of interfaces, so you have the flexibility to > >> implement your model classes however you want, without having to extend > >> a ModelObject class. > >> > >> You can choose to use EMF or another suitable XML databinding > technology > >> to implement your model classes or, probably simpler, just create plain > >> Java classes that implement the model interfaces. The only requirement > >> for a binding model class is to implement the o.a.t.assembly.Binding > >> interface. Then, if you choose the "plain java class" option, to read > >> the model from XML use StAX as we've done for the other bindings (see > >> java/sca/modules/binding-ws-xml for an example), it is actually pretty > >> easy thanks to StAX. > >> > >> Hope this helps. > >> > >> -- > >> Jean-Sebastien > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > Right, if multiple extensions choose to use a specific databinding or > modeling technology for their models they'll need to coordinate if they > want to share some code. > > I would recommend to try implementing your model using plain Java > classes first, at least this way you can share more code with the other > model modules from Tuscany. > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Hi Snehit, You are correct, the code base has moved on since the document you refer was written. Not only is the code being tidied up but we are trying to improve the docs as well. I just took a look and Raymond has started a page on how to extend Tuscany [1] on the project website/wiki. It's just a start and I don't think that the way extension points are written has settled down 100% but you get the idea. Most of the function of the Tuscany SCA runtime implementation is provided using the extension point/module activator mechanism that Raymond is starting to describe. If you look at the list of modules in the source code [2] you see it is starting to grow in length. Not all of these are loaded as extensions but all of the implementation, bindings and databindings are. Picking one at random, say the runtime that support components implemented using Java, you can see a module called implementation-java-runtime. Look inside there and you see a module activator file [3] which in turn refers to a class that is run automatically by the runtime (using the JDK service loading mechanism) when it loads all of the extension modules it finds on the classpath. If you look inside the referenced class [4] you can see what it has to do to register support for the SCA "implementation.java" element. I have to admit that I'm not an expert on how the implementation.javaruntime works but there are people here that are so ask away:-) Also if you start looking at this and you have thoughts/comments about what you see you are more than welcome to contribute to both the documentation and the code. Regards Simon [1] http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Extension+Guide [2] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/ [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-java-runtime/src/main/resources/META-INF/services/org.apache.tuscany.core.ModuleActivator [4] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-java-runtime/src/main/java/org/apache/tuscany/implementation/java/module/JavaRuntimeModuleActivator.java
