Jean-Sebastien Delfino wrote:
ant elder wrote:
On 4/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Raymond Feng wrote:
> Hi,
>
> I think we should start to leverage the extensibility story (see the
> thread titled "The pluggability for Tuscany runtime extensions")
> instead of hard-coding all the processors into the SimpleRuntimeImpl.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, April 11, 2007 10:14 AM
> Subject: svn commit: r527581 - in
> /incubator/tuscany/java/sca/modules/host-embedded: pom.xml
> src/main/java/org/apache/tuscany/host/embedded/SimpleRuntimeImpl.java
>
>
Raymond,
I agree that we need to leverage the runtime extensibility story, for
runtime extensions :)
But are the WSDL and Java interface support really extensions or
part of
the base SCA assembly support?
On one hand, no, they are not real extensions as they are part of the
base SCA assembly spec. So we don't need to handle them as extensions,
SimpleRuntimeImpl can depend on them the same way as it depends on the
assembly-xml module.
On the other hand, we could consider them as extensions, as Java and
WSDL are just two of many programming languages that can be used to
define service interfaces. To do this we just need two new Maven
modules
hosting their ModuleActivators. Going further, we could even consider
assembly-xml as an extension, and have a ModuleActivator for it as
well.
So, our new modularized kernel structure allows for both approaches.
It's a matter of where we want to draw the line between core SCA and
extensions. At the moment, I'm tempted to follow the structure of the
SCA specifications to draw these lines. What's in the SCA assembly spec
is part of the base, what's not in the SCA assembly spec is extensions.
But I could be convinced otherwise...
Thoughts?
I'd be leaning to making them proper extensions unless it makes the code
significantly more complicated.
One of the problems we've had in the past is that by not making
things like
Java 1st class extensions then when it comes to adding something else
as a
real extension various issues get exposed. Another thing is that the SCA
assembly spec also says that the WS binding MUST be supported by an SCA
runtime so following the argument above our Axis2 binding could be
hardcoded
into the runtime which doesn't seem right.
...ant
Ok, good points. Like I said above I could be convinced... both
Raymond and you seem to favor that direction so, if anybody has time
to create the two new Maven modules (interface-java-runtime and
interface-wsdl-runtime) contributing the corresponding
ModuleActivators then let's just do that as it's cleaner. If nobody
else gets to it before tomorrow then I'll try to do it tomorrow.
I have created the two Maven modules contributing the ModuleActivators
for interface-java and interface-wsdl:
- modules/interface-java-runtime, registers the StAX artifact processor
for <interface.java>
- modules/interface-wsdl-runtime, registers the StAX artifact processor
for <interface.wsdl> and the URL artifact processor for WSDL documents
For now I have kept a dependency on these two modules in host-embedded
(with <scope>runtime</scope>) to avoid having to touch all the samples
and integration tests that use Java and WSDL interfaces and have to add
these 2 modules to them individually. Once they all have the correct
dependencies we can remove the dependency in host-embedded.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
