Hi,
I added the namespace support for the SAX handler and a minor fix to call
setXSDType against Property.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, March 13, 2007 1:08 PM
Subject: Assembly metadata, was: Queries on References
Jean-Sebastien Delfino wrote:
[snip]
Jean-Sebastien Delfino wrote:
Venkata Krishnan wrote:
Hi Sebastien,
I agree with your suggestions on two accounts...
- its really good to have the model defined around interfaces as it
gives
the flexibility to improve / modify the implementations we choose over
a
period of time without the impacting the core which I assume will use
only
these interfaces. If we use factories to instantiate model objects
(i.e.
specific implementations of these interfaces) that will keep the core
futher
away from impacts of changes to implementation of the SPI model. We
could
probably configure the factory class to be used as part of the scdl -
for
example as the property of a Loader(s). Hope I am making sense?
Yes, making a lot of sense to me...
I've created an AssemblyFactory interface. Hope it will help decouple the
various modules. I'll try what you're proposing to pass the factory to the
loaders once I manage to get past the circular dependencies with Deployer
that I mentioned in
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/[EMAIL PROTECTED]
(and are preventing me to build the loaders at the moment). If anybody has
any ideas on how to best refactor this to avoid circular dependencies,
let's talk about it.
- Specific to the case of references, I did imagine that we may have to
clearly abstract out references at componentType level, component level
and
composite level as there is something specific in 'references' to each
level
- for example the 'promote' is something that is specific to the
composite
level.
Yes, there's a 4th level in constrainingType, which is the most abstract
and does not have a binding or policySets, but I guess we can go step by
step so I'm not sure we need it yet... I'll leave it up to you.
I have started to make some changes in the SPI model of the kernel.
But
then, it is not going to be difficult for me to migrate this to your
proposed design in the 'assembly'. So I shall continue for now in the
kernel unless you see some issues.
Good, we'll see if we have the same reading of the spec :). What I
posted below was just an initial idea so let me know when you have a
code update on your side and we'll see how we can exchange ideas and
sync up our interfaces / classes.
Thanks.
- Venkat
The same scheme works for Services as well, so I've added similar Service
interfaces + a Wire interface. I'm thinking that all the policy related
stuff will end up in a separate module but for now I've created
placeholders for policy attachments in o.a.t.policy.model.
I'll double check with the spec to see if the same scheme applies to
Properties as well.
I've added Properties and also interfaces for Component, ComponentType and
ConstrainingType referencing the interfaces above.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
