Re: Release 1.3?
On Tue, Jun 10, 2008 at 11:53 AM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 10:14 AM, Simon Nash [EMAIL PROTECTED] wrote: Mike Edwards wrote: Simon Laws wrote: It's been a little while now since we did our 1.2 release. Since then there has been lots of activity and of course we have graduated. It feels like the right time to do a 1.3 release. Looking back at the mail list over the last couple of months there are quite a few candidates for inclusion that I can see; Better BPEL support Improvements to the domain manager app Improved runtime Java2WSDL processing Support for validation monitoring Databinding improvements Performance improvements JSR250 annotation support OSGi support improvements and a simple OSGi runtime test Java 2 security enablement Quite a few more tests for various parts of the runtime Lots of JIRA fixes. and of course we can remove the incubating assignment and drum up a bit of publicity for our TLP graduation I'd also like to have a bit of a tidy up for this release and remove the old domain modules we are no longer using (I'll post on this separately) What else has been added or changed? I think the things I would like to get done can be closed off next week ready to cut a branch. Thoughts? Simon Yes, I give a +1. BPEL is looking a lot better now. I'd like to add a couple of more sophisticated itests/samples as well and the release will be a good spur. Yours, Mike. I think this is a good time to do a 1.3 release. This would make the new runtime Java2WSDL generation available to Tuscany users, and resolve a number of issues with the previous code generation that used Axis2. The other improvements listed are valuable as well. Simon OK, so it looks like people want to do this Re. Luciano's question about RM. I'll volunteer to be RM this time round and all help is greatly appreciated. If though Luciano (or anyone else for that matter) you are keen to RM this time then I won't fight you for it;-) Would seem a little unfair though as you did the last one. Anyone have things they are working one that would stop us moving forward with this and cutting the R1.3 branch at the end of this week? Regards Simon +1 to Simon as RM and taking the branch at the end of this week. ...ant
Re: JMS Client
On Wed, Jun 11, 2008 at 6:42 AM, Nishant Joshi [EMAIL PROTECTED] wrote: Hi All, I can now run JMS client successfully with latest binding.jms, but you need to confirm following with WAS 6 before testing it.. this was done with the help of Ant... This investigation done on sample sample-helloworld-jms-webapp 1) see the link http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=13949798tstart=0 2) You need to add localhost:SIB_ENDPOINT_ADDRESS:BootstrapBasicMessaging,localhost:7276:BootstrapBasicMessaging in the property Provider endpoints of Connection Factory, You can find it in the websphere admin console, under resourses - JMS click on your connection factory Here SIB_ENDPOINT_ADDRESS is the port defined under websphere admin console and look in servers-application server, click on server1, and then in the server1 panel there are two things under Communications in ports it should list SIB_ENDPOINT_ADDRESS here second entry of port 7276 is defaul to provide... 3) In this sample there is a property to set in the web.xml to say start when the server starts up not on the first web request this was not come with standard sample otherwise you need to call your service throgh hello.jsp and then you client would work woth it (jsp is come in the sample sample-helloworld-jms-webapp) by using above steps i can now run my client successfully. Thanks Ant for all your help.. Please Ant correct me in this explanation. please let us know if anybody have any questions... :) -- Thanks Nishant Joshi That all sounds about right, the only thing I'd add is that there is some doc on the connection factory provider endpoints field at http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.express.doc/sibjmsresources/SIBJMSConnectionFactory_DetailForm.html I've added a short section on using this WebSphere client for JMS to the binding.jms doc on the website, its very brief right now and just refers to this email thread, Nishant or anyone else - interested in adding more detail or expanding it out into a separate more detaailed how-to wiki page? ...ant ...ant
NPE in JMS itests was: Re: JMS Client
On Wed, Jun 11, 2008 at 8:23 AM, ant elder [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 6:42 AM, Nishant Joshi [EMAIL PROTECTED]
wrote:
Hi All,
I can now run JMS client successfully with latest binding.jms, but you
need
to confirm following with WAS 6 before testing it.. this was done with
the
help of Ant...
This investigation done on sample sample-helloworld-jms-webapp
1) see the link
http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=13949798tstart=0
2) You need to add
localhost:SIB_ENDPOINT_ADDRESS:BootstrapBasicMessaging,localhost:7276:BootstrapBasicMessaging
in the property Provider endpoints of Connection Factory, You can find it
in
the websphere admin console, under resourses - JMS click on your
connection
factory
Here SIB_ENDPOINT_ADDRESS is the port defined under websphere admin
console and look in servers-application server, click on server1, and
then
in the server1 panel there are two things under Communications in ports
it
should list SIB_ENDPOINT_ADDRESS
here second entry of port 7276 is defaul to provide...
3) In this sample there is a property to set in the web.xml to say start
when the server starts up not on the first web request this was not come
with standard sample otherwise you need to call your service throgh
hello.jsp and then you client would work woth it (jsp is come in the
sample
sample-helloworld-jms-webapp)
by using above steps i can now run my client successfully.
Thanks Ant for all your help..
Please Ant correct me in this explanation.
please let us know if anybody have any questions... :)
--
Thanks
Nishant Joshi
That all sounds about right, the only thing I'd add is that there is some
doc on the connection factory provider endpoints field at
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.express.doc/sibjmsresources/SIBJMSConnectionFactory_DetailForm.html
I've added a short section on using this WebSphere client for JMS to the
binding.jms doc on the website, its very brief right now and just refers to
this email thread, Nishant or anyone else - interested in adding more
detail
or expanding it out into a separate more detaailed how-to wiki page?
...ant
...ant
I'm seeing an NPE in the JMS itests on the line
if
(props.get(Context.INITIAL_CONTEXT_FACTORY).equals(com.ibm.websphere.naming.WsnInitialContextFactory))
{
Seems to be related to the changes here and could do with an if null check
I guess. Is there a fix in hand for this or shall I make the change?
Simon
Re: NPE in JMS itests was: Re: JMS Client
On Wed, Jun 11, 2008 at 8:29 AM, Simon Laws [EMAIL PROTECTED]
wrote:
On Wed, Jun 11, 2008 at 8:23 AM, ant elder [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 6:42 AM, Nishant Joshi [EMAIL PROTECTED]
wrote:
Hi All,
I can now run JMS client successfully with latest binding.jms, but you
need
to confirm following with WAS 6 before testing it.. this was done with
the
help of Ant...
This investigation done on sample sample-helloworld-jms-webapp
1) see the link
http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=13949798tstart=0
2) You need to add
localhost:SIB_ENDPOINT_ADDRESS:BootstrapBasicMessaging,localhost:7276:BootstrapBasicMessaging
in the property Provider endpoints of Connection Factory, You can find
it
in
the websphere admin console, under resourses - JMS click on your
connection
factory
Here SIB_ENDPOINT_ADDRESS is the port defined under websphere admin
console and look in servers-application server, click on server1, and
then
in the server1 panel there are two things under Communications in ports
it
should list SIB_ENDPOINT_ADDRESS
here second entry of port 7276 is defaul to provide...
3) In this sample there is a property to set in the web.xml to say
start
when the server starts up not on the first web request this was not
come
with standard sample otherwise you need to call your service throgh
hello.jsp and then you client would work woth it (jsp is come in the
sample
sample-helloworld-jms-webapp)
by using above steps i can now run my client successfully.
Thanks Ant for all your help..
Please Ant correct me in this explanation.
please let us know if anybody have any questions... :)
--
Thanks
Nishant Joshi
That all sounds about right, the only thing I'd add is that there is some
doc on the connection factory provider endpoints field at
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.express.doc/sibjmsresources/SIBJMSConnectionFactory_DetailForm.html
I've added a short section on using this WebSphere client for JMS to the
binding.jms doc on the website, its very brief right now and just refers
to
this email thread, Nishant or anyone else - interested in adding more
detail
or expanding it out into a separate more detaailed how-to wiki page?
...ant
...ant
I'm seeing an NPE in the JMS itests on the line
if
(props.get(Context.INITIAL_CONTEXT_FACTORY).equals(com.ibm.websphere.naming.WsnInitialContextFactory))
{
Seems to be related to the changes here and could do with an if null
check
I guess. Is there a fix in hand for this or shall I make the change?
Simon
I've just committed a fix.
...ant
Re: NPE in JMS itests was: Re: JMS Client
On Wed, Jun 11, 2008 at 8:34 AM, ant elder [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 8:29 AM, Simon Laws [EMAIL PROTECTED]
wrote:
On Wed, Jun 11, 2008 at 8:23 AM, ant elder [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 6:42 AM, Nishant Joshi
[EMAIL PROTECTED]
wrote:
Hi All,
I can now run JMS client successfully with latest binding.jms, but
you
need
to confirm following with WAS 6 before testing it.. this was done
with
the
help of Ant...
This investigation done on sample sample-helloworld-jms-webapp
1) see the link
http://www-128.ibm.com/developerworks/forums/thread.jspa?messageID=13949798tstart=0
2) You need to add
localhost:SIB_ENDPOINT_ADDRESS:BootstrapBasicMessaging,localhost:7276:BootstrapBasicMessaging
in the property Provider endpoints of Connection Factory, You can
find
it
in
the websphere admin console, under resourses - JMS click on your
connection
factory
Here SIB_ENDPOINT_ADDRESS is the port defined under websphere admin
console and look in servers-application server, click on server1, and
then
in the server1 panel there are two things under Communications in
ports
it
should list SIB_ENDPOINT_ADDRESS
here second entry of port 7276 is defaul to provide...
3) In this sample there is a property to set in the web.xml to say
start
when the server starts up not on the first web request this was not
come
with standard sample otherwise you need to call your service throgh
hello.jsp and then you client would work woth it (jsp is come in the
sample
sample-helloworld-jms-webapp)
by using above steps i can now run my client successfully.
Thanks Ant for all your help..
Please Ant correct me in this explanation.
please let us know if anybody have any questions... :)
--
Thanks
Nishant Joshi
That all sounds about right, the only thing I'd add is that there is
some
doc on the connection factory provider endpoints field at
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.express.doc/sibjmsresources/SIBJMSConnectionFactory_DetailForm.html
I've added a short section on using this WebSphere client for JMS to
the
binding.jms doc on the website, its very brief right now and just
refers
to
this email thread, Nishant or anyone else - interested in adding more
detail
or expanding it out into a separate more detaailed how-to wiki page?
...ant
...ant
I'm seeing an NPE in the JMS itests on the line
if
(props.get(Context.INITIAL_CONTEXT_FACTORY).equals(com.ibm.websphere.naming.WsnInitialContextFactory))
{
Seems to be related to the changes here and could do with an if null
check
I guess. Is there a fix in hand for this or shall I make the change?
Simon
I've just committed a fix.
...ant
Thanks Ant.
Simon
[jira] Updated: (TUSCANY-2242) Incorrent port name in wsdlElement leads to NPE
[ https://issues.apache.org/jira/browse/TUSCANY-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2242: - Attachment: TUSCANY-2242.patch Incorrent port name in wsdlElement leads to NPE --- Key: TUSCANY-2242 URL: https://issues.apache.org/jira/browse/TUSCANY-2242 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.1 Environment: WinXP SP2, IBM JDK 1.5 Reporter: Simon Laws Assignee: Ramkumar Ramalingam Priority: Minor Fix For: Java-SCA-Next Attachments: TUSCANY-2242.patch Can be reproduced by changing the SCDL in sample/helloworld-ws-reference to the following composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldwsclient !-- A component with an embedded reference definition connecting to an external webservice The wsdl interface for the reference is derived from the information specified by the 'wsdlElement' -- component name=HelloTuscanyServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement=http://helloworld#wsdl.port(HelloWorldService/NonExistentPort)/ /reference /component !-- A component with a reference promoted as a composite reference -- component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ /component reference name=HelloWorldService promote=HelloWorldServiceComponent/helloWorldService interface.java interface=helloworld.HelloWorldService / binding.ws wsdlElement=http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)/ /reference /composite Notice the NonExistentPort port name. Running the nit test for ht sample leads to Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:292) at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:252) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:362) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:845) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:139) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:485) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:369) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:165) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:291) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:171) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:243) ... 22 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2379) CompositeProcessor.java is calling promotedService.getService() instead of promotedService.getName() when writing out a composite file.
[
https://issues.apache.org/jira/browse/TUSCANY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramkumar Ramalingam updated TUSCANY-2379:
-
Attachment: TUSCANY-2379.patch
NOTE: Please apply the provided patch after the fixes for TUSCANY-2347 is
committed.
CompositeProcessor.java is calling promotedService.getService() instead of
promotedService.getName() when writing out a composite file.
---
Key: TUSCANY-2379
URL: https://issues.apache.org/jira/browse/TUSCANY-2379
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.2
Reporter: Richard Mah
Assignee: Ramkumar Ramalingam
Attachments: TUSCANY-2379.patch
CompositeProcessor.java is calling promotedService.getService() instead of
promotedService.getName() when writing out the promoted service to file.
Here is the snippet of code starting from line 546 (Revision 665831):
String promote;
if (promotedService != null) {
if (promotedService.getName() != null) {
promote = promotedComponent.getName() + '/' +
promotedService.getService();-Here is the
promotedService.getService() call
} else {
promote = promotedComponent.getName();
}
promotedService.getService() looks like it should be
promotedService.getName() instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2379) CompositeProcessor.java is calling promotedService.getService() instead of promotedService.getName() when writing out a composite file.
[
https://issues.apache.org/jira/browse/TUSCANY-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramkumar Ramalingam updated TUSCANY-2379:
-
Patch Info: [Patch Available]
CompositeProcessor.java is calling promotedService.getService() instead of
promotedService.getName() when writing out a composite file.
---
Key: TUSCANY-2379
URL: https://issues.apache.org/jira/browse/TUSCANY-2379
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.2
Reporter: Richard Mah
Assignee: Ramkumar Ramalingam
Attachments: TUSCANY-2379.patch
CompositeProcessor.java is calling promotedService.getService() instead of
promotedService.getName() when writing out the promoted service to file.
Here is the snippet of code starting from line 546 (Revision 665831):
String promote;
if (promotedService != null) {
if (promotedService.getName() != null) {
promote = promotedComponent.getName() + '/' +
promotedService.getService();-Here is the
promotedService.getService() call
} else {
promote = promotedComponent.getName();
}
promotedService.getService() looks like it should be
promotedService.getName() instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2242) Incorrent port name in wsdlElement leads to NPE
[ https://issues.apache.org/jira/browse/TUSCANY-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2242: - Patch Info: [Patch Available] NOTE: Please apply the provided patch after the fixes for TUSCANY-2347 is committed. Incorrent port name in wsdlElement leads to NPE --- Key: TUSCANY-2242 URL: https://issues.apache.org/jira/browse/TUSCANY-2242 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.1 Environment: WinXP SP2, IBM JDK 1.5 Reporter: Simon Laws Assignee: Ramkumar Ramalingam Priority: Minor Fix For: Java-SCA-Next Attachments: TUSCANY-2242.patch Can be reproduced by changing the SCDL in sample/helloworld-ws-reference to the following composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldwsclient !-- A component with an embedded reference definition connecting to an external webservice The wsdl interface for the reference is derived from the information specified by the 'wsdlElement' -- component name=HelloTuscanyServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement=http://helloworld#wsdl.port(HelloWorldService/NonExistentPort)/ /reference /component !-- A component with a reference promoted as a composite reference -- component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ /component reference name=HelloWorldService promote=HelloWorldServiceComponent/helloWorldService interface.java interface=helloworld.HelloWorldService / binding.ws wsdlElement=http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)/ /reference /composite Notice the NonExistentPort port name. Running the nit test for ht sample leads to Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:292) at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:252) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:362) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:845) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:139) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:1) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:485) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:369) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:165) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:291) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:171) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:243) ... 22 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On 6/10/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. From an OSGi point of view I would like to ensure that we will continue to have one bundle per 3rd party jar and that these will not be aggregated regardless of how the distribution is zipped up. As for one bundle per maven module, I think there are pros and cons for finely grained and coarsely grained bundles, and it is really just a matter of preference. Since we anyway have nearly 150 3rd party bundles/jars anyway, I personally dont see any problem with one bundle per module. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. IMHO modularizing Tuscany is about code quality and maintenance - something internal benefitting Tuscany developers. So we have 100 modules based on the developer's view of Tuscany internals. That does not necessarily mean that end users have to deal with 100 bundles. If 20 core modules are very tightly coupled together and will only operate with each other, as far as an end user is concerned, this could as well be one bundle. Can a Tuscany user combine assembly-xml version 1.3.0 with assembly version 1.3.1? Or even implementation-java with implementation-java-runtime of a different version? The answer is
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: snip If we are anyway going to require a launcher of some form, wouldn't it be just as easy to maintain one-bundle-per-module? I agree, if we go back to requiring a launcher that changes a lot how we'd could put this together. I'm not at all against requiring a launcher as that does make things easier in some respects, but lets remember why we did used to do this and then chucked it out in the 0.90 rewrite ;) ...ant
Unable to download the artifact from any repository
Hi, I'm re-doing my SCA installation by following the steps in [1] and keep running into a problem when doing clean install: mvn clean install -Dtest=no After searching the mailing list archives I found some suggestions, but haven't been able to resolve the problem. I posted the stack trace in [2]. What can be going wrong? Any suggestions? Any help is greatly appreciated. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/30may2008 [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/10Jun2008 -- best, -oscar Oscar Castañeda
Re: [VOTE] Release SDO 1.1.1
So thats works ok for two, doesn't work for one. Luciano, I had to build a couple of times with -U to get all the emf jars successfully downloaded, have you tried that or can you find any other way to get a build through in your environment? ...ant On Tue, Jun 10, 2008 at 11:32 AM, Murtaza Goga [EMAIL PROTECTED] wrote: I built this release last night, built clean. -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 5:29 AM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Release SDO 1.1.1 I'd like to get this voted on and released but nervous to start that after Kelvin had trouble getting the emf dependencies, could any one else try building the tag and seeing if it works or not for them - https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R C2/-https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/- its a small checkout and doesn't take long to build. ...ant On Sat, Jun 7, 2008 at 9:15 AM, ant elder [EMAIL PROTECTED] wrote: It seems to work fine for me, the binary distribution ends up with a lib folder containing: backport-util-concurrent-3.0.jar codegen-2.2.3.jar codegen-ecore-2.2.3.jar common-2.2.3.jar ecore-2.2.3.jar ecore-change-2.2.3.jar ecore-xmi-2.2.3.jar sample-sdo-1.1.1.jar stax-api-1.0.1.jar tuscany-sdo-api-r2.1-1.1.1.jar tuscany-sdo-impl-1.1.1.jar tuscany-sdo-lib-1.1.1.jar tuscany-sdo-tools-1.1.1.jar wstx-asl-3.2.1.jar xsd-2.2.3.jar I've put the distributions that I get from the 1.1.1-RC2 tag up at http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2http://people.apache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2 http://people.a pache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2, how do they look? ...ant On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, yes, I added that workaround, and that satisfied most of the EMF jars, but not these two. It's odd, the 2 jars we need are there in the repository you suggested, but maven will not download them. Kelvin. 2008/6/6 Luciano Resende [EMAIL PROTECTED]: Did you try the workaround I mentioned before on this thread [1] where I added a new repository ? It was actually for other jars, but might help in this case as well... [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson [EMAIL PROTECTED] wrote: I've made all the changes required in the tag [1] to get rid of the felix jars, find and include the emf jars, and I've removed the incubating tag, DISCLAIMER files etc. However, I'm currently stumped as to why two emf jars available [2] and [3] don't get downloaded by the build. The build output complains about URLs that, if cut and pasted into a browser, work fine. Any clues to explain this odd maven behaviour are welcome. Kelvin [1] https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R C2/https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-RC2/ [2] http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/c odegen/2.2.3/http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen/2.2.3/ [3] http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/c odegen-ecore/2.2.3/http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/codegen-ecore/2.2.3/ 2008/6/3 Rajini Sivaram [EMAIL PROTECTED]: Kelvin, Sorry about the delay in getting back to you - I can see that you have found a solution. Yes, you are absolutely right, the felix framework should use scope provided since SdoBundleActivator is only used when SDO is running inside an OSGi container, and the framework classes are provided by the container. On 6/3/08, kelvin goodson [EMAIL PROTECTED] wrote: Just a thought, would I be right in guessing that if ever our SdoBundleActivator is touched in the runtime, then the environment would be expected to provide the classes to satisfy import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; ? in which case I think declaring a provided scope for the felix dependency would be the right way to do things Kelvin. 2008/6/3 kelvin goodson [EMAIL PROTECTED]: Thanks Ant, that looks like progress, but the felix framework jar is now not in the list of distributed jars. Kelvin. 2008/6/3 ant elder [EMAIL PROTECTED]: Adding an exclude for felix to the distribution pom can fix that, eg here's local changes i have just tried: Index: src/main/assembly/bin.xml
Re: Endpoint model design, was: Endpoints
Hi
So apart from these minor comments you like it;-) I think you are several
chapters ahead of me here. This Endpoint model is my first effort at
addressing some of the issues at hand and adding some function over the top
of the model we already have without breaking the existing model. Now I know
a little more it's clear that we need to review the way that bindings are
used and, in particular, the way that they drive wire creation. For me
personally this was too big a piece to bite off in the first instance.
Hopefully we can iterate to something that satisfies both of us. I've put
some comments in line.
Simon
On Tue, Jun 10, 2008 at 7:00 PM, Jean-Sebastien Delfino [EMAIL PROTECTED]
wrote:
Simon Laws wrote:
...
I've created an itest (late-reference-resolution) to show how late
resolution could be done using endpoint resolvers.
...
I've spent some time looking at that test and the following classes:
Endpoint
EndpointFactory
Endpoint
EndpointResolver
EndpointResolverFactory
EndpointResolverFactoryExtensionPoint
EndpointWireImpl
I'd like to suggest the following alternate design:
A) Endpoint has two many relationships with other model objects IMO, and
when I put it in a UML diagram I noticed that it duplicates a number of
existing model relationships and mixes real attributes and setter accessors
for derived attributes or relationships:
getCandidateBindings()
getSourceBinding()
getSourceCallbackBinding()
getSourceComponent()
getSourceComponentReference()
getTargetBinding()
getTargetComponent()
getTargetComponentService()
getTargetName()
setSourceBinding(Binding)
setSourceCallbackBinding(Binding)
setSourceComponent(Component)
setSourceComponentReference(ComponentReference)
setTargetBinding(Binding)
setTargetComponent(Component)
setTargetComponentService(ComponentService)
setTargetName(String)
That may be true. I wasn't heading for model perfection I was aiming for
something that worked and that allowed me to better understand the model as
it stands today without breaking it. I added the things to Endpont that I
needed given the model and processing as it stands with a view to removing
any that weren't as we polish the model further.
I thought that Endpoint could just boil down to:
interface EndpointB extends Binding {
B getBinding();
void setBinding(B);
}
I think we are talking about different things. This strikes me as a resolved
endpoint in that you already know what the binding is going to be. I am
concerned about representing an unresolved target so that it can be resolved
at a later date. Maybe I chose the wrong term when I called it Endpoint and
I'm confusing you. Should we have a Target model instead?
with a Endpoint (0..n) -- (1) Binding relationship. No big invention here
that looks like a WSDL endpoint.
B) I think that Endpoints are specific to protocols/middleware/binding
types. They all have a URI plus additional derived binding-specific fields.
The normal extension mechanism that we use to handle Binding extensions
should apply to Endpoints here too (allowing you to provide a specific
Endpoint implementation extension for WebService, EJB, JMS etc.)
I think that the way that you resolve endpoints may be specific to a
particular binding type and that the concept of a resolved endpoint is
specific to a binding type. I don't agree that the Endpoint model itself has
to be specific to a binding. However I think your mental model of an
endpoint includes some binding specific data that maybe the binding provider
could use for configuration. So I guess we are thinking about different
parts of the problem. Hopefully we can bring them together!
C) I was envisioning ReferenceEndpointProvider and ServiceEndpointProvider
interfaces, mirrored on the current ReferenceBindingProvider and
ServiceBindingProvider but working with Endpoints instead, giving you the
ability to handle invocations in an endpoint specific way, on an endpoint
basis (allowing you to manage connection pools for example, which we can't
really do at the moment with the Binding based design).
So was I but Raymond didn't like that (see previous thread) so I changed it.
Again I wasn't considering that an endpoint would be involved during
invocation which I think is what you are suggesting.
D) Resolution of the address of a target could be done when initializing
/resolving the Endpoint model, at EndpointProvider.start() time, or at
invocation time. When done at model initialization/resolution time, the
outcome of the resolution would be visible in the domain assembly model,
providing useful feedback to the domain administrator.
Agreed. This is the flexibility I have added.
E) The late-reference-resolution itest uses a static global to implement
its dynamic lookup. I think that shows that the current EndpointResolver SPI
does not give it enough context to do that kind of resolution. I think that
the Endpoint model should be able to obtain a pointer
Re: Running vtests with security on
On Wed, Jun 11, 2008 at 11:20 AM, ant elder [EMAIL PROTECTED] wrote:
On Thu, May 15, 2008 at 8:32 PM, Dan Becker [EMAIL PROTECTED]
wrote:
Since I am not much of a Maven expert, I thought I would run this by the
Tuscany community to see if I am going down the right path or to see if
there are better ideas.
Normally when I test with any Tuscany sample or test with Java 2
security enabled, I use the JVM options -Djava.security.manager
-Djava.security.policy=tuscany.policy -Djava.security.debug=policy. The
tuscany.policy file enables certain parts of Tuscany code to access
sensitive API calls, such as reading system properties or writing to the
file system. When I run Tuscany JUnit tests in Eclipse, I add these
options to the JUnit Run As dialog settings.
The Tuscany vtests run when you execute Maven on the vtest pom with the
test goal. I was thinking of adding a profile that specifies the
additional properties above. Also, I would provide an example
tuscany.policy file that provides the proper permissions for the Tuscany
code base. This when you wanted to run vtests with security on, you
would invoke this profile along with the test goal.
Any additional suggestions or comments?
--
Thanks, Dan Becker
In preparation for the 1.3 branch I've just had a try building trunk with
security on and get a few failures:
[INFO] Error for project: Apache Tuscany SCA Databinding Integration Tests
-
JAXB Bottom Up (during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\databindings\jaxb-bottom-up\target\surefire-reports
for the individual test results.
[INFO]
[INFO] Error for project: Apache Tuscany SCA Late Reference Resolution
Integration Test (during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\late-reference-resolution\target\surefire-reports
for the individual test results.
[INFO]
[INFO] Error for project: Apache Tuscany SCA OSGi-SCA Integration Tests
(during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\osgi-implementation\target\surefire-reports for
the individual test results.
(the itests jaxb-bottom-up and late-reference-resolution fail as well but
they're also failing for me in trunk right now without security on)
Thats using the command:
mvn test -P security
-Dtuscany.policy.file=file:///c:\Tuscany\tuscany.policy -o
and with a the tuscany.policy file containing:
grant codeBase file:/C:/Tuscany/SVN/trunk/- {
permission java.security.AllPermission;
};
grant codeBase file:/C:/Documents and
Settings/Administrator/.m2/repository/- {
permission java.security.AllPermission;
};
grant codeBase file:/e:/temp/eclipse/eclipse/- {
// permission java.security.AllPermission;
permission java.net.SocketPermission 127.0.0.1:*,
connect,accept,resolve;
permission java.io.FilePermission ALL FILES, read;
permission java.lang.RuntimePermission accessDeclaredMembers;
permission java.lang.RuntimePermission getClassLoader;
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission *, read;
};
...ant
I'm seeing the jaxb-bottom-up failure also. You need to do an svn up. Vamsi
has added some @Ignores to the test as some things don't quite work yet
apparently. Haven't seen the late-reference-binding problem yet.
Simon
Re: Running vtests with security on
On Thu, May 15, 2008 at 8:32 PM, Dan Becker [EMAIL PROTECTED] wrote:
Since I am not much of a Maven expert, I thought I would run this by the
Tuscany community to see if I am going down the right path or to see if
there are better ideas.
Normally when I test with any Tuscany sample or test with Java 2
security enabled, I use the JVM options -Djava.security.manager
-Djava.security.policy=tuscany.policy -Djava.security.debug=policy. The
tuscany.policy file enables certain parts of Tuscany code to access
sensitive API calls, such as reading system properties or writing to the
file system. When I run Tuscany JUnit tests in Eclipse, I add these
options to the JUnit Run As dialog settings.
The Tuscany vtests run when you execute Maven on the vtest pom with the
test goal. I was thinking of adding a profile that specifies the
additional properties above. Also, I would provide an example
tuscany.policy file that provides the proper permissions for the Tuscany
code base. This when you wanted to run vtests with security on, you
would invoke this profile along with the test goal.
Any additional suggestions or comments?
--
Thanks, Dan Becker
In preparation for the 1.3 branch I've just had a try building trunk with
security on and get a few failures:
[INFO] Error for project: Apache Tuscany SCA Databinding Integration Tests -
JAXB Bottom Up (during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\databindings\jaxb-bottom-up\target\surefire-reports
for the individual test results.
[INFO]
[INFO] Error for project: Apache Tuscany SCA Late Reference Resolution
Integration Test (during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\late-reference-resolution\target\surefire-reports
for the individual test results.
[INFO]
[INFO] Error for project: Apache Tuscany SCA OSGi-SCA Integration Tests
(during test)
[INFO]
[INFO] There are test failures.
Please refer to
C:\Tuscany\SVN\trunk\itest\osgi-implementation\target\surefire-reports for
the individual test results.
(the itests jaxb-bottom-up and late-reference-resolution fail as well but
they're also failing for me in trunk right now without security on)
Thats using the command:
mvn test -P security
-Dtuscany.policy.file=file:///c:\Tuscany\tuscany.policy -o
and with a the tuscany.policy file containing:
grant codeBase file:/C:/Tuscany/SVN/trunk/- {
permission java.security.AllPermission;
};
grant codeBase file:/C:/Documents and
Settings/Administrator/.m2/repository/- {
permission java.security.AllPermission;
};
grant codeBase file:/e:/temp/eclipse/eclipse/- {
// permission java.security.AllPermission;
permission java.net.SocketPermission 127.0.0.1:*,
connect,accept,resolve;
permission java.io.FilePermission ALL FILES, read;
permission java.lang.RuntimePermission accessDeclaredMembers;
permission java.lang.RuntimePermission getClassLoader;
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission *, read;
};
...ant
[jira] Commented: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes
[ https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604180#action_12604180 ] Vamsavardhana Reddy commented on TUSCANY-2371: -- Completed: At revision: 18 o Fix javax.xml.transform.Source related tests. The Source returned may use a different type of Source. Compare the content instead of using equals(). Databinding tests for StandardTypes, array of StandardTypes --- Key: TUSCANY-2371 URL: https://issues.apache.org/jira/browse/TUSCANY-2371 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2371.patch Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1]. JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes: java.lang.String java.math.BigInteger java.math.BigDecimal java.util.Calendar java.util.Date javax.xml.namespace.QName java.net.URI javax.xml.datatype.XMLGregorianCalendar javax.xml.datatype.Duration java.lang.Object java.awt.Image javax.activation.DataHandler javax.xml.transform.Source java.util.UUID [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes
[ https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2371. Resolution: Fixed Assignee: Vamsavardhana Reddy (was: Raymond Feng) Complete. Databinding tests for StandardTypes, array of StandardTypes --- Key: TUSCANY-2371 URL: https://issues.apache.org/jira/browse/TUSCANY-2371 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2371.patch Databinding itests for StandardTypes and array of StandardTypes. Local and remotable service. See [1]. JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes: java.lang.String java.math.BigInteger java.math.BigDecimal java.util.Calendar java.util.Date javax.xml.namespace.QName java.net.URI javax.xml.datatype.XMLGregorianCalendar javax.xml.datatype.Duration java.lang.Object java.awt.Image javax.activation.DataHandler javax.xml.transform.Source java.util.UUID [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2384) Message Conversion for Contribution Builders
[ https://issues.apache.org/jira/browse/TUSCANY-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2384: - Attachment: TUSCANY-2384.patch Message Conversion for Contribution Builders Key: TUSCANY-2384 URL: https://issues.apache.org/jira/browse/TUSCANY-2384 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Win XP SP2, JDK 1.5 Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Priority: Minor Fix For: Java-SCA-Next Attachments: TUSCANY-2384.patch Message Conversion were required for the Contribution Builders, where few instance of messages was found without using the messageID and resourcebundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2384) Message Conversion for Contribution Builders
Message Conversion for Contribution Builders Key: TUSCANY-2384 URL: https://issues.apache.org/jira/browse/TUSCANY-2384 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Environment: Win XP SP2, JDK 1.5 Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Priority: Minor Fix For: Java-SCA-Next Attachments: TUSCANY-2384.patch Message Conversion were required for the Contribution Builders, where few instance of messages was found without using the messageID and resourcebundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
If we assume one bundle per Tuscany module for developers, perhaps there's a need for a separate concept that provides a simplified view for users? The SpringSource Application Platform has the concept of a library, which has caused much debate in the OSGi world (it has its own manifest header). A library is a collection of bundles which gives the developer a single 'thing' on which to depend. At runtime the concept goes away and just results in Import/Export-Package statements created through manifest re-writing (the library does not affect package visibility). I'm not suggesting we use the same approach, but it just highlights that others a felt the need for an 'aggregation' concept. I wonder if a bundle repository might also provide such a capability, but I'm not too familiar with things like OBR at the moment. On the subject of the ExtensionRegistry. This is not a standard OSGi feature, but I've been told the Equinox implementation should run on any standard OSGi implementation (e.g. Felix). Is there any reason why we wouldn't just use the standard service registry? It has all the features required to manage the lifecycle of new extensions being installed/uninstalled, etc. Regards, Graham. 2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: snip If we are anyway going to require a launcher of some form, wouldn't it be just as easy to maintain one-bundle-per-module? I agree, if we go back to requiring a launcher that changes a lot how we'd could put this together. I'm not at all against requiring a launcher as that does make things easier in some respects, but lets remember why we did used to do this and then chucked it out in the 0.90 rewrite ;) ...ant
[jira] Created: (TUSCANY-2385) Problem with Databinding for URI and UUID objects when using binding.ws
Problem with Databinding for URI and UUID objects when using binding.ws --- Key: TUSCANY-2385 URL: https://issues.apache.org/jira/browse/TUSCANY-2385 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I am noticing that when I am invoking a service method that takes an object as parameter over binding.ws,, the URI and UUID standard types that map to xs:string XML data type are being presented to the service method as String rather than their respective types. See StandardTypesDatabindingTestCase.testWSNewObject() under sca\itest\databindings\jaxb-bottom-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2386) Databinding problem for array of javax.xml.transform.Source with binding.ws
Databinding problem for array of javax.xml.transform.Source with binding.ws --- Key: TUSCANY-2386 URL: https://issues.apache.org/jira/browse/TUSCANY-2386 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I am getting a TransformationException with a service method that takes an array of javax.xml.transform.Source objects. See StandardTypesDatabindingTestCase.testWSNewSourceArray() under sca\itest\databindings\jaxb-bottom-up. StackTrace is given below: org.apache.tuscany.sca.databinding.TransformationException: No path found for the transformation: java:array-org.apache.axiom.om.OMElement at org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:165) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:69) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:201) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:45) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:81) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:76) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy21.getNewSourceArray(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.impl.StandardTypesLocalServiceClientImpl.getNewSourceArrayForward(StandardTypesLocalServiceClientImpl.java:147) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:111) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy20.getNewSourceArrayForward(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.StandardTypesDatabindingTestCase.performTestNewSourceArray(StandardTypesDatabindingTestCase.java:1300) at org.apache.tuscany.sca.itest.databindings.jaxb.StandardTypesDatabindingTestCase.testWSNewSourceArray(StandardTypesDatabindingTestCase.java:649) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at
[jira] Created: (TUSCANY-2387) Databinding problem for array of javax.xml.transform.Source with binding.sca and remotable service
Databinding problem for array of javax.xml.transform.Source with binding.sca and remotable service -- Key: TUSCANY-2387 URL: https://issues.apache.org/jira/browse/TUSCANY-2387 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next I am getting a MarshalException with a remotable service method that takes an array of javax.xml.transform.Source objects invoked over binding.sca. See StandardTypesDatabindingTestCase.testSCANewSourceArray() under sca\itest\databindings\jaxb-bottom-up. StackTrace is given below: java.lang.IllegalArgumentException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.bind.JAXBException: class javax.xml.transform.dom.DOMSource nor any of its super class is known to this context.] at org.apache.tuscany.sca.databinding.jaxb.JAXBDataBinding.copy(JAXBDataBinding.java:117) at org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.copy(DefaultDataBindingExtensionPoint.java:172) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copy(PassByValueInterceptor.java:241) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.copy(PassByValueInterceptor.java:160) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:106) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy21.getNewSourceArray(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.impl.StandardTypesLocalServiceClientImpl.getNewSourceArrayForward(StandardTypesLocalServiceClientImpl.java:147) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:111) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy20.getNewSourceArrayForward(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.StandardTypesDatabindingTestCase.performTestNewSourceArray(StandardTypesDatabindingTestCase.java:1300) at org.apache.tuscany.sca.itest.databindings.jaxb.StandardTypesDatabindingTestCase.testSCANewSourceArray(StandardTypesDatabindingTestCase.java:354) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at
[jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
[ https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604207#action_12604207 ] Simon Laws commented on TUSCANY-2324: - Is there a test case for this issue that shows the problem? I'm eyeballing the code and its interesting as the code that processes promotion on the reference side works differently to the code that processes promotion on the service side. On the reference side it only copies the bindings down. On the service side it does interface contracts also. InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding --- Key: TUSCANY-2324 URL: https://issues.apache.org/jira/browse/TUSCANY-2324 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Reporter: Scott Kurz Priority: Minor If we take the following example where an inner component reference is overridden in two ways by the outer component using the inner Composite as impl: 1) a binding.ws is added 2) a WSDL intf (compatible with the inner Java intf) is declared composite ... name=OuterComposite component name=OuterComponent implementation.composite name=blah:InnerComposite/ reference name=outerRef target=MyTarget interface.wsdl interface=http://blah#wsdl.interface(HelloWorld) / binding.ws/ /reference /component /composite composite name=InnerComposite component name=InnerComponent implementation.java .../ reference name=helloWorldService interface.java interface=test.sca.w2j.ws.statc.exc.helloworld.HelloWorld/ /reference /component reference name=outerRef promote=InnerComponent/helloWorldService/ /composite we have a problem. The CompositeActivatorImpl is going to start an Axis2ReferenceBindingProvider for the inner Composite ref. The WS binding is propagated down or inwards, you could say.But this WS binding has a null IC, so we're going to look at the component ref IC, but this will be the inner component ref IC, which is a Java IC. This kicks off a Java2WSDL and the new WSDL IC becomes the Axis2 ref binding IC. So the generated WSDL may not match the actual WSDL, which is a problem. Of course, if we had included a wsdlElement (e.g. wsdl.port ) on the outer component's binding.ws/ we would not have had a problem; it would have been propagated inwards along with the binding itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Databinding test for javax.xml.transform.Source problem
I have updated the tests to get the content out of Source objects and compare the contents. I have the following StreamSource as input: new StreamSource(new StringReader(aA/a)). The content I am from this source is as follows: ?xml version=1.0 encoding=UTF-8? aA/a I have a service method that returns a copy of the source that is passed to it. The source that is returned when the service method is invoked over binding.ws is giveing the following content: ?xml version=1.0 encoding=UTF-8? return xmlns=http://jaxb.databindings.itest.sca.tuscany.apache.org/ A/return Notice the namespace and the change in the root tag. Any suggestions on changing the test?
Versioning of Tuscany
Following on from the discussion on OSGi-enabling third party libraries ( http://markmail.org/message/snltdk2yovr6maq5), this thread addresses the options for versioning Tuscany bundles and 3rd party libraries distributed with Tuscany and the implications of choosing these options. I have put together some notes on the wiki ( http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Versioning) There were two outstanding questions from Simon Nash in the previous discussion which I will summarize here to ensure that they are not lost in this discussion. 1. Why can't we generate import constraints which will suit all applications? 2. *I'm concerned by the assumption here that Tuscany's versions of 3rd party bundles will be used both by Tuscany and by applications. An application may be using other software as well as Tuscany, and this other software may include its own versions of bundles for javax.servlet or jaxb. If Tuscany requires its versions of these bundles to be used, and the other software requires its versions to be used, this requires the application developer to understand how to resolve any conflicts.* The answer to 1) relates to how broad (or narrow) version ranges in imports are. Broad ranges prevent isolation and reduce scope for side-by-side execution, narrow ranges prevent class sharing and upgrading to newer versions. There is more detail with examples on the wiki. Question 2) is addressed first on the wiki (Figure 1 and Figure 2 show these scenarios). I would personally like to follow OSGi best practice and enable maximum sharing. There are some cases where we have no choice but to share (eg. SDO). I don't believe we can eliminate conflicts altogether - but following standard practice will make it less complicated for OSGi developers to resolve conflicts. Thoughts? Thank you... Regards, Rajini
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On 6/11/08, Graham Charters [EMAIL PROTECTED] wrote: If we assume one bundle per Tuscany module for developers, perhaps there's a need for a separate concept that provides a simplified view for users? The SpringSource Application Platform has the concept of a library, which has caused much debate in the OSGi world (it has its own manifest header). A library is a collection of bundles which gives the developer a single 'thing' on which to depend. At runtime the concept goes away and just results in Import/Export-Package statements created through manifest re-writing (the library does not affect package visibility). I'm not suggesting we use the same approach, but it just highlights that others a felt the need for an 'aggregation' concept. I wonder if a bundle repository might also provide such a capability, but I'm not too familiar with things like OBR at the moment. OBR does provide similar capability, but IMO the problem with all these approaches (OBR, SpringSource library) is that none of them is a standard. I just hope we dont invent yet another one. On the subject of the ExtensionRegistry. This is not a standard OSGi feature, but I've been told the Equinox implementation should run on any standard OSGi implementation (e.g. Felix). Is there any reason why we wouldn't just use the standard service registry? It has all the features required to manage the lifecycle of new extensions being installed/uninstalled, etc. You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ I dont actually have an opinion, just pointing to the docs. Regards, Graham. 2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: snip If we are anyway going to require a launcher of some form, wouldn't it be just as easy to maintain one-bundle-per-module? I agree, if we go back to requiring a launcher that changes a lot how we'd could put this together. I'm not at all against requiring a launcher as that does make things easier in some respects, but lets remember why we did used to do this and then chucked it out in the 0.90 rewrite ;) ...ant -- Thank you... Regards, Rajini
[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues
[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604217#action_12604217 ] Rajini Sivaram commented on TUSCANY-2343: - Hi all, I have started a discussion on versioning Tuscany on the dev list (http://markmail.org/message/waiieq6cvhtqb332). Since you have already faced problems resulting from inadequate versioning in Tuscany, your input will be very useful. Thank you... - Rajini OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Attachments: Libary Versions.xls, test_bundles.zip Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us. The problems occur with the current snapshot release. Sorry, I do not know which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram [EMAIL PROTECTED] wrote: ,snip You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ Great article, thanks for the link. Thats over a year old now so has much changed eg in relation to comments like The delayed services feature requires some small tweaks to the basic Equinox runtime, and these tweaks have not been implemented yet in the released version 3.2. They do not appear at all yet (at the time of writing) in the other open source OSGi runtimes, Apache Felix and Knopflerfish.? ...ant
Re: Running vtests with security on
ant elder wrote: In preparation for the 1.3 branch I've just had a try building trunk with security on and get a few failures: [INFO] Error for project: Apache Tuscany SCA Databinding Integration Tests - JAXB Bottom Up (during test) [INFO] [INFO] There are test failures. Please refer to C:\Tuscany\SVN\trunk\itest\databindings\jaxb-bottom-up\target\surefire-reports for the individual test results. Hi Ant, I am seeing these errors when running with security OFF as well (after having done an svn update). I am going to do a clean build and try again. -- Thanks, Dan Becker
[jira] Updated: (TUSCANY-2347) Removing the exception throws from the processors
[ https://issues.apache.org/jira/browse/TUSCANY-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2347: - Attachment: TUSCANY-2347-Part4-NEW.patch Removing the exception throws from the processors - Key: TUSCANY-2347 URL: https://issues.apache.org/jira/browse/TUSCANY-2347 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP, Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2347-Part1.patch, TUSCANY-2347-Part2.patch, TUSCANY-2347-Part3.patch, TUSCANY-2347-Part4-NEW.patch, TUSCANY-2347-Part4.patch, TUSCANY-2347-Part5.patch, TUSCANY-2347-Part6.patch, TUSCANY-2347-Part7.patch After introducing the monitors in various part of the code (especially in the processors), while the runtime reads and resolves the contribution. Now we are trying to remove the exception that are being thrown from these modules. As a first step we are removing the exceptions that are safe to remove, by leaving the critical exceptions like a) IOException b) XMLStreamException c) PriviledegedActionException d) and ParseConfigurationExceptions As a second step, we will also be dealing with the above said exception once we have a detailed discussion as how to handle them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2347) Removing the exception throws from the processors
[ https://issues.apache.org/jira/browse/TUSCANY-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2347: - Attachment: TUSCANY-2347-Part6-NEW.patch Removing the exception throws from the processors - Key: TUSCANY-2347 URL: https://issues.apache.org/jira/browse/TUSCANY-2347 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP, Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2347-Part1.patch, TUSCANY-2347-Part2.patch, TUSCANY-2347-Part3.patch, TUSCANY-2347-Part4-NEW.patch, TUSCANY-2347-Part4.patch, TUSCANY-2347-Part5-NEW.patch, TUSCANY-2347-Part5.patch, TUSCANY-2347-Part6-NEW.patch, TUSCANY-2347-Part6.patch, TUSCANY-2347-Part7-NEW.patch, TUSCANY-2347-Part7.patch After introducing the monitors in various part of the code (especially in the processors), while the runtime reads and resolves the contribution. Now we are trying to remove the exception that are being thrown from these modules. As a first step we are removing the exceptions that are safe to remove, by leaving the critical exceptions like a) IOException b) XMLStreamException c) PriviledegedActionException d) and ParseConfigurationExceptions As a second step, we will also be dealing with the above said exception once we have a detailed discussion as how to handle them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2347) Removing the exception throws from the processors
[ https://issues.apache.org/jira/browse/TUSCANY-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2347: - Attachment: TUSCANY-2347-Part7-NEW.patch Removing the exception throws from the processors - Key: TUSCANY-2347 URL: https://issues.apache.org/jira/browse/TUSCANY-2347 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP, Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2347-Part1.patch, TUSCANY-2347-Part2.patch, TUSCANY-2347-Part3.patch, TUSCANY-2347-Part4-NEW.patch, TUSCANY-2347-Part4.patch, TUSCANY-2347-Part5-NEW.patch, TUSCANY-2347-Part5.patch, TUSCANY-2347-Part6-NEW.patch, TUSCANY-2347-Part6.patch, TUSCANY-2347-Part7-NEW.patch, TUSCANY-2347-Part7.patch After introducing the monitors in various part of the code (especially in the processors), while the runtime reads and resolves the contribution. Now we are trying to remove the exception that are being thrown from these modules. As a first step we are removing the exceptions that are safe to remove, by leaving the critical exceptions like a) IOException b) XMLStreamException c) PriviledegedActionException d) and ParseConfigurationExceptions As a second step, we will also be dealing with the above said exception once we have a detailed discussion as how to handle them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2347) Removing the exception throws from the processors
[ https://issues.apache.org/jira/browse/TUSCANY-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramkumar Ramalingam updated TUSCANY-2347: - Attachment: TUSCANY-2347-Part5-NEW.patch Removing the exception throws from the processors - Key: TUSCANY-2347 URL: https://issues.apache.org/jira/browse/TUSCANY-2347 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP, Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next Attachments: TUSCANY-2347-Part1.patch, TUSCANY-2347-Part2.patch, TUSCANY-2347-Part3.patch, TUSCANY-2347-Part4-NEW.patch, TUSCANY-2347-Part4.patch, TUSCANY-2347-Part5-NEW.patch, TUSCANY-2347-Part5.patch, TUSCANY-2347-Part6-NEW.patch, TUSCANY-2347-Part6.patch, TUSCANY-2347-Part7-NEW.patch, TUSCANY-2347-Part7.patch After introducing the monitors in various part of the code (especially in the processors), while the runtime reads and resolves the contribution. Now we are trying to remove the exception that are being thrown from these modules. As a first step we are removing the exceptions that are safe to remove, by leaving the critical exceptions like a) IOException b) XMLStreamException c) PriviledegedActionException d) and ParseConfigurationExceptions As a second step, we will also be dealing with the above said exception once we have a detailed discussion as how to handle them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r666556 - /incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
I have all these test cases passed in my eclipse. I'm checking if I miss any
changes in the commit.
Thanks,
Raymond
--
From: [EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 12:56 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r666556 -
/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
Author: vamsic007
Date: Wed Jun 11 00:56:50 2008
New Revision: 666556
URL: http://svn.apache.org/viewvc?rev=666556view=rev
Log:
Marking the failing tests with @Ignore.
Modified:
incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
Modified:
incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java?rev=666556r1=666555r2=666556view=diff
==
---
incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
(original)
+++
incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
Wed Jun 11 00:56:50 2008
@@ -25,6 +25,7 @@
import
org.apache.tuscany.sca.itest.databindings.jaxb.impl.GenericsTransformer;
import org.junit.AfterClass;
import org.junit.BeforeClass;
+import org.junit.Ignore;
import org.junit.Test;
/**
@@ -81,7 +82,7 @@
* Service method invoked is getTypeExtends.
*/
@Test
-// @Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
+@Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
public void testSCATypeExtends() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientSCAComponent);
performTestTypeExtends(serviceClient);
@@ -113,7 +114,7 @@
* Service method invoked is getWildcardSuper.
*/
@Test
-// @Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
+@Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
public void testSCAWildcardSuper() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientSCAComponent);
performTestWildcardSuper(serviceClient);
@@ -124,7 +125,7 @@
* Service method invoked is getWildcardExtends.
*/
@Test
-// @Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
+@Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
public void testSCAWildcardExtends() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientSCAComponent);
performTestWildcardExtends(serviceClient);
@@ -198,7 +199,7 @@
* Service method invoked is getWildcardSuper.
*/
@Test
-// @Ignore(org.osoa.sca.ServiceRuntimeException:
org.apache.axis2.AxisFault)
+@Ignore(org.osoa.sca.ServiceRuntimeException:
org.apache.axis2.AxisFault)
public void testWSWildcardSuper() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientWSComponent);
performTestWildcardSuper(serviceClient);
@@ -209,7 +210,7 @@
* Service method invoked is getWildcardExtends.
*/
@Test
-// @Ignore(org.osoa.sca.ServiceRuntimeException:
org.apache.axis2.AxisFault)
+@Ignore(org.osoa.sca.ServiceRuntimeException:
org.apache.axis2.AxisFault)
public void testWSWildcardExtends() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientWSComponent);
performTestWildcardExtends(serviceClient);
Re: svn commit: r666556 - /incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
Yes, I missed one file. I'll add it in now.
Thanks,
Raymond
--
From: Raymond Feng [EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 8:14 AM
To: tuscany-dev@ws.apache.org
Subject: Re: svn commit: r666556 -
/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
I have all these test cases passed in my eclipse. I'm checking if I miss
any changes in the commit.
Thanks,
Raymond
--
From: [EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 12:56 AM
To: [EMAIL PROTECTED]
Subject: svn commit: r666556 -
/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
Author: vamsic007
Date: Wed Jun 11 00:56:50 2008
New Revision: 666556
URL: http://svn.apache.org/viewvc?rev=666556view=rev
Log:
Marking the failing tests with @Ignore.
Modified:
incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
Modified:
incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java?rev=666556r1=666555r2=666556view=diff
==
---
incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
(original)
+++
incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up/src/test/java/org/apache/tuscany/sca/itest/databindings/jaxb/GenericsDatabindingTestCase.java
Wed Jun 11 00:56:50 2008
@@ -25,6 +25,7 @@
import
org.apache.tuscany.sca.itest.databindings.jaxb.impl.GenericsTransformer;
import org.junit.AfterClass;
import org.junit.BeforeClass;
+import org.junit.Ignore;
import org.junit.Test;
/**
@@ -81,7 +82,7 @@
* Service method invoked is getTypeExtends.
*/
@Test
-// @Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
+@Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
public void testSCATypeExtends() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientSCAComponent);
performTestTypeExtends(serviceClient);
@@ -113,7 +114,7 @@
* Service method invoked is getWildcardSuper.
*/
@Test
-// @Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
+@Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
public void testSCAWildcardSuper() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientSCAComponent);
performTestWildcardSuper(serviceClient);
@@ -124,7 +125,7 @@
* Service method invoked is getWildcardExtends.
*/
@Test
-// @Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
+@Ignore(java.lang.IllegalArgumentException:
javax.xml.bind.MarshalException)
public void testSCAWildcardExtends() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientSCAComponent);
performTestWildcardExtends(serviceClient);
@@ -198,7 +199,7 @@
* Service method invoked is getWildcardSuper.
*/
@Test
-// @Ignore(org.osoa.sca.ServiceRuntimeException:
org.apache.axis2.AxisFault)
+@Ignore(org.osoa.sca.ServiceRuntimeException:
org.apache.axis2.AxisFault)
public void testWSWildcardSuper() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientWSComponent);
performTestWildcardSuper(serviceClient);
@@ -209,7 +210,7 @@
* Service method invoked is getWildcardExtends.
*/
@Test
-// @Ignore(org.osoa.sca.ServiceRuntimeException:
org.apache.axis2.AxisFault)
+@Ignore(org.osoa.sca.ServiceRuntimeException:
org.apache.axis2.AxisFault)
public void testWSWildcardExtends() throws Exception {
GenericsServiceClient serviceClient =
domain.getService(GenericsServiceClient.class,
GenericsServiceClientWSComponent);
performTestWildcardExtends(serviceClient);
Re: Databinding test for javax.xml.transform.Source problem
If I run the test case alone without others in the same class, then it passes. I think there is some interference from other test cases. Especially, the Source, Image are both map to the same XSD type. We need to dig out what's conflicting. Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 6:01 AM To: tuscany-dev@ws.apache.org Subject: Databinding test for javax.xml.transform.Source problem I have updated the tests to get the content out of Source objects and compare the contents. I have the following StreamSource as input: new StreamSource(new StringReader(aA/a)). The content I am from this source is as follows: ?xml version=1.0 encoding=UTF-8? aA/a I have a service method that returns a copy of the source that is passed to it. The source that is returned when the service method is invoked over binding.ws is giveing the following content: ?xml version=1.0 encoding=UTF-8? return xmlns=http://jaxb.databindings.itest.sca.tuscany.apache.org/ A/return Notice the namespace and the change in the root tag. Any suggestions on changing the test?
Re: Unable to download the artifact from any repository
I continued looking into this issue and found that the parent-2-incubating.pom can't be downloaded and thus leads to the errors shown below. I tested this by checking out the most recent version of the java code and building as explained in [1]. I read that a possible workaround might be to download the pom and do things manually but it's not possible to acces the file on any of these URLs. Is there anywhere else I can get this file from? Am I missing something? (I feel like I might be doing something terribly wrong...) $ mvn clean install -Dtest=no [INFO] Scanning for projects... Downloading: http://people.apache.org/~antelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ws.zones.apache.org/repository2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://www.ibiblio.net/pub/packages/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany ArtifactId: parent Version: 2-incubating Reason: Unable to download the artifact from any repository org.apache.tuscany:parent:pom:2-incubating [1] http://incubator.apache.org/tuscany/sca-java-development-guide.html On Wed, Jun 11, 2008 at 10:43 AM, Oscar Castaneda [EMAIL PROTECTED] wrote: Hi, I'm re-doing my SCA installation by following the steps in [1] and keep running into a problem when doing clean install: mvn clean install -Dtest=no After searching the mailing list archives I found some suggestions, but haven't been able to resolve the problem. I posted the stack trace in [2]. What can be going wrong? Any suggestions? Any help is greatly appreciated. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/30may2008 [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/10Jun2008 -- best, -oscar Oscar Castañeda -- best, -oscar Oscar Castañeda
Re: Unable to download the artifact from any repository
It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelder. Could there be some old config in you maven settings.xml file (eg at C:\Documents and Settings\Administrator\.m2\settings.xml) from when you reviewing the 1.0 RC1a? ...ant On Wed, Jun 11, 2008 at 5:05 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: I continued looking into this issue and found that the parent-2-incubating.pom can't be downloaded and thus leads to the errors shown below. I tested this by checking out the most recent version of the java code and building as explained in [1]. I read that a possible workaround might be to download the pom and do things manually but it's not possible to acces the file on any of these URLs. Is there anywhere else I can get this file from? Am I missing something? (I feel like I might be doing something terribly wrong...) $ mvn clean install -Dtest=no [INFO] Scanning for projects... Downloading: http://people.apache.org/~antelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pomhttp://people.apache.org/%7Eantelder/tuscany/1.0-RC1a/maven/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ws.zones.apache.org/repository2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2//org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://ftp.osuosl.org/pub/eclipse/tools/emf/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom Downloading: http://www.ibiblio.net/pub/packages/maven2/org/apache/tuscany/parent/2-incubating/parent-2-incubating.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany ArtifactId: parent Version: 2-incubating Reason: Unable to download the artifact from any repository org.apache.tuscany:parent:pom:2-incubating [1] http://incubator.apache.org/tuscany/sca-java-development-guide.html On Wed, Jun 11, 2008 at 10:43 AM, Oscar Castaneda [EMAIL PROTECTED] wrote: Hi, I'm re-doing my SCA installation by following the steps in [1] and keep running into a problem when doing clean install: mvn clean install -Dtest=no After searching the mailing list archives I found some suggestions, but haven't been able to resolve the problem. I posted the stack trace in [2]. What can be going wrong? Any suggestions? Any help is greatly appreciated. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/30may2008 [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/10Jun2008 -- best, -oscar Oscar Castañeda -- best, -oscar Oscar Castañeda
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 2:31 PM, Rajini Sivaram [EMAIL PROTECTED] wrote: ,snip You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ Great article, thanks for the link. Thats over a year old now so has much changed eg in relation to comments like The delayed services feature requires some small tweaks to the basic Equinox runtime, and these tweaks have not been implemented yet in the released version 3.2. They do not appear at all yet (at the time of writing) in the other open source OSGi runtimes, Apache Felix and Knopflerfish.? ...ant The delayed services feature is supported in Equinox. The equinox implementation was improved by a contribution from Prosyst. Felix has DS support and documentation mentions the immediate attribute used to control delayed services, so I'm guessing it is also supported in that project. I've not looked at Knopflerfish. Regards, Graham
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Hi Rajini, couple of comments below 2008/6/11 Rajini Sivaram [EMAIL PROTECTED]: On 6/11/08, Graham Charters [EMAIL PROTECTED] wrote: If we assume one bundle per Tuscany module for developers, perhaps there's a need for a separate concept that provides a simplified view for users? The SpringSource Application Platform has the concept of a library, which has caused much debate in the OSGi world (it has its own manifest header). A library is a collection of bundles which gives the developer a single 'thing' on which to depend. At runtime the concept goes away and just results in Import/Export-Package statements created through manifest re-writing (the library does not affect package visibility). I'm not suggesting we use the same approach, but it just highlights that others a felt the need for an 'aggregation' concept. I wonder if a bundle repository might also provide such a capability, but I'm not too familiar with things like OBR at the moment. OBR does provide similar capability, but IMO the problem with all these approaches (OBR, SpringSource library) is that none of them is a standard. I just hope we dont invent yet another one. RFC 112 covers the design for a Bundle Repository (inspired by OBR) so is some way along the path to being a standard. This might make the OBR approach a safer bet. On the subject of the ExtensionRegistry. This is not a standard OSGi feature, but I've been told the Equinox implementation should run on any standard OSGi implementation (e.g. Felix). Is there any reason why we wouldn't just use the standard service registry? It has all the features required to manage the lifecycle of new extensions being installed/uninstalled, etc. You have probably read this already, but others may find Neil Bartlett's discussion useful: http://www.eclipsezone.com/articles/extensions-vs-services/ I dont actually have an opinion, just pointing to the docs. Yes, but thanks for the pointer. It's an excellent article. My comment was less about the technical pros/cons of each approach and more about the standards aspect, although the technical aspects need to be considered. Regards, Graham. 2008/6/11 ant elder [EMAIL PROTECTED]: On Wed, Jun 11, 2008 at 9:09 AM, Rajini Sivaram [EMAIL PROTECTED] wrote: snip If we are anyway going to require a launcher of some form, wouldn't it be just as easy to maintain one-bundle-per-module? I agree, if we go back to requiring a launcher that changes a lot how we'd could put this together. I'm not at all against requiring a launcher as that does make things easier in some respects, but lets remember why we did used to do this and then chucked it out in the 0.90 rewrite ;) ...ant -- Thank you... Regards, Rajini
[jira] Assigned: (TUSCANY-2312) Runtime ignores custom callback when using setCallback()
[ https://issues.apache.org/jira/browse/TUSCANY-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash reassigned TUSCANY-2312: --- Assignee: Simon Nash Runtime ignores custom callback when using setCallback() Key: TUSCANY-2312 URL: https://issues.apache.org/jira/browse/TUSCANY-2312 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash The Java CAA spec states: /** * Lines 728-732 * p * By default, the client component of a service is assumed to be the * callback service for the bidirectional service. However, it is possible * to change the callback by using the ServiceReference.setCallback() * method. The object passed as the callback should implement the interface * defined for the callback, including any additional SCA semantics on that * interface such as its scope and whether or not it is remotable. */ I am getting the following error when I try to provide a custom callback using ServiceReference.setCallback(). I appears that the runtime has injected the client service as the callback rather then the user provided callback resulting in the following exception: java.lang.IllegalArgumentException: java.lang.NoSuchMethodException: No matching method for operation callBack is found on class org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.AServiceImpl at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInvoker(JavaImplementationProvider.java:148) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:315) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:188) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:115) at org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:120) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:184) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:197) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:91) at $Proxy27.callBack(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.BServiceImpl.testCallBack(BServiceImpl.java) 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.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.CallbackInterfaceInterceptor.invoke(CallbackInterfaceInterceptor.java:43) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy26.testCallBack(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.AServiceImpl.testCallback(AServiceImpl.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at
[jira] Resolved: (TUSCANY-2312) Runtime ignores custom callback when using setCallback()
[ https://issues.apache.org/jira/browse/TUSCANY-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-2312. - Resolution: Fixed Fixed in r666738 and r666740. The commit for r666738 also includes a fix for a problem where a conversational service implementation that calls RequestContext.getServiceReference() was getting a CallableReference without a conversation object attached. Runtime ignores custom callback when using setCallback() Key: TUSCANY-2312 URL: https://issues.apache.org/jira/browse/TUSCANY-2312 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash The Java CAA spec states: /** * Lines 728-732 * p * By default, the client component of a service is assumed to be the * callback service for the bidirectional service. However, it is possible * to change the callback by using the ServiceReference.setCallback() * method. The object passed as the callback should implement the interface * defined for the callback, including any additional SCA semantics on that * interface such as its scope and whether or not it is remotable. */ I am getting the following error when I try to provide a custom callback using ServiceReference.setCallback(). I appears that the runtime has injected the client service as the callback rather then the user provided callback resulting in the following exception: java.lang.IllegalArgumentException: java.lang.NoSuchMethodException: No matching method for operation callBack is found on class org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.AServiceImpl at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInvoker(JavaImplementationProvider.java:148) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:315) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:188) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:115) at org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:120) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:184) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:197) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:91) at $Proxy27.callBack(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.BServiceImpl.testCallBack(BServiceImpl.java) 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.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.CallbackInterfaceInterceptor.invoke(CallbackInterfaceInterceptor.java:43) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy26.testCallBack(Unknown Source) at
[jira] Commented: (TUSCANY-2247) vtest content for Java API spec - Conversation/Async
[ https://issues.apache.org/jira/browse/TUSCANY-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604274#action_12604274 ] Simon Nash commented on TUSCANY-2247: - I have fixed TUSCANY-2312 now. vtest content for Java API spec - Conversation/Async - Key: TUSCANY-2247 URL: https://issues.apache.org/jira/browse/TUSCANY-2247 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Kevin Williams Fix For: Java-SCA-Next Add vtest content for Java API/Annotation Spec section 1.6 - Conversations and Async -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Good practice for disabling/ignoring failing test cases
Hi,
I see Vamsi uses the following strategy to disable failing unit test cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean build
while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
Re: Good practice for disabling/ignoring failing test cases
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in Tuscany
source code and have been following it consistently from then on. Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
Re: Good practice for disabling/ignoring failing test cases
On Wed, Jun 11, 2008 at 6:43 PM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in Tuscany
source code and have been following it consistently from then on. Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test
cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
+1 good idea
Simon
[jira] Closed: (TUSCANY-2378) Databinding tests for generics, parameterized and polymorphic types
[ https://issues.apache.org/jira/browse/TUSCANY-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2378. Resolution: Fixed Complete. Databinding tests for generics, parameterized and polymorphic types --- Key: TUSCANY-2378 URL: https://issues.apache.org/jira/browse/TUSCANY-2378 Project: Tuscany Issue Type: Test Components: Java SCA Data Binding Runtime, Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Databinding tests for generics, parameterized and polymorphic types. See http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2361) Databinding tests for primitives and primitive arrays - local service, pass-by-value tests
[ https://issues.apache.org/jira/browse/TUSCANY-2361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2361. Databinding tests for primitives and primitive arrays - local service, pass-by-value tests -- Key: TUSCANY-2361 URL: https://issues.apache.org/jira/browse/TUSCANY-2361 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2361.patch TUSCANY-2350 added databinding tests for primitives and primitive arrays using a remotable service. The same tests need to be done for a local service too (see [1]). Also, the pass-by-value semantics does not seem to be working for byte array. It is a good idea to add tests for pass-by-value for byte array and arrays of other primitive types. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2373) RuntimeException: no data binding for null with binding.ws when the service interface uses generics
[ https://issues.apache.org/jira/browse/TUSCANY-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2373. Resolution: Fixed Assignee: Raymond Feng Fixed as part databinding tests cleanup. RuntimeException: no data binding for null with binding.ws when the service interface uses generics - Key: TUSCANY-2373 URL: https://issues.apache.org/jira/browse/TUSCANY-2373 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2373-testcase.patch I have the following method in my service interface that uses binding.ws: T Bean1T getTypeUnbound(T[] anArray); I am getting the following exception in SCADomain.newInstance() org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70) at org.apache.tuscany.sca.itest.databindings.jaxb.GenericsDatabindingTestCase.setUp(GenericsDatabindingTestCase.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242) ... 16 more Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237) ... 18 more Caused by: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:507) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:481) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:366) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:142) at org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:198) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:68) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47) at
[jira] Closed: (TUSCANY-2356) Databinding itests for Local service
[ https://issues.apache.org/jira/browse/TUSCANY-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2356. Databinding itests for Local service Key: TUSCANY-2356 URL: https://issues.apache.org/jira/browse/TUSCANY-2356 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2356.patch Databinding itests added by TUSCANY-2340 deal with only @Remotable service. This JIRA is for itests for Local service. See [1]. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2340) Databinding integration tests
[ https://issues.apache.org/jira/browse/TUSCANY-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2340. Databinding integration tests - Key: TUSCANY-2340 URL: https://issues.apache.org/jira/browse/TUSCANY-2340 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2340-new.patch, TUSCANY-2340.patch I have been trying out a few tests with databindings and am hitting some TransformationExceptions. I thought it is better I post the tests I am creating to the JIRA so that others can take a look at these tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2350) Databinding tests for primitive types and array of primitive types
[ https://issues.apache.org/jira/browse/TUSCANY-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2350. Databinding tests for primitive types and array of primitive types -- Key: TUSCANY-2350 URL: https://issues.apache.org/jira/browse/TUSCANY-2350 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: TUSCANY-2350.patch Databinding tests for primitive types and array of primitive types -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2349) TransformationException when invoking a method with byte array paramter using webservice binding
[ https://issues.apache.org/jira/browse/TUSCANY-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2349. TransformationException when invoking a method with byte array paramter using webservice binding Key: TUSCANY-2349 URL: https://issues.apache.org/jira/browse/TUSCANY-2349 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Raymond Feng I have a service method that takes a byte array as parameter and returns a byte array. When I invoke the method using webservice binding, I am getting a TransformationException: No path found for the transformation: java:simpleType-java:array. The stacktrace is given below: org.apache.tuscany.sca.databinding.TransformationException: No path found for the transformation: java:simpleType-java:array at org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:163) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:67) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:152) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:76) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy11.negateByteArray(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.impl.PrimitivesServiceClientImpl.negateByteArrayForward(PrimitivesServiceClientImpl.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:110) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy10.negateByteArrayForward(Unknown Source) at org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase.performTestNegateByteArray(PrimitivesDatabindingTestCase.java:372) at org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase.testWSNegateByteArray(PrimitivesDatabindingTestCase.java:236) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at
[jira] Closed: (TUSCANY-2272) @Init and @Destroy annotations on a non-public method
[ https://issues.apache.org/jira/browse/TUSCANY-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2272. @Init and @Destroy annotations on a non-public method -- Key: TUSCANY-2272 URL: https://issues.apache.org/jira/browse/TUSCANY-2272 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2272.patch Java Common Annotations and APIs Specification v1.00 - Sec 1.2.4 - Lines 265 to 269: 265 An implementation type may allow component implementations to declare lifecycle methods that are 266 called when an implementation is instantiated or the scope is expired. @Init denotes the method to be 267 called upon first use of an instance during the lifetime of the scope (except for composite scoped 268 implementation marked to eagerly initialize, see Section XXX). @Destroy specifies the method to be called 269 when the scope ends. *Note that only public, no argument methods may be annotated as lifecycle methods.* Currently @Init and @Destroy annotations on a protected method do not result in an error or a warning whereas these annotations on a private method result in a warning. Should it result in an error in both cases? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2273) Return value of a method with @Init and @Destroy annotations must be a void
[ https://issues.apache.org/jira/browse/TUSCANY-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2273. Return value of a method with @Init and @Destroy annotations must be a void --- Key: TUSCANY-2273 URL: https://issues.apache.org/jira/browse/TUSCANY-2273 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2273.patch Java Common Annotations and APIs v1.00: Sec 1.8.8 @Destroy - Lines 1226 and 1227: 1226 The method must have a void return value and 1227 no arguments. Sec 1.8.11 @Init - Lines 1291 and 1292: 1291 The method must have a void return value and no 1292 arguments. Currently the code checks only for no arguments but not the return type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2090) Test for uniqueness of ConversationIds
[ https://issues.apache.org/jira/browse/TUSCANY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2090. Test for uniqueness of ConversationIds -- Key: TUSCANY-2090 URL: https://issues.apache.org/jira/browse/TUSCANY-2090 Project: Tuscany Issue Type: Test Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Nash Fix For: Java-SCA-1.2 Attachments: TUSCANY-2090.patch Add a test for TUSCANY-2077: ConversationIds are not always unique so that there is no regression. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TUSCANY-2271) Java runtime should not inject property into an unannotated non-public field
[ https://issues.apache.org/jira/browse/TUSCANY-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed TUSCANY-2271. Java runtime should not inject property into an unannotated non-public field Key: TUSCANY-2271 URL: https://issues.apache.org/jira/browse/TUSCANY-2271 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime, Java SCA Verification Tests Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: TUSCANY-2271-vtest.patch, TUSCANY-2271.patch Java Common Annotations and APIs v1.0 - Sec 1.8.13: 1349 Properties may also be injected via public setter methods even when the @Property annotation is not 1350 present. However, the @Property annotation must be used in order to inject a property onto a non-public 1351 field. In the case where there is no @Property annotation, the name of the property is the same as the 1352 name of the field or setter. Currently the properties are injected into unannotated protected fields too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Unable to download the artifact from any repository
It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.tuscany.sca:tuscany-sca' not found in repository: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:573) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1260) ... 17 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:526) ... 18 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:324) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:185) ... 20 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Jun 11 20:08:02 CEST 2008 [INFO] Final Memory: 1M/2M [INFO] On Wed, Jun 11, 2008 at
OSGi presentation
Timely post of a presentation on server side OSGi: http://www.infoq.com/presentations/colyer-server-side-osgi ...ant
Re: Unable to download the artifact from any repository
There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.tuscany.sca:tuscany-sca' not found in repository: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:573) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1260) ... 17 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:526) ... 18 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:324) at
Re: [jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
Simon,
I originally noticed this problem by inspecting trace, and I'm still looking
for an idea how to test this.
The reason it's difficult is interesting.
I thought I'd just take a WS, grab the WSDL, declare it via interface.wsdl
on the outer reference,
and have the inner Java client intf use a package that I knew would map to a
different TNS than that of the portType in the service WSDL.
This is using doc-lit-wrapped WSDL so I thought the wrapper elem with wrong
TNS in the payload would be a problem.
Though the client does send the bad wrapper elem in the SOAP payload, the
service (of course a Tuscany service with binding.ws)
handles the data just fine.Our Tuscany databinding code just realizes
that it can't convert wrapper to wrapper so it simply switches
to convert the wrapper's children.
The reason is the code in Input2InputTransformer:
...
if (sourceWrapperHandler.isInstance(sourceWrapper,
wrapperElement, childElements, context)) {
plus the OMElementWrapperHandler implementation
public boolean isInstance(...)
if (!element.getQName().equals(wrapper.getQName())) {
return false;
So, on the one hand, I thought this was interesting.
On the other, still looking for an idea to test this. Is there an easy way
to create say a raw Axis2 service hosted in the itest environment that would
not be so tolerant?
Scott
On Wed, Jun 11, 2008 at 8:54 AM, Simon Laws (JIRA)
tuscany-dev@ws.apache.org wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604207#action_12604207]
Simon Laws commented on TUSCANY-2324:
-
Is there a test case for this issue that shows the problem? I'm eyeballing
the code and its interesting as the code that processes promotion on the
reference side works differently to the code that processes promotion on the
service side. On the reference side it only copies the bindings down. On the
service side it does interface contracts also.
InterfaceContract is not pushed down to an inner, promoted component
reference only with Axis2 binding
---
Key: TUSCANY-2324
URL: https://issues.apache.org/jira/browse/TUSCANY-2324
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Reporter: Scott Kurz
Priority: Minor
If we take the following example where an inner component reference is
overridden in two ways by the outer component using the inner Composite as
impl:
1) a binding.ws is added
2) a WSDL intf (compatible with the inner Java intf) is declared
composite ... name=OuterComposite
component name=OuterComponent
implementation.composite name=blah:InnerComposite/
reference name=outerRef target=MyTarget
interface.wsdl interface=
http://blah#wsdl.interface(HelloWorld)http://blah#wsdl.interface%28HelloWorld%29
/
binding.ws/
/reference
/component
/composite
composite name=InnerComposite
component name=InnerComponent
implementation.java .../
reference name=helloWorldService
interface.java
interface=test.sca.w2j.ws.statc.exc.helloworld.HelloWorld/
/reference
/component
reference name=outerRef
promote=InnerComponent/helloWorldService/
/composite
we have a problem.
The CompositeActivatorImpl is going to start an
Axis2ReferenceBindingProvider for the inner Composite ref. The WS
binding is propagated down or inwards, you could say.But this WS binding
has a null IC, so we're going to look at the component ref IC, but this will
be the inner component ref IC, which is a Java IC. This kicks off a
Java2WSDL and the new WSDL IC becomes the Axis2 ref binding IC.
So the generated WSDL may not match the actual WSDL, which is a problem.
Of course, if we had included a wsdlElement (e.g. wsdl.port ) on the
outer component's binding.ws/ we would not have had a problem; it would
have been propagated inwards along with the binding itself.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Unable to download the artifact from any repository
Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll continue looking at it, any suggestions are welcome. On Wed, Jun 11, 2008 at 8:21 PM, ant elder [EMAIL PROTECTED] wrote: There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.tuscany.sca:tuscany-sca' not found in repository: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:573) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1260) ... 17 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73) at
Re: Unable to download the artifact from any repository
It looks like what you're building isn't looking in the Apache incubating repository, does the pom.xml in the top level of where you're building have repository idapache.incubator/id urlhttp://people.apache.org/repo/m2-incubating-repository/url /repository in the repositories section? ...ant On Wed, Jun 11, 2008 at 7:29 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll continue looking at it, any suggestions are welcome. On Wed, Jun 11, 2008 at 8:21 PM, ant elder [EMAIL PROTECTED] wrote: There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.tuscany.sca:tuscany-sca' not found in repository: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:573) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1260) ... 17
Re: Unable to download the artifact from any repository
Hi, We should have the following maven repo declared in the pom.xml: repository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository But I cannot find it anywhere in the pom.xml under the java/sca tree. Is it a bug? If we build from sca folder, then it works fine. What about building modules/... from an empty local maven repo? Thanks, Raymond -- From: Oscar Castaneda [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:29 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: Unable to download the artifact from any repository Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll continue looking at it, any suggestions are welcome. On Wed, Jun 11, 2008 at 8:21 PM, ant elder [EMAIL PROTECTED] wrote: There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.tuscany.sca:tuscany-sca' not found in repository: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) at
Test failure: CallBackSetCallbackConvTestCase
Hi, Simon Nash. I'm seeing the following failure after I refreshed from r666738 (your fix for TUSCANY-2312). Thanks, Raymond --- T E S T S --- Running org.apache.tuscany.sca.test.CallBackSetCallbackConvTestCase CallBackSetCallbackConvServiceImpl message received: Knock Knock Entering CallBackSetCallbackObjectCallback callBackMessage: Who's There Entering callback increment: This should do it CallBackSetCallbackConvServiceImpl response sent CallBackSetCallbackConvServiceImpl message received: Knock Knock java.lang.reflect.UndeclaredThrowableException at $Proxy12.callBackMessage(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvServiceImpl.knockKnock(CallBackSetCallbackConvServiceImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:128) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy11.knockKnock(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvClientImpl.test8(CallBackSetCallbackConvClientImpl.java:108) at org.apache.tuscany.sca.test.CallBackSetCallbackConvClientImpl.run(CallBackSetCallbackConvClientImpl.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:128) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy10.run(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvTestCase.testCallBackSetCallback(CallBackSetCallbackConvTestCase.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) Caused by: java.lang.NoSuchMethodException:
Re: Unable to download the artifact from any repository
Looks like you're right and thats missing which does seem like a bug. ...ant On Wed, Jun 11, 2008 at 7:47 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We should have the following maven repo declared in the pom.xml: repository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository But I cannot find it anywhere in the pom.xml under the java/sca tree. Is it a bug? If we build from sca folder, then it works fine. What about building modules/... from an empty local maven repo? Thanks, Raymond -- From: Oscar Castaneda [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:29 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: Unable to download the artifact from any repository Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll continue looking at it, any suggestions are welcome. On Wed, Jun 11, 2008 at 8:21 PM, ant elder [EMAIL PROTECTED] wrote: There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1264) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:749) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:479) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:537) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM
Decompressing problem
Hi, I am trying to download and install maven. I downloaded the binary for Mac osx. but when I try to unpack the tar, I get following error. charuka-silvas-macbook:~ charuka$ tar xzvf apache-maven-2.0.9-bin.tar.gz tar: This does not look like a tar archive tar: Skipping to next header tar: Error exit delayed from previous errors Please help me on this. thank you charuka
Re: GSoC Project - CORBA Support for Apache Tuscany
Hi,
I understand you mean to look at generated classes to determine
Java/CORBA mapping. I followed case A, using existing IDL file:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/resources/general_tests.idl
and focused on interface TestObject. Generated classes are in:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/java/org/apache/tuscany/sca/binding/corba/testing/generated/
Example 1.
Java interface for TestObject implements TestObjectOperations,
org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity. This means that
user should define this interface using CORBA API types. This is what
you mean?
Example 2.
Operation:
SomeStruct setStruct(inout SomeStruct arg)
for interface TestObject uses SomeStructHolder (for passing INOUT
argument) which implements
org.omg.CORBA.portable.Streamable. SomeStructHolder contains SomeStruct
as a structure representation. Again, SomeStruct uses CORBA API
interface - it implements org.omg.CORBA.portable.IDLEntity. In this case
SomeStruct was meant to be INOUT argument, so it uses
SomeStructHolder. If SomeStruct would be declared as OUT, then again
SomeStructHolder would be used, but little different application logic
would be used - argument wouldn't be sent, but only retrieved after
operation invocation (this remaining logic is generated in stubs
and skeletons - so it's outside generated interface). This means, that
user using holders the same way as in the generated style cannot tell
to the binding reference whether the modifier is INOUT or OUT.
This is one example of some real constraints which blocks using Java
interface hierarchy the same way as generated from idlj compiler.
Thanks,
Wojtek
Raymond Feng wrote:
Hi,
There are two specifications in these areas.
1) Java2IDL: http://www.omg.org/docs/formal/08-01-14.pdf
2) IDL2Java: http://www.omg.org/docs/formal/08-01-11.pdf
Let's try to use a few scenarios to help us understand what rules should
be applied.
Case A: There is an existing CORBA service (Java or C++) with IDL. Now
we want to consume it using SCA.
Here is what I would do:
a) Run idl2java to generate a java interface (ignoring other stubs and
skeletons) from the IDL.
b) Declare a SCA reference with binding.corba and set the interface to
the one generated from a)
c) The Tuscany corba invoker should be able to create a request stream
for input args and parse the response to get the return value.
The corba invoker needs to find the corba operation name from the java
method and know how to marshal/unmarshal the parameters/return value.
Case B: We have a SCA component and we want to expose it as a CORBA
service.
The corba service binding listener will have to unpack/pack data from
the ServerRequest. Let's assume the component service interface is
defined in java, then we need to follow the Java2IDL spec so that we
handle the java parameters/return value following the CORBA IDL rules.
Ideally, the exposed CORBA service would behave as it has an IDL
generated from rmic -idl java_interface.
Thanks,
Raymond
[snip]
Hi,
I recently submitted some code, which helps invoking remote objects.
Mechanism for invoking remote CORBA objects is determining operation
arguments types by Java types and I'm not sure that Java to CORBA
mapping model I proposed is OK.
There is quite nice description of Java to CORBA mapping under [1]. It
shows how idlj compiler creates Java structure basing on idl file and
I believe we shouldn't precisely follow those rules and try to make
them as simple as possible. Am I right?
1. Structures
I proposed that CORBA structures will be Java classes, with public
fields and no get/set methods. So every class field is member for
CORBA structure. Or maybe we should map JavaBean classes to CORBA
structures?
2. Sequences and arrays
Sequences and arrays can be mapped to Java by arrays or lists.
Unfortunately both CORBA types behaves bit different, additionally
CORBA arrays have fixed length so there should be possibility to
distinguish those types somehow. For now on I cannot find any other
solution, but annotating arrays with it's target length. Any opinions?
3. Arguments with inout/out modifiers
In CORBA, operation argument value can be changed. As we know Java
supports passing arguments by values only, so update on argument is
not possible. Such was solved in Java by wrapping arguments in holder
classes, ie:
public class IntHolder {
public int value;
}
This means if user wants to get his argument updated he needs to
create argument in holder class, which could be tough (maybe there are
low-level techniques which allows to manipulate such arguments?).
I know I should provide some method to recognize if users class is
holder for inout/out argument:
a. annotation
b. by implementing interface, ie:
public interface Holder {
void setValue(Object value);
Object getValue();
}
Or maybe there is some other
Re: Unable to download the artifact from any repository
Yup, I cannot find it either. After adding it I get the same errors. From the errors I noticed its looking for this file: tuscany-sca-2.0-incubating-SNAPSHOT.pom On [1] there is no such file for the 2.0 branch. So I guess the problem is that its looking for a file it can't find. Then again this is exactly what the error states: Reason: Unable to download the artifact from any repository The strange thing is that I've been able to do this before when I followed Adriano's instructions for replicating his Eclipse workspace. The bug is of course a bigger concern - but what can I do now to build the source I checked out? [1] http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/sca/tuscany-sca/ On Wed, Jun 11, 2008 at 8:56 PM, ant elder [EMAIL PROTECTED] wrote: Looks like you're right and thats missing which does seem like a bug. ...ant On Wed, Jun 11, 2008 at 7:47 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We should have the following maven repo declared in the pom.xml: repository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository /url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository But I cannot find it anywhere in the pom.xml under the java/sca tree. Is it a bug? If we build from sca folder, then it works fine. What about building modules/... from an empty local maven repo? Thanks, Raymond -- From: Oscar Castaneda [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:29 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: Unable to download the artifact from any repository Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll continue looking at it, any suggestions are welcome. On Wed, Jun 11, 2008 at 8:21 PM, ant elder [EMAIL PROTECTED] wrote: There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Comments inline. Simon Rajini Sivaram wrote: On 6/10/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. From an OSGi point of view I would like to ensure that we will continue to have one bundle per 3rd party jar and that these will not be aggregated regardless of how the distribution is zipped up. As for one bundle per maven module, I think there are pros and cons for finely grained and coarsely grained bundles, and it is really just a matter of preference. Since we anyway have nearly 150 3rd party bundles/jars anyway, I personally dont see any problem with one bundle per module. I have a different view on this. See below. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. IMHO modularizing Tuscany is about code quality and maintenance - something internal benefitting Tuscany developers. So we have 100 modules based on the developer's view of Tuscany internals. That does not necessarily mean that end users have to deal with 100 bundles. If 20 core modules are very tightly coupled together and will only operate with each other, as far as an end user is concerned, this could as well be one bundle. Can a Tuscany user combine assembly-xml version 1.3.0 with assembly version 1.3.1? Or even implementation-java with implementation-java-runtime of a
Re: Test failure: CallBackSetCallbackConvTestCase
There are some mismatching in the exceptions. I fixed it under r666812. Thanks, Raymond -- From: Raymond Feng [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:54 AM To: tuscany-dev@ws.apache.org Subject: Test failure: CallBackSetCallbackConvTestCase Hi, Simon Nash. I'm seeing the following failure after I refreshed from r666738 (your fix for TUSCANY-2312). Thanks, Raymond --- T E S T S --- Running org.apache.tuscany.sca.test.CallBackSetCallbackConvTestCase CallBackSetCallbackConvServiceImpl message received: Knock Knock Entering CallBackSetCallbackObjectCallback callBackMessage: Who's There Entering callback increment: This should do it CallBackSetCallbackConvServiceImpl response sent CallBackSetCallbackConvServiceImpl message received: Knock Knock java.lang.reflect.UndeclaredThrowableException at $Proxy12.callBackMessage(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvServiceImpl.knockKnock(CallBackSetCallbackConvServiceImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:128) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy11.knockKnock(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvClientImpl.test8(CallBackSetCallbackConvClientImpl.java:108) at org.apache.tuscany.sca.test.CallBackSetCallbackConvClientImpl.run(CallBackSetCallbackConvClientImpl.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:128) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy10.run(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvTestCase.testCallBackSetCallback(CallBackSetCallbackConvTestCase.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
Test failure: org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation()
Hi, Do any of you see this failure too? Thanks, Raymond org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation() java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:69) at org.junit.Assert.assertTrue(Assert.java:32) at org.junit.Assert.assertNull(Assert.java:256) at org.junit.Assert.assertNull(Assert.java:265) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.impl.BComponentImpl.testNullConversation(BComponentImpl.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:133) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy14.testNullConversation(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation(CallableReferenceTestCase.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Re: Good practice for disabling/ignoring failing test cases
The vtest contributors get credit for this pattern! :-) We also have
a Ruby script that scans the test source and, among other things,
lists ignored tests and the associated blocking Jiras.
On Wed, Jun 11, 2008 at 11:49 AM, Simon Laws [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 6:43 PM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in Tuscany
source code and have been following it consistently from then on. Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test
cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
+1 good idea
Simon
Re: GSoC Project - CORBA Support for Apache Tuscany
Hi, Wojtek. Please see my comments inline. Thanks, Raymond -- From: Wojtek Janiszewski [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:55 AM To: tuscany-dev@ws.apache.org Subject: Re: GSoC Project - CORBA Support for Apache Tuscany Hi, I understand you mean to look at generated classes to determine Java/CORBA mapping. I followed case A, using existing IDL file: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/resources/general_tests.idl and focused on interface TestObject. Generated classes are in: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-corba/src/test/java/org/apache/tuscany/sca/binding/corba/testing/generated/ Example 1. Java interface for TestObject implements TestObjectOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity. This means that user should define this interface using CORBA API types. This is what you mean? To access an existing CORBA service with general_tests.idl, I should be able to use TestObject interface generated from the IDL in my SCA reference with binding.corba. The CORBA reference binding invoker should be able to marshal/marshal the data from the interface. Another case is that Java2IDL compliant java interface (for example, the remote interfaces for EJB). We already have support in the binding.ejb module. Example 2. Operation: SomeStruct setStruct(inout SomeStruct arg) for interface TestObject uses SomeStructHolder (for passing INOUT argument) which implements org.omg.CORBA.portable.Streamable. SomeStructHolder contains SomeStruct as a structure representation. Again, SomeStruct uses CORBA API interface - it implements org.omg.CORBA.portable.IDLEntity. In this case SomeStruct was meant to be INOUT argument, so it uses SomeStructHolder. If SomeStruct would be declared as OUT, then again SomeStructHolder would be used, but little different application logic would be used - argument wouldn't be sent, but only retrieved after operation invocation (this remaining logic is generated in stubs and skeletons - so it's outside generated interface). This means, that user using holders the same way as in the generated style cannot tell to the binding reference whether the modifier is INOUT or OUT. This is one example of some real constraints which blocks using Java interface hierarchy the same way as generated from idlj compiler. OK. My understanding is that the generated java interface doesn't catch all the information from the IDL because some of them are in the generated stubs/skeletons. We probably need to decide what's the best default here. For example, for the Holder type, we will default to INOUT. Another perspective is that for SCA remotable interfaces, the data exchange semantics is pass-by-value. In the case that @AllowsPassByReference is used, it only means the data is safe to pass by reference and it does NOT mandate pass-by-reference. So we can perfectly argue that the binding.corba doesn't support the INOUT and OUT arguments. Thanks, Wojtek Raymond Feng wrote: Hi, There are two specifications in these areas. 1) Java2IDL: http://www.omg.org/docs/formal/08-01-14.pdf 2) IDL2Java: http://www.omg.org/docs/formal/08-01-11.pdf Let's try to use a few scenarios to help us understand what rules should be applied. Case A: There is an existing CORBA service (Java or C++) with IDL. Now we want to consume it using SCA. Here is what I would do: a) Run idl2java to generate a java interface (ignoring other stubs and skeletons) from the IDL. b) Declare a SCA reference with binding.corba and set the interface to the one generated from a) c) The Tuscany corba invoker should be able to create a request stream for input args and parse the response to get the return value. The corba invoker needs to find the corba operation name from the java method and know how to marshal/unmarshal the parameters/return value. Case B: We have a SCA component and we want to expose it as a CORBA service. The corba service binding listener will have to unpack/pack data from the ServerRequest. Let's assume the component service interface is defined in java, then we need to follow the Java2IDL spec so that we handle the java parameters/return value following the CORBA IDL rules. Ideally, the exposed CORBA service would behave as it has an IDL generated from rmic -idl java_interface. Thanks, Raymond [snip] Hi, I recently submitted some code, which helps invoking remote objects. Mechanism for invoking remote CORBA objects is determining operation arguments types by Java types and I'm not sure that Java to CORBA mapping model I proposed is OK. There is quite nice description of Java to CORBA mapping under [1]. It shows how idlj compiler creates Java structure basing on idl file and I believe we shouldn't precisely follow those rules and try to make them as simple as possible. Am I right? 1. Structures
[jira] Closed: (TUSCANY-2375) vtest to test generated wsdl
[ https://issues.apache.org/jira/browse/TUSCANY-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Williams closed TUSCANY-2375. --- Resolution: Fixed vtest to test generated wsdl Key: TUSCANY-2375 URL: https://issues.apache.org/jira/browse/TUSCANY-2375 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Affects Versions: Java-SCA-Next Reporter: Gilbert Kwan Assignee: Kevin Williams Priority: Minor Attachments: T2375.vtest.patch, T2375.vtest.zip Test the section 2.3.2, 2.3.3, and 2.3.3.1 of WS Binding Spec V1.00 by examining the generated wsdl -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GSoC Project - CORBA Support for Apache Tuscany
To map CORBA exceptions (object id) to java exceptions, we can follow the
logic in org.apache.tuscany.sca.binding.ejb.util.EJBHandler.java:
} catch (ApplicationException ex) {
in = (InputStream)ex.getInputStream();
try {
org.apache.tuscany.sca.binding.ejb.corba.Java2IDLUtil.throwException(methodInfo.getMethod(),
in);
return null;
} catch (Throwable e) {
throw new RemoteException(e.getMessage(), e);
}
} catch (RemarshalException ex) {
return invokeRemoteCORBACall(stub, methodName, args);
} finally {
stub._releaseReply(in);
}
} catch (SystemException ex) {
throw Util.mapSystemException(ex);
}
Please note
org.apache.tuscany.sca.binding.ejb.corba.Java2IDLUtil.throwException maps
the object id to a declared java exception.
Thanks,
Raymond
--
From: Wojtek Janiszewski [EMAIL PROTECTED]
Sent: Sunday, June 08, 2008 6:50 PM
To: tuscany-dev@ws.apache.org
Subject: Re: GSoC Project - CORBA Support for Apache Tuscany
Hi,
I've gathered all current/past issues regarding project on wiki page:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/CORBA+reference+binding+features%2C+bugs%2C+issues
Comments are always welcome.
Thanks,
Wojtek
Wojtek Janiszewski wrote:
Wojtek Janiszewski wrote:
Simon Nash wrote:
One comment inline.
Simon
6. If CORBA objects operation argument is object reference, then
user should provide object which was previously obtained from
binding or other CORBA object. User cannot use users-side object as
an argument.
Yes. Let's don't worry object reference too much at this point. We
are in the SOA world instead of distributed object :-).
This is OK if we are exposing a SCA service via CORBA. If we are using
SCA to invoke existing CORBA services that expect object references
to be passed, we will need to come up with an approach for handling
them.
I'd suggest that we start first with exposing SCA services via CORBA
as this seems to be the simplest and most useful form of integration.
Unfortunately I started earlier with reference bindings - even submitted
a patch today.
My thoughts for object references are that after obtaining some remote
reference, it will be enhanced by cglib and connected to users declared
interface. By enhancing I mean interception of methods invocations and
adding dynamic CORBA invocations. Such enhanced object could be
recognizable by dynamic invocation mechanism, and it could be passed
while invoking operations on remote objects.
In this solution we would have two types of CORBA objects - ones that
were intentionally declared, and ones that were obtained from roots, and
which are transparent. It's maybe kind of out of control by Tuscany
runtime, but is there any other way to obtain and use CORBA references
which are not registered in name services?
Thanks,
Wojtek
Hi,
I recently submitted some code, which helps invoking remote objects.
Mechanism for invoking remote CORBA objects is determining operation
arguments types by Java types and I'm not sure that Java to CORBA mapping
model I proposed is OK.
There is quite nice description of Java to CORBA mapping under [1]. It
shows how idlj compiler creates Java structure basing on idl file and I
believe we shouldn't precisely follow those rules and try to make them as
simple as possible. Am I right?
1. Structures
I proposed that CORBA structures will be Java classes, with public fields
and no get/set methods. So every class field is member for CORBA
structure. Or maybe we should map JavaBean classes to CORBA structures?
2. Sequences and arrays
Sequences and arrays can be mapped to Java by arrays or lists.
Unfortunately both CORBA types behaves bit different, additionally CORBA
arrays have fixed length so there should be possibility to distinguish
those types somehow. For now on I cannot find any other solution, but
annotating arrays with it's target length. Any opinions?
3. Arguments with inout/out modifiers
In CORBA, operation argument value can be changed. As we know Java
supports passing arguments by values only, so update on argument is not
possible. Such was solved in Java by wrapping arguments in holder
classes, ie:
public class IntHolder {
public int value;
}
This means if user wants to get his argument updated he needs to create
argument in holder class, which could be tough (maybe there are low-level
techniques which allows to manipulate such arguments?).
I know I should provide some method to recognize if users class is holder
for inout/out argument:
a. annotation
b. by implementing interface, ie:
public interface Holder {
void setValue(Object value);
Object getValue();
}
Or maybe there is some other solution? Which one should I choose?
I'll appreciate any comments.
Re: Test failure: org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation()
Raymond Feng wrote: Hi, Do any of you see this failure too? Yes, I see it. It appears the test is wrong, and this is now showing up because of my recent check-in r666738 in which I fixed a problem where the conversation object was incorrectly being returned as null even though there is an active conversation. This test appears to be checking for the incorrect behaviour. The call b.testNullConversation() creates a conversation, since the BComponent interface is @Conversational and BComponentImpl has @Scope(CONVERSATION). Calling RequestContext.getConversation() while this method is active should return non-null, not null. Simon Thanks, Raymond org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation() java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:69) at org.junit.Assert.assertTrue(Assert.java:32) at org.junit.Assert.assertNull(Assert.java:256) at org.junit.Assert.assertNull(Assert.java:265) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.impl.BComponentImpl.testNullConversation(BComponentImpl.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:133) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy14.testNullConversation(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation(CallableReferenceTestCase.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Re: Test failure: CallBackSetCallbackConvTestCase
Raymond Feng wrote: There are some mismatching in the exceptions. I fixed it under r666812. Thanks for fixing this. There are also some deeper problems with various wrong paths being taken through this test case. I am investigating and I will check in a further update when I am confident that my changes are OK, probably tomorrow. Simon Thanks, Raymond -- From: Raymond Feng [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:54 AM To: tuscany-dev@ws.apache.org Subject: Test failure: CallBackSetCallbackConvTestCase Hi, Simon Nash. I'm seeing the following failure after I refreshed from r666738 (your fix for TUSCANY-2312). Thanks, Raymond --- T E S T S --- Running org.apache.tuscany.sca.test.CallBackSetCallbackConvTestCase CallBackSetCallbackConvServiceImpl message received: Knock Knock Entering CallBackSetCallbackObjectCallback callBackMessage: Who's There Entering callback increment: This should do it CallBackSetCallbackConvServiceImpl response sent CallBackSetCallbackConvServiceImpl message received: Knock Knock java.lang.reflect.UndeclaredThrowableException at $Proxy12.callBackMessage(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvServiceImpl.knockKnock(CallBackSetCallbackConvServiceImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:128) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy11.knockKnock(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvClientImpl.test8(CallBackSetCallbackConvClientImpl.java:108) at org.apache.tuscany.sca.test.CallBackSetCallbackConvClientImpl.run(CallBackSetCallbackConvClientImpl.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:128) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy10.run(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvTestCase.testCallBackSetCallback(CallBackSetCallbackConvTestCase.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) 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
Re: Good practice for disabling/ignoring failing test cases
+1 for using this pattern to disable/ignore tests that are failing.
How about also running the script in an automated fashion and sending
an e-mail to the list with the results ? What would be a good interval
for running the script ?
On Wed, Jun 11, 2008 at 1:03 PM, Kevin Williams [EMAIL PROTECTED] wrote:
The vtest contributors get credit for this pattern! :-) We also have
a Ruby script that scans the test source and, among other things,
lists ignored tests and the associated blocking Jiras.
On Wed, Jun 11, 2008 at 11:49 AM, Simon Laws [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 6:43 PM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in Tuscany
source code and have been following it consistently from then on. Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test
cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
+1 good idea
Simon
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Good practice for disabling/ignoring failing test cases
I think weekly report makes sense. When we try to cut a release, we would
like to see the reports too.
Thanks,
Raymond
--
From: Luciano Resende [EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 2:49 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Good practice for disabling/ignoring failing test cases
+1 for using this pattern to disable/ignore tests that are failing.
How about also running the script in an automated fashion and sending
an e-mail to the list with the results ? What would be a good interval
for running the script ?
On Wed, Jun 11, 2008 at 1:03 PM, Kevin Williams [EMAIL PROTECTED]
wrote:
The vtest contributors get credit for this pattern! :-) We also have
a Ruby script that scans the test source and, among other things,
lists ignored tests and the associated blocking Jiras.
On Wed, Jun 11, 2008 at 11:49 AM, Simon Laws [EMAIL PROTECTED]
wrote:
On Wed, Jun 11, 2008 at 6:43 PM, Vamsavardhana Reddy
[EMAIL PROTECTED]
wrote:
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in
Tuscany
source code and have been following it consistently from then on.
Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test
cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA
TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a
clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
+1 good idea
Simon
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Unable to download the artifact from any repository
The version you are looking for is in : http://people.apache.org/repo/m2-snapshot-repository/org/apache/tuscany/tuscany-sca/SNAPSHOT/ If you don't find a specific SNAPSHOT version of a module in a repository, you can always build it locally and it will be installed in your local maven repository. In your case, if you are looking for the sca pom, go to java/sca and do a mvn -N clean install. I have also re-deployed the SNAPSHOT version for the sca module. On Wed, Jun 11, 2008 at 12:23 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: Yup, I cannot find it either. After adding it I get the same errors. From the errors I noticed its looking for this file: tuscany-sca-2.0-incubating-SNAPSHOT.pom On [1] there is no such file for the 2.0 branch. So I guess the problem is that its looking for a file it can't find. Then again this is exactly what the error states: Reason: Unable to download the artifact from any repository The strange thing is that I've been able to do this before when I followed Adriano's instructions for replicating his Eclipse workspace. The bug is of course a bigger concern - but what can I do now to build the source I checked out? [1] http://people.apache.org/repo/m2-incubating-repository/org/apache/tuscany/sca/tuscany-sca/ On Wed, Jun 11, 2008 at 8:56 PM, ant elder [EMAIL PROTECTED] wrote: Looks like you're right and thats missing which does seem like a bug. ...ant On Wed, Jun 11, 2008 at 7:47 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, We should have the following maven repo declared in the pom.xml: repository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository /url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository But I cannot find it anywhere in the pom.xml under the java/sca tree. Is it a bug? If we build from sca folder, then it works fine. What about building modules/... from an empty local maven repo? Thanks, Raymond -- From: Oscar Castaneda [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:29 AM To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED] Subject: Re: Unable to download the artifact from any repository Thanks ant. I tried it but unfortunately I'm getting the same problem. I'll continue looking at it, any suggestions are welcome. On Wed, Jun 11, 2008 at 8:21 PM, ant elder [EMAIL PROTECTED] wrote: There's a Maven settings.xml we have for Tuscany the might help you at: https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/settings.xml ...ant On Wed, Jun 11, 2008 at 7:13 PM, Oscar Castaneda [EMAIL PROTECTED] wrote: It doesn't look right that the first of those URLs is pointing at my apache space - http://people.apache.org/~antelderhttp://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder http://people.apache.org/%7Eantelder . Thanks alot ant, you're right! I changed settings.xml following an old email thread. I deleted the file and executed mvn and its now complaining about not being able to resolve artifacts (and that's solvable my manually installing them I think). However, I was only testing this because of the problems I was experiencing when building revision 643746. Any ideas here? Maybe modifying the settings.xml to get the required files from somewhere else? Here's the trace: $ mvn clean install -Dtest=no [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.tuscany.sca ArtifactId: tuscany-sca Version: 2.0-incubating-SNAPSHOT Reason: Unable to download the artifact from any repository org.apache.tuscany.sca:tuscany-sca:pom:2.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache.tuscany.sca:tuscany-sca for project: null:tuscany-modules:pom:null at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond -- From: Simon Nash [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 12:33 PM To: tuscany-dev@ws.apache.org Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes Comments inline. Simon Rajini Sivaram wrote: On 6/10/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing
Re: [VOTE] Release SDO 1.1.1
Well, after really multiple times (about 5 or 6) I got a sucessful build. But how would our users feel by experiencing this issue ? On Wed, Jun 11, 2008 at 3:35 AM, ant elder [EMAIL PROTECTED] wrote: So thats works ok for two, doesn't work for one. Luciano, I had to build a couple of times with -U to get all the emf jars successfully downloaded, have you tried that or can you find any other way to get a build through in your environment? ...ant On Tue, Jun 10, 2008 at 11:32 AM, Murtaza Goga [EMAIL PROTECTED] wrote: I built this release last night, built clean. -Original Message- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 5:29 AM To: tuscany-dev@ws.apache.org Subject: Re: [VOTE] Release SDO 1.1.1 I'd like to get this voted on and released but nervous to start that after Kelvin had trouble getting the emf dependencies, could any one else try building the tag and seeing if it works or not for them - https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R C2/- its a small checkout and doesn't take long to build. ...ant On Sat, Jun 7, 2008 at 9:15 AM, ant elder [EMAIL PROTECTED] wrote: It seems to work fine for me, the binary distribution ends up with a lib folder containing: backport-util-concurrent-3.0.jar codegen-2.2.3.jar codegen-ecore-2.2.3.jar common-2.2.3.jar ecore-2.2.3.jar ecore-change-2.2.3.jar ecore-xmi-2.2.3.jar sample-sdo-1.1.1.jar stax-api-1.0.1.jar tuscany-sdo-api-r2.1-1.1.1.jar tuscany-sdo-impl-1.1.1.jar tuscany-sdo-lib-1.1.1.jar tuscany-sdo-tools-1.1.1.jar wstx-asl-3.2.1.jar xsd-2.2.3.jar I've put the distributions that I get from the 1.1.1-RC2 tag up at http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC2http://people.a pache.org/%7Eantelder/tuscany/sdo/1.1.1-RC2, how do they look? ...ant On Fri, Jun 6, 2008 at 6:18 PM, kelvin goodson [EMAIL PROTECTED] wrote: Hi Luciano, yes, I added that workaround, and that satisfied most of the EMF jars, but not these two. It's odd, the 2 jars we need are there in the repository you suggested, but maven will not download them. Kelvin. 2008/6/6 Luciano Resende [EMAIL PROTECTED]: Did you try the workaround I mentioned before on this thread [1] where I added a new repository ? It was actually for other jars, but might help in this case as well... [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg31727.html On Fri, Jun 6, 2008 at 4:56 AM, kelvin goodson [EMAIL PROTECTED] wrote: I've made all the changes required in the tag [1] to get rid of the felix jars, find and include the emf jars, and I've removed the incubating tag, DISCLAIMER files etc. However, I'm currently stumped as to why two emf jars available [2] and [3] don't get downloaded by the build. The build output complains about URLs that, if cut and pasted into a browser, work fine. Any clues to explain this odd maven behaviour are welcome. Kelvin [1] https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sdo/1.1.1-R C2/ [2] http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/c odegen/2.2.3/ [3] http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/org/eclipse/emf/c odegen-ecore/2.2.3/ 2008/6/3 Rajini Sivaram [EMAIL PROTECTED]: Kelvin, Sorry about the delay in getting back to you - I can see that you have found a solution. Yes, you are absolutely right, the felix framework should use scope provided since SdoBundleActivator is only used when SDO is running inside an OSGi container, and the framework classes are provided by the container. On 6/3/08, kelvin goodson [EMAIL PROTECTED] wrote: Just a thought, would I be right in guessing that if ever our SdoBundleActivator is touched in the runtime, then the environment would be expected to provide the classes to satisfy import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; ? in which case I think declaring a provided scope for the felix dependency would be the right way to do things Kelvin. 2008/6/3 kelvin goodson [EMAIL PROTECTED]: Thanks Ant, that looks like progress, but the felix framework jar is now not in the list of distributed jars. Kelvin. 2008/6/3 ant elder [EMAIL PROTECTED]: Adding an exclude for felix to the distribution pom can fix that, eg here's local changes i have just tried: Index: src/main/assembly/bin.xml === --- src/main/assembly/bin.xml (revision 662488) +++ src/main/assembly/bin.xml (working copy) @@ -120,13 +120,13
Re: Good practice for disabling/ignoring failing test cases
Simon Laws wrote:
On Wed, Jun 11, 2008 at 6:43 PM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in Tuscany
source code and have been following it consistently from then on. Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test
cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
+1 good idea
Simon
+1
--
Jean-Sebastien
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! -- Jean-Sebastien
[jira] Created: (TUSCANY-2388) Data binding does not work when Java interface implementation (where method param is not String, primitive) exposed with a web services binding
Data binding does not work when Java interface implementation (where method
param is not String, primitive) exposed with a web services binding
--
Key: TUSCANY-2388
URL: https://issues.apache.org/jira/browse/TUSCANY-2388
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.1
Environment: Windows XP; IBM J2RE 1.5.0 (Build 2.3)
Reporter: Peter Kemp
1. Create a component with a java implementation, with a service defined by a
Java interface.
The parameter to the method is not a String, primitive or wrapper - rather,
it's a class containing a couple of Strings and an Integer.
2. Expose the service with a webservice binding.
3. Deploy the composite (as a WAR or embedded).
4. Retrieve the WSDL for the service (eg from
http://localhost:8080/SomeServices?wsdl).
5. Generate a web service request from the WSDL.
The runtime fails to map the web service request message to the implementation
class method parameters - it calls the correct method, but the method parameter
is null.
The test works fine when the parameter is a String.
Composite definition (some.composite):
---
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://test; xmlns:test=http://test; name=some
service name=SomeServices promote=SomeServicesComponent
binding.ws uri=http://localhost:8080/SomeServices/
/service
component name=SomeServicesComponent
implementation.java class=service.SomeServiceImpl/
service name=SomeService
interface.java interface=service.SomeService /
/service
/component
/composite
Service interface:
---
/**
*
*/
package service;
import org.osoa.sca.annotations.Remotable;
@Remotable
public interface SomeService {
public AnObject getUsingString(String stringParam);
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam);
}
Implementation:
--
package service;
import org.osoa.sca.annotations.Service;
@Service(SomeService.class)
public class SomeServiceImpl implements SomeService {
public AnObject getUsingString(String stringParam) {
System.out.println(Param value: + stringParam);
return getAnObject(stringParam);
}
private AnObject getAnObject(String stringParam) {
// TODO Auto-generated method stub
return new AnObject(stringParam + 123, 123);
}
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam) {
System.out.println(Param value: + moreComplexParam.getStringParam());
return getAnObject(moreComplexParam.getStringParam());
}
}
MoreComplexObject.java
---
/**
*
*/
package service;
import java.io.Serializable;
public class MoreComplexObject implements Serializable{
private static final long serialVersionUID = 43242314234123L;
private String stringParam;
private Integer intParam;
private String stringParam2;
public String getStringParam() {
return stringParam;
}
public void setStringParam(String stringParam) {
this.stringParam = stringParam;
}
public Integer getIntParam() {
return intParam;
}
public void setIntParam(Integer intParam) {
this.intParam = intParam;
}
public String getStringParam2() {
return stringParam2;
}
public void setStringParam2(String stringParam2) {
this.stringParam2 = stringParam2;
}
}
AnObject.java
-
package service;
public class AnObject {
private String someRetValue;
private Integer someOtherRetValue;
public AnObject() {
}
public AnObject(String someRetValue, Integer someOtherRetValue) {
this.someRetValue = someRetValue;
this.someOtherRetValue = someOtherRetValue;
}
/**
* @return the someOtherRetValue
*/
public Integer getSomeOtherRetValue() {
return someOtherRetValue;
}
/**
* @param someOtherRetValue the someOtherRetValue to set
*/
public void setSomeOtherRetValue(Integer someOtherRetValue) {
this.someOtherRetValue = someOtherRetValue;
}
/**
* @return the someRetValue
*/
public String getSomeRetValue() {
return someRetValue;
}
/**
* @param someRetValue the someRetValue to set
*/
public void setSomeRetValue(String someRetValue) {
this.someRetValue = someRetValue;
}
}
WSDL returned by http://localhost:8080/SomeServices?wsdl
[jira] Updated: (TUSCANY-2388) Data binding does not work when Java interface implementation (where method param is not String, primitive) exposed with a web services binding
[
https://issues.apache.org/jira/browse/TUSCANY-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Kemp updated TUSCANY-2388:
Attachment: testcase.zip
Test case to reproduce bug
Data binding does not work when Java interface implementation (where method
param is not String, primitive) exposed with a web services binding
--
Key: TUSCANY-2388
URL: https://issues.apache.org/jira/browse/TUSCANY-2388
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.1
Environment: Windows XP; IBM J2RE 1.5.0 (Build 2.3)
Reporter: Peter Kemp
Attachments: testcase.zip
1. Create a component with a java implementation, with a service defined by a
Java interface.
The parameter to the method is not a String, primitive or wrapper - rather,
it's a class containing a couple of Strings and an Integer.
2. Expose the service with a webservice binding.
3. Deploy the composite (as a WAR or embedded).
4. Retrieve the WSDL for the service (eg from
http://localhost:8080/SomeServices?wsdl).
5. Generate a web service request from the WSDL.
The runtime fails to map the web service request message to the
implementation class method parameters - it calls the correct method, but the
method parameter is null.
The test works fine when the parameter is a String.
Composite definition (some.composite):
---
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://test; xmlns:test=http://test; name=some
service name=SomeServices promote=SomeServicesComponent
binding.ws uri=http://localhost:8080/SomeServices/
/service
component name=SomeServicesComponent
implementation.java class=service.SomeServiceImpl/
service name=SomeService
interface.java interface=service.SomeService /
/service
/component
/composite
Service interface:
---
/**
*
*/
package service;
import org.osoa.sca.annotations.Remotable;
@Remotable
public interface SomeService {
public AnObject getUsingString(String stringParam);
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam);
}
Implementation:
--
package service;
import org.osoa.sca.annotations.Service;
@Service(SomeService.class)
public class SomeServiceImpl implements SomeService {
public AnObject getUsingString(String stringParam) {
System.out.println(Param value: + stringParam);
return getAnObject(stringParam);
}
private AnObject getAnObject(String stringParam) {
// TODO Auto-generated method stub
return new AnObject(stringParam + 123, 123);
}
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam) {
System.out.println(Param value: +
moreComplexParam.getStringParam());
return getAnObject(moreComplexParam.getStringParam());
}
}
MoreComplexObject.java
---
/**
*
*/
package service;
import java.io.Serializable;
public class MoreComplexObject implements Serializable{
private static final long serialVersionUID = 43242314234123L;
private String stringParam;
private Integer intParam;
private String stringParam2;
public String getStringParam() {
return stringParam;
}
public void setStringParam(String stringParam) {
this.stringParam = stringParam;
}
public Integer getIntParam() {
return intParam;
}
public void setIntParam(Integer intParam) {
this.intParam = intParam;
}
public String getStringParam2() {
return stringParam2;
}
public void setStringParam2(String stringParam2) {
this.stringParam2 = stringParam2;
}
}
AnObject.java
-
package service;
public class AnObject {
private String someRetValue;
private Integer someOtherRetValue;
public AnObject() {
}
public AnObject(String someRetValue, Integer someOtherRetValue) {
this.someRetValue = someRetValue;
this.someOtherRetValue = someOtherRetValue;
}
/**
* @return the someOtherRetValue
*/
public Integer getSomeOtherRetValue() {
return someOtherRetValue;
}
/**
* @param someOtherRetValue the someOtherRetValue to set
*/
public void setSomeOtherRetValue(Integer someOtherRetValue) {
this.someOtherRetValue = someOtherRetValue;
}
/**
* @return the someRetValue
Re: svn commit: r666943 - in /incubator/tuscany/java/sca: distribution/bundle/ distribution/manifest/ distribution/webapp/ itest/osgi-tuscany/tuscany-extensions/ itest/osgi-tuscany/tuscany-osgi-instal
On Thu, Jun 12, 2008 at 2:46 AM, [EMAIL PROTECTED] wrote: Author: jsdelfino Date: Wed Jun 11 18:46:06 2008 New Revision: 666943 URL: http://svn.apache.org/viewvc?rev=666943view=rev Log: Merged implementation-node-xml with implementation-node as it only depends on assembly-xml and no other modules depend on it. Added: incubator/tuscany/java/sca/modules/implementation-node/src/main/java/org/apache/tuscany/sca/implementation/node/xml/ incubator/tuscany/java/sca/modules/implementation-node/src/main/java/org/apache/tuscany/sca/implementation/node/xml/ConfiguredNodeImplementationProcessor.java - copied, changed from r666925, incubator/tuscany/java/sca/modules/implementation-node-xml/src/main/java/org/apache/tuscany/sca/implementation/node/xml/ConfiguredNodeImplementationProcessor.java incubator/tuscany/java/sca/modules/implementation-node/src/main/java/org/apache/tuscany/sca/implementation/node/xml/NodeImplementationProcessor.java - copied, changed from r666925, incubator/tuscany/java/sca/modules/implementation-node-xml/src/main/java/org/apache/tuscany/sca/implementation/node/xml/NodeImplementationProcessor.java incubator/tuscany/java/sca/modules/implementation-node/src/main/resources/META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor - copied, changed from r666925, incubator/tuscany/java/sca/modules/implementation-node-xml/src/main/resources/META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor incubator/tuscany/java/sca/modules/implementation-node/src/test/java/org/apache/tuscany/sca/implementation/node/xml/ incubator/tuscany/java/sca/modules/implementation-node/src/test/java/org/apache/tuscany/sca/implementation/node/xml/ReadTestCase.java - copied, changed from r666925, incubator/tuscany/java/sca/modules/implementation-node-xml/src/test/java/org/apache/tuscany/sca/implementation/node/xml/ReadTestCase.java incubator/tuscany/java/sca/modules/implementation-node/src/test/java/org/apache/tuscany/sca/implementation/node/xml/WriteTestCase.java - copied, changed from r666925, incubator/tuscany/java/sca/modules/implementation-node-xml/src/test/java/org/apache/tuscany/sca/implementation/node/xml/WriteTestCase.java incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/ incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/ incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/ incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/ incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/ incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/ incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/ incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/ incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestComposite.composite - copied, changed from r666925, incubator/tuscany/java/sca/modules/implementation-node-xml/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestComposite.composite incubator/tuscany/java/sca/modules/implementation-node/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestNode.composite - copied, changed from r666925, incubator/tuscany/java/sca/modules/implementation-node-xml/src/test/resources/org/apache/tuscany/sca/implementation/node/xml/TestNode.composite Removed: incubator/tuscany/java/sca/modules/implementation-node-xml/DISCLAIMER incubator/tuscany/java/sca/modules/implementation-node-xml/LICENSE incubator/tuscany/java/sca/modules/implementation-node-xml/NOTICE incubator/tuscany/java/sca/modules/implementation-node-xml/pom.xml incubator/tuscany/java/sca/modules/implementation-node-xml/src/main/java/org/apache/tuscany/sca/implementation/node/xml/ConfiguredNodeImplementationProcessor.java incubator/tuscany/java/sca/modules/implementation-node-xml/src/main/java/org/apache/tuscany/sca/implementation/node/xml/NodeImplementationProcessor.java incubator/tuscany/java/sca/modules/implementation-node-xml/src/main/resources/META-INF/services/org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor incubator/tuscany/java/sca/modules/implementation-node-xml/src/test/java/org/apache/tuscany/sca/implementation/node/xml/ReadTestCase.java incubator/tuscany/java/sca/modules/implementation-node-xml/src/test/java/org/apache/tuscany/sca/implementation/node/xml/WriteTestCase.java
[GSoC] 4th weekly progress report
Hi Luciano, Please check the project blog for the 4th weekly progress report: Link:http://gdatabindingtuscany.blogspot.com The wiki page is also updated: Link: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Integrate+Google+services+in+SCA+compositions%28Apache+Tuscany%29 I believe the project is in a good shape so far, I have a good upstanding of the binding extension of Tuscany now; and the development and testing environment is ready; an initial binding extension has been tried and it worked successfully. Thanks a lot, Haibo
[jira] Resolved: (TUSCANY-2325) Schema validation does not register the exception with the Problem, yet Problem looks for it and finds it to be not-null
[
https://issues.apache.org/jira/browse/TUSCANY-2325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-2325.
--
Resolution: Cannot Reproduce
Fix Version/s: Java-SCA-Next
This looks working as expected now :
Jun 11, 2008 10:07:58 PM
org.apache.tuscany.sca.monitor.impl.DefaultLoggingMonitorImpl problem
SEVERE: XMLSchema validation error occured in: null ,line = 21, column = 9,
Message = UndeclaredPrefix: Cannot resolve 'ipxxx:allowed_users' as a QName:
the prefix 'ipxxx' is not declared.
Jun 11, 2008 10:07:58 PM
org.apache.tuscany.sca.monitor.impl.DefaultLoggingMonitorImpl problem
SEVERE: XMLSchema validation error occured in: null ,line = 21, column = 9,
Message = cvc-attribute.3: The value 'ipxxx:allowed_users' of attribute
'policySets' on element 'implementation.java' is not valid with respect to its
type, 'listOfQNames'.
Schema validation does not register the exception with the Problem, yet
Problem looks for it and finds it to be not-null
Key: TUSCANY-2325
URL: https://issues.apache.org/jira/browse/TUSCANY-2325
Project: Tuscany
Issue Type: Bug
Components: Java SCA Problem Determination
Environment: All
Reporter: Hasan Muhammad
Assignee: Luciano Resende
Priority: Critical
Fix For: Java-SCA-Next
The following code exists in ValidatingXMLStreamReader
/**
* Report a error.
*
* @param problems
* @param message
* @param model
*/
private void error(String message, Object model, Object...
messageParameters) {
Problem problem = new ProblemImpl(this.getClass().getName(),
contribution-validation-messages, Severity.ERROR, model, message,
(Object[])messageParameters);
monitor.problem(problem);
}
In this case, it does not register the exception with the problem. In the
monitor code, we have this
else if (problem.getSeverity() == Severity.ERROR) {
if (problem.getCause() != null) {
problemLogger.log(Level.SEVERE, problem.getMessageId(),
problem.getCause());
} else {
problemLogger.log(Level.SEVERE, problem.getMessageId(),
problem.getMessageParams());
}
It finds the cause to be not null, and simply logs the error like this
ValidatingXML E SchemaError
So either, the Reader should register the exception with problem, or the
cause be explicitely initalized to null in the ProblemImpl
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2388) Data binding does not work when Java interface implementation (where method param is not String, primitive) exposed with a web services binding
[
https://issues.apache.org/jira/browse/TUSCANY-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604421#action_12604421
]
Scott Kurz commented on TUSCANY-2388:
-
This looks like it should work, since though your MoreComplexObject doesn't
have JAXB annotations, it does follow the JavaBean pattern with
getters/setters. I tried on r666142 and it seemed to work for me.
Data binding does not work when Java interface implementation (where method
param is not String, primitive) exposed with a web services binding
--
Key: TUSCANY-2388
URL: https://issues.apache.org/jira/browse/TUSCANY-2388
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.1
Environment: Windows XP; IBM J2RE 1.5.0 (Build 2.3)
Reporter: Peter Kemp
Attachments: testcase.zip
1. Create a component with a java implementation, with a service defined by a
Java interface.
The parameter to the method is not a String, primitive or wrapper - rather,
it's a class containing a couple of Strings and an Integer.
2. Expose the service with a webservice binding.
3. Deploy the composite (as a WAR or embedded).
4. Retrieve the WSDL for the service (eg from
http://localhost:8080/SomeServices?wsdl).
5. Generate a web service request from the WSDL.
The runtime fails to map the web service request message to the
implementation class method parameters - it calls the correct method, but the
method parameter is null.
The test works fine when the parameter is a String.
Composite definition (some.composite):
---
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://test; xmlns:test=http://test; name=some
service name=SomeServices promote=SomeServicesComponent
binding.ws uri=http://localhost:8080/SomeServices/
/service
component name=SomeServicesComponent
implementation.java class=service.SomeServiceImpl/
service name=SomeService
interface.java interface=service.SomeService /
/service
/component
/composite
Service interface:
---
/**
*
*/
package service;
import org.osoa.sca.annotations.Remotable;
@Remotable
public interface SomeService {
public AnObject getUsingString(String stringParam);
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam);
}
Implementation:
--
package service;
import org.osoa.sca.annotations.Service;
@Service(SomeService.class)
public class SomeServiceImpl implements SomeService {
public AnObject getUsingString(String stringParam) {
System.out.println(Param value: + stringParam);
return getAnObject(stringParam);
}
private AnObject getAnObject(String stringParam) {
// TODO Auto-generated method stub
return new AnObject(stringParam + 123, 123);
}
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam) {
System.out.println(Param value: +
moreComplexParam.getStringParam());
return getAnObject(moreComplexParam.getStringParam());
}
}
MoreComplexObject.java
---
/**
*
*/
package service;
import java.io.Serializable;
public class MoreComplexObject implements Serializable{
private static final long serialVersionUID = 43242314234123L;
private String stringParam;
private Integer intParam;
private String stringParam2;
public String getStringParam() {
return stringParam;
}
public void setStringParam(String stringParam) {
this.stringParam = stringParam;
}
public Integer getIntParam() {
return intParam;
}
public void setIntParam(Integer intParam) {
this.intParam = intParam;
}
public String getStringParam2() {
return stringParam2;
}
public void setStringParam2(String stringParam2) {
this.stringParam2 = stringParam2;
}
}
AnObject.java
-
package service;
public class AnObject {
private String someRetValue;
private Integer someOtherRetValue;
public AnObject() {
}
public AnObject(String someRetValue, Integer someOtherRetValue) {
this.someRetValue = someRetValue;
this.someOtherRetValue = someOtherRetValue;
}
/**
* @return the someOtherRetValue
*/
public Integer getSomeOtherRetValue() {
return someOtherRetValue;
}
/**
* @param someOtherRetValue the
Re: Good practice for disabling/ignoring failing test cases
Since the vtest script assumes a test comment structure around
specification line numbers, I created a new script specific to this
purpose and added it to /java/etc. It scans for files named
*testCase.java and collects methods annotated with @Ignore.
I could use some help getting this automated but, in the meantime,
I'll run this scan weekly and post results to the dev-list
Here is output from tonight's scan:
-
Content generated by from C:/tuscanysvn/java/sca
Test case files scanned 2008-06-11 (svn:Revision: 663374)
* Total files processed = 591
* Total ingnored test cases = 26
The following test cases have ignored test methods ...
org.apache.tuscany.sca.itest.databindings.jaxb.DatabindingTestCase
testWSMap() , no associated jira
testWSHashMap() , no associated jira
org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase
testSCANegateByteArray() , T-2351
testWSNegateByteArray() , T-2349
org.apache.tuscany.sca.itest.references.ManualWiredReferenceTestCase
testD2Reference() , no associated jira
client.CatalogEJBClientTestCase
testCatalogEJB() , no associated jira
org.apache.tuscany.sca.vtest.assembly.ctypefile.CompomnentTypeFileTestCase
typeFile3() , T-2383
org.apache.tuscany.sca.vtest.javaapi.annotations.conversationattributes.ConversationAttributesAnnotationTestCase
singlePrincipal() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.annotations.property.PropertyAnnotationTestCase
atProperty7() , T-2289
org.apache.tuscany.sca.vtest.javaapi.annotations.reference.ReferenceAnnotationTestCase
bogusComponentName() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.annotations.scope.ScopeAnnotationTestCase
atScope1() , T-2274
atScope7() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.apis.componentcontext.ComponentContextTestCase
testGetRequestContext() , no associated jira
testServiceLookup() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.apis.exception.ExceptionTestCase
testServiceUnavailableException() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.apis.requestcontext.RequestContextTestCase
testGetSecuritySubject() , no associated jira
org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase
statefulMixedCallback() , T-2291
statelessCallback3() , T-2306
customCallback() , T-2312
org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.LifetimeTestCase
lifetime2() , T-2243
lifetime11() , T-2283
org.apache.tuscany.sca.vtest.wsbinding.nowsdl.multisoapbindings.GeneratedWSDLTestCase
testMultiSoapBindings4() , no associated jira
org.apache.tuscany.sca.vtest.wsbinding.nowsdl.soapversion.GeneratedWSDLTestCase
testSoapVersion4() , no associated jira
testSoapVersion5() , no associated jira
org.apache.tuscany.sca.vtest.wsbinding.WsdlEndpointTestCase
testWsdlEndpoint() , no associated jira
org.apache.tuscany.sca.vtest.wsbinding.WsdlServiceTestCase
testWsdlService() , T-2298
On Wed, Jun 11, 2008 at 6:42 PM, Jean-Sebastien Delfino
[EMAIL PROTECTED] wrote:
Simon Laws wrote:
On Wed, Jun 11, 2008 at 6:43 PM, Vamsavardhana Reddy [EMAIL PROTECTED]
wrote:
Thanks Raymond for pointing this out. We never used this strategy in
Geronimo (infact, I have never put any JIRA number in any of the source
files other that Release Notes may be). I have come across this in
Tuscany
source code and have been following it consistently from then on. Should
give credit to who ever started this in Tuscany :)
++Vamsi
On Wed, Jun 11, 2008 at 11:02 PM, Raymond Feng [EMAIL PROTECTED]
wrote:
Hi,
I see Vamsi uses the following strategy to disable failing unit test
cases.
@Test
@Ignore(TUSCANY-) // Ignore the test case due to JIRA TUSCANY-
public void testMySrtuff() {
}
I think it's a very good practice we should follow to maintain a clean
build while keep track of the ignored failing test cases with JIRAs.
Thanks,
Raymond
+1 good idea
Simon
+1
--
Jean-Sebastien
