>> I think what I'm really asking is when does the services-config.xml >> metadata get "baked into" a .swf (or .swc)?
When you compile with mxmlc and -services, a subset of your config is baked in the swf. It looks like compc doesn't complain about a -services option, although the 'baked in' aspect of this is code-gen'ed into the generated Flex init code. I don't know whether any of that is generated for a swc, but feel free to give it a try. You could test by compiling a swc with -services, then building a swf (including this swc) without -services and checking for baked in config. The baked in subset of config ends up living here at runtime: mx.messaging.config.ServerConfig#xml If you change services-config.xml, you should recompile the artifact that it's baked into. Avoid compiling it into multiple artifacts. After changes to [RemoteClass]'s you should recompile the respective artifacts they live in. With your componentization all being a compile time concern here, it seems to me like you could get this all to work. Good luck :) Best, Seth From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Maciek Sakrejda Sent: Wednesday, December 10, 2008 9:56 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] RE: services-config.xml: compc or just mxmlc? Seth, Thanks--this is really handy. But I think what I was asking is a little simpler: there are no modules (in the Flex sense of the word) here. I'm essentially just interested in building a main app and being able to extend it after-the-fact with an add-on that gets compiled into a single .swf application. That is: main app: src/index.mxml (the Application, but only a wrapper around Main.mxml) src/Main.mxml (the actual brains of the app) src/util1.as src/util2.as services-config.xml gets compiled into foo.swf (the default app) *and (separately) foo.swc (a library which includes all the classes compiled from the above sources except index.mxml) later on, someone else (with access to index.mxml, services-config.xml, and foo.swc, but not the sources, wants to extend this): extended version: src/index.mxml (same as above, but now modified to reference Extended.mxml) src/Extended.mxml src/util3.as lib/foo.swc (from above) services-config.xml (from above) this gets compiled into super-foo.swf (the extended app) Suppose that the extended version does not even change services-config.xml or add any objects with [RemoteAlias] metadata. Do I need to reference services-config.xml when (1) building the original foo.swc (2) building the super-foo.swf (3) both ? And if I do extend services-config.xml or add new [RemoteAlias] objects to the extended version, does the answer to the above change (obviously, it has to be at least 2 or 3)? I think what I'm really asking is when does the services-config.xml metadata get "baked into" a .swf (or .swc)? -- Maciek Sakrejda Truviso, Inc. http://www.truviso.com -----Original Message----- From: Seth Hodgson <shodg...@adobe.com> Reply-To: flexcoders@yahoogroups.com To: flexcoders@yahoogroups.com <flexcoders@yahoogroups.com> Subject: [flexcoders] RE: services-config.xml: compc or just mxmlc? Date: Tue, 9 Dec 2008 09:43:18 -0800 Hi Maciek, I don't have any practical experience with attempting to compile service config and associated classes into modules and I don't know whether compc would support it or not, but based on some informal discussions with Alex and Jeff I wouldn't recommend it. The core issue is that AMF serialization mappings (client to server class aliases) within Flash Player aren't scoped per module or even app domain as loaded classes are - unfortunately they're scoped to a security domain (broader scope). This means that if the root swf loads two or more modules (each will be loaded in its own child ApplicationDomain by default), where these modules bake in overlapping sets of classes that use [RemoteClass] metadata things won't work. The modules will effectively trample each other's registered class aliases to point to their respective local classes. Say you have a class Foo ([RemoteClass(alias="com.Foo")]), that you've compiled into both modules. You now have two separate class defs on the client (one per module/sub app domain), but only one alias registered (scoped to the security domain both of these app domains belong to). When the loosing module receives a Foo off the network it will fail to deserialize correctly because the alias mapping points to the class def in the other module, which this module doesn't have access to. I think the best approach for now is to place your service config and all shared classes with [RemoteClass] metadata into your root swf, and then expose this to your modules through a controlled API - say a registry of network services or operations the modules can use. You may be able to get away with keeping non-shared classes with [RemoteClass] metadata in specific modules, but I haven't tried that. Best, Seth From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Maciek Sakrejda Sent: Sunday, December 07, 2008 9:42 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] services-config.xml: compc or just mxmlc? Does compc care about the contents of the services-config.xml file? If I compile a .swc component with compc with one set of services defined, but then change the services-config.xml file and build a .swf with mxmlc, are the mxmlc service definitions used for everything? Is it some weird combination? I know I can probably poke at this through experimentation, but the docs explicitly *don't* list service-config as an option that does not apply to compc, so I was curious. -Maciek