Comments inline.
Luciano Resende wrote:
I have modified the SCADomain to utilize sca-contribution.xml to find the
root of the contribution and the deployable composites when these are not
explicitly passed to the SCADomain. This helps simplify our webApp
story and
promote a consistent way to identify deployable composites.
Below, you can find a summary of the usage scenarios of the SCADomain and
how it would use sca-contribution.xml or sca-contribution-generated.xml
newInstance() or newInstance("http://localhost";, null) -> assumes an
sca-contribution.xml, finds the contribution root from it, uses the
deployables specified in it.
newInstance("http://localhost";, ".") -> assumes an sca-contribution.xml,
uses the given location, uses the deployables in contrib.xml
... and determines the actual location of the contribution root using
sca-contribution.xml (same algorithm as in the next case where we
determine the actual location of the contribution using the given path
to a composite, here we use META-INF/sca-contribution.xml instead).
newInstance("http://localhost";, ".", "MyComposite.composite") -> does not
require sca-contribution.xml, finds the contribution from the given
composite and adds the given composite to the domain.
I have also modified the implementation-composite sample to use
sca-contribution.xml to define the deployable composite.
During this exercise, I found that the SCADomain spi is confusing, and
would
like to propose the following signatures to be available :
public static SCADomain newInstance(String domainURI)
public static SCADomain newInstance(String domainURI, String
contributionLocation, String... composites)
and remove the current
public static SCADomain newInstance(String composite)
This should help avoid further confusion
+1, SCADomain.newInstance(domainURI) replaces
SCADomain.newInstance(composite)
Thoughts ?
On 5/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
[snip]
Raymond Feng wrote:
> Hi,
>
> I have now refactored the RuntimeWire.Source and RuntimeWire.Target
> into a new interface EndpointReference uner r538339. The Message
> interface now has the following methods:
>
> public interface Message {
> ...
> EndpointReference<RuntimeComponentReference> getFrom();
> void setFrom(EndpointReference<RuntimeComponentReference> from);
> EndpointReference<RuntimeComponentService> getTo();
> void setTo(EndpointReference<RuntimeComponentService> to);
> }
>
> The EndpointReference can be later on used to implement the
> CallableReference/ServiceReference and it can be serialized as URI to
> represent an endpoint.
>
> Please let me know your opinions.
>
> Thanks,
> Raymond
>
Do we absolutely need these generics? What if we wanted to send a
message back to a client, we probably wouldn't have a component service
to send the message to, right?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
