On Wed, Apr 30, 2008 at 12:00 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > On Wed, Apr 30, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > Bring this comment to the dev list: > > > > "The tuscany web app support doesn't use this evolving node > > implementation > > just yet. I don't imagine it would be difficult to plug it in ...." > > - http://apache.markmail.org/message/4hvdrcafhapy3kyy > > > > Coincidentally i was having a look at this just the other day after that > > user posted about support for Tomcat with multiple webapps in the same > > SCA > > domain - http://apache.markmail.org/message/ttssxoruzpndkado. > > > > Could you give any pointers at all on where to start with using this > > evolving node implementation like this? Theres no doc and I'm a bit lost > > on > > even which Tuscany modules, samples or tests are current. What I'd like > > to > > do is start exploring the updating of the old runtime-tomcat code to use > > the > > latest domain stuff so that as Tomcat starts up webapps are detected as > > SCA > > contributions and added to a single Tomcat SCA domain. One issue that I > > remember came up last time doing this is that as this happens during > > Tomcat > > startup no http communication can take place so all the registrations of > > contributions with the domain need to be in-vm. > > > > ...ant > > > > Hi Ant > > Am keen to work with you on this. While svn has been down I've spent time > to resurrect a load balancing demo I have on my local disc (not checked in > yet) and would like to update the webapps I'm using to the lasted domain > code but of course I can't. > > Here's a summary of what I think is current in terms of > domain/node/runtime support (but have to admit that there is an amount of > guessing here)..... > > sca/distribution/standalone - not sure but think it's redundant - > forerunner of runtime-standalone? > sca/distribution/tomcat - not sure but think it's redundant - forerunner > of runtime-tomcat? > sca/distribution/war - not sure but think it's redundant - forerunner of > runtime-war? > sca/distribution/webapp - not sure but think it's redundant > sca/modules/domain - old domain SPI > sca/modules/domain-api - old domain API > sca/modules/domain-impl - old domain Implementation - has been superseded > by domain-manager > sca/modules/domain-manager - new domain management application - replaces > domain-impl > sca/modules/host-embedded - original single JVM domain implementation - > still used in most samples > sca/modules/host-webapp - original webapp runtime - fires up tuscany based > on web.xml filter > sca/modules/host-webapp-junit - not sure but have a feeling it's something > to do with running itests in different web containers > sca/modules/node - old node SPI > sca/modules/node-api - old node API > sca/modules/node-impl - old node implementation that runs one or more > composites in a single JVM as part of a distributed domain > sca/modules/node2-api - new node API > sca/modules/node2-impl - new node implementation. This node is coded to > read it's configuration as an atom feed from the new domain-manager > sca/modules/node2-launcher - start up a node from the command line > sca/modules/node2-launcher-webapp - had noticed this before - maybe node2 > integration with webapps has been looked at. Let's see! > sca/modules/runtime - I think this was the last attempt at providing a > common runtime baseline to be specialized for different environments > sca/modules/runtime-standalone - command line runtime > sca/modules/runtime-tomcat - deep tomcat integration (IIRC) > sca/modules/runtime-war - war rutime > sca/modules/workspace - SPI for some of the machinery required to process > contributions at the domain level. Used by domain-manager > sca/modules/workspace-impl - Implementation of the workspace > sca/modules/workspace-xml - Reading/writing workspace as XML > > So can we get together here and work out what the true picture is and how > to mode modules/runtime* to node2. First things first I'm going to go look > at node2-launcher-webapp. > > I think the start up process for nodes in a webapp will potentially be > easier now as the node is just reading atom feeds and not making soap calls. > Time will tell! > > Simon > Great, working together would be good and i'm sure make getting somewhere useful happen much quicker :) Thanks for the list of module statuses thats helpful, i'll also go look the node2-launcher-webapp one. The comment on the use of atom feeds is interesting. To be honest i'd hope we could have a way to avoid that being needed in this Tomcat use case, or at least being optional. One issue we had last time when we tried to do this was that there had to be a separate standalone "domain manager" running before you could start up a Tomcat instance, and that sucks quite a bit IMHO so i'd like to try to get a design from the beginning where its not needed. This will all be happening in a single JVM and with the code bootstrapping Tuscany being at the "top" classloader so everything should be accessible to just make direct SPI calls to configure a domain instead of going via a remote binding shouldn't it? There have been some emails recently about the domain/workspace SPIs i guess i need to go read more closely what they were about. ...ant
