Objective of the following sandbox - tuscany/sandbox/sebastien/java
Sebastien, Can you please explain to everyone the purpose of this svn area and what you are planning to do here? thanks, dims -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Objective of the following sandbox - tuscany/sandbox/sebastien/java
Davanum Srinivas wrote: Sebastien, Can you please explain to everyone the purpose of this svn area and what you are planning to do here? thanks, dims Dims, In the sandbox, I am trying to demonstrate a modular Tuscany kernel that can support what I described in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15782.html I'm working on this in sandbox/sebastien/java/sca/modules. Basically I'm trying to come up with a set of black-box modules, with minimum SPIs, minimum inter-dependencies, covering the following aspects: - modules/assembly - SCA core assembly model - modules/policy - SCA Policy model - modules/scdl - SCDL support (reading/writing the model from/to SCDL) - modules/builder - A prototype of a different API to the assembly model (showing how the same model can implement multiple interfaces) - modules/java and java-scdl - SCA Java model and SCDL support for it - modules/wsdl and wsdl-scdl - SCA WSDL model and SCDL support for it - modules/crud and crud-scdl - a prototype of a simplistic SCA component implementation type, to help validate the pluggability into the model and the SCDL support - modules/http http-tomcat and http-jetty - embedded Tomcat and Jetty, I want to experiment with a binding (probably based on HTTP) and I'm not sure which to pick between Tomcat and Jetty for that so I pulled these two modules in as well and put in modules/http a small ServletHost interface that will help integrate them. I'm also just starting to prototype a variant implementation of the assembly model, to see how a fairly different model implementation can be swapped without breaking the other pieces (using the assembly model API interfaces). So this first set of modules covers part of the SCA metadata/model story. Next I'd like to start looking at the execution runtime and see how the execution part of kernel/core can be split in multiple modules as well. I'd like to see how the SCA Java component support can be extracted as a separate module for example. I also copied to my sandbox a top-down build structure including end to end samples and integration tests, which I'd like to use to validate that these ideas and this assembly of modules hold together. So, as I said in the above thread, I'd like feedback, ideas or help with this work. People have asked for a more concrete proposal and more details, the proposal is starting to take shape, and I'm happy to continue to work on it wherever the community feel it should be done. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Objective of the following sandbox - tuscany/sandbox/sebastien/java
On Mar 23, 2007, at 8:52 PM, Jean-Sebastien Delfino wrote: Davanum Srinivas wrote: Sebastien, Can you please explain to everyone the purpose of this svn area and what you are planning to do here? thanks, dims Dims, In the sandbox, I am trying to demonstrate a modular Tuscany kernel that can support what I described in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15782.html I'm working on this in sandbox/sebastien/java/sca/modules. Basically I'm trying to come up with a set of black-box modules, with minimum SPIs, minimum inter-dependencies, covering the following aspects: - modules/assembly - SCA core assembly model - modules/policy - SCA Policy model - modules/scdl - SCDL support (reading/writing the model from/to SCDL) - modules/builder - A prototype of a different API to the assembly model (showing how the same model can implement multiple interfaces) - modules/java and java-scdl - SCA Java model and SCDL support for it - modules/wsdl and wsdl-scdl - SCA WSDL model and SCDL support for it - modules/crud and crud-scdl - a prototype of a simplistic SCA component implementation type, to help validate the pluggability into the model and the SCDL support - modules/http http-tomcat and http-jetty - embedded Tomcat and Jetty, I want to experiment with a binding (probably based on HTTP) and I'm not sure which to pick between Tomcat and Jetty for that so I pulled these two modules in as well and put in modules/http a small ServletHost interface that will help integrate them. I'm also just starting to prototype a variant implementation of the assembly model, to see how a fairly different model implementation can be swapped without breaking the other pieces (using the assembly model API interfaces). So this first set of modules covers part of the SCA metadata/model story. Next I'd like to start looking at the execution runtime and see how the execution part of kernel/core can be split in multiple modules as well. I'd like to see how the SCA Java component support can be extracted as a separate module for example. I also copied to my sandbox a top-down build structure including end to end samples and integration tests, which I'd like to use to validate that these ideas and this assembly of modules hold together. So, as I said in the above thread, I'd like feedback, ideas or help with this work. People have asked for a more concrete proposal and more details, the proposal is starting to take shape, and I'm happy to continue to work on it wherever the community feel it should be done. From looking at the above description and the commit history it seems you have forked the code. For example, the "variant implementation of the assembly model" has a number of changes that coupled with what you describe above will basically require a re- write of kernel. What are the reasons for these changes? Couldn't trunk be incrementally improved? Are there any plans for merging this with trunk? Is this a revolution? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Objective of the following sandbox - tuscany/sandbox/sebastien/java
>> -Original Message- >> From: Jim Marino [mailto:[EMAIL PROTECTED] >> Sent: 24 March 2007 07:34 >> To: tuscany-dev@ws.apache.org >> Subject: Re: Objective of the following sandbox - >> tuscany/sandbox/sebastien/java >> >> >> On Mar 23, 2007, at 8:52 PM, Jean-Sebastien Delfino wrote: >> >> > Davanum Srinivas wrote: >> >> Sebastien, >> >> >> >> Can you please explain to everyone the purpose of this >> svn area and >> >> what you are planning to do here? >> >> >> >> thanks, >> >> dims >> >> >> > >> > Dims, >> > >> > In the sandbox, I am trying to demonstrate a modular >> Tuscany kernel >> > that can support what I described in this thread: >> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15782.html >> > >> > I'm working on this in sandbox/sebastien/java/sca/modules. >> > >> > Basically I'm trying to come up with a set of black-box >> modules, with >> > minimum SPIs, minimum inter-dependencies, covering the following >> > aspects: >> > - modules/assembly - SCA core assembly model >> > - modules/policy - SCA Policy model >> > - modules/scdl - SCDL support (reading/writing the model >> from/to SCDL) >> > - modules/builder - A prototype of a different API to the assembly >> > model (showing how the same model can implement multiple >> interfaces) >> > - modules/java and java-scdl - SCA Java model and SCDL >> support for it >> > - modules/wsdl and wsdl-scdl - SCA WSDL model and SCDL >> support for it >> > - modules/crud and crud-scdl - a prototype of a simplistic SCA >> > component implementation type, to help validate the >> pluggability into >> > the model and the SCDL support >> > - modules/http http-tomcat and http-jetty - embedded >> Tomcat and Jetty, >> > I want to experiment with a binding (probably based on >> HTTP) and I'm >> > not sure which to pick between Tomcat and Jetty for that >> so I pulled >> > these two modules in as well and put in modules/http a small >> > ServletHost interface that will help integrate them. >> > >> > I'm also just starting to prototype a variant >> implementation of the >> > assembly model, to see how a fairly different model >> implementation can >> > be swapped without breaking the other pieces (using the >> assembly model >> > API interfaces). >> > >> > So this first set of modules covers part of the SCA metadata/model >> > story. Next I'd like to start looking at the execution >> runtime and see >> > how the execution part of kernel/core can be split in >> multiple modules >> > as well. I'd like to see how the SCA Java component support can be >> > extracted as a separate module for example. >> > >> > I also copied to my sandbox a top-down build structure >> including end >> > to end samples and integration tests, which I'd like to use to >> > validate that these ideas and this assembly of modules >> hold together. >> > >> > So, as I said in the above thread, I'd like feedback, >> ideas or help >> > with this work. People have asked for a more concrete proposal and >> > more details, the proposal is starting to take shape, and >> I'm happy to >> > continue to work on it wherever the community feel it >> should be done. >> >> From looking at the above description and the commit >> history it seems you have forked the code. For example, the >> "variant implementation of the assembly model" has a number >> of changes that coupled with what you describe above will >> basically require a re- write of kernel. What are the >> reasons for these changes? Couldn't trunk be incrementally >> improved? Are there any plans for merging this with trunk? >> Is this a revolution? >> >> Jim >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> This message has been checked for all email viruses by MessageLabs. >> I would like to know how this would impact all the work we have done in the last couple of months on trunk in terms of separating the logical and physical. From, a t
Re: Objective of the following sandbox - tuscany/sandbox/sebastien/java
Jim, My comments inline Jim Marino wrote: On Mar 23, 2007, at 8:52 PM, Jean-Sebastien Delfino wrote: Davanum Srinivas wrote: Sebastien, Can you please explain to everyone the purpose of this svn area and what you are planning to do here? thanks, dims Dims, In the sandbox, I am trying to demonstrate a modular Tuscany kernel that can support what I described in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15782.html I'm working on this in sandbox/sebastien/java/sca/modules. Basically I'm trying to come up with a set of black-box modules, with minimum SPIs, minimum inter-dependencies, covering the following aspects: - modules/assembly - SCA core assembly model - modules/policy - SCA Policy model - modules/scdl - SCDL support (reading/writing the model from/to SCDL) - modules/builder - A prototype of a different API to the assembly model (showing how the same model can implement multiple interfaces) - modules/java and java-scdl - SCA Java model and SCDL support for it - modules/wsdl and wsdl-scdl - SCA WSDL model and SCDL support for it - modules/crud and crud-scdl - a prototype of a simplistic SCA component implementation type, to help validate the pluggability into the model and the SCDL support - modules/http http-tomcat and http-jetty - embedded Tomcat and Jetty, I want to experiment with a binding (probably based on HTTP) and I'm not sure which to pick between Tomcat and Jetty for that so I pulled these two modules in as well and put in modules/http a small ServletHost interface that will help integrate them. I'm also just starting to prototype a variant implementation of the assembly model, to see how a fairly different model implementation can be swapped without breaking the other pieces (using the assembly model API interfaces). So this first set of modules covers part of the SCA metadata/model story. Next I'd like to start looking at the execution runtime and see how the execution part of kernel/core can be split in multiple modules as well. I'd like to see how the SCA Java component support can be extracted as a separate module for example. I also copied to my sandbox a top-down build structure including end to end samples and integration tests, which I'd like to use to validate that these ideas and this assembly of modules hold together. So, as I said in the above thread, I'd like feedback, ideas or help with this work. People have asked for a more concrete proposal and more details, the proposal is starting to take shape, and I'm happy to continue to work on it wherever the community feel it should be done. >From looking at the above description and the commit history it seems you have forked the code. I copied some of the Tuscany code to my sandbox to work on the modularization proposal, as I obviously didn't want to start from scratch. For example, the "variant implementation of the assembly model" has a number of changes that coupled with what you describe above will basically require a re-write of kernel. I have not committed yet this variant implementation of the assembly model as I just started to experiment with it yesterday. What I have in the sandbox at the moment is a set of interfaces defining an assembly model API, and a default implementation of these interfaces. The variant implementation that I'm talking about is a prototype of a different implementation of (a subset of) the same model interfaces, backed by Spring bean definitions. This will help illustrate how clean interfaces allow for alternate implementations of one or more modules, and facilitate the integration with a particular runtime environment (Spring in this case). I've just spent a few hours on this prototype so it's not really baked yet, but I'll commit what I have soon so that people can take a look if they are interested. With respect to "a re-write of kernel" I hope we can avoid re-writing it... I'm not sure why you're saying that this will require a re-write. Now that I've made some progress on the metadata handling (models etc), as I already said in my previous email, my intention is to start looking at how to modularize the execution part of the kernel, and I obviously don't want to restart it from scratch. I'm hoping to have to adjust only some of the runtime builders and minimize changes in the rest of the kernel core. It's not really serious to speculate anyway, I think that prototyping this work will actually tell what's required. What are the reasons for these changes? Couldn't trunk be incrementally improved? Are there any plans for merging this with trunk? As you said yourself when you asked me to continue to work on this in a sandbox instead of trunk in: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15726.html, the approach taken is significantly different than the design we have in trunk. I am prototyping a different design, with independent modules, minimal interfaces between the
Re: Objective of the following sandbox - tuscany/sandbox/sebastien/java
[snip] Jean-Sebastien Delfino wrote: For example, the "variant implementation of the assembly model" has a number of changes that coupled with what you describe above will basically require a re-write of kernel. I have not committed yet this variant implementation of the assembly model as I just started to experiment with it yesterday. What I have in the sandbox at the moment is a set of interfaces defining an assembly model API, and a default implementation of these interfaces. The variant implementation that I'm talking about is a prototype of a different implementation of (a subset of) the same model interfaces, backed by Spring bean definitions. This will help illustrate how clean interfaces allow for alternate implementations of one or more modules, and facilitate the integration with a particular runtime environment (Spring in this case). I've just spent a few hours on this prototype so it's not really baked yet, but I'll commit what I have soon so that people can take a look if they are interested. I just committed a few classes in sca/modules/bean and bean-test under revision r522186 to show what I meant by a variant implementation of the assembly model. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Objective of the following sandbox - tuscany/sandbox/sebastien/java
On 3/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: [snip] Jean-Sebastien Delfino wrote: > >> For example, the "variant implementation of the assembly model" has a >> number of changes that coupled with what you describe above will >> basically require a re-write of kernel. > > I have not committed yet this variant implementation of the assembly > model as I just started to experiment with it yesterday. What I have > in the sandbox at the moment is a set of interfaces defining an > assembly model API, and a default implementation of these interfaces. > The variant implementation that I'm talking about is a prototype of a > different implementation of (a subset of) the same model interfaces, > backed by Spring bean definitions. This will help illustrate how clean > interfaces allow for alternate implementations of one or more modules, > and facilitate the integration with a particular runtime environment > (Spring in this case). I've just spent a few hours on this prototype > so it's not really baked yet, but I'll commit what I have soon so that > people can take a look if they are interested. > I just committed a few classes in sca/modules/bean and bean-test under revision r522186 to show what I meant by a variant implementation of the assembly model. It looks to me like this code you've been doing in the sandbox now has enough to illustrate a lot of the concepts that have been suggested for a more modular kernel. How about we now talk about what you've done and about how further development of these ideas could happen in trunk? It sounds like everyone now agrees we need a more modular kernel, is everyone willing to start doing this in trunk instead of this sandbox? ...ant
Re: Objective of the following sandbox - tuscany/sandbox/sebastien/java
ant elder wrote: On 3/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: [snip] Jean-Sebastien Delfino wrote: > >> For example, the "variant implementation of the assembly model" has a >> number of changes that coupled with what you describe above will >> basically require a re-write of kernel. > > I have not committed yet this variant implementation of the assembly > model as I just started to experiment with it yesterday. What I have > in the sandbox at the moment is a set of interfaces defining an > assembly model API, and a default implementation of these interfaces. > The variant implementation that I'm talking about is a prototype of a > different implementation of (a subset of) the same model interfaces, > backed by Spring bean definitions. This will help illustrate how clean > interfaces allow for alternate implementations of one or more modules, > and facilitate the integration with a particular runtime environment > (Spring in this case). I've just spent a few hours on this prototype > so it's not really baked yet, but I'll commit what I have soon so that > people can take a look if they are interested. > I just committed a few classes in sca/modules/bean and bean-test under revision r522186 to show what I meant by a variant implementation of the assembly model. It looks to me like this code you've been doing in the sandbox now has enough to illustrate a lot of the concepts that have been suggested for a more modular kernel. How about we now talk about what you've done and about how further development of these ideas could happen in trunk? It sounds like everyone now agrees we need a more modular kernel, is everyone willing to start doing this in trunk instead of this sandbox? ...ant Ant, Yes, what I have been doing in the sandbox probably has enough to illustrate modularization of how we handle metadata (models etc.) in our runtime. Like I said in [1] I think some of this work should be done in trunk. I also think that we need a working trunk and as discussed in [2] I'm not advocating for a complete re-write of the kernel, so we may need to find a way to do this modularization work incrementally. Here are some initial ideas to help do this: - Move some of these modules to trunk and evolve them in trunk, then port pieces of the runtime that want to use them incrementally over time, when people feel ready for it. For example we could start using the model I have been proposing in the WSDL2Java tool, that does not mean that kernel/core has to change right away. - Move some of these modules in trunk, and adjust some of the model SPI in trunk (made of classes) to implement the model interfaces that I have been proposing, allowing kernel/core to continue to work with these classes until somebody wishes to do the work to port it to the interfaces. I'm not sure how practical it's going to be, but as usual actually writing the code and trying it will help understand the implications of this approach. What's not in my sandbox yet (and which I would like to see prototyped quickly to help have a concrete discussion on it) is a modularization of the execution part of the kernel. For this to happen I think we need to start looking at ways to assemble our SCA runtime kernel without using SCA itself, as this is causing a sort of a chicken and egg problem at the moment, and preventing modularization of the support for Java components in particular since the kernel/core relies on it to assemble itself. I'm not sure about how to approach this second part of the modularization work. I had indicated in [2] my intention to try first in the sandbox (try to make the support for Java components a separate module), but I'd very happy to work on it in the trunk if our community feels that it's an acceptable approach. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15725.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15978.html Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java
Jean-Sebastien Delfino wrote: ant elder wrote: On 3/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: [snip] Jean-Sebastien Delfino wrote: > >> For example, the "variant implementation of the assembly model" has a >> number of changes that coupled with what you describe above will >> basically require a re-write of kernel. > > I have not committed yet this variant implementation of the assembly > model as I just started to experiment with it yesterday. What I have > in the sandbox at the moment is a set of interfaces defining an > assembly model API, and a default implementation of these interfaces. > The variant implementation that I'm talking about is a prototype of a > different implementation of (a subset of) the same model interfaces, > backed by Spring bean definitions. This will help illustrate how clean > interfaces allow for alternate implementations of one or more modules, > and facilitate the integration with a particular runtime environment > (Spring in this case). I've just spent a few hours on this prototype > so it's not really baked yet, but I'll commit what I have soon so that > people can take a look if they are interested. > I just committed a few classes in sca/modules/bean and bean-test under revision r522186 to show what I meant by a variant implementation of the assembly model. It looks to me like this code you've been doing in the sandbox now has enough to illustrate a lot of the concepts that have been suggested for a more modular kernel. How about we now talk about what you've done and about how further development of these ideas could happen in trunk? It sounds like everyone now agrees we need a more modular kernel, is everyone willing to start doing this in trunk instead of this sandbox? ...ant Ant, Yes, what I have been doing in the sandbox probably has enough to illustrate modularization of how we handle metadata (models etc.) in our runtime. Like I said in [1] I think some of this work should be done in trunk. I also think that we need a working trunk and as discussed in [2] I'm not advocating for a complete re-write of the kernel, so we may need to find a way to do this modularization work incrementally. Here are some initial ideas to help do this: - Move some of these modules to trunk and evolve them in trunk, then port pieces of the runtime that want to use them incrementally over time, when people feel ready for it. For example we could start using the model I have been proposing in the WSDL2Java tool, that does not mean that kernel/core has to change right away. - Move some of these modules in trunk, and adjust some of the model SPI in trunk (made of classes) to implement the model interfaces that I have been proposing, allowing kernel/core to continue to work with these classes until somebody wishes to do the work to port it to the interfaces. I'm not sure how practical it's going to be, but as usual actually writing the code and trying it will help understand the implications of this approach. What's not in my sandbox yet (and which I would like to see prototyped quickly to help have a concrete discussion on it) is a modularization of the execution part of the kernel. For this to happen I think we need to start looking at ways to assemble our SCA runtime kernel without using SCA itself, as this is causing a sort of a chicken and egg problem at the moment, and preventing modularization of the support for Java components in particular since the kernel/core relies on it to assemble itself. I'm not sure about how to approach this second part of the modularization work. I had indicated in [2] my intention to try first in the sandbox (try to make the support for Java components a separate module), but I'd very happy to work on it in the trunk if our community feels that it's an acceptable approach. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15725.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15978.html Thoughts? I haven't seen any replies to this, so under revision r523577 I copied the assembly and policy model modules that I have been working on in my sandbox to the trunk. I put the code under tuscany/java/sca/scdl4j, as discussed in [3], for people to review or experiment with it. This is an addition to the trunk, not breaking any other module. I'm planning to continue to work on this in the trunk under tuscany/java/sca/scdl4j. [3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16122.html -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SCDL4J (was Re: Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java
On 3/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I haven't seen any replies to this, so under revision r523577 I copied the assembly and policy model modules that I have been working on in my sandbox to the trunk. I put the code under tuscany/java/sca/scdl4j, as discussed in [3], for people to review or experiment with it. This is an addition to the trunk, not breaking any other module. I'm planning to continue to work on this in the trunk under tuscany/java/sca/scdl4j. I think this was said on the other thread about this, but just to be clear, this is also going to include XML serializers and deserializers isn't it? So for a start we could just copy all the existing Loaders to the scdl4j module and hook them up to create the various assembly objects? Another thing is should there be a plugable extension mechanism? So for example a JavaScript container would be able to plug in an extension so scdl4j can work with ? If so I'd like to help with these (though i may not get to it for a week or so). ...ant
Re: SCDL4J (was Re: Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java
ant elder wrote: On 3/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I haven't seen any replies to this, so under revision r523577 I copied the assembly and policy model modules that I have been working on in my sandbox to the trunk. I put the code under tuscany/java/sca/scdl4j, as discussed in [3], for people to review or experiment with it. This is an addition to the trunk, not breaking any other module. I'm planning to continue to work on this in the trunk under tuscany/java/sca/scdl4j. I think this was said on the other thread about this, but just to be clear, this is also going to include XML serializers and deserializers isn't it? So for a start we could just copy all the existing Loaders to the scdl4j module and hook them up to create the various assembly objects? Yes. we need serializers/deserializers (or readers/writers) that support the latest SCDL. When I tried to reuse the core loaders as-is a while ago I ran into a number of dependency issues (see [1]). So, for now I'm probably just going to use the SAX handlers that I have put together in my sandbox, to get going and exercise the model without having to do any big breaking changes in the StAX based loaders. In the next few days I think I'm going to focus more on the serializers/serializers to get a complete read/write story in place, which we can refine later. If you or anybody else is interested in trying to use the existing loaders to create the scdl4j assembly objects in the meantime, just go ahead. When it works we can compare and merge and maybe just deprecate the handlers. Another thing is should there be a plugable extension mechanism? So for example a JavaScript container would be able to plug in an extension so scdl4j can work with ? Yes, and it needs to cover the writing of the model in addition to the reading part. If so I'd like to help with these (though i may not get to it for a week or so). ...ant Cool, there's a lot to do to support the latest SCDL version, so let's sync up on the list when you're ready. I'll start to create the structure under scdl4j to host this work. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCDL4J (was Re: Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java
Pressed send too quickly, added the link to the email I was referencing :) Jean-Sebastien Delfino wrote: ant elder wrote: On 3/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I haven't seen any replies to this, so under revision r523577 I copied the assembly and policy model modules that I have been working on in my sandbox to the trunk. I put the code under tuscany/java/sca/scdl4j, as discussed in [3], for people to review or experiment with it. This is an addition to the trunk, not breaking any other module. I'm planning to continue to work on this in the trunk under tuscany/java/sca/scdl4j. I think this was said on the other thread about this, but just to be clear, this is also going to include XML serializers and deserializers isn't it? So for a start we could just copy all the existing Loaders to the scdl4j module and hook them up to create the various assembly objects? Yes. we need serializers/deserializers (or readers/writers) that support the latest SCDL. When I tried to reuse the core loaders as-is a while ago I ran into a number of dependency issues (see [1]). So, for now I'm probably just going to use the SAX handlers that I have put together in my sandbox, to get going and exercise the model without having to do any big breaking changes in the StAX based loaders. [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15361.html In the next few days I think I'm going to focus more on the serializers/serializers to get a complete read/write story in place, which we can refine later. If you or anybody else is interested in trying to use the existing loaders to create the scdl4j assembly objects in the meantime, just go ahead. When it works we can compare and merge and maybe just deprecate the handlers. Another thing is should there be a plugable extension mechanism? So for example a JavaScript container would be able to plug in an extension so scdl4j can work with ? Yes, and it needs to cover the writing of the model in addition to the reading part. If so I'd like to help with these (though i may not get to it for a week or so). ...ant Cool, there's a lot to do to support the latest SCDL version, so let's sync up on the list when you're ready. I'll start to create the structure under scdl4j to host this work. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCDL4J (was Re: Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java
Hi, I'll give a try to reorganize the current StAX based loader framework to support the loading of SCDLs using StAX. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Friday, March 30, 2007 12:42 PM Subject: Re: SCDL4J (was Re: Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java ant elder wrote: On 3/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I haven't seen any replies to this, so under revision r523577 I copied the assembly and policy model modules that I have been working on in my sandbox to the trunk. I put the code under tuscany/java/sca/scdl4j, as discussed in [3], for people to review or experiment with it. This is an addition to the trunk, not breaking any other module. I'm planning to continue to work on this in the trunk under tuscany/java/sca/scdl4j. I think this was said on the other thread about this, but just to be clear, this is also going to include XML serializers and deserializers isn't it? So for a start we could just copy all the existing Loaders to the scdl4j module and hook them up to create the various assembly objects? Yes. we need serializers/deserializers (or readers/writers) that support the latest SCDL. When I tried to reuse the core loaders as-is a while ago I ran into a number of dependency issues (see [1]). So, for now I'm probably just going to use the SAX handlers that I have put together in my sandbox, to get going and exercise the model without having to do any big breaking changes in the StAX based loaders. In the next few days I think I'm going to focus more on the serializers/serializers to get a complete read/write story in place, which we can refine later. If you or anybody else is interested in trying to use the existing loaders to create the scdl4j assembly objects in the meantime, just go ahead. When it works we can compare and merge and maybe just deprecate the handlers. Another thing is should there be a plugable extension mechanism? So for example a JavaScript container would be able to plug in an extension so scdl4j can work with ? Yes, and it needs to cover the writing of the model in addition to the reading part. If so I'd like to help with these (though i may not get to it for a week or so). ...ant Cool, there's a lot to do to support the latest SCDL version, so let's sync up on the list when you're ready. I'll start to create the structure under scdl4j to host this work. -- Jean-Sebastien - 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]
Re: SCDL4J (was Re: Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java
Hi, FYI: I checked in the first cut of the StAX-based loaders under scdl4j/stax. The logic is very similar to the SAX handlers. Thanks, Raymond - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Friday, March 30, 2007 12:59 PM Subject: Re: SCDL4J (was Re: Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java Hi, I'll give a try to reorganize the current StAX based loader framework to support the loading of SCDLs using StAX. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Friday, March 30, 2007 12:42 PM Subject: Re: SCDL4J (was Re: Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java ant elder wrote: On 3/29/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I haven't seen any replies to this, so under revision r523577 I copied the assembly and policy model modules that I have been working on in my sandbox to the trunk. I put the code under tuscany/java/sca/scdl4j, as discussed in [3], for people to review or experiment with it. This is an addition to the trunk, not breaking any other module. I'm planning to continue to work on this in the trunk under tuscany/java/sca/scdl4j. I think this was said on the other thread about this, but just to be clear, this is also going to include XML serializers and deserializers isn't it? So for a start we could just copy all the existing Loaders to the scdl4j module and hook them up to create the various assembly objects? Yes. we need serializers/deserializers (or readers/writers) that support the latest SCDL. When I tried to reuse the core loaders as-is a while ago I ran into a number of dependency issues (see [1]). So, for now I'm probably just going to use the SAX handlers that I have put together in my sandbox, to get going and exercise the model without having to do any big breaking changes in the StAX based loaders. In the next few days I think I'm going to focus more on the serializers/serializers to get a complete read/write story in place, which we can refine later. If you or anybody else is interested in trying to use the existing loaders to create the scdl4j assembly objects in the meantime, just go ahead. When it works we can compare and merge and maybe just deprecate the handlers. Another thing is should there be a plugable extension mechanism? So for example a JavaScript container would be able to plug in an extension so scdl4j can work with ? Yes, and it needs to cover the writing of the model in addition to the reading part. If so I'd like to help with these (though i may not get to it for a week or so). ...ant Cool, there's a lot to do to support the latest SCDL version, so let's sync up on the list when you're ready. I'll start to create the structure under scdl4j to host this work. -- Jean-Sebastien - 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]
