Hi,
I have checked in the changes under [1].
* A DomainRegistryFactoryExtensionPoint is introduced to collect different
implementations of DomainRegistryFactory
* DomainRegistryFactory is that factory to create EndpointRegistry for a
given registryURI/domainURI. It also has a getSupportedSchemes() to indicate
what URI shemes it supports
* An ExtensibleDomainRegistryFactory wraps the
DomainRegistryFactoryExtensionPoint to make the scheme based delegation. It
loops through all the DomainRegistryFactory objects to check if they can
handle such registryURI/domainURI.
* Two abstract base classes (BaseDomainRegistryFactory,
BaseEndpointRegistry) are introduced to simplify the DomainRegistryFactory
and EndpointRegistry implementations.
The next will rename EndpointRegistry to DomainRegistry and add other types
such as Policy definitions to it.
[1] http://svn.apache.org/viewvc?rev=904367&view=rev
Thanks,
Raymond
--------------------------------------------------
From: "Raymond Feng" <[email protected]>
Sent: Wednesday, January 27, 2010 9:14 PM
To: <[email protected]>
Subject: Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
I'm starting to introduce the DomainRegistryFactoryExtensionPoint, stay
tuned :-).
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Tuesday, January 26, 2010 6:39 AM
To: <[email protected]>
Subject: Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
The key technical requirement AIUI is to support multiple
domain/contribution/composite applications with plugable
implementations of all the runtime extensions to do that. But that
doesn't mean supporting multiple different extension implementations
concurrently in the same active runtime, and so far when we've tried
to do that we've never been very successful - eg the multiple
ServletHost or SCA bindings impls. The runtime is pretty lightweight
and has lazy loading of things all over the place so its probably not
much overhead to run several instances, and its also unlikely that
there would ever be very many different endpoint registry impls wanted
to be run concurrently so its not really going to be a lot of overhead
to use separate runtimes. I can see you're keen to do this though so
why don't you go ahead and implement the tweaks you talked about in
the first email in this thread.
What i do think would be good though is if we could just pick one
registry impl and make it work consistently for all the main use cases
we have instead of trying to maintain several different ones each with
separate capabilities and limitations and test and samples and ways of
being configured.
...ant
On Mon, Jan 25, 2010 at 4:54 PM, Raymond Feng <[email protected]>
wrote:
Come on, Ant. I'm talking about a key technical requirement here:
1) Now we have the ability to run a shared Tuscany runtime in a JVM and
it
can be used to create multiple nodes, with each of them running a
composite
application from one or more SCA domains.
2) The Tuscany runtime (NodeFactory and the ExtensionPointRegistry)
doesn't
keep any application related states, including the
domain/contribution/composite. This is keen to be able to embed Tuscany
in a
managed container such as Web or OSGi so that one shared instance of
Tuscany
runtime to work with multiple composite apps.
3) Requiring different Tuscany runtime instances for composite
applications
from different SCA domains will definitely increase the memory footprint
and
the overhead to bootstrap more Tuscany runtime instances.
4) I'm not against the possibility to use different Tuscany runtime
instances at the application scope, for example, each web app can
potentially package Tuscany runtime in the WAR. But for the shared
Tuscany
runtime case, I want the feasibility to use a singleton to deal with
multiple composite apps from one or more SCA domains that require
different
protocols for the endpoint registry.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Monday, January 25, 2010 1:49 AM
To: <[email protected]>
Subject: Re: Changing the endpoint registry usage to be based on the
discovered impl not the domain uri scheme
On Sun, Jan 24, 2010 at 5:55 PM, Raymond Feng <[email protected]>
wrote:
[[SNIP]]
It sounds like we don't really need multiple registries concurrently
in the same runtime but whats really wanted is a way to have
separately configurable Tuscany runtime instances from the same set
of
Tuscany jars. That would be really useful, it would simplify a a lot
of our code, it would fix other cases where this has been an issue
like the ServletHost problems mentioned above, and it would help with
some other things i've never been able to find easy ways to do with
the current configuration options. So -
NO! Why do we have to clone Tuscany runtime instances in the same JVM
for
the mere purpose of supporting multiple domains? Please remember that
all
the code in the extension point registry is stateless and independent
of
the application state (domain/node/contribution/composite).
Thats a strawman argument Raymond so I'm not going to get drawn into
it.
...ant
