ant elder wrote:
(don't you hate the way gmail sends the mail before you've finished if you
hit the wrong key)
So the key problem here was that the standard Tuscany bindings aren't the
same as custom ones. Custom bindings and component types need to be in their
own namespace, and the SCDLModelLoader impl needs to have a static
initializer to register the new ScdlFactory. Wouldn't it be better if all
bindings and component types were done the same way? It would make it easier
to see how they work, and for example, say you take an sca module with a
Java component and deploy it in a C++ or PHP or whatever langauge SCA
runtime then Java is not going to be in the default namespace so you'll have
to update your sca.module file wont you?
...ant
On 3/6/06, ant elder <[EMAIL PROTECTED]> wrote:
So the key problem here was that the standard Tuscany bindings aren't the
same as custom ones. Custom bindings need to be in their own namespace, and
the SCDLModelLoader impl needs to have a static initilizer to reg
On 3/6/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
ant elder wrote:
I'm messing about trying to add a new binding to Tuscany but can't get
it to
work. There must be something I'm missing to register the new binding
SCDL
as all I get is the exception below saying "Feature ' binding.ajax'
not
found". Could someone have a quick look if its something obvious? The
code's up at http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/ant/
,
the AJAXAssemblyLoaderTestCase shows the problem.
Thanks,
...ant
java.lang.RuntimeException:
file:/C:/SCA/SVN/WORK/sca/binding.ajax/bin/org/apache/tuscany/binding/ajax/assembly/tests/sca.module
at
org.apache.tuscany.model.scdl.loader.impl.SCDLXMLReader.getRootObject
(SCDLXMLReader.java:103)
at
org.apache.tuscany.model.scdl.loader.impl.SCDLXMLReader.getModule(
SCDLXMLReader.java :61)
at
org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadModule
(SCDLAssemblyModelLoaderImpl.java:101)
at
org.apache.tuscany.binding.ajax.assembly.tests.AJAXAssemblyLoaderTestCase.testLoader
(AJAXAssemblyLoaderTestCase.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run (TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
RemoteTestRunner.java:478)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
RemoteTestRunner.java:344)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (
RemoteTestRunner.java:196)
Caused by:
org.eclipse.emf.ecore.resource.Resource$IOWrappedException:Feature '
binding.ajax' not found. (http:///temp.xml, 23, 24)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(
XMLLoadImpl.java:283)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(
XMLResourceImpl.java:646)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.load (
XMLResourceImpl.java:614)
at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(
XMLDocumentImpl.java:246)
at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(
XMLDocumentImpl.java :225)
at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(
XMLHelperImpl.java
:72)
at org.apache.tuscany.sdo.helper.XMLHelperImpl.load(
XMLHelperImpl.java
:66)
at
org.apache.tuscany.model.scdl.loader.impl.SCDLXMLReader.getRootObject
(SCDLXMLReader.java:100)
... 18 more
Ant,
Good news, I took a look at your AJAX binding in your sandbox and was
able to get your test case working... You just had a few minor problems
in your XSD, missing a namespace prefix declaration, and some left-over
references to axis2.
I am committing the fixes for you. Here are the details:
- In sca-binding-ajax.xsd, removed the <include
location="sca-core.xsd"/> which actually included a copy of the whole
SCDL schema in your Ajax binding namespace. This is not necessary,
instead the base SCDL XSD needs to be correctly imported so that your
AJAXBinding can extend the correct base SCDL Binding type.
- Fixed the location attribute in the <import location="....
sca-core.xsd"> to a correct relative location pointing to sca-core.xsd
in the java/sca/model project from your sandbox/ant/binding.ajax.
- In sca.module, added an ajax namespace prefix declaration for your
Ajax binding namespace and changed <binding.ajax/> to <ajax:binding.ajax
/>.
- Changed the left over references to axis2 to ajax in sca.module and
the test case itself.
Hope this helps...
--
Jean-Sebastien
Ant,
I think you raised a very interesting issue:
The SCA assembly XSD from the 0.9 SCA spec currently includes the Java
component type and the WebService binding in the core namespace. The CPP
component type is also part of the same namespace. I think the idea here
is to make it simpler for an app developer to use these core bindings
and component types without having to fight with XML namespaces and
namespace prefixes.
To illustrate this, let's compare an sca.module with everything in the
core SCA namespace :
<module xmlns="http://www.osoa.org/xmlns/sca/0.9";
xmlns:v="http://www.osoa.org/xmlns/sca/values/0.9";
name="tuscany.samples.bigbank.account">
<entryPoint name="AccountService">
<interface.java
interface="org.apache.tuscany.samples.bigbank.account.services.account.AccountService"/>
<binding.ws
port="http://www.bigbank.com/Account/#AccountServiceSOAP"/>
<reference>AccountServiceComponent/AccountService</reference>
</entryPoint>
<component name="AccountServiceComponent">
<implementation.java
class="org.apache.tuscany.samples.bigbank.account.services.account.AccountServiceImpl"/>
<references>
<v:accountDataService>AccountDataServiceComponent</v:accountDataService>
<v:stockQuoteService>StockQuoteService</v:stockQuoteService>
</references>
</component>
</module>
with the same sca.module if we were using multiple namespaces:
<module xmlns="http://www.osoa.org/xmlns/sca/0.9";
xmlns:v="http://www.osoa.org/xmlns/sca/values/0.9";
xmls:java="http://www.osoa.org/xmlns/sca/0.9/java";
xmls:ws="http://www.osoa.org/xmlns/sca/0.9/webservice";
name="tuscany.samples.bigbank.account">
<entryPoint name="AccountService">
<java:interface.java
interface="org.apache.tuscany.samples.bigbank.account.services.account.AccountService"/>
<ws:binding.ws
port="http://www.bigbank.com/Account/#AccountServiceSOAP"/>
<reference>AccountServiceComponent/AccountService</reference>
</entryPoint>
<component name="AccountServiceComponent">
<java:implementation.java
class="org.apache.tuscany.samples.bigbank.account.services.account.AccountServiceImpl"/>
<references>
<v:accountDataService>AccountDataServiceComponent</v:accountDataService>
<v:stockQuoteService>StockQuoteService</v:stockQuoteService>
</references>
</component>
</module>
I think we should bring up that issue to the SCA spec collaboration team:
- do we want to have the java component type, the cpp component type and
the web service binding in different namespaces from the SCA core namespace?
- if we do that can we simplify and change <java:implementation.java> to
<java:implementation > since the .java is not really necessary anymore.
IMO <implementation.java> or <implementation.cpp> is less error prone
than an xmlns:java="..." + <java:implementation>, and I always get all
these namespaces wrong when I write an XML doc, so I'd prefer to stay
with what we have now in the spec, i.e. all the core bindings and
component implementation types in the core SCA namespace.
Now what about new component types and bindings, which are extensions to
SCA not defined in the core SCA spec?
Again here if I put SCA app developer hat on I would prefer to see them
in the same SCA namespace, and a naming convention like binding.ws,
binding.ajax, implementation.js etc to avoid name collisions. But this
raises a number of issues:
- can people actually add to the SCA core namespace and still comply
with the SCA spec?
- will we have a central XSD containing all the bindings and component
types? How is that extensible, what will be the development process to
modify that central schema?
- if we don't have a central XSD with all the extensions, it'll probably
not be possible to validate sca.module files using XML schema
validation. Is that an issue?
- if all the models for the various component types and bindings are
covering the same namespace, should they be packaged together? or can we
have model fragments packaged in separate jars contributing to a single
namespace?
The alternative is to have new bindings and component types defined in
their own schema, in their own namespace. This is what we have now:
- built-in core component types and bindings in the sca-core.xsd and the
SCA namespace
- others in the other namespaces.
What do people in the group think? Any ideas?
--
Jean-Sebastien
