What would be in the core namespace of a PHP SCA runtime? If a goal is to be able to take any SCA module and deploy it unchanged in any SCA runtime then doesn't it have to be consistent - either everything in the core namespace or everything in its own namespace?
...ant On 3/7/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > 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 > >
