Brady, Instead of having the system paths be set up as a colon-delimited list, could we instead have it set up as a "root" directory, underneath which all other dirs would be pulled in as apps? For example, instead of "apps/services/service1:apps/services/service2:..." could we just use "apps/services" as a root and then each composite under that would be pulled in as a "system"?
I can see a problem in that some composite files may include sub-composite files, in which case we do NOT want to pull in those sub-composite files (since they would already be read in from the main file). I dunno, maybe the colon delimited list is better, but it's worth a thought, I guess. It just seems like a colon-delimited list can get bothersome with a large number of loaded apps. Also, the spec says that the "system" composite isn't a real entity from a file on disk (which suggests that the current behavior of having a "root" composite file for all apps may need to change), but rather it should be a "repository" which all loaded composites should reside "as if ... containing an <include../>". This seems to say that we should load up a single system object, but we can then search for composites (either though the colon-delimited list or whatever), and then we load them up into the system composite as "includes". Then after than we can resolve that composite as if it existed on disk with all of those include directives. This would allow us to keep a single composite for the "system" and not have to worry about mapping multiple system composite objects. What are your thoughts? Thanks! -- Michael Micucci -- Project Team Lead - HydraSCA Agent Core Project -- Roguewave Software - [EMAIL PROTECTED] -----Original Message----- From: Brady Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 3:22 PM To: [email protected] Subject: RE: [TuscanySCA CPP] problems trying to load services from multiple directories at once After reading through the 0.96 Assembly Model spec, a system is not any one entity, but rather, to quote the spec: "The SCA System has no single file which represents its contents. The SCA System is a notional entity, built from the set of composite files which are deployed into it. The set of files is indentified by the files being placed into a specific location ("the system directory") in the filesystem or repository which is used to support the SCA system. The system directory acts as if it is a composite containing an <include../> element for each of the composite files contributed." So what I am doing is trying to represent multiple "systems" in the same TuscanySCA runtime, which I believe was originally intended to represent only one system. So the use cases as I see it are as follows: - Single System in a single TuscanySCA runtime (existing behaviour) - Multiple Systems in a single TuscanySCA runtime In order to support the second use case (Multiple Systems in a single TuscanySCA runtime) I would like to propose the following changes: - If the systemRoot used to instantiate the runtime has colons, then each colon seperated path will be an individual system, and systemPath will have no affect. - If systemRoot does not have colons, then the behaviour will be as is now, and systemPath may affect loading if present. - SCARuntime can now have multiple systems, so getSystem() will be replaced by getSystem( std::string name ) where name is the composite/name element of the top level composite. (How intrusive will this be???) - There will also have to be a new method to get the system names: std::list<std::string> SCARuntime::getSystemNames() Thoughts anyone? -------------------- Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -----Original Message----- From: Mike Micucci [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 11:35 AM To: [email protected] Subject: RE: [TuscanySCA CPP] problems trying to load services from multiple directories at once Brady, I'm a little unclear on how system composites are supposed to work. When I first went through the composite loading code I got the impression that a system composite was meant to list all the services for an entire server (i.e. a "root" composite). Is that the case? Or is a "system composite" meant for a particular service (hence we'd expect to see multiple "system composites" in a particular Tuscany setup)? With the latter, I think your proposal makes sense. Personally, I'd rather see the loading of the composites done via a stronger API than setting up an environment variable (an API or a direct option mechanism has the advantage of being checked and having better error messages/diagnostics), but this way may be simpler and more straightforward. In this case, it sounds like we can maybe even eliminate the need for a separate environment variable. If a system composite is meant for an entire server then we may have to slightly alter the composite loading mechanism if we want to allow multiple different services to be available. From what little bit I know though, this sounds unlikely so hopefully your change will work out. Thanks! -----Original Message----- From: Brady Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 10:26 AM To: [email protected] Subject: RE: [TuscanySCA CPP] problems trying to load services from multiple directories at once I think I figured out how to make this work, but I don't think it's the intended usage. If I set TUSCANY_SCACPP_SYSTEM_ROOT to: "~/tuscany/services/serviceA:~/tuscany/services/serviceB" And leave TUSCANY_SCACPP_SYSTEM_PATH blank, then I get all of the services loaded. Its not loaded as intended though, since what it does is populate the SCARuntime::system composite with the system composites from serviceA and serviceB. Does that seem correct? -------------------- Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -----Original Message----- From: Brady Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 10:17 AM To: [email protected] Subject: RE: [TuscanySCA CPP] problems trying to load services from multiple directories at once I have since updated the JIRA with a clarification of what I am trying to do and have included it here in <JIRA update> tags. <JIRA update> Just to clarify one piece of information about this problem: serviceA and serviceB are totally unrelated. The system composites are located as follows: ~/tuscany/services/ | +----->serviceA/serviceA.composite | +----->serviceB/serviceB.composite </JIRA update> Seems like the problem is that the SCARuntime was designed towards just having one service loaded at a time. And what I am trying to do is to be able to load several unrelated services. -------------------- Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -----Original Message----- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 9:42 AM To: [email protected] Subject: Re: [TuscanySCA CPP] problems trying to load services from multiple directories at once I think that them intent is for any composites under the TUSCANY_SCACPP_SYSTEM_ROOT to be loaded so I think it may be an error to specify a _PATH that includes or is a subdirectory of the SYSTEM_ROOT. Maybe we could police this or change the loader to ignore duplicates from the same location.?? On 10/07/07, Brady Johnson <[EMAIL PROTECTED]> wrote: > > I created a JIRA for this issue: > https://issues.apache.org/jira/browse/TUSCANY-1418 > > Im trying to start the Tuscany SCA runtime so that it loads several > service directories at once. Im assuming that this should be achieved > by using the systemPath argument of the > SCARuntime::initializeSharedRuntime() method. Im also assuming that > the systemPath should be a ":" (colon) or ";" (semi-colon) seperated > list of directories, each of which is a separate SCA service > directory. > > If my assumptions are correct, then what purpose does the systemRoot > paramater serve when systemPath is specified? > In the call to ModelLoader::load(), if systemPath is specified, then > the following call is made: > ModelLoader::loadComposites(systemRoot + PATH_SEPARATOR + > systemPath); > > So lets assume that systemRoot is "~/tuscany/services" and systemPath > is "~/tuscany/services/serviceA:~/tuscany/services/serviceB" > Then ModelLoader::loadComposites() will be called with this string: > > "~/tuscany/services:~/tuscany/services/serviceA:~/tuscany/services/ser > vi > ceB" > Since the Files() constructor in loadComposites has the subdirectories > parameter set to true, the directories will be traversed as follows: > 1. everything under "~/tuscany/services" (including serviceA and > serviceB) > 2. everything under "~/tuscany/services/serviceA" > 3. everything under "~/tuscany/services/serviceB" > > This is problematic since the services get loaded/parsed multiple times. > > > When systemPath is set, changing the call do loadComposites() to this: > ModelLoader::loadComposites(systemPath); > Avoids the multiple loading of the services. There is still some sort > of error when loading multiple services when loadComposites() is > called this way. It appears that the systemComposite is being > overwritten somehow and ends up empty. > > Before digging into the second problem further, I would like to make > sure that my previous assumptions are accurate. It may be that Im not > invoking the runtime correctly. > > -------------------- > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] > -- Pete --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]
