services-config.xml: compc or just mxmlc?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

services-config.xml: compc or just mxmlc?

Maciek Sakrejda
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
Reply | Threaded
Open this post in threaded view
|

RE: services-config.xml: compc or just mxmlc?

Seth Hodgson
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: [hidden email] [mailto:[hidden email]] On Behalf Of Maciek Sakrejda
Sent: Sunday, December 07, 2008 9:42 PM
To: [hidden email]
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

Reply | Threaded
Open this post in threaded view
|

Re: RE: services-config.xml: compc or just mxmlc?

Maciek Sakrejda
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 <[hidden email]>
Reply-To: [hidden email]
To: [hidden email] <[hidden email]>
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: [hidden email] [mailto:[hidden email]] On
Behalf Of Maciek Sakrejda
Sent: Sunday, December 07, 2008 9:42 PM
To: [hidden email]
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




 


Reply | Threaded
Open this post in threaded view
|

RE: RE: services-config.xml: compc or just mxmlc?

Seth Hodgson
>> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Maciek Sakrejda
Sent: Wednesday, December 10, 2008 9:56 AM
To: [hidden email]
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 <[hidden email]>
Reply-To: [hidden email]
To: [hidden email] <[hidden email]>
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: [hidden email] [mailto:[hidden email]] On
Behalf Of Maciek Sakrejda
Sent: Sunday, December 07, 2008 9:42 PM
To: [hidden email]
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