On Thu, May 8, 2008 at 8:19 PM, ant elder <[EMAIL PROTECTED]> wrote: > I've been trying to use the new distributed domain stuff - domain-manager > and node2* etc - to get Tomcat as a domain manager with SCA webapps being > individual nodes, but not really making much progress getting it to work so > asking here to see if there are any suggestions - mainly from you Sebastien > as you've written most of those new modules :-) > > What i'd like is for during Tomcat startup to create a domain manager and > then as each webapp is initialized create a new node for each webapp and > register it with the domain, and to do that registration with in-JVM calls. > Right now the domain manger needs to know about all the nodes before the > domain can be started (i think?) but thats problematic in this scenario as > the webapps are initialized one by one and its hard to batch all those up > and then initialize the domain and then correctly insert the node into the > webapps context. This is discussed in a bit more detail in the thread at > [1]. > > I wondered about enhancing the domain manager so that it can be created > "empty" and then create/register nodes one-by-one and then activate the > domain once thats done (which probably would require the more dynamic > endpoint stuff being talked about in [2]), but I'm not sure that approach > really fits in with the current design of the distributed domain support? > > WDYT, any comments or suggestions? > > ...ant > > [1] http://apache.markmail.org/message/2i6gtkveapk3n4nr > [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30314.html >
I'm sure Sebastien will jump in with a completely different scheme but I'll have a stab at explaining my mental model of what has been built;-) I guess the first question is why does Tomcat have to run the domain manager. Is the assumption here that the scope of a domain is restricted to a single instance? It doesn't seem a big burden to assume that the domain manager would always be running separately. Looking at the code in trunk is seems that there is some generic webapp launcher code that supports this scenario. I haven't tried it though so Sebastien would have to explain it. I know there has been some discussion of these kinds of scenarios on the user list so lets assume that you do want to have this restriction and that you want the user experience of adding SCA webapp contributions directly to Tomcat (by dropping them in the webapps directory). The domain manager is a stateless app. As you prod it to ask it for details of, say, a configured composite it fluffs up all the information it needs from the files on disc (workspace.xml, domain.composite, cloud.composite) for each request. This is important because while, at the moment, the domain manager web GUI is used to update these files as new things are added in reality, of course, anything can update them. So, for example, you could have a piece of code that runs in your container play the role of the domain manager and update these files. Sounds like it would require some deep integration. You can then reuse all the code that does useful things with the information to get the nodes running. So you could imagine this new piece of code doing the following; 1 - notice that a webapp has been started (and that webapp is an SCA contribution) 2 - update the files to add a new node associated with a composite from the new webapp contribution 3 - provide to the new webapp a configured composite based on configuration now in the files. There is the problem here though that you pointed out. All webapps would have to be processed for steps 1 and 2 before step 3 could be performed. The domain manager logic assumes this is the case. This is because to fully resolve a composite you will need endpoint information for all of the services it references. These could be in any of the webapps that are added to Tomcat. Without changing this static configuration scheme a couple of strategies come to mind. Calculate the composites for all webapps each time a webapp contribution is added. For any composite that has changed since last time it was generate restart its node. Sounds like it would be awfully slow. Or Only fire up the node in the webapp when the composite for that webapp is know to be fully resolved. I like this better but there are some wrinkles as if you have references with multiplicity > 1 you can't tell when the're fully resolved. If you are up for adding a bit of dynamic behaviour we could extend the domain manager to provide a feed of the services that are currently available in the domain and then use this in conjunction with the dynamic binding stuff I'm currently working on to allow references to be resolved at point of time after composite start. Quite a bit of work there though. Simon
