TypeMappings - lifecycles and locations

[Glen Daniels <gd...@macromedia.com>]

A few comments/ideas on TypeMappingRegistries.

Where shoudl typemappings be defined?  I see two major scopes:

1) Global, engine-wide mappings.
2) Service-specific mappings.

(there's also a potential to define another layer of scoping here, such as
"accounting department services", which I'd like to keep in mind but not do
much about now)

Do we want to enable multiple engines with different "global" mappings in the
same JVM?  If we don't care about this case, let's just make the global
mappings a statically-accessible singleton, perhaps?

In any case, I don't think MessageContext is the right place for TypeMappings
to live, and I'd like to pull them out of there ASAP.  There might still be a
getTypeMappingRegistry() in there, but it should return the global mapping
registry unless the service has been determined, and in that case the
service-specific registry.

All service-specific registries should point to the global registry as their
parent.

TypeMappingRegistry should be made thread-safe.  This should perhaps happen in
two steps.  First, keep the Deserializers themselves stateful (one per
element), but make sure the factories and such are thread-safe.  Then, we might
eventually move to a stateless model for the deserializers (keeping state in
thread-local storage or in the MessageContext/DeserializationContext).

How does all that sound to folks?  I can get started on this soon.

--Glen

Re: TypeMappings - lifecycles and locations

[Rob Jellinghaus <ro...@unrealities.com>]

+1

Cheers,
Rob

At 02:30 PM 6/1/2001 -0400, Glen Daniels wrote:
>A few comments/ideas on TypeMappingRegistries.
>
>Where shoudl typemappings be defined?  I see two major scopes:
>
>1) Global, engine-wide mappings.
>2) Service-specific mappings.
>
>(there's also a potential to define another layer of scoping here, such as
>"accounting department services", which I'd like to keep in mind but not do
>much about now)
>
>Do we want to enable multiple engines with different "global" mappings in the
>same JVM?  If we don't care about this case, let's just make the global
>mappings a statically-accessible singleton, perhaps?
>
>In any case, I don't think MessageContext is the right place for TypeMappings
>to live, and I'd like to pull them out of there ASAP.  There might still be a
>getTypeMappingRegistry() in there, but it should return the global mapping
>registry unless the service has been determined, and in that case the
>service-specific registry.
>
>All service-specific registries should point to the global registry as their
>parent.
>
>TypeMappingRegistry should be made thread-safe.  This should perhaps
happen in
>two steps.  First, keep the Deserializers themselves stateful (one per
>element), but make sure the factories and such are thread-safe.  Then, we
might
>eventually move to a stateless model for the deserializers (keeping state in
>thread-local storage or in the MessageContext/DeserializationContext).
>
>How does all that sound to folks?  I can get started on this soon.
>
>--Glen
>
>
>
>