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
