[ANNOUNCE] Apache Tuscany Java DAS 1.0-incubating-beta1 released
August 21st 2007 - Apache Tuscany is pleased to announce the 1.0-incubating-beta1 release of the Java DAS project. Data Access Services (DAS) works together with Service Data Objects (SDO) simplifying handling of data when interacting with the back-end data source and frees application developers from dealing with tedious and error-prone transformation between end source types and SDO Data Object Types/properties. Key features of 1.0-incubating-beta1 release are : - Support for J2SE connections in DAS config using Driver Manager. - Added support for multiple database schemas in queries - Enhanced Optimistic Concurrency Control with overqualified updates - Multiple enhancements around ApplyChanges API - Enhanced Documentation : User, Developer and Architect guides as well as javadocs - Enhanced and new sample applications For a complete list of changes on this release, please view the release notes. https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1/distribution/binary/RELEASE_NOTES To download Java DAS please follow the link to http://incubator.apache.org/tuscany/das-downloads.html Apache Tuscany welcomes your help. Any contribution, including code, testing, improving the documentation, or bug reporting is always appreciated. For more information on how to get involved in Apache Tuscany visit the website at: http://incubator.apache.org/tuscany. Thank you for your interest in Apache Tuscany! The Apache Tuscany Team. --- Tuscany is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Web services PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1463) Support for Clob and Array fields
[ https://issues.apache.org/jira/browse/TUSCANY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521702 ] Adriano Crestani commented on TUSCANY-1463: --- Commited ; ) Amita, I had some problems applying this patch, I think it was something with my svn, than I fixed it manually. Can you please check if the tests are running as you expect? Regards, Adriano Crestani > Support for Clob and Array fields > - > > Key: TUSCANY-1463 > URL: https://issues.apache.org/jira/browse/TUSCANY-1463 > Project: Tuscany > Issue Type: Bug > Components: Java DAS RDB >Affects Versions: Java-DAS-Next >Reporter: Amita Vadhavkar >Assignee: Amita Vadhavkar > Fix For: Java-DAS-Next > > Attachments: 1463.patch, moin-www.png > > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19981.html, > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20400.html > Action on the issues discussed in above mails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
Hi, Are there plans to include 'spi' to the names of packages in the spi module as part of this effort ? Thanks - Venkat On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Module core contains an o.a.t.sca.scope package. > > I'm trying to fix package names to be consistent with the module names > so o.a.t.sca.scope should be renamed to o.a.t.sca.core.scope, but > there's already another o.a.t.sca.core.scope in module core! > > What is the difference between these two packages? > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Simple scenario integrating policies with runtime
Hi... With some implementation for the policy fwk model, I have tried to get a simple scenario of the runtime integrated with policies. I have extended the binding-echo-extension sample to include a policy now. Presently the intention is not to demonstrate the policy framework - rather the intention is to use this scenario to identify and prioritize things that need to be fleshed further in the policy fwk implementation. Please feel free to comment on the direction that I am headed with this. Thanks - Venkat
[jira] Commented: (TUSCANY-1564) xsi:type not always set for complexTypes
[
https://issues.apache.org/jira/browse/TUSCANY-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521605
]
Pete Robbins commented on TUSCANY-1564:
---
I have applied a patch to the branch only which I believe works. I think that
we should always write xsi:type information for properties that are of an
abstract type. In this case the property 'request' is of abstract type
'requestType' so we must specify what the real type of the property is.
I have tested this and it appears not to break anything else so please can you
try this out in php and let me know.
> xsi:type not always set for complexTypes
>
>
> Key: TUSCANY-1564
> URL: https://issues.apache.org/jira/browse/TUSCANY-1564
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: Win XP and Gentoo Linux
>Reporter: Matthew Peters
>
> This has been reported by a user of the PHP SDO code. I have verified that he
> is right - the problem does exist. I will cut and paste in the PHP example
> from the defect http://pecl.php.net/bugs/bug.php?id=11774 but the php-ness of
> the example is irrelevant: under the covers we are just manipulating a C++
> SDO and then calling XMLHelper->save()
> In the defect text below he puts in both expected and actual output. He is
> right to raise the problem in the sense that I have tried reading in the
> actual and expected xml under XERCES with schema validation turned on, and
> the actual will *not* validate whereas the expected will.
> Incidentally there is some history w.r.t. xsi:types - in a different case
> they were coming out when we did not want them and they were suppressed for
> us. See for example JIRA 1297. I do not know the rules which should determine
> whether it should be present or not.
> Here follows the original PHP defect.
> Description:
>
> xsi:type is not always set for complexTypes. Notice the absence of
> xsi:type="collectionInfo" in the actual output.
> Reproduce code:
> ---
>
> http://www.w3.org/2001/XMLSchema";>
>
>
>
>
>
>
>
>
>fixed="collectionInfo"/>
>
>
>
>
>
>
>
>
>
>
>
> try {
> $xmldas = SDO_DAS_XML::create("request.xsd");
> try {
> $doc = $xmldas->createDocument('', 'request-list');
> $rdo = $doc->getRootDataObject();
> $request = $xmldas->createDataObject('', 'collectionInfo');
> $request->collection->insert('Blah');
> $request->kind = 'collectionInfo';
> $rdo->request->insert($request);
> print($xmldas->saveString($doc));
> } catch (SDO_Exception $e) {
> print($e);
> }
> } catch (SDO_Exception $e) {
> print("Problem creating an XML document: " . $e->getMessage());
> }
> ?>
> Expected result:
>
>
> http://www.w3.org/2001/XMLSchema-instance";>
>
> Blah
>
>
> Actual result:
> --
>
> http://www.w3.org/2001/XMLSchema-instance";>
>
> Blah
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Current XQuery implementation issues
Hi Vasil, Some comments, answers, and more questions :) inline. Vasil Vasilev wrote: Hi All, You can take a look at http://issues.apache.org/jira/browse/TUSCANY-1536 for a list of current issues with the XQuery implementation. For issues 1 and 6 a wrote an e-mail to the Saxon mailing list and I am waiting for an answer. For the other issues: 2. I need the data type of the input and output of the data that go into and out of the XQueryInvoker be of the Saxon data type. That's why I need to set the data binding in some way from the side of the XQueryInvoker. What I am not sure is if this is the right way, or is this more a hack to do it? What you're describing sounds right to me. The general idea is that an implementation should be able to tag the interface it's providing or requiring with a particular databinding (because the implementation logic wants that particular databinding, or because the technology you're using in your implementation extension works with that databinding, Saxon in your case). I'd be interested in your feedback and whether you think it's easy enough to do, or if it feels more like a hack :) You also mentioned in the JIRA that you had to make the interface remotable. There may be an issue with the Tuscany databinding framework here, I'd imagine that it you had a string of XQuery components (all using the same Saxon binding), you'd probably not want to have to mark their interfaces remotable. Raymond, what do you think? Isn't that an issue? why couldn't this work with a local interface as well? 3. I didn't have the time to do it, but generally it is possible to be done. Yes I'd think so. It looks like a good thing to do as I guess most XQuery component developers will work with XSDs and will probably interact with Web Services as well. Some may even say that they only care about XML and don't want to have to deal with any Java code or Java interface :) 4. I would like to know if a can use some kind of context, which is associated with given request and if I can use this context to put some data there. I do not want this context to be transferred in web service invocation for example, but only in the chain of transformers to the target invoker. We may be able to extend the Tuscany Message or EndpointReference to carry extra context data, but could you give me a little more background on what kind of data you'd like to pass or keep around, and how it's going to be used? In the JIRA you mentioned "which configuration is associated with an invocation"... The message carrying an invocation should have pointers to assembly model representing the from (reference) and target (service), from which I think you could navigate to the binding model and its configuration. Is that the kind of configuration you're looking for? or some other configuration? 5. This limitation is again due to the fact I didn't have time to implement it. Ok, time is always too short :) 7, and 8 - are just questions if somebody knows is this the right way to do it. For 7, are you talking about Web Services? or is it an assumption you made in the XQuery component? (8) looks like bug, we should create a JIRA for it. Another thing that we should think about is whether it is useful to provide a scope for the XQuery implementation. Currently it is not scoped. Ah interesting, I'm not an XQuery expert :) so do you have an example showing the kind of state that an XQuery component could support? Are you thinking about keeping variables around across multiple invocations of the same component? Thanks... Bye, Vasil - Познай победителя във Формула 1 и спечели награда! http://www.clubf1.net/ - 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]
[jira] Resolved: (TUSCANY-1566) Element coming out in the wrong namespace
[
https://issues.apache.org/jira/browse/TUSCANY-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Robbins resolved TUSCANY-1566.
---
Resolution: Fixed
Fix Version/s: Cpp-Next
Fixed in HEAD and the branch.
> Element coming out in the wrong namespace
> -
>
> Key: TUSCANY-1566
> URL: https://issues.apache.org/jira/browse/TUSCANY-1566
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: WinXP
>Reporter: Matthew Peters
> Fix For: Cpp-Next
>
> Attachments: Atom1.0.xsd
>
>
> We have a schema file that defines an atom feed. It specified
> elementFormDefault="qualified" so that lower level elements should be in the
> target namespace. I will attach the schema as a separate file. With a very
> simple php test case as follows:
> $xmldas = SDO_DAS_XML::create('Atom1.0.xsd');
> $document = $xmldas->createDocument('http://www.w3.org/2005/Atom','entry');
> $entry = $document->getRootDataObject();
> $author = $entry->createDataObject('author');
> $author->name[] = "Caroline Maynard";
> print $xmldas->saveString($document,2);
> we get
>
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns:tns="http://www.w3.org/2005/Atom";>
>
> Caroline Maynard
>
>
> whereas we should see the element in the tns namespace.
> I have checked this with XERCES: the xml that we are generating will not
> validate, whereas if I alter it to have in the tns namespace it will.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [NOTICE] Brady Johnson voted as Tuscany committer
Thanks everybody. I'm really excited about this and looking forward to working with all of you. Best Regards Brady -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 21, 2007 1:03 PM To: tuscany-dev@ws.apache.org Subject: Re: [NOTICE] Brady Johnson voted as Tuscany committer Congratulations, Brady! It has been great to see what you have been doing to improve the "native" implementation. Simon Raymond Feng wrote: > Welcome on board, Brady. > > Raymond > > - Original Message - From: "Pete Robbins" > <[EMAIL PROTECTED]> > To: > Sent: Tuesday, August 21, 2007 7:42 AM > Subject: [NOTICE] Brady Johnson voted as Tuscany committer > > >> The Tuscany PPMC and Incubator PMC have voted for Brady to become a >> Tuscany committer. >> >> Congratulations and welcome Brady! >> >> I look forward to your continued excellent contributions to Tuscany. >> >> Cheers, >> >> -- >> Pete >> - 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]
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
Raymond Feng wrote: Hi, The o.a.t.sca.scope contains the interfaces/classes which used to be SPIs while the o.a.t.sca.core.scope contains implementation classes. As we approach release 1.0, I'd like to suggest again that we pick a consistent naming convention for SPIs and implementation classes. We should bear in mind that SPIs are divided into two types: 1. Interfaces intended to be implemented by extensions. Adding methods to these is a breaking change for extensions and should be avoided if possible. 2. Interfaces intended to be called by extensions. Removing methods from these is a breaking change for extensions and should be avoided if possible. Ideally I'd like to see a clear naming convention that distinguishes implementations / type 1 SPIs / type 2 SPIs. Would others like to see this? If so, I'll make a concrete proposal. Simon Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 21, 2007 10:33 AM Subject: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope Module core contains an o.a.t.sca.scope package. I'm trying to fix package names to be consistent with the module names so o.a.t.sca.scope should be renamed to o.a.t.sca.core.scope, but there's already another o.a.t.sca.core.scope in module core! What is the difference between these two packages? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Congratulations, Brady! It has been great to see what you have been doing to improve the "native" implementation. Simon Raymond Feng wrote: Welcome on board, Brady. Raymond - Original Message - From: "Pete Robbins" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 21, 2007 7:42 AM Subject: [NOTICE] Brady Johnson voted as Tuscany committer The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Renaming binding-ajax to binding-dwr?
How about binding-ajax-dwr? This seems to go well with binding-ws-axis2. Simon Mike Edwards wrote: +1 to the rename. Best to name the binding by the transport mechanism involved, not the implementation used to drive it. Yours, Mike. Jean-Sebastien Delfino wrote: ant elder wrote: On 8/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: I'd like to rename binding-ajax to binding-dwr, as Ajax is a really generic term, and it will make clear that this binding is actually using the DWR (Direct Web Remoting) protocol. Thoughts? Right now that it uses DWR is an implementation detail thats not exposed anywhere, just as Axis2 is not exposed anywhere in our binding.ws, so really we can call it whatever we like. Axis2 is an implementation detail, and that's the reason why we do not say in SCA. However, the protocol used to expose a service in an SOA is not an implementation detail at all... Here are three examples: binding.ws -> the SOAP protocol is used to talk to the service binding.jsonrpc -> the JSON-RPC protocol is used to talk to the service binding.ajax -> the Direct Web Remoting protocol is used to talk to the service Binding.dwr will better indicate than binding.ajax that the service is provided through the DWR protocol. To web clients binding.jsonrpc used to work acidentically to binding.ajax but the last couple of changes to binding.jsonrpc mean they've now got out of sync. If renaming binding-ajax will help you engage in keeping these both updated to work the same then Yes! lets rename it. ...ant OK, I'll rename it then. If you're talking about the change to how service URIs get determined, I'll be happy to help make it work like the other ones, but... - it didn't seem like it was initially working like the other ones, as it hardcoded a single URI and didn't use the binding URI at all, here's the code I found: public static final String SERVLET_PATH = AjaxServlet.AJAX_SERVLET_PATH + "/*"; and servlet.addService(binding.getName(), type, proxy); - answering my question on this subject at [1] would be a good starting point [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200708.mbox/[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-313) Tuscany SCA and SDO plugins attempt to generate code on incorrect goals
[ https://issues.apache.org/jira/browse/TUSCANY-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende closed TUSCANY-313. --- Resolution: Won't Fix Fix Version/s: Java-SCA-Next I haven't heard anything on the thread discussing some scenarios on this issue. http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21839.html So, I'm closing this for now... feel free to re-open if you think we need to look further into this issue. > Tuscany SCA and SDO plugins attempt to generate code on incorrect goals > --- > > Key: TUSCANY-313 > URL: https://issues.apache.org/jira/browse/TUSCANY-313 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Tools, Java SDO Tools >Reporter: Jean-Sebastien Delfino >Priority: Minor > Fix For: Java-SDO-Next, Java-SCA-Next > > > The tuscany SCA and SDO plugins attempt to generate code on incorrect goals, > for example the eclipse:eclipse goal. > To reproduce the problem, from the tuscany/java directory do the following: > mvn clean eclipse:eclipse > The SCA and SDO maven plugins will generate Java interfaces for services and > SDO classes. They shouldn't. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany/Geronimo Integration Demo
On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Simon Nash wrote: > > > > Jean-Sebastien Delfino wrote: > > > >> Jean-Sebastien Delfino wrote: > >> > >>> A few questions. > >>> > >>> [snip] > >>> ant elder wrote: > >>> > I'm not very keen at all on doing that. Couldn't we actually put > the code in > our svn instead of using SVN externals (if necessary the Geronimo > guys could > use SVN externals if they really want it). > >>> > >>> > >>> Necessary yes, as far as I know the Geronimo guys are the guys > >>> working on this code. > >>> > >>> But will that work if the code moves to our SVN, will they still be > >>> able to commit their changes? Can you help me understand how that > >>> will work? > >>> > I'd quite like this code in our > svn anyway as some of it could be shared by others who're also > integrating > Tuscany. > > >>> > >>> > >>> I'm not sure I understand. What exactly will prevent others who are > >>> also integrating with Tuscany to share this code if it stays where > >>> it is now in the Geronimo SVN repository? > >>> > >> > >> I'd like to spend a little bit of time today to get the > >> Geronimo/Integration code building as part of the Tuscany build, get > >> it into our Eclipse build profile to generate the correct classpath > >> declarations, and add an itest for this integration. > >> > >> We have discussed two options for having this code built in Tuscany > >> so far: > >> [a] keep the integration code in the Geronimo repository, have > >> Tuscany point to it using SVN externals > >> [b] move the integration code to the Tuscany repository and have the > >> Geronimo folks point to it using SVN externals if they want > >> > >> I prefer [a] for now, as it allows me to build this code in Tuscany, > >> while continuing to allow the Geronimo folks to work on it without > >> breaking them. > >> > >> Ant has raised concerns with [a]. I have raised questions and > >> concerns with [b], but I may very well be convinced that [b] is > >> better... if I get answers to the questions I asked, and if the > >> Geronimo folks working on this integration are OK with [b] as well. > >> > >> Could people please jump in and describe what will work best for > >> them, I'd like to make progress on this. Thanks. > >> > > In the long or medium term this code should become a Geronimo feature > > that > > is part of the Geronimo release distribution. Moving it to the Tuscany > > repository is a step in the wrong direction from this perspective. > > > > In the short term it seems that this could be regarded as a separate > > component that is not directly part of either Geronimo or Tuscany but > > requires both of these to be installed in order to use it. As a > separate > > component, it could be bundled with the Tuscany binary distro like the > > many other external dependencies that we include. > > > > So I'd go for [a] but structure the build to place the binaries for this > > component somewhere different than the modules that are part of > > java/sca/. > > Something like java/sca/externals/geronimo-tuscany perhaps? And I'd > > suggest publishing it to the mvn repos (when it's ready) under the > > "geronimo" group ID, not "tuscany". > > > > Simon > > > > > > I agree that the Geronimo plugin for Tuscany more naturally belongs to > Geronimo and should become a Geronimo feature. This is a good reason for > keeping this code in the Geronimo repository. > > So: > I'm +1 on keeping the code in Geronimo > -1 on moving it to the Tuscany SVN > > I won't use SVN externals to point to this code from the Tuscany SVN > since Ant is -1 on this. > > Manu, Vamsi, I have two questions: > - are you planning to move this code to a better place than sandbox in > the Geronimo repository? I was not sure if this code was to be put under Geronimo svn. I will find out if I can move this out of sandbox to geronimo\plugins. - are you planning to publish > geronimo-tuscany-plugin-1.0-incubating-SNAPSHOT.car somewhere? So far it has not been published to any repository. I was making it available in geronimo sandbox itself. In the meantime: > - the source is at > http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration > - it built OK for me before but now I'm getting this error > > [WARNING] Unable to get resource > 'org.apache.geronimo.plugins:car-maven-plugin:pom:2.0.1' from repository > central (http://repo1.maven.org/maven2) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > GroupId: org.apache.geronimo.plugins > ArtifactId: car-maven-plugin > Version: 2.0.1 > > Reason: Unable to download the artifact from any repository > > org.apache.geronimo.plugins:car-maven-plugin:pom:2.0.1 > > from the specified remote repositories: > central (http://repo1.maven.org/maven2
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
Hi, The o.a.t.sca.scope contains the interfaces/classes which used to be SPIs while the o.a.t.sca.core.scope contains implementation classes. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 21, 2007 10:33 AM Subject: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope Module core contains an o.a.t.sca.scope package. I'm trying to fix package names to be consistent with the module names so o.a.t.sca.scope should be renamed to o.a.t.sca.core.scope, but there's already another o.a.t.sca.core.scope in module core! What is the difference between these two packages? -- 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]
[jira] Created: (TUSCANY-1567) NPE when hosting "calculator-webapp" sample under Tomcat when the Tomcat install path contains spaces.
NPE when hosting "calculator-webapp" sample under Tomcat when the Tomcat install path contains spaces. -- Key: TUSCANY-1567 URL: https://issues.apache.org/jira/browse/TUSCANY-1567 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Integration Environment: MS windows Vista. Tomcat 6.0.13/jvm 1.5.0_11-b03 java/sca source revision 568049 Reporter: Steve Jones Running Tuscany calculator-webapp sample under Tomcat. If Tomcat is installed in its default install folder: C:\Program Files\Apache Software Foundation\Tomcat 6.0 A NPE occurs when the samples calc.jsp page is served. Reinstalling Tomcat in: D:\tomcat\tomcat60\ Fixes the problem Cheers. Tomcat log file: SEVERE: exception initializing SCADomain org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: java.lang.IllegalArgumentException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82) at org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63) at org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4334) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:566) 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 org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: org.osoa.sca.ServiceRuntimeException: java.lang.IllegalArgumentException at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230) ... 27 more Caused by: java.lang.IllegalArgumentException at java.net.URI.create(Unknown Source) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getContributionLocation(DefaultSCADomain.java:246) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:103) ... 28 more Caused by: java.net.URISyntaxException: Illegal character in path at index 16: file:/C:/Program Files/Apache Software Foundation/Tomcat 6.0/webapps/sample-calculator-webapp/ at java.net.URI$Parser.fail(Unknown Source) at java.net.URI$Parser.checkChars(Unknown Source) at java.net.URI$Parser.parseHierarchical(Unknown Source) at java.net.URI$Parser.parse(Unknown Source) at java.net.URI.(Unknown Source) ... 31 more 21-Aug-2007 12:12:58 org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() 21-Aug-2007 12:12:58 org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() 21-Aug-2007 12:13:09 org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet jsp threw exception java.lang.NullPointerException at org.apache.jsp.calc_jsp._jspService(calc_jsp.java:63) at org.apach
[jira] Resolved: (TUSCANY-1523) Enhance ArtifactProcessors to be registered for file names, as well as for file types
[ https://issues.apache.org/jira/browse/TUSCANY-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1523. -- Resolution: Fixed Fixed (568218). We now support file names (file.composite) as well as file types as (.composite). The lookup order is first based on the file name, then on the file type. > Enhance ArtifactProcessors to be registered for file names, as well as for > file types > - > > Key: TUSCANY-1523 > URL: https://issues.apache.org/jira/browse/TUSCANY-1523 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-Next >Reporter: Luciano Resende >Assignee: Luciano Resende > Fix For: Java-SCA-Next > > > Details on the following thread: > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg21338.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
Module core contains an o.a.t.sca.scope package. I'm trying to fix package names to be consistent with the module names so o.a.t.sca.scope should be renamed to o.a.t.sca.core.scope, but there's already another o.a.t.sca.core.scope in module core! What is the difference between these two packages? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1566) Element coming out in the wrong namespace
[
https://issues.apache.org/jira/browse/TUSCANY-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521534
]
Pete Robbins commented on TUSCANY-1566:
---
This should be fairly easy to fix. I think it is in the logic where we are
writing a primitive as an element in a sequenced DO.
> Element coming out in the wrong namespace
> -
>
> Key: TUSCANY-1566
> URL: https://issues.apache.org/jira/browse/TUSCANY-1566
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: WinXP
>Reporter: Matthew Peters
> Attachments: Atom1.0.xsd
>
>
> We have a schema file that defines an atom feed. It specified
> elementFormDefault="qualified" so that lower level elements should be in the
> target namespace. I will attach the schema as a separate file. With a very
> simple php test case as follows:
> $xmldas = SDO_DAS_XML::create('Atom1.0.xsd');
> $document = $xmldas->createDocument('http://www.w3.org/2005/Atom','entry');
> $entry = $document->getRootDataObject();
> $author = $entry->createDataObject('author');
> $author->name[] = "Caroline Maynard";
> print $xmldas->saveString($document,2);
> we get
>
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns:tns="http://www.w3.org/2005/Atom";>
>
> Caroline Maynard
>
>
> whereas we should see the element in the tns namespace.
> I have checked this with XERCES: the xml that we are generating will not
> validate, whereas if I alter it to have in the tns namespace it will.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Account Request - Brady Johnson - Tuscany (incubating)
Dear root, Please create an id for Brady Johnson on the Tuscany project under Incubation. Preferred userid: bjohnson, bajohnson, brady_johnson, johnson_brady, bradya_johnson Full name: Brady Allen Johnson Forwarding email address: [EMAIL PROTECTED] Requested Karma for: ws-tuscany ICLA is on file. Vote: On tuscany-private and incubator-private. Please see the following id's. [EMAIL PROTECTED] [EMAIL PROTECTED] Many thanks, ...ant
Re: Renaming binding-ajax to binding-dwr?
ant elder wrote: How about the binding.resource and implementation.resource? Should they be renamed to binding.http and implementation.file? :) ...ant Actually, yes for binding.resource, good point! :) I'll push it out of the implementation-resource module, into a binding-http module (since having it in implementation-resource is also creating an inconsistency with the package names, which I noticed yesterday as I was reviewing packages and starting to look into this kind of naming issues). With respect to the implementation extension type, I'd like to stick to implementation.resource for now, as this implementation covers files, folders, and I think could cover more "resource" types (as the Tomcat default resource servlet can also cover "virtual" resource directories mapped to JNDI namespaces for example). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TUSCANY-1356
On 8/21/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Comments inline. > > Thanks, > Raymond > > - Original Message - > From: "ant elder" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, August 21, 2007 9:12 AM > Subject: Re: Patch for TUSCANY-1356 > > > > On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > >> > >> Simon Nash wrote: > >> > > >> > ant elder wrote: > >> >> On 8/20/07, Simon Nash <[EMAIL PROTECTED]> wrote: > >> >> > >> >>> I'm restarting the discussion on this because the previous thread > [1] > >> >>> did not reach a conclusion. I thought it would be useful to > >> >>> summarize > >> >>> the issues with the extension samples as they stand, and explain > how > >> >>> the patch for TUSCANY-1356 resolves these issues. > >> >>> > >> >>> In the implementation-crud sample (the client application code), we > >> >>> have > >> >>> CRUDClient.java, crud.composite, and CRUDTestCase.java. > >> >>> CRUDClient.java > >> >>> and crud.composite together provide a sample client that exercises > >> >>> implementation-crud-extension, and these two files are correctly > part > >> >>> of implementation-crud because they are not part of the extension > >> >>> jar. > >> >>> The problem with implementation-crud is the inclusion of > >> >>> CRUDTestCase.java > >> >>> , > >> >>> which does not use or test any of the above client code, but is > just > >> >>> a > >> >>> copy of the same file from implementation-crud-extension (and > >> >>> executed > >> >>> by mvn when implementation-crud-extension is built). The patch for > >> >>> TUSCANY-1356 eliminates this duplicate copy of CRUDTestCase.java in > >> >>> implementation-crud and adds a new itest (not part of the samples) > >> that > >> >>> runs the implementation-crud client code to make sure it executes > OK. > >> >>> > >> >>> The crud.composite file from the implementation-crud sample client > >> >>> is also > >> >>> duplicated as part of the test code for > >> >>> implementation-crud-extension. > >> >>> There is no need for this code to be duplicated. The patch for > >> >>> TUSCANY-1356 eliminates this duplicate copy of crud.composite by > >> having > >> >>> the JUnit test for implementation-crud-extension use the > >> crud.composite > >> >>> file that is part of implementation-crud. > >> >>> > >> >>> Similarly, in the binding-echo-extension sample, under src/test > >> >>> there are > >> >>> duplicates of the implementation code, composite file, and JUnit > >> >>> test code > >> >>> from binding-echo. The patch for TUSCANY-1356 removes duplicate > code > >> >>> from binding-echo-extension by having the JUnit tests in > >> >>> binding-echo-extension take this code from binding-echo, adds a > >> >>> non-sample > >> >>> itest to exercise EchoBindingClient.java from binding-echo, and > >> removes > >> >>> redundant JUnit test code from binding-echo (not needed because the > >> >>> JUnit > >> >>> tests in binding-echo-extension contains exactly the same code). > >> >>> > >> >>> With these changes, all duplicate code is eliminated from these > >> >>> samples, > >> >>> all sample code is tested either by sample JUnit tests or separate > >> >>> itests, and the distinction between the extension and > >> >>> client/application > >> >>> samples is much clearer. > >> >>> > >> >>> Simon > >> >>> > >> >>> [1] > >> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19026.html > >> >> > >> >> > >> >> > >> >> How about instead just deleting the implementation.crud sample? > We've > >> >> the > >> >> implementation.pojo sample now which seems like a better sample to > me > >> >> anyway. > >> >> > >> > The patch for TUSCANY-1356 also corrects similar problems with the > >> > binding-echo and binding-echo-extension samples. This part of the > >> > patch > >> > could be applied while we consider whether or not to delete > >> > implementation-crud. > >> > > >> > I looked at the implementation-pojo-extension sample. It has no > >> > associated > >> > client to run "out of the box" using ant. The issues addressed by > >> > TUSCANY-1356 arose out of the work that was done on > >> > implementation-crud and > >> > binding-echo to factor them into an extension sample and > >> > client/application > >> > sample so that the client code could run out of the box using > ant. If > >> we > >> > decide to replace implementation-crud by implementation-pojo, we > would > >> > need > >> > to fix up implementation-pojo-extension to add a client sample, with > >> code > >> > divided between the extension sample and the client sample in the > same > >> > way > >> > that the patch for TUSCANY-1356 does. > >> > > >> > Simon > >> > > >> > > >> > - > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > >> I would like to keep implementation-crud as it's showing an > >> implementation type different from a POJO. Implementation-crud and
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Welcome on board, Brady. Raymond - Original Message - From: "Pete Robbins" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 21, 2007 7:42 AM Subject: [NOTICE] Brady Johnson voted as Tuscany committer The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - 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]
Re: Patch for TUSCANY-1356
Comments inline. Thanks, Raymond - Original Message - From: "ant elder" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 21, 2007 9:12 AM Subject: Re: Patch for TUSCANY-1356 On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: Simon Nash wrote: > > ant elder wrote: >> On 8/20/07, Simon Nash <[EMAIL PROTECTED]> wrote: >> >>> I'm restarting the discussion on this because the previous thread [1] >>> did not reach a conclusion. I thought it would be useful to >>> summarize >>> the issues with the extension samples as they stand, and explain how >>> the patch for TUSCANY-1356 resolves these issues. >>> >>> In the implementation-crud sample (the client application code), we >>> have >>> CRUDClient.java, crud.composite, and CRUDTestCase.java. >>> CRUDClient.java >>> and crud.composite together provide a sample client that exercises >>> implementation-crud-extension, and these two files are correctly part >>> of implementation-crud because they are not part of the extension >>> jar. >>> The problem with implementation-crud is the inclusion of >>> CRUDTestCase.java >>> , >>> which does not use or test any of the above client code, but is just >>> a >>> copy of the same file from implementation-crud-extension (and >>> executed >>> by mvn when implementation-crud-extension is built). The patch for >>> TUSCANY-1356 eliminates this duplicate copy of CRUDTestCase.java in >>> implementation-crud and adds a new itest (not part of the samples) that >>> runs the implementation-crud client code to make sure it executes OK. >>> >>> The crud.composite file from the implementation-crud sample client >>> is also >>> duplicated as part of the test code for >>> implementation-crud-extension. >>> There is no need for this code to be duplicated. The patch for >>> TUSCANY-1356 eliminates this duplicate copy of crud.composite by having >>> the JUnit test for implementation-crud-extension use the crud.composite >>> file that is part of implementation-crud. >>> >>> Similarly, in the binding-echo-extension sample, under src/test >>> there are >>> duplicates of the implementation code, composite file, and JUnit >>> test code >>> from binding-echo. The patch for TUSCANY-1356 removes duplicate code >>> from binding-echo-extension by having the JUnit tests in >>> binding-echo-extension take this code from binding-echo, adds a >>> non-sample >>> itest to exercise EchoBindingClient.java from binding-echo, and removes >>> redundant JUnit test code from binding-echo (not needed because the >>> JUnit >>> tests in binding-echo-extension contains exactly the same code). >>> >>> With these changes, all duplicate code is eliminated from these >>> samples, >>> all sample code is tested either by sample JUnit tests or separate >>> itests, and the distinction between the extension and >>> client/application >>> samples is much clearer. >>> >>> Simon >>> >>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19026.html >> >> >> >> How about instead just deleting the implementation.crud sample? We've >> the >> implementation.pojo sample now which seems like a better sample to me >> anyway. >> > The patch for TUSCANY-1356 also corrects similar problems with the > binding-echo and binding-echo-extension samples. This part of the > patch > could be applied while we consider whether or not to delete > implementation-crud. > > I looked at the implementation-pojo-extension sample. It has no > associated > client to run "out of the box" using ant. The issues addressed by > TUSCANY-1356 arose out of the work that was done on > implementation-crud and > binding-echo to factor them into an extension sample and > client/application > sample so that the client code could run out of the box using ant. If we > decide to replace implementation-crud by implementation-pojo, we would > need > to fix up implementation-pojo-extension to add a client sample, with code > divided between the extension sample and the client sample in the same > way > that the patch for TUSCANY-1356 does. > > Simon > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > I would like to keep implementation-crud as it's showing an implementation type different from a POJO. Implementation-crud and implementation-pojo are meant to show different approaches to component implementations, and I'll be concerned if our only implementation sample leads all people down the POJO path. If people have serious and concrete enough issues with implementation-crud, please raise them and we should take a look at them. +1 to keep the implementation-crud. Indeed, I think it should be the primary example to demonstrate how to add a new implementation type to Tuscany. I'm not very sure if we have to force the extension developers to only take the pattern that the extension-helper supports (for example, I might prefer to load the exten
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Don't worry, Pete just gave me the details. ...ant On 8/21/07, ant elder <[EMAIL PROTECTED]> wrote: > > Brady, your CLA is on file now so if you let me know your preferred Apache > userid and the email address you used on the CLA then i can send off the > request to get your account set up. > >...ant > > On 8/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > > > The Tuscany PPMC and Incubator PMC have voted for Brady to become a > > Tuscany committer. > > > > Congratulations and welcome Brady! > > > > I look forward to your continued excellent contributions to Tuscany. > > > > Cheers, > > > > -- > > Pete > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Great summary Sebastien (you were faster then me), looks like option B is the consensus, and I'd like to give it a try so we could still get it to the release branch on the next couple days. Please let me know if anyone has any objections. On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Simon Nash wrote: > > -1 for A. This violates the spec. > > +1 for B. Spec compliant, supports validation, and ensures > > "future proof" SCDLs that won't break if Tuscany extension elements > > are later adopted by the spec group but with subtle differences. > > -1 for C alone. -0.9 for C if done in addition to B. C doesn't > > handle the "future proofing" scenario, so the joy of simplicity will > > turn into a nightmare if Tuscany extension elements are later adopted > > by the spec group but with subtle differences. I'm also not convinced > > that simplicity is improved by providing two different alternatives here. > > > > Simon > > > > Mike Edwards wrote: > > > >> Folks, > >> > >> In some ways, I'm glad I was on vacation while much of this debate > >> raged!! ;-) > >> > >> Comments below. > >> > >> Jean-Sebastien Delfino wrote: > >> > >>> [A] What we have right now, standard SCA extensions and tuscany > >>> extensions sharing the standard SCA namespace > >>> (B) What IMO is a more correct use of XML namespaces, standard SCA > >>> extensions in the standard SCA namespace, and Tuscany extensions in > >>> a Tuscany namespace > >>> [C] What an application developer could write if we allowed > >>> namespaces to be omitted > >>> .. > >>> Now here are a few "side effects" :) > >>> > >>> Option [A] > >>> - I cannot validate this composite against the standard SCA schemas > >>> (it'll show errors in my XSD aware XML editor) our Tuscany > >>> extensions violate the standard SCA namespace > >>> - I have one less namespace and prefix declaration to care about > >>> > >>> Option [B] > >>> - I can validate this composite against the standard SCA schemas, as > >>> the Tuscany extensions match the xsd:any namespace="##other" > >>> extensibility points in the SCA schema > >>> - I have one more namespace and prefix declaration to write covering > >>> the Tuscany extensions > >>> > >>> Option [C] > >>> - I don't need to worry about namespaces, which are usually long and > >>> error prone, writing the composite is simpler > >>> - I cannot validate this composite against the standard SCA schemas > >>> as it does not declare namespaces > >>> > >>> My preference is to do both: > >>> - [B], be correct with respect to our usage of XML schema, to make > >>> people who care about XML schema validation and use XML schema tools > >>> happy > >>> - and [C] allow people who don't like namespaces to not have to > >>> write them > >>> > >>> Why do I like [C] as well? Here are a few examples: > >>> > >>> > >>> > >>> Hello! I can write XML without namespaces, isn't that nice? > >>> > >>> > >>> > >>> An axis2.xml configuration file > >>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml > >>> > >>> > >>> An MS WCF configuration > >>> http://msdn2.microsoft.com/en-us/library/ms735103.aspx > >>> > >>> A Tomcat server.xml file > >>> http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html > >>> > >>> All work without namespaces... > >>> > >> > >> Let me tackle them in reverse order (the more debateable first) > >> > >> C) Yes, this is indeed simpler. No namespaces is wonderful. (PS I > >> will declare here that I am no fan of XML, so less XML always keeps > >> me happy) > >> > >> The downside of this is that it "assumes" that you know all the valid > >> XML in advance, if any validation is going to be done. I suppose > >> that you have options: > >> > >> - 1. Don't worry about validation at all. > >> - 2. Do validation and have some non-namespace way of knowing all > >> the XSDs that contribute. > >> > >> The problem really hits when you start to build SCA Assemblies using > >> tooling that is not part of Tuscany. The SOA Tools project at > >> Eclipse comes to mind. We may come up with some approach for > >> Tuscany, but can that also be used for the SOA Tools project? > >> > >> Namespaces may be ugly but at least they represent a standard that > >> all can use > >> > >> B) This is the SCA spec approach. I'd recommend at least supporting > >> this even if other techniques are also allowed. > >> > >> A) Is really problematic. It implies hacking the XSDs defined by the > >> SCA specs. How will anyone know when they have violated the spec > >> XSDs that form part of the Portability conformance that is part of > >> the value of SCA (ie build and run my stuff on Tuscany and the same > >> stuff should work on Oracle's runtime, if I stick to the stuff > >> defined in the SCA specs...). > >> > >> A will also imply the existence of at least 2 sets of "SCA XSDs" - > >> the spec on
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Brady, your CLA is on file now so if you let me know your preferred Apache userid and the email address you used on the CLA then i can send off the request to get your account set up. ...ant On 8/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > The Tuscany PPMC and Incubator PMC have voted for Brady to become a > Tuscany committer. > > Congratulations and welcome Brady! > > I look forward to your continued excellent contributions to Tuscany. > > Cheers, > > -- > Pete > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[jira] Updated: (TUSCANY-1438) Change TuscanySCA Native build system to use ant
[ https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brady Johnson updated TUSCANY-1438: --- Attachment: tuscany_patch_update10_jira1438.corrected Uploading corrected patch made from the latest trunk version. > Change TuscanySCA Native build system to use ant > > > Key: TUSCANY-1438 > URL: https://issues.apache.org/jira/browse/TUSCANY-1438 > Project: Tuscany > Issue Type: Improvement > Components: C++ SCA >Affects Versions: Cpp-Next > Environment: all platforms >Reporter: Brady Johnson >Priority: Minor > Fix For: Cpp-Next > > Attachments: README_ANT_INSTALL.txt, samples.CppBigBank.build.xml, > tuscany_patch_update10_jira1438, tuscany_patch_update10_jira1438.corrected, > tuscany_patch_update2_jira1438, tuscany_patch_update3_jira1438, > tuscany_patch_update4_jira1438, tuscany_patch_update5_jira1438, > tuscany_patch_update6_jira1438, tuscany_patch_update7_jira1438, > tuscany_patch_update8_jira1438, tuscany_patch_update9_jira1438, > TuscanySCANative.ant.display.system, tuscanySCAnative_ant.tar.gz, > tuscanySCAnative_ant_update1.tar.gz > > > In an effort to simplify the build process, I would like to propose switching > over to use ant instead of automake. It will be much easier to maintain, and > is used by many more developers today than automake. > Per a request by Pete Robbins to show what the build scripts would look like > for cpp/sca/runtime/core, I will attach a patch with the build infrastructure > to build, link, and install said library. > > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (TUSCANY-1438) Change TuscanySCA Native build system to use ant
Ok, I fixed it. I just hadn't pulled down the latest from svn for a few days. Can you try again Adriano. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Brady Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 21, 2007 9:33 AM To: Adriano Crestani (JIRA) Subject: RE: [jira] Commented: (TUSCANY-1438) Change TuscanySCA Native build system to use ant Ok thanks Adriano. I'll look into this now. Brady -Original Message- From: Adriano Crestani (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, August 20, 2007 6:42 PM To: Brady Johnson Subject: [jira] Commented: (TUSCANY-1438) Change TuscanySCA Native build system to use ant [ https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.ji ra.plugin.system.issuetabpanels:comment-tabpanel#action_12521286 ] Adriano Crestani commented on TUSCANY-1438: --- The patch tuscany_patch_update10_jira1438 seems to be generated from a old trunk version, somehow my tortoiseSVN is reporting "The patch seems outdated". Regards, Adriano Crestani > Change TuscanySCA Native build system to use ant > > > Key: TUSCANY-1438 > URL: https://issues.apache.org/jira/browse/TUSCANY-1438 > Project: Tuscany > Issue Type: Improvement > Components: C++ SCA >Affects Versions: Cpp-Next > Environment: all platforms >Reporter: Brady Johnson >Priority: Minor > Fix For: Cpp-Next > > Attachments: README_ANT_INSTALL.txt, > samples.CppBigBank.build.xml, tuscany_patch_update10_jira1438, > tuscany_patch_update2_jira1438, tuscany_patch_update3_jira1438, > tuscany_patch_update4_jira1438, tuscany_patch_update5_jira1438, > tuscany_patch_update6_jira1438, tuscany_patch_update7_jira1438, > tuscany_patch_update8_jira1438, tuscany_patch_update9_jira1438, > TuscanySCANative.ant.display.system, tuscanySCAnative_ant.tar.gz, > tuscanySCAnative_ant_update1.tar.gz > > > In an effort to simplify the build process, I would like to propose switching over to use ant instead of automake. It will be much easier to maintain, and is used by many more developers today than automake. > Per a request by Pete Robbins to show what the build scripts would look like for cpp/sca/runtime/core, I will attach a patch with the build infrastructure to build, link, and install said library. > > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - 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]
Re: Patch for TUSCANY-1356
On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Simon Nash wrote: > > > > ant elder wrote: > >> On 8/20/07, Simon Nash <[EMAIL PROTECTED]> wrote: > >> > >>> I'm restarting the discussion on this because the previous thread [1] > >>> did not reach a conclusion. I thought it would be useful to summarize > >>> the issues with the extension samples as they stand, and explain how > >>> the patch for TUSCANY-1356 resolves these issues. > >>> > >>> In the implementation-crud sample (the client application code), we > >>> have > >>> CRUDClient.java, crud.composite, and CRUDTestCase.java. > >>> CRUDClient.java > >>> and crud.composite together provide a sample client that exercises > >>> implementation-crud-extension, and these two files are correctly part > >>> of implementation-crud because they are not part of the extension jar. > >>> The problem with implementation-crud is the inclusion of > >>> CRUDTestCase.java > >>> , > >>> which does not use or test any of the above client code, but is just a > >>> copy of the same file from implementation-crud-extension (and executed > >>> by mvn when implementation-crud-extension is built). The patch for > >>> TUSCANY-1356 eliminates this duplicate copy of CRUDTestCase.java in > >>> implementation-crud and adds a new itest (not part of the samples) > that > >>> runs the implementation-crud client code to make sure it executes OK. > >>> > >>> The crud.composite file from the implementation-crud sample client > >>> is also > >>> duplicated as part of the test code for implementation-crud-extension. > >>> There is no need for this code to be duplicated. The patch for > >>> TUSCANY-1356 eliminates this duplicate copy of crud.composite by > having > >>> the JUnit test for implementation-crud-extension use the > crud.composite > >>> file that is part of implementation-crud. > >>> > >>> Similarly, in the binding-echo-extension sample, under src/test > >>> there are > >>> duplicates of the implementation code, composite file, and JUnit > >>> test code > >>> from binding-echo. The patch for TUSCANY-1356 removes duplicate code > >>> from binding-echo-extension by having the JUnit tests in > >>> binding-echo-extension take this code from binding-echo, adds a > >>> non-sample > >>> itest to exercise EchoBindingClient.java from binding-echo, and > removes > >>> redundant JUnit test code from binding-echo (not needed because the > >>> JUnit > >>> tests in binding-echo-extension contains exactly the same code). > >>> > >>> With these changes, all duplicate code is eliminated from these > >>> samples, > >>> all sample code is tested either by sample JUnit tests or separate > >>> itests, and the distinction between the extension and > >>> client/application > >>> samples is much clearer. > >>> > >>> Simon > >>> > >>> [1] > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19026.html > >> > >> > >> > >> How about instead just deleting the implementation.crud sample? We've > >> the > >> implementation.pojo sample now which seems like a better sample to me > >> anyway. > >> > > The patch for TUSCANY-1356 also corrects similar problems with the > > binding-echo and binding-echo-extension samples. This part of the patch > > could be applied while we consider whether or not to delete > > implementation-crud. > > > > I looked at the implementation-pojo-extension sample. It has no > > associated > > client to run "out of the box" using ant. The issues addressed by > > TUSCANY-1356 arose out of the work that was done on > > implementation-crud and > > binding-echo to factor them into an extension sample and > > client/application > > sample so that the client code could run out of the box using ant. If > we > > decide to replace implementation-crud by implementation-pojo, we would > > need > > to fix up implementation-pojo-extension to add a client sample, with > code > > divided between the extension sample and the client sample in the same > > way > > that the patch for TUSCANY-1356 does. > > > > Simon > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > I would like to keep implementation-crud as it's showing an > implementation type different from a POJO. Implementation-crud and > implementation-pojo are meant to show different approaches to component > implementations, and I'll be concerned if our only implementation sample > leads all people down the POJO path. If people have serious and concrete > enough issues with implementation-crud, please raise them and we should > take a look at them. One of the things I've found confusing with implementation.crud is that because it has a single fixed service interface you can easily just have the component use implementation.java to invoke a CRUD impl and use properties for whatever configuring it needs, so it makes you wonder why using an extension is even necessary.
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Simon Nash wrote: -1 for A. This violates the spec. +1 for B. Spec compliant, supports validation, and ensures "future proof" SCDLs that won't break if Tuscany extension elements are later adopted by the spec group but with subtle differences. -1 for C alone. -0.9 for C if done in addition to B. C doesn't handle the "future proofing" scenario, so the joy of simplicity will turn into a nightmare if Tuscany extension elements are later adopted by the spec group but with subtle differences. I'm also not convinced that simplicity is improved by providing two different alternatives here. Simon Mike Edwards wrote: Folks, In some ways, I'm glad I was on vacation while much of this debate raged!! ;-) Comments below. Jean-Sebastien Delfino wrote: [A] What we have right now, standard SCA extensions and tuscany extensions sharing the standard SCA namespace (B) What IMO is a more correct use of XML namespaces, standard SCA extensions in the standard SCA namespace, and Tuscany extensions in a Tuscany namespace [C] What an application developer could write if we allowed namespaces to be omitted .. Now here are a few "side effects" :) Option [A] - I cannot validate this composite against the standard SCA schemas (it'll show errors in my XSD aware XML editor) our Tuscany extensions violate the standard SCA namespace - I have one less namespace and prefix declaration to care about Option [B] - I can validate this composite against the standard SCA schemas, as the Tuscany extensions match the xsd:any namespace="##other" extensibility points in the SCA schema - I have one more namespace and prefix declaration to write covering the Tuscany extensions Option [C] - I don't need to worry about namespaces, which are usually long and error prone, writing the composite is simpler - I cannot validate this composite against the standard SCA schemas as it does not declare namespaces My preference is to do both: - [B], be correct with respect to our usage of XML schema, to make people who care about XML schema validation and use XML schema tools happy - and [C] allow people who don't like namespaces to not have to write them Why do I like [C] as well? Here are a few examples: Hello! I can write XML without namespaces, isn't that nice? An axis2.xml configuration file http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/resources/org/apache/tuscany/sca/binding/axis2/engine/config/axis2.xml An MS WCF configuration http://msdn2.microsoft.com/en-us/library/ms735103.aspx A Tomcat server.xml file http://tomcat.apache.org/tomcat-6.0-doc/default-servlet.html All work without namespaces... Let me tackle them in reverse order (the more debateable first) C) Yes, this is indeed simpler. No namespaces is wonderful. (PS I will declare here that I am no fan of XML, so less XML always keeps me happy) The downside of this is that it "assumes" that you know all the valid XML in advance, if any validation is going to be done. I suppose that you have options: - 1. Don't worry about validation at all. - 2. Do validation and have some non-namespace way of knowing all the XSDs that contribute. The problem really hits when you start to build SCA Assemblies using tooling that is not part of Tuscany. The SOA Tools project at Eclipse comes to mind. We may come up with some approach for Tuscany, but can that also be used for the SOA Tools project? Namespaces may be ugly but at least they represent a standard that all can use B) This is the SCA spec approach. I'd recommend at least supporting this even if other techniques are also allowed. A) Is really problematic. It implies hacking the XSDs defined by the SCA specs. How will anyone know when they have violated the spec XSDs that form part of the Portability conformance that is part of the value of SCA (ie build and run my stuff on Tuscany and the same stuff should work on Oracle's runtime, if I stick to the stuff defined in the SCA specs...). A will also imply the existence of at least 2 sets of "SCA XSDs" - the spec ones and the Tuscany ones. How will anyone know which one they've got in their hands? So: A) -1not a good place to be B) +1its the standard C) +0.5 I can envisage this as +1 if it is an optional setting that a user can knowingly choose to use - as long as it is clear what they lose Yours, Mike. PS The Microsoft WCF config works without a namespace since I think it is not extensible, unlike SCA which allows all kinds of extension. PS 2 If anyone can think of a better way for SCA to handle its extensibility, that will allow us to drop namespaces, the spec team will be all ears. The spec group debated the use of namespaces at some length before adopting the current spec definition (and I was one of those trying to keep namespaces out of it). No more technical comments on this thread today.
Re: Do we still need special handling of callback bindings and wires?
Comments inline. Simon Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: "Simon Nash" <[EMAIL PROTECTED]> To: Sent: Monday, August 20, 2007 5:14 PM Subject: Re: Do we still need special handling of callback bindings and wires? The short answer is Yes. The long answer follows below :-) I'll describe the design approach used by the code in my patch for TUSCANY-1496. Things are moving rapidly in this area with Raymond's work to support late binding between references and services, so some of this description may need to be updated. It's my turn to update the discription now :-) Wires may be reference wires or service wires: 1. Reference wires connect a source reference to a target binding and endpoint. The source reference could be a callback service's pseudo-reference. 2. Service wires connect a binding endpoint to a service implementation. The service implementation could be a callback reference's pseudo-service. Reference wires may be static or dynamic: 1. A static wire targets a specific binding and endpoint (local or remote). Dispatching a call down an invocation chain for this wire results in a call to the statically configured binding and endpoint for the wire. 2. A dynamic wire targets a specific binding but an unspecified endpoint. The actual target endpoint is provided at invocation time. Depending on the binding type, dynamic wires may perform worse than static wires, or their performance may be the same. Some bindings may only support static wires. Some may only support dynamic wires. Some may support both, with static wires providing better performance. I'm not sure why you think it's the binding's job to support static or dynanic wire. To me, the dynamic wire needs to be bound an endpoint before it can used for invocations. Maybe the terminology "static" and "dynamic" is confusing here. By "static" I mean a wire that is bound to a specific target endpoint and all invocations down that wire will go to this pre-bound endpoint. By "dynamic" I mean a wire that is not pre-bound to a specific endpoint, allowing each invocation down the wire to specify its target endpoint. Some bindings can optimize if they have have static knowledge of the target. The local SCA binding is in this category, because static pre-knowledge allows the source and target invocation chains to be connected (now by means of the binding invoker), so that each invocation becomes a direct call through pre-built invocation chains. Other bindings perform the same whether or not they have this static knowledge. The Axis2 Web Service binding is in this category, because it always creates an Axis2 operation client for each request, and it passes the target endpoint into Axis2 as a creation parameter for the operation client. Requiring all wires to be be pre-bound to a target endpoint before they can be used for an invocation would require many more wires to be created than is necessary. An extreme case of this is callbacks over Web Services from multiple clients to a single service, where the service's callback pseudo-reference should not use a separate callback wire for each client but should have a single dynamic wire that can invoke any client endpoint. Forcing every callback operation to create and bind a runtime wire first is unneccessary and will incur both time and space costs. Service wires are effectively always static since on the service side, the binding and endpoint is known. Every service and binding combination has a single service wire that is used by the binding provider to invoke the service. For statically connected references and services (e.g., wired in SCDL, using an SCA binding, and locally accessible), static forward wires are created. The core can't fully complete the end-to-end invocation chain for the static wire, so the start methods of bindings that support local optimization (like the local SCA binding) can complete these connections using information provided by the core. Now we support the lazy creation of RuntimeWire/Invocation for a reference. I also changed the code to have the RuntimeSCABindingInvoker to delegate the call to the first invoker in the target service chain instead of trying to merge/connect the two chains together. Lazy creation is fine, as long as it does not compromise performance. I looked at some of the code that does this and I am concerned about the impact on performance (see below for more specifics). Having RuntimeSCABindingInvoker delegate to the service's invocation chain instead of linking the invocation chains seems a better approach. If the statically wired reference/service pair defines a callback interface, static wires for callback purposes are created from the pseudo-reference to the pseudo-service (this is what the code at line 503 is doing). Again, the binding's start method may perform invocation chain optimization. These
Re: [NOTICE] Brady Johnson voted as Tuscany committer
On 8/21/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > Welcome Brady !!! > > On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Pete Robbins wrote: > > > The Tuscany PPMC and Incubator PMC have voted for Brady to become a > > > Tuscany committer. > > > > > > Congratulations and welcome Brady! > > > > > > I look forward to your continued excellent contributions to Tuscany. > > > > > > Cheers, > > > > > > > > > > Welcome Brady! > > > > -- > > Jean-Sebastien > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Luciano Resende > Apache Tuscany Committer > http://people.apache.org/~lresende > http://lresende.blogspot.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Welcome on board Brady. Simon
SCA/SDO seminars in China using Apache Tuscany
I've just found out that a series of seminars are being held to promote SCA/SDO technology from a vendor-neutral viewpoint (http://www.ibm.com/developerworks/offers/techbriefings/details/scasdo.html ). Apache Tuscany is going to be used in demos. The first 3 seminars will be in China at the end of this month. I asked and am told that other countries will be announced soon. Here are the locations that the website is advertising now. Beijing, China Zhao Long hotel 2 Gongti North Road Chaoyang, Biejing Venue: Longxi Room 2007 Aug 25 (09:00 to 13:00) Shanghai, China Pudong Software Park 498 GuoShouJing Road Pudong, Shanghai 2007 Aug 29 (09:00 to 13:00) Shenzhen, China Four Points by Sheraton Guihua Road 5 Shenzhen Venue: Shenzhen A Room 2007 Sep 01 (09:00 to 13:00) Details can be found at ( http://www.ibm.com/developerworks/offers/techbriefings/details/scasdo.html ) You can register through the web page (see the "select location and register" link). Regards Simon
Re: nullp when running binding-echo sample
Thank you both :) On 8/20/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > I fixed first :) You sent e-mail first :) > > On 8/20/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > > > It was fixed by Luciano a few minutes ago before I tried to check in the > > same fix :-). > > > > Thanks, > > Raymond > > - Original Message - > > From: "Luciano Resende" <[EMAIL PROTECTED]> > > To: > > Sent: Monday, August 20, 2007 9:44 PM > > Subject: Re: nullp when running binding-echo sample > > > > > > >I get an exception either from inside Eclipse IDE or from distribution > > > using ant. Could you please create a jira for tracking this issue. > > > > > > On 8/20/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > >> Hi, > > >> > > >> I am running this sample from the distribution that I built based on > the > > >> latest code. > > >> When I ran the sample following ant instructions, I get the > following: > > >> > > >> C:\tuscany-new\sca-dist\tuscany- > > >> sca-1.0-incubating-SNAPSHOT\samples\binding-echo > > >> >ant run > > >> Buildfile: build.xml > > >> > > >> run: > > >> [java] Returned message: foo > > >> [java] Echo reference = foo > > >> [java] Exception in thread "main" java.lang.NullPointerException > > >> [java] at echo.server.EchoServer.sendReceive(EchoServer.java > :75) > > >> [java] at echo.EchoBindingClient.main(EchoBindingClient.java > :44) > > >> [java] Java Result: 1 > > >> > > >> BUILD SUCCESSFUL > > >> Total time: 1 second > > >> C:\tuscany-new\sca-dist\tuscany- > > >> sca-1.0-incubating-SNAPSHOT\samples\binding-echo > > >> > > >> > > >> I this a known problem that is being worked on? > > >> > > > > > > > > > -- > > > Luciano Resende > > > Apache Tuscany Committer > > > http://people.apache.org/~lresende > > > http://lresende.blogspot.com/ > > > > > > - > > > 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] > > > > > > > -- > Luciano Resende > Apache Tuscany Committer > http://people.apache.org/~lresende > http://lresende.blogspot.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Welcome Brady !!! On 8/21/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Pete Robbins wrote: > > The Tuscany PPMC and Incubator PMC have voted for Brady to become a > > Tuscany committer. > > > > Congratulations and welcome Brady! > > > > I look forward to your continued excellent contributions to Tuscany. > > > > Cheers, > > > > > > Welcome Brady! > > -- > Jean-Sebastien > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany/Geronimo Integration Demo
Simon Nash wrote: Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: A few questions. [snip] ant elder wrote: I'm not very keen at all on doing that. Couldn't we actually put the code in our svn instead of using SVN externals (if necessary the Geronimo guys could use SVN externals if they really want it). Necessary yes, as far as I know the Geronimo guys are the guys working on this code. But will that work if the code moves to our SVN, will they still be able to commit their changes? Can you help me understand how that will work? I'd quite like this code in our svn anyway as some of it could be shared by others who're also integrating Tuscany. I'm not sure I understand. What exactly will prevent others who are also integrating with Tuscany to share this code if it stays where it is now in the Geronimo SVN repository? I'd like to spend a little bit of time today to get the Geronimo/Integration code building as part of the Tuscany build, get it into our Eclipse build profile to generate the correct classpath declarations, and add an itest for this integration. We have discussed two options for having this code built in Tuscany so far: [a] keep the integration code in the Geronimo repository, have Tuscany point to it using SVN externals [b] move the integration code to the Tuscany repository and have the Geronimo folks point to it using SVN externals if they want I prefer [a] for now, as it allows me to build this code in Tuscany, while continuing to allow the Geronimo folks to work on it without breaking them. Ant has raised concerns with [a]. I have raised questions and concerns with [b], but I may very well be convinced that [b] is better... if I get answers to the questions I asked, and if the Geronimo folks working on this integration are OK with [b] as well. Could people please jump in and describe what will work best for them, I'd like to make progress on this. Thanks. In the long or medium term this code should become a Geronimo feature that is part of the Geronimo release distribution. Moving it to the Tuscany repository is a step in the wrong direction from this perspective. In the short term it seems that this could be regarded as a separate component that is not directly part of either Geronimo or Tuscany but requires both of these to be installed in order to use it. As a separate component, it could be bundled with the Tuscany binary distro like the many other external dependencies that we include. So I'd go for [a] but structure the build to place the binaries for this component somewhere different than the modules that are part of java/sca/. Something like java/sca/externals/geronimo-tuscany perhaps? And I'd suggest publishing it to the mvn repos (when it's ready) under the "geronimo" group ID, not "tuscany". Simon I agree that the Geronimo plugin for Tuscany more naturally belongs to Geronimo and should become a Geronimo feature. This is a good reason for keeping this code in the Geronimo repository. So: I'm +1 on keeping the code in Geronimo -1 on moving it to the Tuscany SVN I won't use SVN externals to point to this code from the Tuscany SVN since Ant is -1 on this. Manu, Vamsi, I have two questions: - are you planning to move this code to a better place than sandbox in the Geronimo repository? - are you planning to publish geronimo-tuscany-plugin-1.0-incubating-SNAPSHOT.car somewhere? In the meantime: - the source is at http://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration - it built OK for me before but now I'm getting this error [WARNING] Unable to get resource 'org.apache.geronimo.plugins:car-maven-plugin:pom:2.0.1' from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.geronimo.plugins ArtifactId: car-maven-plugin Version: 2.0.1 Reason: Unable to download the artifact from any repository org.apache.geronimo.plugins:car-maven-plugin:pom:2.0.1 from the specified remote repositories: central (http://repo1.maven.org/maven2), tomcat-m2-repo (http://repository.codehaus.org), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), temp-repo (http://people.apache.org/~manugeorge/repository), apache-incubating (http://people.apache.org/repo/m2-incubating-repository), ussg-maven-repo (http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2), ws.zones (http://ws.zones.apache.org/repository) Do I need to add another Maven repos to my Maven settings? Is version 2.0.1 correct for this plugin? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TUSCANY-1356
Simon Nash wrote: ant elder wrote: On 8/20/07, Simon Nash <[EMAIL PROTECTED]> wrote: I'm restarting the discussion on this because the previous thread [1] did not reach a conclusion. I thought it would be useful to summarize the issues with the extension samples as they stand, and explain how the patch for TUSCANY-1356 resolves these issues. In the implementation-crud sample (the client application code), we have CRUDClient.java, crud.composite, and CRUDTestCase.java. CRUDClient.java and crud.composite together provide a sample client that exercises implementation-crud-extension, and these two files are correctly part of implementation-crud because they are not part of the extension jar. The problem with implementation-crud is the inclusion of CRUDTestCase.java , which does not use or test any of the above client code, but is just a copy of the same file from implementation-crud-extension (and executed by mvn when implementation-crud-extension is built). The patch for TUSCANY-1356 eliminates this duplicate copy of CRUDTestCase.java in implementation-crud and adds a new itest (not part of the samples) that runs the implementation-crud client code to make sure it executes OK. The crud.composite file from the implementation-crud sample client is also duplicated as part of the test code for implementation-crud-extension. There is no need for this code to be duplicated. The patch for TUSCANY-1356 eliminates this duplicate copy of crud.composite by having the JUnit test for implementation-crud-extension use the crud.composite file that is part of implementation-crud. Similarly, in the binding-echo-extension sample, under src/test there are duplicates of the implementation code, composite file, and JUnit test code from binding-echo. The patch for TUSCANY-1356 removes duplicate code from binding-echo-extension by having the JUnit tests in binding-echo-extension take this code from binding-echo, adds a non-sample itest to exercise EchoBindingClient.java from binding-echo, and removes redundant JUnit test code from binding-echo (not needed because the JUnit tests in binding-echo-extension contains exactly the same code). With these changes, all duplicate code is eliminated from these samples, all sample code is tested either by sample JUnit tests or separate itests, and the distinction between the extension and client/application samples is much clearer. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19026.html How about instead just deleting the implementation.crud sample? We've the implementation.pojo sample now which seems like a better sample to me anyway. The patch for TUSCANY-1356 also corrects similar problems with the binding-echo and binding-echo-extension samples. This part of the patch could be applied while we consider whether or not to delete implementation-crud. I looked at the implementation-pojo-extension sample. It has no associated client to run "out of the box" using ant. The issues addressed by TUSCANY-1356 arose out of the work that was done on implementation-crud and binding-echo to factor them into an extension sample and client/application sample so that the client code could run out of the box using ant. If we decide to replace implementation-crud by implementation-pojo, we would need to fix up implementation-pojo-extension to add a client sample, with code divided between the extension sample and the client sample in the same way that the patch for TUSCANY-1356 does. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I would like to keep implementation-crud as it's showing an implementation type different from a POJO. Implementation-crud and implementation-pojo are meant to show different approaches to component implementations, and I'll be concerned if our only implementation sample leads all people down the POJO path. If people have serious and concrete enough issues with implementation-crud, please raise them and we should take a look at them. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (TUSCANY-1438) Change TuscanySCA Native build system to use ant
Ok thanks Adriano. I'll look into this now. Brady -Original Message- From: Adriano Crestani (JIRA) [mailto:[EMAIL PROTECTED] Sent: Monday, August 20, 2007 6:42 PM To: Brady Johnson Subject: [jira] Commented: (TUSCANY-1438) Change TuscanySCA Native build system to use ant [ https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.ji ra.plugin.system.issuetabpanels:comment-tabpanel#action_12521286 ] Adriano Crestani commented on TUSCANY-1438: --- The patch tuscany_patch_update10_jira1438 seems to be generated from a old trunk version, somehow my tortoiseSVN is reporting "The patch seems outdated". Regards, Adriano Crestani > Change TuscanySCA Native build system to use ant > > > Key: TUSCANY-1438 > URL: https://issues.apache.org/jira/browse/TUSCANY-1438 > Project: Tuscany > Issue Type: Improvement > Components: C++ SCA >Affects Versions: Cpp-Next > Environment: all platforms >Reporter: Brady Johnson >Priority: Minor > Fix For: Cpp-Next > > Attachments: README_ANT_INSTALL.txt, > samples.CppBigBank.build.xml, tuscany_patch_update10_jira1438, > tuscany_patch_update2_jira1438, tuscany_patch_update3_jira1438, > tuscany_patch_update4_jira1438, tuscany_patch_update5_jira1438, > tuscany_patch_update6_jira1438, tuscany_patch_update7_jira1438, > tuscany_patch_update8_jira1438, tuscany_patch_update9_jira1438, > TuscanySCANative.ant.display.system, tuscanySCAnative_ant.tar.gz, > tuscanySCAnative_ant_update1.tar.gz > > > In an effort to simplify the build process, I would like to propose switching over to use ant instead of automake. It will be much easier to maintain, and is used by many more developers today than automake. > Per a request by Pete Robbins to show what the build scripts would look like for cpp/sca/runtime/core, I will attach a patch with the build infrastructure to build, link, and install said library. > > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Pete Robbins wrote: The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, Welcome Brady! -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1556) Incorrect WSDL generated for service interfaces passing SDO DataObjects
[ https://issues.apache.org/jira/browse/TUSCANY-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reopened TUSCANY-1556: - Reopening as this JIRAs give more information about the problem and how to reproduce it. I'm happy to link them to the umbrella TUSCANY-1544 issue. I don't agree with postponing the resolution of the JIRA to after 0.99, as complying with a known XMLschema is the point of using a Web Service binding. With respect to your comment that the current test case does not fail, that's because it does not check that the data flowing on the wire is correct. The test case is insufficient and should be changed to perform that checking. I described in the JIRA how to see that there is actually a problem. > Incorrect WSDL generated for service interfaces passing SDO DataObjects > > > Key: TUSCANY-1556 > URL: https://issues.apache.org/jira/browse/TUSCANY-1556 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Axis Binding Extension >Reporter: Jean-Sebastien Delfino > Fix For: Java-SCA-Next > > > Here's an easy way to reproduce the problem: > Add a sleep statement to itest/wsdlless SDOWSDLTestCase.tearDown() to keep > the server running a while, start that test case, then point your Web browser > to http://localhost:8085/AccountService?wsdl. > You'll get a WSDL containing incorrect XSDs, as they are completely different > from the XSDs representing the SDOs on the AccountService interface. The > namespaces are not correct, the element and type definitions are not correct > either. > > targetNamespace="http://accountdata.services.account.bigbank"; > xmlns:axis2="http://accountdata.services.account.bigbank"; > xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"; > xmlns:ns="http://accountdata.services.account.bigbank/xsd"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";> > > elementFormDefault="qualified" > targetNamespace="http://account.bigbank.com/xsd"; > xmlns:ax29="http://account.bigbank.com/xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema";> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > elementFormDefault="qualified" > targetNamespace="http://accountdata.services.account.bigbank/xsd"; > xmlns:ns0="http://account.bigbank.com/xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema";> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >wsaw:Action="urn:getAccountLog"> > >wsaw:Action="urn:getAccountLog"> > > > >wsaw:Action="urn:getAccountReport"> > >wsaw:Action="urn:getAccountReport"> > > > >wsaw:Action="urn:createAccount"> > >wsaw:Action="urn:createAccount"> > > > >wsaw:Action="urn:getCustomerProfile"> > >wsaw:Action="urn:getCustomerProfile"> > > > >wsaw:Action="urn:purchaseStock"> > >wsaw:Action="urn:purchaseStock"> > > > >wsaw:Action="urn:sellStock"> > >wsaw:Action="urn:sellStock"> > > > > > >wsaw:Action="urn:deposit"> > > > > > >wsaw:Action="urn:withdraw"> > > > >type="axis2:AccountDataServicePortType"> > transport="http://schemas.xmlsoap.org/soap/http"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
[jira] Reopened: (TUSCANY-1557) Web Service response does not match the schema of the returned SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reopened TUSCANY-1557: - Reopening as this JIRAs give more information about the problem and how to reproduce it. I'm happy to link them to the umbrella TUSCANY-1544 issue. I don't agree with postponing the resolution of the JIRA to after 0.99, as complying with a known XMLschema is the point of using a Web Service binding. With respect to your comment that the current test case does not fail, that's because it does not check that the data flowing on the wire is correct. The test case is insufficient and should be changed to perform that checking. I described in the JIRA how to see that there is actually a problem. > Web Service response does not match the schema of the returned SDO > --- > > Key: TUSCANY-1557 > URL: https://issues.apache.org/jira/browse/TUSCANY-1557 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Axis Binding Extension >Reporter: Jean-Sebastien Delfino > Fix For: Java-SCA-Next > > > To see the problem, monitor the HTTP traffic returned by the itest/wsdlless > SDOWSDLTestCase. > This test case exercises the AccountService.createAccount and > getAccountReport methods, both returning SDOs, described by the XSD inlined > in that wsdl: > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdlless/src/main/resources/wsdl/AccountService.wsdl > The test Web service returns the following XML, incorrect as not compliant > with the XSD at all (attributes instead of elements, incorrect namespace, > references to commonj.sdo in the XML). > http://schemas.xmlsoap.org/soap/envelope/";?> > http://schemas.xmlsoap.org/soap/envelope/";> > > <_ns_:getAccountReportResponse > xmlns:_ns_="http://accountdata.services.account.bigbank/xsd";> > http://accountdata.services.account.bigbank/xsd"; > xmlns:p0="commonj.sdo" xmlns:p1="http://www.bigbank.com/account"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="p1:AccountReport"> > balance="1000.0"/> > balance="2000.0"/> > > > > > and > http://schemas.xmlsoap.org/soap/envelope/";?> > http://schemas.xmlsoap.org/soap/envelope/";> > > <_ns_:createAccountResponse > xmlns:_ns_="http://accountdata.services.account.bigbank/xsd";> > http://accountdata.services.account.bigbank/xsd"; > xmlns:p0="commonj.sdo" xmlns:p1="http://www.bigbank.com/account"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="p1:CustomerProfileData"> > petra > A > home > [EMAIL PROTECTED] > petra > ant > 1 > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Congratulations and welcome Brady ...ant On 8/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote: > > The Tuscany PPMC and Incubator PMC have voted for Brady to become a > Tuscany committer. > > Congratulations and welcome Brady! > > I look forward to your continued excellent contributions to Tuscany. > > Cheers, > > -- > Pete > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
[NOTICE] Brady Johnson voted as Tuscany committer
The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions
[
https://issues.apache.org/jira/browse/TUSCANY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1565.
-
Resolution: Cannot Reproduce
I tried it with the latest from HEAD, and there was no exception. I guess it's
a bug in the 1.0 release that has since been fixed.
> CopyHelper.copy() fails to copy schema extensions
> -
>
> Key: TUSCANY-1565
> URL: https://issues.apache.org/jira/browse/TUSCANY-1565
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Win XP, IBM JRE 1.4.2 & IBM JRE 1.5.0
>Reporter: Chris Mildebrandt
> Attachments: Address.xsd, CopyTest.java, Person.xsd
>
>
> Hello,
> I've been seeing some weird behavior with the copy implementation. I have two
> schemas, one with the following line:
> maxOccurs="unbounded"/>
> I'm inserting the second schema into the first as a part of this extension.
> When I run the CopyHelper.INSTANCE.copy() method against it, weird things
> start to happen.
> The first case:
> Both schema files are defined dynamically. The data objects are created and
> one is added to the other. That looks like this:
> HelperContext context = HelperProvider.getDefaultContext();
> {
> InputStream in = new File("Person.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> }
> {
> InputStream in = new File("Address.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> }
> DataObject person1 =
> context.getDataFactory().create("http://www.example.org/Person";,
> "PersonType");
> DataObject address =
> context.getDataFactory().create("http://www.example.org/Address";,
> "AddressType");
> person1.set("Age", "30");
> person1.set("Name", "Jim");
> address.set("Street", "123 Fake St.");
> address.set("City", "Springfield");
> address.set("Zip", "46392");
> Property addressProperty =
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
> "Address", true);
> (person1).getList(addressProperty).add(address);
>
> DataObject person2 = CopyHelper.INSTANCE.copy(person1);
>
> person2.getList(addressProperty).clear();
> person2.getList(addressProperty).add(address);
> When I save the data objects to files, the person1 data object doesn't
> contain the address data object, but person2 does. When I remove the last
> line that adds the address to person2, then the person1 data object correctly
> contains the address data object. I would think the person1 data object
> shouldn't be affected by changes to the person2 (copy of person1) data object.
> The second case:
> Static classes are generated for the first schema, the second is defined
> dynamically. Data objects are created for both, and the second is added to
> the first. That looks like this:
> HelperContext context = HelperProvider.getDefaultContext();
> PersonFactory.INSTANCE.register(context);
> PersonType person1 = PersonFactory.INSTANCE.createPersonType();
> person1.setAge("30");
> person1.setName("Jim");
> InputStream in = new File("Address.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> DataObject address =
> context.getDataFactory().create("http://www.example.org/Address";,
> "AddressType");
> address.set("Street", "123 Fake St.");
> address.set("City", "Springfield");
> address.set("Zip", "46392");
> Property addressProperty =
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
> "Address", true);
> ((DataObject) person1).getList(addressProperty).add(address);
>
> PersonType person2 = (PersonType)
> CopyHelper.INSTANCE.copy((DataObject) person1);
>
> ((DataObject) person2).getList(addressProperty).clear();
> ((DataObject) person2).getList(addressProperty).add(address);
> When I run with this, I get the following exception:
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array
> index out of range: -2
> at
> org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.dynamicGet(ExtensibleDataObjectImpl.java:128)
> at
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicInverseRemove(EStructuralFeatureImpl.java:1687)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicInverseRemove(BasicEObjectImpl.java:1038)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1027)
> at
> org.apache.tuscany.sdo.impl.DataObjectBase.inverseRemove
[jira] Reopened: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions
[
https://issues.apache.org/jira/browse/TUSCANY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Mildebrandt reopened TUSCANY-1565:
Thank you for the clarification on the specification. I understand that case
now. I regenerated my classes with the Tuscany 1.0 jars and see the same
exception. Please let me know if you have any additional questions.
Thanks,
-Chris
> CopyHelper.copy() fails to copy schema extensions
> -
>
> Key: TUSCANY-1565
> URL: https://issues.apache.org/jira/browse/TUSCANY-1565
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Win XP, IBM JRE 1.4.2 & IBM JRE 1.5.0
>Reporter: Chris Mildebrandt
> Attachments: Address.xsd, CopyTest.java, Person.xsd
>
>
> Hello,
> I've been seeing some weird behavior with the copy implementation. I have two
> schemas, one with the following line:
> maxOccurs="unbounded"/>
> I'm inserting the second schema into the first as a part of this extension.
> When I run the CopyHelper.INSTANCE.copy() method against it, weird things
> start to happen.
> The first case:
> Both schema files are defined dynamically. The data objects are created and
> one is added to the other. That looks like this:
> HelperContext context = HelperProvider.getDefaultContext();
> {
> InputStream in = new File("Person.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> }
> {
> InputStream in = new File("Address.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> }
> DataObject person1 =
> context.getDataFactory().create("http://www.example.org/Person";,
> "PersonType");
> DataObject address =
> context.getDataFactory().create("http://www.example.org/Address";,
> "AddressType");
> person1.set("Age", "30");
> person1.set("Name", "Jim");
> address.set("Street", "123 Fake St.");
> address.set("City", "Springfield");
> address.set("Zip", "46392");
> Property addressProperty =
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
> "Address", true);
> (person1).getList(addressProperty).add(address);
>
> DataObject person2 = CopyHelper.INSTANCE.copy(person1);
>
> person2.getList(addressProperty).clear();
> person2.getList(addressProperty).add(address);
> When I save the data objects to files, the person1 data object doesn't
> contain the address data object, but person2 does. When I remove the last
> line that adds the address to person2, then the person1 data object correctly
> contains the address data object. I would think the person1 data object
> shouldn't be affected by changes to the person2 (copy of person1) data object.
> The second case:
> Static classes are generated for the first schema, the second is defined
> dynamically. Data objects are created for both, and the second is added to
> the first. That looks like this:
> HelperContext context = HelperProvider.getDefaultContext();
> PersonFactory.INSTANCE.register(context);
> PersonType person1 = PersonFactory.INSTANCE.createPersonType();
> person1.setAge("30");
> person1.setName("Jim");
> InputStream in = new File("Address.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> DataObject address =
> context.getDataFactory().create("http://www.example.org/Address";,
> "AddressType");
> address.set("Street", "123 Fake St.");
> address.set("City", "Springfield");
> address.set("Zip", "46392");
> Property addressProperty =
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
> "Address", true);
> ((DataObject) person1).getList(addressProperty).add(address);
>
> PersonType person2 = (PersonType)
> CopyHelper.INSTANCE.copy((DataObject) person1);
>
> ((DataObject) person2).getList(addressProperty).clear();
> ((DataObject) person2).getList(addressProperty).add(address);
> When I run with this, I get the following exception:
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array
> index out of range: -2
> at
> org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.dynamicGet(ExtensibleDataObjectImpl.java:128)
> at
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicInverseRemove(EStructuralFeatureImpl.java:1687)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicInverseRemove(BasicEObjectImpl.java:1038)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:
[jira] Resolved: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions
[
https://issues.apache.org/jira/browse/TUSCANY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1565.
-
Resolution: Invalid
Hi Chris,
This is working as expected. This line:
person2.getList(addressProperty).add(address);
is adding to person2 the same address object from person1. Since it's a
contained DataObject, SDO removes the object from it's old container (person1).
See the last paragraph of section 3.1.6 in the spec
(http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1).
The exception you were seeing sounds like a generated code compatibility issue.
Make sure you regenerate the classes with the version of SDO that you will run
them with. If you do that and still see the problem (in the latest from HEAD -
bug may have been fixed) please reopen the JIRA for it.
Thanks,
Frank.
> CopyHelper.copy() fails to copy schema extensions
> -
>
> Key: TUSCANY-1565
> URL: https://issues.apache.org/jira/browse/TUSCANY-1565
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Win XP, IBM JRE 1.4.2 & IBM JRE 1.5.0
>Reporter: Chris Mildebrandt
> Attachments: Address.xsd, CopyTest.java, Person.xsd
>
>
> Hello,
> I've been seeing some weird behavior with the copy implementation. I have two
> schemas, one with the following line:
> maxOccurs="unbounded"/>
> I'm inserting the second schema into the first as a part of this extension.
> When I run the CopyHelper.INSTANCE.copy() method against it, weird things
> start to happen.
> The first case:
> Both schema files are defined dynamically. The data objects are created and
> one is added to the other. That looks like this:
> HelperContext context = HelperProvider.getDefaultContext();
> {
> InputStream in = new File("Person.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> }
> {
> InputStream in = new File("Address.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> }
> DataObject person1 =
> context.getDataFactory().create("http://www.example.org/Person";,
> "PersonType");
> DataObject address =
> context.getDataFactory().create("http://www.example.org/Address";,
> "AddressType");
> person1.set("Age", "30");
> person1.set("Name", "Jim");
> address.set("Street", "123 Fake St.");
> address.set("City", "Springfield");
> address.set("Zip", "46392");
> Property addressProperty =
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
> "Address", true);
> (person1).getList(addressProperty).add(address);
>
> DataObject person2 = CopyHelper.INSTANCE.copy(person1);
>
> person2.getList(addressProperty).clear();
> person2.getList(addressProperty).add(address);
> When I save the data objects to files, the person1 data object doesn't
> contain the address data object, but person2 does. When I remove the last
> line that adds the address to person2, then the person1 data object correctly
> contains the address data object. I would think the person1 data object
> shouldn't be affected by changes to the person2 (copy of person1) data object.
> The second case:
> Static classes are generated for the first schema, the second is defined
> dynamically. Data objects are created for both, and the second is added to
> the first. That looks like this:
> HelperContext context = HelperProvider.getDefaultContext();
> PersonFactory.INSTANCE.register(context);
> PersonType person1 = PersonFactory.INSTANCE.createPersonType();
> person1.setAge("30");
> person1.setName("Jim");
> InputStream in = new File("Address.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> DataObject address =
> context.getDataFactory().create("http://www.example.org/Address";,
> "AddressType");
> address.set("Street", "123 Fake St.");
> address.set("City", "Springfield");
> address.set("Zip", "46392");
> Property addressProperty =
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
> "Address", true);
> ((DataObject) person1).getList(addressProperty).add(address);
>
> PersonType person2 = (PersonType)
> CopyHelper.INSTANCE.copy((DataObject) person1);
>
> ((DataObject) person2).getList(addressProperty).clear();
> ((DataObject) person2).getList(addressProperty).add(address);
> When I run with this, I get the following exception:
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException:
Re: Mismatch in current ServiceProcessor and SCA Java Common Annotations and APIs spec
I guess no need of any new method, simple check like
interfaze.isAssignableFrom(clazz) - will do the same.
Regards,
Amita
On 8/21/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
>
> I was debugging JIRA-1517 when came up with the below findings. Please see
> if this
> is the right way to fix it or any alternatives.
>
> From spec:-
> 1) All methods from interface @Service(interfaceName/s) should be present
> in the
> implementation class.
> 2)If a Java implementation needs to realize two services with the same
> interface, then this is achieved
> through subclassing of the interface. The subinterface must not add any
> methods. Both interfaces are
> listed in the @Service annotation of the Java implementation class.
>
> Problem:
>
> Now, take for example sample-calculator, below is changed in ServiceImpl
> (introduced wrong interface name)
>
> @Service(Calculator3Service.class)
> public class CalculatorServiceImpl implements CalculatorService {
>
> Also there is an interface Calculator3Service which has String
> myService(); and nothing else.
> Whereas CalculatorService interface has add(), subtract(), multiply(),
> divide().
>
> So 1) above is violated.
>
> When client calls,
> scaDomain = SCADomain.newInstance("Calculator.composite");
> calculatorService = scaDomain.getService(CalculatorService.class,
> "CalculatorServiceComponent");
> calculatorService.add(3, 2);
>
> During invokation when
> org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.map(Interface
> target, Operation source)
> is called, as target has only operation myService() which does not match
> source, returns null and
> then
> org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceUtil.findMethod()
> throws NPE.
>
> Solution:
>
> To avoid this, can @Service processor be more strict and check if there is
> a mismatch
> in @Service(interface/s) and what is there in implements of the
> serviceImpl - for the methods
> in them? It may not be correct to match names of the interfaces, as in
> case of rule 2) these
> may not match. So, the safest way will be, in ServiceProcessor.visitClass(),
> call a new method
> for this check say like below and for any mismatch found
> throw IllegalServiceDefinitionException("Interface "+interfaceName+" is
> not implemented by " + className)
>
> New method: in ServiceProcessor
> ___
> public boolean checkMethodsImplemented(Class clazz, Class
> interfaze) {
> Method[] interfaceMethods = interfaze.getMethods();
> Method[] classMethods = clazz.getMethods();
> List classMethodsList = Arrays.asList(classMethods);
>
> for(Method interfaceMethod : interfaceMethods) {
> if(!classMethodsList.contains(interfaceMethod)) {
> return false;
> }
> }
> return true;
> }
>
> Use in: ServiceProcessor.visitClass()...
> ___...
> for (Class interfaze : interfaces) {
> if (!interfaze.isInterface()) {
> throw new InvalidServiceType("Service must be an interface",
> interfaze);
> }
>
> if(!checkMethodsImplemented(clazz, interfaze)) {
> throw IllegalServiceDefinitionException("Interface
> "+interfaze.getName()+" is not implemented by " + clazz.getName());
> }
>
> Service service;
> try {
> service = createService(interfaze);
> } catch (InvalidInterfaceException e) {
> throw new IntrospectionException(e);
> }
> type.getServices().add(service);
> }
> .
>
> Regards,
> Amita
>
[jira] Updated: (TUSCANY-1566) Element coming out in the wrong namespace
[
https://issues.apache.org/jira/browse/TUSCANY-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Peters updated TUSCANY-1566:
Attachment: Atom1.0.xsd
> Element coming out in the wrong namespace
> -
>
> Key: TUSCANY-1566
> URL: https://issues.apache.org/jira/browse/TUSCANY-1566
> Project: Tuscany
> Issue Type: Bug
> Components: C++ SDO
>Affects Versions: Cpp-Next
> Environment: WinXP
>Reporter: Matthew Peters
> Attachments: Atom1.0.xsd
>
>
> We have a schema file that defines an atom feed. It specified
> elementFormDefault="qualified" so that lower level elements should be in the
> target namespace. I will attach the schema as a separate file. With a very
> simple php test case as follows:
> $xmldas = SDO_DAS_XML::create('Atom1.0.xsd');
> $document = $xmldas->createDocument('http://www.w3.org/2005/Atom','entry');
> $entry = $document->getRootDataObject();
> $author = $entry->createDataObject('author');
> $author->name[] = "Caroline Maynard";
> print $xmldas->saveString($document,2);
> we get
>
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns:tns="http://www.w3.org/2005/Atom";>
>
> Caroline Maynard
>
>
> whereas we should see the element in the tns namespace.
> I have checked this with XERCES: the xml that we are generating will not
> validate, whereas if I alter it to have in the tns namespace it will.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1566) Element coming out in the wrong namespace
Element coming out in the wrong namespace
-
Key: TUSCANY-1566
URL: https://issues.apache.org/jira/browse/TUSCANY-1566
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-Next
Environment: WinXP
Reporter: Matthew Peters
We have a schema file that defines an atom feed. It specified
elementFormDefault="qualified" so that lower level elements should be in the
target namespace. I will attach the schema as a separate file. With a very
simple php test case as follows:
$xmldas = SDO_DAS_XML::create('Atom1.0.xsd');
$document = $xmldas->createDocument('http://www.w3.org/2005/Atom','entry');
$entry = $document->getRootDataObject();
$author = $entry->createDataObject('author');
$author->name[] = "Caroline Maynard";
print $xmldas->saveString($document,2);
we get
http://www.w3.org/2001/XMLSchema-instance";
xmlns:tns="http://www.w3.org/2005/Atom";>
Caroline Maynard
whereas we should see the element in the tns namespace.
I have checked this with XERCES: the xml that we are generating will not
validate, whereas if I alter it to have in the tns namespace it will.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions
[
https://issues.apache.org/jira/browse/TUSCANY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Mildebrandt updated TUSCANY-1565:
---
Attachment: Person.xsd
Address.xsd
CopyTest.java
> CopyHelper.copy() fails to copy schema extensions
> -
>
> Key: TUSCANY-1565
> URL: https://issues.apache.org/jira/browse/TUSCANY-1565
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
>Affects Versions: Java-SDO-1.0
> Environment: Win XP, IBM JRE 1.4.2 & IBM JRE 1.5.0
>Reporter: Chris Mildebrandt
> Attachments: Address.xsd, CopyTest.java, Person.xsd
>
>
> Hello,
> I've been seeing some weird behavior with the copy implementation. I have two
> schemas, one with the following line:
> maxOccurs="unbounded"/>
> I'm inserting the second schema into the first as a part of this extension.
> When I run the CopyHelper.INSTANCE.copy() method against it, weird things
> start to happen.
> The first case:
> Both schema files are defined dynamically. The data objects are created and
> one is added to the other. That looks like this:
> HelperContext context = HelperProvider.getDefaultContext();
> {
> InputStream in = new File("Person.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> }
> {
> InputStream in = new File("Address.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> }
> DataObject person1 =
> context.getDataFactory().create("http://www.example.org/Person";,
> "PersonType");
> DataObject address =
> context.getDataFactory().create("http://www.example.org/Address";,
> "AddressType");
> person1.set("Age", "30");
> person1.set("Name", "Jim");
> address.set("Street", "123 Fake St.");
> address.set("City", "Springfield");
> address.set("Zip", "46392");
> Property addressProperty =
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
> "Address", true);
> (person1).getList(addressProperty).add(address);
>
> DataObject person2 = CopyHelper.INSTANCE.copy(person1);
>
> person2.getList(addressProperty).clear();
> person2.getList(addressProperty).add(address);
> When I save the data objects to files, the person1 data object doesn't
> contain the address data object, but person2 does. When I remove the last
> line that adds the address to person2, then the person1 data object correctly
> contains the address data object. I would think the person1 data object
> shouldn't be affected by changes to the person2 (copy of person1) data object.
> The second case:
> Static classes are generated for the first schema, the second is defined
> dynamically. Data objects are created for both, and the second is added to
> the first. That looks like this:
> HelperContext context = HelperProvider.getDefaultContext();
> PersonFactory.INSTANCE.register(context);
> PersonType person1 = PersonFactory.INSTANCE.createPersonType();
> person1.setAge("30");
> person1.setName("Jim");
> InputStream in = new File("Address.xsd").toURL().openStream();
> context.getXSDHelper().define(in, null);
> DataObject address =
> context.getDataFactory().create("http://www.example.org/Address";,
> "AddressType");
> address.set("Street", "123 Fake St.");
> address.set("City", "Springfield");
> address.set("Zip", "46392");
> Property addressProperty =
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
> "Address", true);
> ((DataObject) person1).getList(addressProperty).add(address);
>
> PersonType person2 = (PersonType)
> CopyHelper.INSTANCE.copy((DataObject) person1);
>
> ((DataObject) person2).getList(addressProperty).clear();
> ((DataObject) person2).getList(addressProperty).add(address);
> When I run with this, I get the following exception:
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array
> index out of range: -2
> at
> org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.dynamicGet(ExtensibleDataObjectImpl.java:128)
> at
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicInverseRemove(EStructuralFeatureImpl.java:1687)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicInverseRemove(BasicEObjectImpl.java:1038)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1027)
> at
> org.apache.tuscany.sdo.impl.DataObjectBase.inverseRemove(DataObjectBase.java:307)
> at
> org.example.person.impl.PersonTypeImpl
[jira] Created: (TUSCANY-1565) CopyHelper.copy() fails to copy schema extensions
CopyHelper.copy() fails to copy schema extensions
-
Key: TUSCANY-1565
URL: https://issues.apache.org/jira/browse/TUSCANY-1565
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Environment: Win XP, IBM JRE 1.4.2 & IBM JRE 1.5.0
Reporter: Chris Mildebrandt
Hello,
I've been seeing some weird behavior with the copy implementation. I have two
schemas, one with the following line:
I'm inserting the second schema into the first as a part of this extension.
When I run the CopyHelper.INSTANCE.copy() method against it, weird things start
to happen.
The first case:
Both schema files are defined dynamically. The data objects are created and one
is added to the other. That looks like this:
HelperContext context = HelperProvider.getDefaultContext();
{
InputStream in = new File("Person.xsd").toURL().openStream();
context.getXSDHelper().define(in, null);
}
{
InputStream in = new File("Address.xsd").toURL().openStream();
context.getXSDHelper().define(in, null);
}
DataObject person1 =
context.getDataFactory().create("http://www.example.org/Person";, "PersonType");
DataObject address =
context.getDataFactory().create("http://www.example.org/Address";,
"AddressType");
person1.set("Age", "30");
person1.set("Name", "Jim");
address.set("Street", "123 Fake St.");
address.set("City", "Springfield");
address.set("Zip", "46392");
Property addressProperty =
context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
"Address", true);
(person1).getList(addressProperty).add(address);
DataObject person2 = CopyHelper.INSTANCE.copy(person1);
person2.getList(addressProperty).clear();
person2.getList(addressProperty).add(address);
When I save the data objects to files, the person1 data object doesn't contain
the address data object, but person2 does. When I remove the last line that
adds the address to person2, then the person1 data object correctly contains
the address data object. I would think the person1 data object shouldn't be
affected by changes to the person2 (copy of person1) data object.
The second case:
Static classes are generated for the first schema, the second is defined
dynamically. Data objects are created for both, and the second is added to the
first. That looks like this:
HelperContext context = HelperProvider.getDefaultContext();
PersonFactory.INSTANCE.register(context);
PersonType person1 = PersonFactory.INSTANCE.createPersonType();
person1.setAge("30");
person1.setName("Jim");
InputStream in = new File("Address.xsd").toURL().openStream();
context.getXSDHelper().define(in, null);
DataObject address =
context.getDataFactory().create("http://www.example.org/Address";,
"AddressType");
address.set("Street", "123 Fake St.");
address.set("City", "Springfield");
address.set("Zip", "46392");
Property addressProperty =
context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";,
"Address", true);
((DataObject) person1).getList(addressProperty).add(address);
PersonType person2 = (PersonType) CopyHelper.INSTANCE.copy((DataObject)
person1);
((DataObject) person2).getList(addressProperty).clear();
((DataObject) person2).getList(addressProperty).add(address);
When I run with this, I get the following exception:
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array
index out of range: -2
at
org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.dynamicGet(ExtensibleDataObjectImpl.java:128)
at
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicInverseRemove(EStructuralFeatureImpl.java:1687)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicInverseRemove(BasicEObjectImpl.java:1038)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1027)
at
org.apache.tuscany.sdo.impl.DataObjectBase.inverseRemove(DataObjectBase.java:307)
at
org.example.person.impl.PersonTypeImpl.inverseRemove(PersonTypeImpl.java:355)
at
org.apache.tuscany.sdo.impl.DataObjectBase.eInverseRemove(DataObjectBase.java:484)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1017)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eBasicRemoveFromContainer(BasicEObjectImpl.java:966)
at
org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseAdd(BasicEObjectImpl.java:991)
at
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$ContainmentUpdatingFeatureMapEntry.i
[jira] Commented: (TUSCANY-1517) If serviceImpl is pointing to wrong service in @Service annotation, error message should point out to exact problem with serviceImpl/service/operation
[
https://issues.apache.org/jira/browse/TUSCANY-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521415
]
Amita Vadhavkar commented on TUSCANY-1517:
--
I tried to debug this and the stack trace I get is a bit different than one
pasted here. But anyways,
I have tried to find which can be the place to fix the issue and mailed all
details on
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21922.html
I will create a patch based on the response.
Regards,
Amita
> If serviceImpl is pointing to wrong service in @Service annotation, error
> message should point out to exact problem with serviceImpl/service/operation
> ---
>
> Key: TUSCANY-1517
> URL: https://issues.apache.org/jira/browse/TUSCANY-1517
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Problem Determination
>Reporter: Rashmi Hunt
> Fix For: Java-SCA-Next
>
>
> If user makes error in service impl, pointing to a wrong service interface
> in @Service annotation, during composite startup, Tuscany tries to introspect
> the
> impl and tries to match to service operation and fails with below exception.
> Even though it's user error, with this exception message, user can not
> figure out what is the problem with the composite. Exception message should
> be clear
> enough to point to exact error with details about which
> serviceImpl/service/operation.
> Example serviceimpl for this defect
> @Service(HelloWorld3Service.class)
> public class HelloWorldImpl implements HelloWorldService {
>
> }
> Exception:
> Caused by: java.lang.IllegalArgumentException:
> org.apache.tuscany.sca.implementation.java.context.TargetMethodNotFoundException:
> Target method not found for operation
> at
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInvoker(JavaImplementationProvider.java:134)
> at
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.addImplementationInterceptor(CompositeActivatorImpl.java:647)
> at
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createWires(CompositeActivatorImpl.java:520)
> at
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.createRuntimeWires(CompositeActivatorImpl.java:376)
> at
> org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:781)
> ... 39 more
> Caused by:
> org.apache.tuscany.sca.implementation.java.context.TargetMethodNotFoundException:
> Target method not found for operation
> at
> org.apache.tuscany.sca.implementation.java.invocation.JavaComponentInfo.createTargetInvoker(JavaComponentInfo.java:399)
> at
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInvoker(JavaImplementationProvider.java:132)
> ... 43 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Mismatch in current ServiceProcessor and SCA Java Common Annotations and APIs spec
I was debugging JIRA-1517 when came up with the below findings. Please see
if this
is the right way to fix it or any alternatives.
>From spec:-
1) All methods from interface @Service(interfaceName/s) should be present in
the
implementation class.
2)If a Java implementation needs to realize two services with the same
interface, then this is achieved
through subclassing of the interface. The subinterface must not add any
methods. Both interfaces are
listed in the @Service annotation of the Java implementation class.
Problem:
Now, take for example sample-calculator, below is changed in ServiceImpl
(introduced wrong interface name)
@Service(Calculator3Service.class)
public class CalculatorServiceImpl implements CalculatorService {
Also there is an interface Calculator3Service which has String myService();
and nothing else.
Whereas CalculatorService interface has add(), subtract(), multiply(),
divide().
So 1) above is violated.
When client calls,
scaDomain = SCADomain.newInstance("Calculator.composite");
calculatorService = scaDomain.getService(CalculatorService.class,
"CalculatorServiceComponent");
calculatorService.add(3, 2);
During invokation when
org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.map(Interface
target, Operation source)
is called, as target has only operation myService() which does not match
source, returns null and
then
org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceUtil.findMethod()
throws NPE.
Solution:
To avoid this, can @Service processor be more strict and check if there is a
mismatch
in @Service(interface/s) and what is there in implements of the serviceImpl
- for the methods
in them? It may not be correct to match names of the interfaces, as in case
of rule 2) these
may not match. So, the safest way will be, in ServiceProcessor.visitClass(),
call a new method
for this check say like below and for any mismatch found
throw IllegalServiceDefinitionException("Interface "+interfaceName+" is not
implemented by " + className)
New method: in ServiceProcessor
___
public boolean checkMethodsImplemented(Class clazz, Class
interfaze) {
Method[] interfaceMethods = interfaze.getMethods();
Method[] classMethods = clazz.getMethods();
List classMethodsList = Arrays.asList(classMethods);
for(Method interfaceMethod : interfaceMethods) {
if(!classMethodsList.contains(interfaceMethod)) {
return false;
}
}
return true;
}
Use in: ServiceProcessor.visitClass()...
___...
for (Class interfaze : interfaces) {
if (!interfaze.isInterface()) {
throw new InvalidServiceType("Service must be an interface", interfaze);
}
if(!checkMethodsImplemented(clazz, interfaze)) {
throw IllegalServiceDefinitionException("Interface
"+interfaze.getName()+" is not implemented by " + clazz.getName());
}
Service service;
try {
service = createService(interfaze);
} catch (InvalidInterfaceException e) {
throw new IntrospectionException(e);
}
type.getServices().add(service);
}
.
Regards,
Amita
Re: Query: Running a Sample Web application in Tomcat
On 8/20/07, ant elder <[EMAIL PROTECTED]> wrote: > > On 8/17/07, Naveen MC <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I am trying to execute a Sample web application (calculator-webapp) from > > the > > tuscany-sca-0.91-incubating Release. I am using "Tomcat V 6.0" as a > > application server. The original sample which is there in the release > will > > get executed fine and i can able to see the results. > > But In the same sample, i modified few things and added one more > > service > > and built the WAR file. If i try to run this, i get the following error. > > > > I could able to test the new service by building the sample using MVN ( > > using JUnit assertEquals, that is comparing the expected result with the > > result returned by the service), it works fine. But when i try to run > the > > same using Eclipse with Tomcat v6.0. > > > > *type* Exception report > > > > *message* > > > > *description* *The server encountered an internal error () that > prevented > > it > > from fulfilling this request.* > > > > *exception* > > > > org.apache.jasper.JasperException: java.lang.NullPointerException > > org.apache.jasper.servlet.JspServletWrapper.handleJspException( > > JspServletWrapper.java:541) > > org.apache.jasper.servlet.JspServletWrapper.service( > > JspServletWrapper.java:435) > > org.apache.jasper.servlet.JspServlet.serviceJspFile( > > JspServlet.java:320) > > org.apache.jasper.servlet.JspServlet.service(JspServlet.java > :266) > > javax.servlet.http.HttpServlet.service(HttpServlet.java:803) > > > > *root cause* > > > > java.lang.NullPointerException > > org.apache.jsp.calc_jsp._jspService(calc_jsp.java:63) > > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java > :70) > > javax.servlet.http.HttpServlet.service(HttpServlet.java:803) > > org.apache.jasper.servlet.JspServletWrapper.service( > > JspServletWrapper.java:393) > > org.apache.jasper.servlet.JspServlet.serviceJspFile( > > JspServlet.java:320) > > org.apache.jasper.servlet.JspServlet.service(JspServlet.java > :266) > > javax.servlet.http.HttpServlet.service(HttpServlet.java:803) > > > > > > Please let me know if anyone had faced the similar problem. > > Thanks > > > > Regards, > > Naveen. MC > > > > > Hard to tell just from that exception, could you paste into an email the > new > .composite file contents? > > ...ant > Hi Ant, here is the composit file. I just added a new service called "squareRootService" and "SquareRootServiceImpl" impliments the same. http://www.osoa.org/xmlns/sca/1.0"; name="Calculator"> let me know if you can think of any soln for this. Thanks Naveen
[jira] Created: (TUSCANY-1564) xsi:type not always set for complexTypes
xsi:type not always set for complexTypes
Key: TUSCANY-1564
URL: https://issues.apache.org/jira/browse/TUSCANY-1564
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-Next
Environment: Win XP and Gentoo Linux
Reporter: Matthew Peters
This has been reported by a user of the PHP SDO code. I have verified that he
is right - the problem does exist. I will cut and paste in the PHP example from
the defect http://pecl.php.net/bugs/bug.php?id=11774 but the php-ness of the
example is irrelevant: under the covers we are just manipulating a C++ SDO and
then calling XMLHelper->save()
In the defect text below he puts in both expected and actual output. He is
right to raise the problem in the sense that I have tried reading in the actual
and expected xml under XERCES with schema validation turned on, and the actual
will *not* validate whereas the expected will.
Incidentally there is some history w.r.t. xsi:types - in a different case they
were coming out when we did not want them and they were suppressed for us. See
for example JIRA 1297. I do not know the rules which should determine whether
it should be present or not.
Here follows the original PHP defect.
Description:
xsi:type is not always set for complexTypes. Notice the absence of
xsi:type="collectionInfo" in the actual output.
Reproduce code:
---
http://www.w3.org/2001/XMLSchema";>
createDocument('', 'request-list');
$rdo = $doc->getRootDataObject();
$request = $xmldas->createDataObject('', 'collectionInfo');
$request->collection->insert('Blah');
$request->kind = 'collectionInfo';
$rdo->request->insert($request);
print($xmldas->saveString($doc));
} catch (SDO_Exception $e) {
print($e);
}
} catch (SDO_Exception $e) {
print("Problem creating an XML document: " . $e->getMessage());
}
?>
Expected result:
http://www.w3.org/2001/XMLSchema-instance";>
Blah
Actual result:
--
http://www.w3.org/2001/XMLSchema-instance";>
Blah
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Patch for TUSCANY-1356
ant elder wrote: On 8/20/07, Simon Nash <[EMAIL PROTECTED]> wrote: I'm restarting the discussion on this because the previous thread [1] did not reach a conclusion. I thought it would be useful to summarize the issues with the extension samples as they stand, and explain how the patch for TUSCANY-1356 resolves these issues. In the implementation-crud sample (the client application code), we have CRUDClient.java, crud.composite, and CRUDTestCase.java. CRUDClient.java and crud.composite together provide a sample client that exercises implementation-crud-extension, and these two files are correctly part of implementation-crud because they are not part of the extension jar. The problem with implementation-crud is the inclusion of CRUDTestCase.java , which does not use or test any of the above client code, but is just a copy of the same file from implementation-crud-extension (and executed by mvn when implementation-crud-extension is built). The patch for TUSCANY-1356 eliminates this duplicate copy of CRUDTestCase.java in implementation-crud and adds a new itest (not part of the samples) that runs the implementation-crud client code to make sure it executes OK. The crud.composite file from the implementation-crud sample client is also duplicated as part of the test code for implementation-crud-extension. There is no need for this code to be duplicated. The patch for TUSCANY-1356 eliminates this duplicate copy of crud.composite by having the JUnit test for implementation-crud-extension use the crud.composite file that is part of implementation-crud. Similarly, in the binding-echo-extension sample, under src/test there are duplicates of the implementation code, composite file, and JUnit test code from binding-echo. The patch for TUSCANY-1356 removes duplicate code from binding-echo-extension by having the JUnit tests in binding-echo-extension take this code from binding-echo, adds a non-sample itest to exercise EchoBindingClient.java from binding-echo, and removes redundant JUnit test code from binding-echo (not needed because the JUnit tests in binding-echo-extension contains exactly the same code). With these changes, all duplicate code is eliminated from these samples, all sample code is tested either by sample JUnit tests or separate itests, and the distinction between the extension and client/application samples is much clearer. Simon [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19026.html How about instead just deleting the implementation.crud sample? We've the implementation.pojo sample now which seems like a better sample to me anyway. The patch for TUSCANY-1356 also corrects similar problems with the binding-echo and binding-echo-extension samples. This part of the patch could be applied while we consider whether or not to delete implementation-crud. I looked at the implementation-pojo-extension sample. It has no associated client to run "out of the box" using ant. The issues addressed by TUSCANY-1356 arose out of the work that was done on implementation-crud and binding-echo to factor them into an extension sample and client/application sample so that the client code could run out of the box using ant. If we decide to replace implementation-crud by implementation-pojo, we would need to fix up implementation-pojo-extension to add a client sample, with code divided between the extension sample and the client sample in the same way that the patch for TUSCANY-1356 does. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
I have not worked on the latest DAS-SCA integration so far, and am quite sure Lucinao will have good pointers in this area. But looking at the current tuscany-implementation-das, can see the following possible. So take this as my attempt to understand intents/policySets and DAS-SCA integration :) DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand contains org.apache.tuscany.sca.assembly.Service dasService. Using dasService, requiredIntents on the Service can be found. org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these intents. DAS internally can configure DASConfig reflecting the intents specified , so that DAS instance construction happens with correct attributes. Based on these attributes DAS transaction control will occur (if intent is TransactionControl). Intent TransactionControl can be qualified as say, 1) Container Transaction Control, 2) DAS Transaction Control. Advantage of having intent attached to a service will be, using different intents for different services of same component. Questions: What will be the policySets here? Say, if policySet/intent "Container Transaction Control" mandates that the implementation should expose getConnection() so that container Runtime can use it, how this mandate can be achieved? When DAS is not running as part of SCA runtime, DAS Config will support required equiavalent attributes thru DAS Config. Regards, Amita On 8/21/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > Aligning the two transaction handling model makes sense specially when > there > is support for a generic DAS as an SCA service. There has been some > discussions on DAS as a service on the mailing list in the past. > > On 8/20/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > > > > Folks, > > > > Sorry to cut across the discussion about Transaction support in DAS, but > > are folks aware of the proposal for Transaction support in SCA? > > > > which leads to the entertaining question of how the DAS transaction > > support relates to the SCA transaction support. > > > > The problem at the moment is that the SCA spec group only has an > > unpublished draft of the Transaction support spec. The intention is to > > publish an updated draft in the near future. > > > > However, I can say that the SCA spec mechanism is based on the use of > > Intents to apply transactional characteristics to SCA components. > > > > > > Yours, Mike. > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
[jira] Updated: (TUSCANY-1563) WSDL generated on the fly has some problem
[ https://issues.apache.org/jira/browse/TUSCANY-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1563: --- Duplicate of TUSCANY-1277 I'll try to fix this today. > WSDL generated on the fly has some problem > -- > > Key: TUSCANY-1563 > URL: https://issues.apache.org/jira/browse/TUSCANY-1563 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core Runtime > Environment: Eclipse, tuscany-sca-1.0-incubating-SNAPSHOT (Tuscany > Nightly Build), Windows XP >Reporter: Nishant Joshi > > Hi, I have generated wsdl on the fly using Tuscany Nightly Build.It was > creating wsdl with some problem. > problem is in generation of tag " location="http://XX:XX:XX:XX:8080/ExampleComponent/MyService"; />". > here root folder name of Tomcat/webapps is missing.Here in my example root > folder name is "Example-0.0.1" > so soap address will be like " location="http://XX:XX:XX:XX:8080/Example-0.0.1/ExampleComponent/MyService"; > />" not " location="http://XX:XX:XX:XX:8080/ExampleComponent/MyService"; />". > So here root folder name is missing in soap address location. > Because it was creating problem when I have tried to create WebService client > using Eclipse Europa's plugins facility. > Thanks in advance > Nishant Joshi > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1563) WSDL generated on the fly has some problem
WSDL generated on the fly has some problem -- Key: TUSCANY-1563 URL: https://issues.apache.org/jira/browse/TUSCANY-1563 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: Eclipse, tuscany-sca-1.0-incubating-SNAPSHOT (Tuscany Nightly Build), Windows XP Reporter: Nishant Joshi Hi, I have generated wsdl on the fly using Tuscany Nightly Build.It was creating wsdl with some problem. problem is in generation of tag "http://XX:XX:XX:XX:8080/ExampleComponent/MyService"; />". here root folder name of Tomcat/webapps is missing.Here in my example root folder name is "Example-0.0.1" so soap address will be like "http://XX:XX:XX:XX:8080/Example-0.0.1/ExampleComponent/MyService"; />" not "http://XX:XX:XX:XX:8080/ExampleComponent/MyService"; />". So here root folder name is missing in soap address location. Because it was creating problem when I have tried to create WebService client using Eclipse Europa's plugins facility. Thanks in advance Nishant Joshi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1562) Service method's "throws Exception" clause create problem at time of on fly generation of wsdl
Service method's "throws Exception" clause create problem at time of on fly
generation of wsdl
--
Key: TUSCANY-1562
URL: https://issues.apache.org/jira/browse/TUSCANY-1562
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Environment: Windows XP, tuscany-sca-1.0-incubating-SNAPSHOT, Eclipse,
Tomcat 6, maven
Reporter: Nishant Joshi
Hi, I am creating a simple programme in which when i declared throws clause in
my method, following error is occured, when i try to deploy my war file in to
Tomcat. WAR is generated using maven.
I have also tried using custom Exception but result is same.
Now when i have catch the exception in service method then problem
is solved and wsdl is generated.(so now there is no throws clause).
So in sort problem is defining throws clause in service method create problem.
Note: Following error is in localhost.log file of Tomcat 6.0 at time of
starting of Tomcat.I am using Nightly build SNAPSHOT that i have mentioned in
environment.
SEVERE: exception initializing SCADomain
org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts for
fault message : {http://example.com}Exception
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:82)
at
org.apache.tuscany.sca.webapp.SCADomainHelper.initSCADomain(SCADomainHelper.java:63)
at
org.apache.tuscany.sca.webapp.TuscanyContextListener.contextInitialized(TuscanyContextListener.java:37)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4334)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
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 org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts for
fault message : {http://example.com}Exception
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:169)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 27 more
Caused by: org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no parts for
fault message : {http://example.com}Exception
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:747)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:167)
... 28 more
Caused by: java.lang.RuntimeException: org.apache.axis2.AxisFault: There are no
parts for fault message : {http://example.com}Exception
at
org.apache.tuscany.sca.binding.axis2.Axis2ServiceClient.createServiceClient(Axis2ServiceClient.java:89)
at
org.apache.tuscany.sca.bi
[jira] Closed: (TUSCANY-1556) Incorrect WSDL generated for service interfaces passing SDO DataObjects
[ https://issues.apache.org/jira/browse/TUSCANY-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1556. -- Resolution: Duplicate See TUSCANY-1544 which is currently scheduled for after 0.99 but before 1.0. And note just to be clear the testcase this JIRA uses does actually run successfully. > Incorrect WSDL generated for service interfaces passing SDO DataObjects > > > Key: TUSCANY-1556 > URL: https://issues.apache.org/jira/browse/TUSCANY-1556 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Axis Binding Extension >Reporter: Jean-Sebastien Delfino > Fix For: Java-SCA-Next > > > Here's an easy way to reproduce the problem: > Add a sleep statement to itest/wsdlless SDOWSDLTestCase.tearDown() to keep > the server running a while, start that test case, then point your Web browser > to http://localhost:8085/AccountService?wsdl. > You'll get a WSDL containing incorrect XSDs, as they are completely different > from the XSDs representing the SDOs on the AccountService interface. The > namespaces are not correct, the element and type definitions are not correct > either. > > targetNamespace="http://accountdata.services.account.bigbank"; > xmlns:axis2="http://accountdata.services.account.bigbank"; > xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"; > xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; > xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"; > xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"; > xmlns:ns="http://accountdata.services.account.bigbank/xsd"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";> > > elementFormDefault="qualified" > targetNamespace="http://account.bigbank.com/xsd"; > xmlns:ax29="http://account.bigbank.com/xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema";> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > elementFormDefault="qualified" > targetNamespace="http://accountdata.services.account.bigbank/xsd"; > xmlns:ns0="http://account.bigbank.com/xsd"; > xmlns:xs="http://www.w3.org/2001/XMLSchema";> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >wsaw:Action="urn:getAccountLog"> > >wsaw:Action="urn:getAccountLog"> > > > >wsaw:Action="urn:getAccountReport"> > >wsaw:Action="urn:getAccountReport"> > > > >wsaw:Action="urn:createAccount"> > >wsaw:Action="urn:createAccount"> > > > >wsaw:Action="urn:getCustomerProfile"> > >wsaw:Action="urn:getCustomerProfile"> > > > >wsaw:Action="urn:purchaseStock"> > >wsaw:Action="urn:purchaseStock"> > > > >wsaw:Action="urn:sellStock"> > >wsaw:Action="urn:sellStock"> > > > > > >wsaw:Action="urn:deposit"> > > > > > >wsaw:Action="urn:withdraw"> > > > >type="axis2:AccountDataServicePortType"> > transport="http://schemas.xmlsoap.org/soap/http"/> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > binding="axis2:AccountDataServiceSOAP11Binding"> > http://9.67.28.200:8085/AccountService"/> > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-1557) Web Service response does not match the schema of the returned SDO
[ https://issues.apache.org/jira/browse/TUSCANY-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1557. -- Resolution: Duplicate See TUSCANY-1544 which is currently scheduled for after 0.99 but before 1.0. And note just to be clear the testcase this JIRA uses does actually run successfully. > Web Service response does not match the schema of the returned SDO > --- > > Key: TUSCANY-1557 > URL: https://issues.apache.org/jira/browse/TUSCANY-1557 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Axis Binding Extension >Reporter: Jean-Sebastien Delfino > Fix For: Java-SCA-Next > > > To see the problem, monitor the HTTP traffic returned by the itest/wsdlless > SDOWSDLTestCase. > This test case exercises the AccountService.createAccount and > getAccountReport methods, both returning SDOs, described by the XSD inlined > in that wsdl: > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdlless/src/main/resources/wsdl/AccountService.wsdl > The test Web service returns the following XML, incorrect as not compliant > with the XSD at all (attributes instead of elements, incorrect namespace, > references to commonj.sdo in the XML). > http://schemas.xmlsoap.org/soap/envelope/";?> > http://schemas.xmlsoap.org/soap/envelope/";> > > <_ns_:getAccountReportResponse > xmlns:_ns_="http://accountdata.services.account.bigbank/xsd";> > http://accountdata.services.account.bigbank/xsd"; > xmlns:p0="commonj.sdo" xmlns:p1="http://www.bigbank.com/account"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="p1:AccountReport"> > balance="1000.0"/> > balance="2000.0"/> > > > > > and > http://schemas.xmlsoap.org/soap/envelope/";?> > http://schemas.xmlsoap.org/soap/envelope/";> > > <_ns_:createAccountResponse > xmlns:_ns_="http://accountdata.services.account.bigbank/xsd";> > http://accountdata.services.account.bigbank/xsd"; > xmlns:p0="commonj.sdo" xmlns:p1="http://www.bigbank.com/account"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="p1:CustomerProfileData"> > petra > A > home > [EMAIL PROTECTED] > petra > ant > 1 > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1559) Exception flowing a simple Java bean through a Web service with no WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1559: --- Component/s: (was: Java SCA Axis Binding Extension) Java SCA Java Implementation Extension Nothing to do with the WS binding, this is the old problem of implementation.java pass-by-value support only working with remotable services when the arguments are serializable > Exception flowing a simple Java bean through a Web service with no WSDL > --- > > Key: TUSCANY-1559 > URL: https://issues.apache.org/jira/browse/TUSCANY-1559 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Java Implementation Extension >Reporter: Jean-Sebastien Delfino > Fix For: Java-SCA-Next > > Attachments: helloworld-bean.zip > > > To reproduce the problem, replace the string in the helloworld-ws-service > sample with a simple JavaBean. > You'll get the following exception when you run the test case in the sample: > Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 5.995 sec <<< > FAILURE! > testServiceCall(helloworld.HelloWorldServerTestCase) Time elapsed: 1.184 sec > <<< ERROR! > java.lang.reflect.UndeclaredThrowableException > at $Proxy5.getGreetings(Unknown Source) > at > helloworld.HelloWorldServerTestCase.testServiceCall(HelloWorldServerTestCase.java:56) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at > org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) > at > org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) > at > org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) > at > org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) > at > org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) > at > org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) > at > org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) > at > org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) > at > org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) > at org.apache.maven.surefire.Surefire.run(Surefire.java:132) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:615) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) > Caused by: org.apache.axis2.AxisFault: Pass-by-value is not supported for the > given object > at > org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:434) > at > org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:373) > at > org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) > at > org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:87) > at > org.apache.tuscany.sca.binding.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:67) > at > org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:68) > at > org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:231) > at > org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:92) > ... 26 more > Results : > Tests in error: > testServiceCall(helloworld.HelloWorldServerTestCase) > Tests run: 2, Failures: 0, Error
[jira] Created: (TUSCANY-1561) Move up from Axis2 1.2 to 1.3
Move up from Axis2 1.2 to 1.3 - Key: TUSCANY-1561 URL: https://issues.apache.org/jira/browse/TUSCANY-1561 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.91 Reporter: ant elder Fix For: Java-SCA-Next Move up from Axis2 1.2 to 1.3 and associated sub-components like Axiom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1554) Support alternate WorkScheduler implementations
[ https://issues.apache.org/jira/browse/TUSCANY-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1554. -- Resolution: Fixed Applied, thanks for the patch! > Support alternate WorkScheduler implementations > --- > > Key: TUSCANY-1554 > URL: https://issues.apache.org/jira/browse/TUSCANY-1554 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-0.90 >Reporter: Greg Dritschler >Assignee: ant elder >Priority: Minor > Attachments: Tuscany-1554.patch > > > A patch is submitted that allows Tuscany's implementation of the > WorkScheduler SPI, Jsr237WorkScheduler, to be plug-replaced by another > implementation. The patch uses the mechanism created in revision 564364 > which allows the implementations of registry objects to be created > dynamically based on a metadata file. > In order to simplify things, I took the position that the WorkManager is now > a private implementation detail of the WorkScheduler. This avoids the need > for the dynamic registry object creation mechanism to support a specialized > WorkScheduler constructor. The only use of the WorkManager outside the > WorkScheduler was a destroy() call in ReallySmallRuntime. I moved the > destroy() method into the WorkScheduler interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1554) Support alternate WorkScheduler implementations
[ https://issues.apache.org/jira/browse/TUSCANY-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-1554: -- Assignee: ant elder > Support alternate WorkScheduler implementations > --- > > Key: TUSCANY-1554 > URL: https://issues.apache.org/jira/browse/TUSCANY-1554 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-0.90 >Reporter: Greg Dritschler >Assignee: ant elder >Priority: Minor > Attachments: Tuscany-1554.patch > > > A patch is submitted that allows Tuscany's implementation of the > WorkScheduler SPI, Jsr237WorkScheduler, to be plug-replaced by another > implementation. The patch uses the mechanism created in revision 564364 > which allows the implementations of registry objects to be created > dynamically based on a metadata file. > In order to simplify things, I took the position that the WorkManager is now > a private implementation detail of the WorkScheduler. This avoids the need > for the dynamic registry object creation mechanism to support a specialized > WorkScheduler constructor. The only use of the WorkManager outside the > WorkScheduler was a destroy() call in ReallySmallRuntime. I moved the > destroy() method into the WorkScheduler interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1560) A component with multiple services does not work.
[
https://issues.apache.org/jira/browse/TUSCANY-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder updated TUSCANY-1560:
---
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-0.99
> A component with multiple services does not work.
> -
>
> Key: TUSCANY-1560
> URL: https://issues.apache.org/jira/browse/TUSCANY-1560
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: windows
>Reporter: Zhenghui Lee
>Priority: Critical
> Fix For: Java-SCA-0.99
>
>
> In code org.apache.tuscany.sca.core.component.ComponentContextImpl, at line
> 130 :
> if (regularServices.size() != 1) {
> throw new ServiceRuntimeException("The component doesn't have
> exactly one service");
> }
> multiple services per component will be failed by above checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1560) A component with multiple services does not work.
A component with multiple services does not work.
-
Key: TUSCANY-1560
URL: https://issues.apache.org/jira/browse/TUSCANY-1560
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Environment: windows
Reporter: Zhenghui Lee
Priority: Critical
Fix For: Java-SCA-Next
In code org.apache.tuscany.sca.core.component.ComponentContextImpl, at line
130 :
if (regularServices.size() != 1) {
throw new ServiceRuntimeException("The component doesn't have
exactly one service");
}
multiple services per component will be failed by above checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
On 8/19/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > On 8/13/07, ant elder <[EMAIL PROTECTED]> wrote: > > > > > > > > On 8/13/07, Luciano Resende < [EMAIL PROTECTED]> wrote: > > > > > > Simon Laws wrote: > > > > +1 for 21st as the target. Can I suggest we take some time (assuming > > > there > > > > is some) on the 20th to test the samples and check through the > > > readmes etc > > > > before taking the branch. > > > > > > We could probably get a "stable distribution" available on the 20th, > > > and we would check that. > > > > > > That sounds like a good plan, i'll continue with some tidy up this week > > aiming to get distribution out for the 20th. > > > >...ant > > > > > Just a reminder that this plan is still on target, i'll get an example > "stable distribution" out tomorrow for review then cut a branch on the 21st, > and an RC out for voting on by the 23rd. If you've changes planned you want > included please get them committed ASAP, if the change is more than trivial > raising a JIRA now for the release would be a help so we all know whats > coming. > > ...ant > A bunch off us had an off-list discussion about this and as we're not quite ready i'll hold off cutting the branch till Thursday and get an RC1 out by Friday the 24th. ...ant
Re: Renaming binding-ajax to binding-dwr?
How about the binding.resource and implementation.resource? Should they be renamed to binding.http and implementation.file? :) ...ant On 8/20/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > > +1 to the rename. Best to name the binding by the transport mechanism > involved, not the implementation used to drive it. > > > Yours, Mike. > > Jean-Sebastien Delfino wrote: > > ant elder wrote: > >> On 8/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > >> > >>> I'd like to rename binding-ajax to binding-dwr, as Ajax is a really > >>> generic term, and it will make clear that this binding is actually > using > >>> the DWR (Direct Web Remoting) protocol. > >>> > >>> Thoughts? > >>> > >> > >> > >> Right now that it uses DWR is an implementation detail thats not > exposed > >> anywhere, just as Axis2 is not exposed anywhere in our binding.ws, so > >> really > >> we can call it whatever we like. > > > > Axis2 is an implementation detail, and that's the reason why we do not > > say in SCA. > > > > However, the protocol used to expose a service in an SOA is not an > > implementation detail at all... > > > > Here are three examples: > > binding.ws -> the SOAP protocol is used to talk to the service > > binding.jsonrpc -> the JSON-RPC protocol is used to talk to the service > > binding.ajax -> the Direct Web Remoting protocol is used to talk to the > > service > > > > Binding.dwr will better indicate than binding.ajax that the service is > > provided through the DWR protocol. > > > >> To web clients binding.jsonrpc used to work > >> acidentically to binding.ajax but the last couple of changes to > >> binding.jsonrpc mean they've now got out of sync. If renaming > >> binding-ajax > >> will help you engage in keeping these both updated to work the same > then > >> Yes! lets rename it. > >> > >> ...ant > >> > >> > > > > OK, I'll rename it then. > > > > If you're talking about the change to how service URIs get determined, > > I'll be happy to help make it work like the other ones, but... > > > > - it didn't seem like it was initially working like the other ones, as > > it hardcoded a single URI and didn't use the binding URI at all, here's > > the code I found: > > > >public static final String SERVLET_PATH = > > AjaxServlet.AJAX_SERVLET_PATH + "/*"; > > > >and > > > >servlet.addService(binding.getName(), type, proxy); > > > > - answering my question on this subject at [1] would be a good starting > > point > > > > [1] > > > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200708.mbox/[EMAIL > PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
