I'm about to check-in some code to support embedding Tuscany in any servlet container -- mostly a servlet listener that launches the runtime. It's not a lot of code (if it were, I'd be worried :), but I could still see moving it out into a separate place in the svn tree & build, once we figure out the layout/strategy for that.
There's currently a "runtime" dir under "sca" where the equinox OSGi and "standalone" runtimes live.. but the standalone being just a packaging thing, and the equinox code isn't active in the build currently. I'm building off the core.launcher pkg, which seems flexible enough with some tweaks. I haven't thought too hard yet about further modularization -- I don't grok the code well enough yet to have a strong opinion..
4) What's the right way to think about Tuscany in relation to a hosting environment? Is it always imbedded or are there use cases where server function in imbedded in Tuscany?
This is a key question IMO. I've been thinking mostly in terms of Tuscany embedding in existing server environments, mostly because those strike me as the most compelling use cases at this point (given SCA as a technology that purports to ease integration). But there's no reason why it can't go the other way around -- e.g. embedding server functionality into Tuscany via something like jetty. Indeed, the current standalone is a very basic "server" that embeds Tuscany. On 7/19/06, scabooz <[EMAIL PROTECTED]> wrote:
Jeremy (and others of course), There have been a few recent threads that have touched on the various aspects of how Tuscany might be imbedded in a larger runtime environment. At least Jeremy is already starting to form a mental model of what that should look like, so I'm wondering if someone could elaborate more in general about what you're thinking. Questions like the following come to mind: 1) Is there a distribution for imbedders? 2) Is the runtime config mechanism extensible enough? 3) Is the build modular enough to only build the pieces you want to imbed? I saw some posts on modularizing the build that seemed useful. ...there's many more questions... Hopefully that's enough to provoke a discussion. Dave Booz --------------------------------------------------------------------- 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]
