Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
Hi, Are there plans to include 'spi' to the names of packages in the spi module as part of this effort ? Thanks - Venkat On 8/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Module core contains an o.a.t.sca.scope package. I'm trying to fix package names to be consistent with the module names so o.a.t.sca.scope should be renamed to o.a.t.sca.core.scope, but there's already another o.a.t.sca.core.scope in module core! What is the difference between these two packages? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1463) Support for Clob and Array fields
[ https://issues.apache.org/jira/browse/TUSCANY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521702 ] Adriano Crestani commented on TUSCANY-1463: --- Commited ; ) Amita, I had some problems applying this patch, I think it was something with my svn, than I fixed it manually. Can you please check if the tests are running as you expect? Regards, Adriano Crestani Support for Clob and Array fields - Key: TUSCANY-1463 URL: https://issues.apache.org/jira/browse/TUSCANY-1463 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1463.patch, moin-www.png http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19981.html, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20400.html Action on the issues discussed in above mails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Apache Tuscany Java DAS 1.0-incubating-beta1 released
August 21st 2007 - Apache Tuscany is pleased to announce the 1.0-incubating-beta1 release of the Java DAS project. Data Access Services (DAS) works together with Service Data Objects (SDO) simplifying handling of data when interacting with the back-end data source and frees application developers from dealing with tedious and error-prone transformation between end source types and SDO Data Object Types/properties. Key features of 1.0-incubating-beta1 release are : - Support for J2SE connections in DAS config using Driver Manager. - Added support for multiple database schemas in queries - Enhanced Optimistic Concurrency Control with overqualified updates - Multiple enhancements around ApplyChanges API - Enhanced Documentation : User, Developer and Architect guides as well as javadocs - Enhanced and new sample applications For a complete list of changes on this release, please view the release notes. https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubating-beta1/distribution/binary/RELEASE_NOTES To download Java DAS please follow the link to http://incubator.apache.org/tuscany/das-downloads.html Apache Tuscany welcomes your help. Any contribution, including code, testing, improving the documentation, or bug reporting is always appreciated. For more information on how to get involved in Apache Tuscany visit the website at: http://incubator.apache.org/tuscany. Thank you for your interest in Apache Tuscany! The Apache Tuscany Team. --- Tuscany is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the Apache Web services PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reason changed instantiation of javax.xml.stream.XMLInputFactory
Hello every body, 2 days ago, I inquired why inside class ReallySmallRuntimeBuilder method createContributionService(...), instantiation of javax.xml.stream.XMLInputFactory has been changed form XMLInputFactory xmlFactory = XMLInputFactory.newInstance(); to XMLInputFactory xmlFactory = registry.getExtensionPoint(XMLInputFactory.class); Today found this is because of the wstx-asl-3.2.1.jar inside classpath, this jar is not neessary for compile, but it has /META-INF/service/javax.xml.stream.* files which are used for the current coding style. I wish this could be of a little value for Tuscany debuggers. Good day. - Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
[jira] Commented: (TUSCANY-1463) Support for Clob and Array fields
[ https://issues.apache.org/jira/browse/TUSCANY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521721 ] Amita Vadhavkar commented on TUSCANY-1463: -- I have verified from the latest trunk code that the patch and new test cases are working fine. Regards, Amita Support for Clob and Array fields - Key: TUSCANY-1463 URL: https://issues.apache.org/jira/browse/TUSCANY-1463 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1463.patch, moin-www.png http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19981.html, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20400.html Action on the issues discussed in above mails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1463) Support for Clob and Array fields
[ https://issues.apache.org/jira/browse/TUSCANY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani resolved TUSCANY-1463. --- Resolution: Fixed Support for Clob and Array fields - Key: TUSCANY-1463 URL: https://issues.apache.org/jira/browse/TUSCANY-1463 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Assignee: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1463.patch, moin-www.png http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19981.html, http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg20400.html Action on the issues discussed in above mails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
On 8/22/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Are there plans to include 'spi' to the names of packages in the spi module as part of this effort ? Thanks - Venkat On 8/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Module core contains an o.a.t.sca.scope package. I'm trying to fix package names to be consistent with the module names so o.a.t.sca.scope should be renamed to o.a.t.sca.core.scope, but there's already another o.a.t.sca.core.scope in module core! What is the difference between these two packages? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] It would be useful for me for SPIs to be more easily identifiable. A suggestion. Given Sebastiens comment that started this thread we should be applying the name core-spi to the packages it contains. This would give us a model to follow in identifying spis, e.g. assembly-spi, contribution-spi, core-spi, binding-spi, databinding-spi etc. The alternative is to get rid of core-spi and roll the packages into the the existing modules. I would still like to see the packages identified as spis though. Doing either of these things would mean changing the current location of the spis of course. Are we ready for that kind of change? Other points Not all of the packages in core-spi are part of the SPI we declared in the CHANGES file Why are the interfaces in o.a.t.sca.scope an ex-spi? Simon
Re: [NOTICE] Brady Johnson voted as Tuscany committer
Brady, A warm welcome... Mike. Pete Robbins wrote: The Tuscany PPMC and Incubator PMC have voted for Brady to become a Tuscany committer. Congratulations and welcome Brady! I look forward to your continued excellent contributions to Tuscany. Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Jean-Sebastien, Jean-Sebastien Delfino wrote: snip Looks like option (B) is the most preferred option with: - one -1 - five +1 - one more spec compliant Do we need more technical discussion? or a new [VOTE] thread to close this issue? Thanks for a great summary. I'm happy with the conclusion. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
Sounds good to have the SPIs more easily identifiable. One thing is that the lots of individual modules structure is aimed at making Tuscany developer's lives easier and the tuscany-sca bundle jar is aimed at making Tuscany user's lives easier. Should we encourage most uses to use the bundle jar not the individual modules (as discussed on the Geronimo integration thread [1])? I think so, and then having the SPI classes identifiable from the package name not the module name sounds good from that respect. The bundle jar isn't perfect yet, there's the issue with the dependencies, I also wondered if we should split apart into something like tuscany-scdl4j and tuscany-sca-runtime so you can use the scdl4j jar if you just want to process scdl - in a tool or in an integration scenario like Synapse which wants to use its own runtime, and you use the tuscany-sca-runtime jar when you want a complete runtime like with our standalone or webapp distro or the Geronimo integration? Doing that split could help identify what the APIs and SPIs are. ...ant [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21802.html On 8/22/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, Are there plans to include 'spi' to the names of packages in the spi module as part of this effort ? Thanks - Venkat On 8/21/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Module core contains an o.a.t.sca.scope package. I'm trying to fix package names to be consistent with the module names so o.a.t.sca.scope should be renamed to o.a.t.sca.core.scope, but there's already another o.a.t.sca.core.scope in module core! What is the difference between these two packages? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unintended SCDL
Currently the result of: composite ... name=HelloWorld interface.java interface=/ ... Is an NPE. The same is true for the other extensions we have defined. This is because the code is expecting the appropriate component/service/reference/binding structure to have been read before encountering the extension Putting extensions where the code is not expecting them is unlikely to lead to the desired result and more importantly the open content in the sca model expects namespace=##other and currently all of the extensions are in the sca namespace. I'm going to change the code to report an error in this case. Simon
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
On 8/22/07, Simon Laws [EMAIL PROTECTED] wrote: snip Doing either of these things would mean changing the current location of the spis of course. Are we ready for that kind of change? We're planning on cutting the branch for the release tomorrow so I'm not at all keen for a change like this to happen for that :) Post 1.0 we need to keep the SPIs stable so its really between now and 1.0 for our final opportunity to come up with a structure and SPIs we're all happy with. I think we're ready for a clean up like this so should have a go at doing it. ...ant
Re: Spec clarification for conversational/callback semantics: Reply #2
Mike Edwards wrote: Simon, Yes, you've hit one of the parts of the Java spec that makes me least comfortable. The idea of sending around a reference for others to use is not something that fills me with joy, when that reference is essentially a reference to an instance. I feel the religious debates about WS-Addressing coming on Once instances can disappear in a puff of smoke, this whole area of function gets to be very uncomfortable. Furthermore, if you did the passing around in the case of a callback service, who does the provider get to talk with??? I think the callback endpoint should be part of the service reference that is passed around. We have to support the capability to do this for the case where setCallback() was called on the service reference, passing a callback object that is a service reference. The receiver of the reference may not support the callback interface itself, so it wouldn't work in general to say that the callback target is the receiver of the service reference. If we do this, it would be good to allow the receiver of the service reference to redirect callbacks to itself if it has the capability to support them. It seems that setCallback() could be used for this purpose, but there is a slight difficulty in how to create the service reference that would be passed to setCallback(). It could be a self-reference that was created by ComponentContext.createSelfReference(myCallbackInterface) where myCallbackInterface is the callback interface of a reference of the component, but it's not clear that this will work given that the callback is not a real service. A similar issue applies to all uses of ServiceReference.setCallback(aServiceReference) even when service references are not being passed around. Does aServiceReference represent a regular service (non-callback) that supports the callback interface, or does it represent a callback pseudo-service that was created under the covers for a reference with a callback interface, or can it be either of these? The concept of a callback pseudo-service is currently something in the Tuscany implementation and not in the spec, but it seems that the spec needs to clarify whether or not a callback reference can be used to create a service reference for use in this way. And if this can be done, is this service reference usable for regular calls or only for callbacks? Simon Simon Laws wrote: Yes, I think so. From a specification point of view I was worrying about the expected timescale of resource removal. Your assertion that it means that the conversation cannot be reused clarifies this point. I'm not sure I agree with the MAY in the sentence depending on the implementation of the comms mechanism between client and provider that MAY require some additional communication to travel from the client side to the provider side.. I can't square this away easily with the requirement of section 1.6.3 of the Java Annotations and API spec to allow for the passing of conversational services as parameters where, if I understand it correctly, a third party could be holding a reference to a conversation for which the original client now calls Conversation.end(). Here a timeout is not good enough and the service should be aware that the conversation has ended. I suppose the MAY clause can be seen as being associated with whether any references have been copied or not. If not, there are no worries. At least the sending of a reference can in principle be detected since it can't be used unless instantiated by some (SCA) runtime. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1568) tuscany-sca bundle jar clean up
tuscany-sca bundle jar clean up --- Key: TUSCANY-1568 URL: https://issues.apache.org/jira/browse/TUSCANY-1568 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-Next Reporter: ant elder Fix For: Java-SCA-Next Clean up the tuscany-sca bundle jar built by thats built in the distribution. For example: - fix the dependencies so you can do something like: dependency groupIdorg.apache.tuscany/groupId artifactIdtuscany-sca/artifactId version1.0-incubating/version /dependency and that would cause including all all the necessary transitive dependencies to have a minimal runtime work. Other dependencies for non-essential extensions would be optional so if you want to use those extensions then you add more dependency elements for them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
So not much consensus on what to do with this yet. The binary distro is currently coming in at 107MB. Of that the following 5 samples and demo's account for about 50MB: demo-allert-aggregator.war demo-mortgage-creditcheck.war sample-helloworld-ws-sdo-webapp.war sample-helloworld-ws-service-webapp.war sample-calculator-webapp-ws.war Should we delete these, keep these, delete some of these, keep but don't distribute pre-built artifacts? The three samples are quite similar so i think at least one maybe two of them could be removed for this release and then look at just having simple SCA contribution jar's for the samples and demo's for 1.0. (at least one of these was contributed by a user so we should try to keep that one) ...ant On 8/14/07, Luciano Resende [EMAIL PROTECTED] wrote: So, let me try to understand this. We are going to remove the -webapp samples from the release binary distribution (due to size constrains), but we are still going to continue supporting the -webapp story. Users can still see these samples on the source distributions, right ? I'm asking this because I think that our users DO use Tuscany in the scenario of a -webapp, and if we are going to remove the -webapp samples, users that are evaluating the new release might think we removed the webapp support, so we need to be clear. If the webapp story is changing, then we should document (wiki) and test so our users can migrate to the new story. If this requires implementation.web I'd think we should implement these changes when it's ready. As an alternative approach, what about creating a samples-webapp distro ? On 8/14/07, ant elder [EMAIL PROTECTED] wrote: On 8/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Anderson, Jeff T (CA - Toronto) wrote: I like having the samples, in the absence of extensive documentation these are key to understanding Tuscany... I like the idea of packaging the samples as simple SCA contribution jar's. I think keeping the footprint as little as possible is important, both in terms of optics and managing the complexity and understanding. Just my humble opinion... Jeff +1 to keep the samples as simple SCA contribution JARs. The current webapp packaging is not quite right anyway as it's introducing a half baked mix of J2EE and SCA programming model inside the webapp. I'd suggest the following: - Package SCA sample components as simple SCA contribution JARs, stay away from webapps. - To allow JSP and servlets to invoke SCA service component, support implementation.web Web components as described in [1]. [1] http://www.osoa.org/pages/viewpage.action?pageId=3980 (now back on the dev list) Just to make sure I understand, as an example right now we have sample-helloworld-ws-service and sample-helloworld-ws-service-webapp, do we just delete the -webapp one? Yes And then you can use the jar built by the sample-helloworld-ws-service with either the the Geronimo/Tuscany integration or our webapp runtime or with the standalone runtime we already use it with today? That sounds like the way to go to me but that seems like quite a big change, do we want to try to get this done in time for the upcoming release or wait till after that and just make the changes for 1.0? ...ant I prefer to do it now. I'm not quite sure why it's a big change? Isn't it just about deleting Maven modules? we have equivalent samples already working with the standalone runtime right? Is the Geronimo integration ready to be included in the the release? -- Jean-Sebastien I also think sooner would be better so happy to help go for it. The list of current webapps is: demo-alert-aggregator demo-mortgage-creditcheck sample-calculator-webapp sample-chat-webapp sample-helloworld-dojo sample-helloworld-jsonrpc sample-helloworld-ws-sdo-webapp sample-helloworld-ws-service-webapp Not sure we do have equivalent non-webapp samples for all those, i'll have a go at and seeing if they all those sample- ones run ok out side of a webapp. ..ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Model printing - Causing problems in binding-sca-axis2
Changes overnight mean that the tests for the remote version of the sca binding don't run. CompositeActivator.addReferenceBindingProvider(RuntimeComponent, RuntimeComponentReference, Binding) Is now deferred until someone gets the runtime wires from the component reference. Here are the unfortunate events that cause the remote tests to fail. In the remote case a warning is printed to say that the target is not found Some new logging code prints out the model in this case The method for getting the runtime wires is getRuntimeWires which the model printer calls as a property getter This call builds the reference wires before all of the model information has been loaded. So I've commented out the model printing for now. But we need to think about the location of this wire initialization code. Simon
[jira] Closed: (TUSCANY-1566) Element coming out in the wrong namespace
[
https://issues.apache.org/jira/browse/TUSCANY-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Peters closed TUSCANY-1566.
---
I have tested the fix in the cpp-pre2.1 branch and it is indeed fixed. Thanks.
Element coming out in the wrong namespace
-
Key: TUSCANY-1566
URL: https://issues.apache.org/jira/browse/TUSCANY-1566
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-Next
Environment: WinXP
Reporter: Matthew Peters
Fix For: Cpp-Next
Attachments: Atom1.0.xsd
We have a schema file that defines an atom feed. It specified
elementFormDefault=qualified so that lower level elements should be in the
target namespace. I will attach the schema as a separate file. With a very
simple php test case as follows:
$xmldas = SDO_DAS_XML::create('Atom1.0.xsd');
$document = $xmldas-createDocument('http://www.w3.org/2005/Atom','entry');
$entry = $document-getRootDataObject();
$author = $entry-createDataObject('author');
$author-name[] = Caroline Maynard;
print $xmldas-saveString($document,2);
we get
?xml version=1.0 encoding=UTF-8?
tns:entry xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:tns=http://www.w3.org/2005/Atom;
tns:author
nameCaroline Maynard/name
/tns:author
/tns:entry
whereas we should see the name element in the tns namespace.
I have checked this with XERCES: the xml that we are generating will not
validate, whereas if I alter it to have name in the tns namespace it will.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1564) xsi:type not always set for complexTypes
[
https://issues.apache.org/jira/browse/TUSCANY-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Peters closed TUSCANY-1564.
---
Resolution: Fixed
I have tested the fix in the cpp-pre2.1 branch and it is indeed fixed. Thanks.
xsi:type not always set for complexTypes
Key: TUSCANY-1564
URL: https://issues.apache.org/jira/browse/TUSCANY-1564
Project: Tuscany
Issue Type: Bug
Components: C++ SDO
Affects Versions: Cpp-Next
Environment: Win XP and Gentoo Linux
Reporter: Matthew Peters
Fix For: Cpp-Next
This has been reported by a user of the PHP SDO code. I have verified that he
is right - the problem does exist. I will cut and paste in the PHP example
from the defect http://pecl.php.net/bugs/bug.php?id=11774 but the php-ness of
the example is irrelevant: under the covers we are just manipulating a C++
SDO and then calling XMLHelper-save()
In the defect text below he puts in both expected and actual output. He is
right to raise the problem in the sense that I have tried reading in the
actual and expected xml under XERCES with schema validation turned on, and
the actual will *not* validate whereas the expected will.
Incidentally there is some history w.r.t. xsi:types - in a different case
they were coming out when we did not want them and they were suppressed for
us. See for example JIRA 1297. I do not know the rules which should determine
whether it should be present or not.
Here follows the original PHP defect.
Description:
xsi:type is not always set for complexTypes. Notice the absence of
xsi:type=collectionInfo in the actual output.
Reproduce code:
---
?xml version=1.0 encoding=UTF-8?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=request type=requestType/
xsd:complexType name=requestType abstract=true/
xsd:complexType name=collectionInfo
xsd:complexContent
xsd:extension base=requestType
xsd:sequence minOccurs=0 maxOccurs=unbounded
xsd:element name=collection/
/xsd:sequence
xsd:attribute name=kind type=xsd:string
fixed=collectionInfo/
/xsd:extension
/xsd:complexContent
/xsd:complexType
xsd:element name=request-list
xsd:complexType
xsd:sequence
xsd:element ref=request minOccurs=0 maxOccurs=unbounded/
/xsd:sequence
/xsd:complexType
/xsd:element
/xsd:schema
?php
try {
$xmldas = SDO_DAS_XML::create(request.xsd);
try {
$doc = $xmldas-createDocument('', 'request-list');
$rdo = $doc-getRootDataObject();
$request = $xmldas-createDataObject('', 'collectionInfo');
$request-collection-insert('Blah');
$request-kind = 'collectionInfo';
$rdo-request-insert($request);
print($xmldas-saveString($doc));
} catch (SDO_Exception $e) {
print($e);
}
} catch (SDO_Exception $e) {
print(Problem creating an XML document: . $e-getMessage());
}
?
Expected result:
?xml version=1.0 encoding=UTF-8?
request-list xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
request kind=collectionInfo xsi:type=collectionInfo
collectionBlah/collection
/request
/request-list
Actual result:
--
?xml version=1.0 encoding=UTF-8?
request-list xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
request kind=collectionInfo
collectionBlah/collection
/request
/request-list
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1569) Minor fixes for implementation.osgi
Minor fixes for implementation.osgi Key: TUSCANY-1569 URL: https://issues.apache.org/jira/browse/TUSCANY-1569 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Update pom.xml and felix.config.properties in itest/osgi-implementation to use the latest bundles. Add OSGiImplementation.equals method to check bundle location and properties. There is an exception thrown during Felix shutdown by one of the tests in itest. This exception does not cause a test failure, and has been raised as a Felix bug (https://issues.apache.org/jira/browse/FELIX-341). --- Exception with component : Unexpected problem executing task --- java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:105) at org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503) at org.apache.felix.scr.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:369) at org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55) at org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java:176) at org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1569) Minor fixes for implementation.osgi
[ https://issues.apache.org/jira/browse/TUSCANY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajini Sivaram updated TUSCANY-1569: Attachment: modules-implementation-osgi-patch.txt itest-osgi-implementation-patch.txt Minor fixes for implementation.osgi Key: TUSCANY-1569 URL: https://issues.apache.org/jira/browse/TUSCANY-1569 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-implementation-osgi-patch.txt Update pom.xml and felix.config.properties in itest/osgi-implementation to use the latest bundles. Add OSGiImplementation.equals method to check bundle location and properties. There is an exception thrown during Felix shutdown by one of the tests in itest. This exception does not cause a test failure, and has been raised as a Felix bug (https://issues.apache.org/jira/browse/FELIX-341). --- Exception with component : Unexpected problem executing task --- java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:105) at org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503) at org.apache.felix.scr.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:369) at org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55) at org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java:176) at org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
EJB binding still using OPENEJB snapshot
The ejb binding is still has a dependency on an openejb snapshot jar. I can't see a 3.0.0 released version of openejb anywhere, am i looking in the wrong place? If not what would be the implications of rolling back the ejb binding to not depend on this snapshot? ...ant
Re: Release management for next release, was: SCA 0.92 release?
Please review the current distributions so we've a good shot and getting an RC1 on friday that passes. You can build the absolute latest distro's yourself from sca/distribution or I'm right now uploading pre-built ones to http://people.apache.org/~antelder/tuscany/SNAPSHOT/. This isn't complete and there's still a lot to fix up so don't expect perfection yet but if you see major issues please point them out. ...ant On 8/21/07, ant elder [EMAIL PROTECTED] wrote: On 8/19/07, ant elder [EMAIL PROTECTED] wrote: On 8/13/07, ant elder [EMAIL PROTECTED] wrote: On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Simon Laws wrote: +1 for 21st as the target. Can I suggest we take some time (assuming there is some) on the 20th to test the samples and check through the readmes etc before taking the branch. We could probably get a stable distribution available on the 20th, and we would check that. That sounds like a good plan, i'll continue with some tidy up this week aiming to get distribution out for the 20th. ...ant Just a reminder that this plan is still on target, i'll get an example stable distribution out tomorrow for review then cut a branch on the 21st, and an RC out for voting on by the 23rd. If you've changes planned you want included please get them committed ASAP, if the change is more than trivial raising a JIRA now for the release would be a help so we all know whats coming. ...ant A bunch off us had an off-list discussion about this and as we're not quite ready i'll hold off cutting the branch till Thursday and get an RC1 out by Friday the 24th. ...ant
binding-ws-axis2 callback processing
In Axis2ReferenceBindingProvider constructor there is some code that looks
for the callback associated with the reference, if there is one, to get the
binding. From this it ultimately determines the from address for outgoing
messages.
// look for a matching callback binding
WebServiceBinding callbackBinding = null;
if (reference.getCallback() != null) {
for (Binding binding : reference.getCallback().getBindings()) {
if (binding instanceof WebServiceBinding) {
// set the first compatible callback binding
callbackBinding = (WebServiceBinding)binding;
continue;
}
}
}
In the case where the callback information is inferred from the
implementation rather than explicitly included in the SCDL the callback
model object on the reference is incomplete, i.e. there is no binding
information, but the callback service runtime object appears to be complete.
So we either need to ensure that the model is up to date in these situations
or that we go get the required information from the callback service. If it
is generally the case that the model is an accurate reflection of the
current runtime objects then we should make sure the model is updated.
Thoughts?
Regards
Simon
Re: SCA distribution is really big now
On 8/22/07, ant elder [EMAIL PROTECTED] wrote: So not much consensus on what to do with this yet. The binary distro is currently coming in at 107MB. Of that the following 5 samples and demo's account for about 50MB: demo-allert-aggregator.war demo-mortgage-creditcheck.war sample-helloworld-ws-sdo-webapp.war sample-helloworld-ws-service-webapp.war sample-calculator-webapp-ws.war Should we delete these, keep these, delete some of these, keep but don't distribute pre-built artifacts? The three samples are quite similar so i think at least one maybe two of them could be removed for this release and then look at just having simple SCA contribution jar's for the samples and demo's for 1.0. (at least one of these was contributed by a user so we should try to keep that one) ...ant On 8/14/07, Luciano Resende [EMAIL PROTECTED] wrote: So, let me try to understand this. We are going to remove the -webapp samples from the release binary distribution (due to size constrains), but we are still going to continue supporting the -webapp story. Users can still see these samples on the source distributions, right ? I'm asking this because I think that our users DO use Tuscany in the scenario of a -webapp, and if we are going to remove the -webapp samples, users that are evaluating the new release might think we removed the webapp support, so we need to be clear. If the webapp story is changing, then we should document (wiki) and test so our users can migrate to the new story. If this requires implementation.web I'd think we should implement these changes when it's ready. As an alternative approach, what about creating a samples-webapp distro ? On 8/14/07, ant elder [EMAIL PROTECTED] wrote: On 8/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/14/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Anderson, Jeff T (CA - Toronto) wrote: I like having the samples, in the absence of extensive documentation these are key to understanding Tuscany... I like the idea of packaging the samples as simple SCA contribution jar's. I think keeping the footprint as little as possible is important, both in terms of optics and managing the complexity and understanding. Just my humble opinion... Jeff +1 to keep the samples as simple SCA contribution JARs. The current webapp packaging is not quite right anyway as it's introducing a half baked mix of J2EE and SCA programming model inside the webapp. I'd suggest the following: - Package SCA sample components as simple SCA contribution JARs, stay away from webapps. - To allow JSP and servlets to invoke SCA service component, support implementation.web Web components as described in [1]. [1] http://www.osoa.org/pages/viewpage.action?pageId=3980 (now back on the dev list) Just to make sure I understand, as an example right now we have sample-helloworld-ws-service and sample-helloworld-ws-service-webapp, do we just delete the -webapp one? Yes And then you can use the jar built by the sample-helloworld-ws-service with either the the Geronimo/Tuscany integration or our webapp runtime or with the standalone runtime we already use it with today? That sounds like the way to go to me but that seems like quite a big change, do we want to try to get this done in time for the upcoming release or wait till after that and just make the changes for 1.0? ...ant I prefer to do it now. I'm not quite sure why it's a big change? Isn't it just about deleting Maven modules? we have equivalent samples already working with the standalone runtime right? Is the Geronimo integration ready to be included in the the release? -- Jean-Sebastien I also think sooner would be better so happy to help go for it. The list of current webapps is: demo-alert-aggregator demo-mortgage-creditcheck sample-calculator-webapp sample-chat-webapp sample-helloworld-dojo sample-helloworld-jsonrpc sample-helloworld-ws-sdo-webapp sample-helloworld-ws-service-webapp Not sure we do have equivalent non-webapp samples for all those, i'll have a go at and seeing if they all those sample- ones run ok out side of a webapp. ..ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] If the build scripts work I would go for leaving them in but not distributing the war. I don't think removing one
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
ant elder wrote: On 8/22/07, Simon Laws [EMAIL PROTECTED] wrote: snip Doing either of these things would mean changing the current location of the spis of course. Are we ready for that kind of change? We're planning on cutting the branch for the release tomorrow so I'm not at all keen for a change like this to happen for that :) Post 1.0 we need to keep the SPIs stable so its really between now and 1.0 for our final opportunity to come up with a structure and SPIs we're all happy with. I think we're ready for a clean up like this so should have a go at doing it. ...ant +1 for not making that kind of change now. I'm simply going through modules and making sure that their packages contain enough of the module names, but I'm happy enough for now with core-spi containing org.apache.tuscany.sca.core.* or contribution-impl containing org.apache.tuscany.contribution.service.util for example. While this new thread of thoughts about reorganizing the whole set of SPIs and modules that contain them is interesting, I was a little surprised to see my little question about sca.scope and vs sca.core.scope start such an interesting discussion :) and I don't have any good ideas about it at the moment, so I'll try to comment on the subject... but later, probably after the 0.99 release. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
ant elder wrote: So not much consensus on what to do with this yet. The binary distro is currently coming in at 107MB. Of that the following 5 samples and demo's account for about 50MB: demo-allert-aggregator.war demo-mortgage-creditcheck.war sample-helloworld-ws-sdo-webapp.war sample-helloworld-ws-service-webapp.war sample-calculator-webapp-ws.war Should we delete these, keep these, delete some of these, keep but don't distribute pre-built artifacts? The three samples are quite similar so i think at least one maybe two of them could be removed for this release and then look at just having simple SCA contribution jar's for the samples and demo's for 1.0. (at least one of these was contributed by a user so we should try to keep that one) ...ant This is obviously an issue that we need to fix now. I have two questions: - Why are they so big? isn't that a problem in the samples themselves? - If all WARs hosting Tuscany apps are going to be so big, isn't that going to be a problem for a our users as soon as they create two or three of this WARs? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB binding still using OPENEJB snapshot
Hi, I looked into this dependency last night as I was hoping the release of Geronimo 2.0.1 could help us move to a stable level of OPENEJB. Here is what I found out: a) The Geronimo 2.0.1 release depends on a fixed revision (3.0.0-r562820) [1] of OPENEJB 3.0.0 stream, but it is not an official release. I'll investigate more when the G 2.0.1 artifacts show up in the maven repo. b) Our dependency on OPENEJB is a test dependency. Would it be possible to disable the test case so that we release it without SNAPSHOT dependencies? Thanks, Raymond [1] http://svn.apache.org/repos/asf/geronimo/server/tags/2.0.1/pom.xml - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Wednesday, August 22, 2007 6:53 AM Subject: EJB binding still using OPENEJB snapshot The ejb binding is still has a dependency on an openejb snapshot jar. I can't see a 3.0.0 released version of openejb anywhere, am i looking in the wrong place? If not what would be the implications of rolling back the ejb binding to not depend on this snapshot? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB binding still using OPENEJB snapshot
If it comes to (b) then that sounds ok to me, better than not including the ejb binding in the release anyway. ...ant On 8/22/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I looked into this dependency last night as I was hoping the release of Geronimo 2.0.1 could help us move to a stable level of OPENEJB. Here is what I found out: a) The Geronimo 2.0.1 release depends on a fixed revision (3.0.0-r562820) [1] of OPENEJB 3.0.0 stream, but it is not an official release. I'll investigate more when the G 2.0.1 artifacts show up in the maven repo. b) Our dependency on OPENEJB is a test dependency. Would it be possible to disable the test case so that we release it without SNAPSHOT dependencies? Thanks, Raymond [1] http://svn.apache.org/repos/asf/geronimo/server/tags/2.0.1/pom.xml - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Wednesday, August 22, 2007 6:53 AM Subject: EJB binding still using OPENEJB snapshot The ejb binding is still has a dependency on an openejb snapshot jar. I can't see a 3.0.0 released version of openejb anywhere, am i looking in the wrong place? If not what would be the implications of rolling back the ejb binding to not depend on this snapshot? ...ant
[jira] Assigned: (TUSCANY-1569) Minor fixes for implementation.osgi
[ https://issues.apache.org/jira/browse/TUSCANY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-1569: -- Assignee: ant elder Minor fixes for implementation.osgi Key: TUSCANY-1569 URL: https://issues.apache.org/jira/browse/TUSCANY-1569 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: ant elder Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-implementation-osgi-patch.txt Update pom.xml and felix.config.properties in itest/osgi-implementation to use the latest bundles. Add OSGiImplementation.equals method to check bundle location and properties. There is an exception thrown during Felix shutdown by one of the tests in itest. This exception does not cause a test failure, and has been raised as a Felix bug (https://issues.apache.org/jira/browse/FELIX-341). --- Exception with component : Unexpected problem executing task --- java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:105) at org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503) at org.apache.felix.scr.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:369) at org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55) at org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java:176) at org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Model printing - Causing problems in binding-sca-axis2
Hi, Thank you for catching this. Using the getters to dump objects seems to be destructive in some cases. I'll add a field introspection based approach to the PrintUtil. Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Wednesday, August 22, 2007 5:29 AM Subject: Model printing - Causing problems in binding-sca-axis2 Changes overnight mean that the tests for the remote version of the sca binding don't run. CompositeActivator.addReferenceBindingProvider(RuntimeComponent, RuntimeComponentReference, Binding) Is now deferred until someone gets the runtime wires from the component reference. Here are the unfortunate events that cause the remote tests to fail. In the remote case a warning is printed to say that the target is not found Some new logging code prints out the model in this case The method for getting the runtime wires is getRuntimeWires which the model printer calls as a property getter This call builds the reference wires before all of the model information has been loaded. So I've commented out the model printing for now. But we need to think about the location of this wire initialization code. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1569) Minor fixes for implementation.osgi
[ https://issues.apache.org/jira/browse/TUSCANY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1569. -- Resolution: Fixed Patch applied, thanks for the code Rajini. Minor fixes for implementation.osgi Key: TUSCANY-1569 URL: https://issues.apache.org/jira/browse/TUSCANY-1569 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: ant elder Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-implementation-osgi-patch.txt Update pom.xml and felix.config.properties in itest/osgi-implementation to use the latest bundles. Add OSGiImplementation.equals method to check bundle location and properties. There is an exception thrown during Felix shutdown by one of the tests in itest. This exception does not cause a test failure, and has been raised as a Felix bug (https://issues.apache.org/jira/browse/FELIX-341). --- Exception with component : Unexpected problem executing task --- java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:105) at org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503) at org.apache.felix.scr.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:369) at org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55) at org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java:176) at org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] What's next for Tuscany DAS ?
With the DAS beta1 release out, I'd like to look forward to things that we want to do next for DAS. I think that there are still couple things that we can improve our core DAS features, the main one would be adding support for multiple DAS implementations, and review our SDO 2.1 APIs usage. As for our history with SCA integration, we have started efforts around Data Services/Declarative DAS (implementation.das) and Data Feeds (implementation.data), and this is probably another area we would like to continue to work going forward. I also think we should continue to improve our user documentation and distribution infrastructure to make our release cut easier. Below is a summary list of items and JIRAs that are related to these possible items : - TUSCANY-986 - DAS integration with SDO 2.1 APIs - TUSCANY-961 - DAS: Using deprected SDO method causes Type lookup failure - Refactoring DAS to allow multiple implementatons As for timeframe, maybe it would be good to have a release in the next couple weeks, to support SDO 1.0 and be available to the SCA release, so we can have the integration story with SCA available. This is just of brain dump of where my thinking is at the moment, I'm sure everyone has their own thoughts about things we should tackle. It would be good to get to them all on the table :-) Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1569) Minor fixes for implementation.osgi
[ https://issues.apache.org/jira/browse/TUSCANY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1569: - Assignee: Raymond Feng (was: ant elder) Minor fixes for implementation.osgi Key: TUSCANY-1569 URL: https://issues.apache.org/jira/browse/TUSCANY-1569 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: Raymond Feng Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-implementation-osgi-patch.txt Update pom.xml and felix.config.properties in itest/osgi-implementation to use the latest bundles. Add OSGiImplementation.equals method to check bundle location and properties. There is an exception thrown during Felix shutdown by one of the tests in itest. This exception does not cause a test failure, and has been raised as a Felix bug (https://issues.apache.org/jira/browse/FELIX-341). --- Exception with component : Unexpected problem executing task --- java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:105) at org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503) at org.apache.felix.scr.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:369) at org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55) at org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java:176) at org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
Raymond Feng wrote: Hi, The o.a.t.sca.scope contains the interfaces/classes which used to be SPIs while the o.a.t.sca.core.scope contains implementation classes. Thanks, Raymond What you said here quickly started a whole new discussion about SPIs :) but I'd like to make I understand exactly what you meant, since the packages I'm talking about are not in the list of SPIs in our CHANGES file... By which used to be SPIs, did you mean which used to be SPIs before we modularized the whole kernel 5 months ago, but are not SPIs now I guess, since they are in the core module and are not listed in the SPI section of our CHANGES file? Is that what you meant? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
On 8/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: So not much consensus on what to do with this yet. The binary distro is currently coming in at 107MB. Of that the following 5 samples and demo's account for about 50MB: demo-allert-aggregator.war demo-mortgage-creditcheck.war sample-helloworld-ws-sdo-webapp.war sample-helloworld-ws-service-webapp.war sample-calculator-webapp-ws.war Should we delete these, keep these, delete some of these, keep but don't distribute pre-built artifacts? The three samples are quite similar so i think at least one maybe two of them could be removed for this release and then look at just having simple SCA contribution jar's for the samples and demo's for 1.0. (at least one of these was contributed by a user so we should try to keep that one) ...ant This is obviously an issue that we need to fix now. I have two questions: - Why are they so big? isn't that a problem in the samples themselves? - If all WARs hosting Tuscany apps are going to be so big, isn't that going to be a problem for a our users as soon as they create two or three of this WARs? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The previous posts to this thread have established that there are concerns with 1 - what is in the war that is build from these samples - currently all of the tuscany jars required 2 - the mechanism in which web apps are built using tuscany - currently using host-webapp 2 first. Sebastien has suggested that we follow the approach outlined in the link he provided [1] Its not clear to me that this implies that the war file goes but certainly the mechansim by which servlets, jsps are connected to tuscany change. The war file might have to go to make the mvn build work but that's a slightly different issue I believe. If I understand correctly running a sample in this mode would be a two phase process. a) install tuscany support into you favourite app server host-geronimo, host-tomcat b) deploy ear, war, jars to the tuscany runtime(s) provided as part of this integration, e.g ant's hot update runtime is an example of how this could be done 1 in this case all of the runtime jars will be moved out of the sample war/jar and into the hosting adapater. That leaves just the sample files and web resources. Doing 1 is a relatively straightforward exercise of refactoring the current war into a slimmed down version. I'm still not convinced that it's a good idea to remove the webapp samples and compress everything into a small number of samples Doing 2 properly is a little more time consuming. Anyone given any thought to host-tomcat (I realize the geronimo integration is in the pipeline) or to implementation.web. Can we use the implementation.resource as a basis? As the document at [1] is subject to change maybe we can still use the host-webapp approach but just take ant's webapp distribution approach and separate the samples from packaging all the jars. At least that way we start to move toward the right model .I could spend a little time on this but if someone is a way down the path I don't want to repeat effort. Simon [1] http://www.osoa.org/pages/viewpage.action?pageId=3980
Re: binding-ws-axis2 callback processing
I don't think we should go down the path of copying all the runtime
information back into the model. In this specific case, omitting
explicit callback binding information from the model means that the
implementation runtime can make a choice. So there is no inconsistency
with the runtime having more information than is explicitly stored in
the model. A similar case would be a WSDL-less Web Service binding,
which I would expect to keep more information around at runtime than
is explictly stored in the model. There are probably other cases
as well.
I'd suggest changing the code listed below to use runtime objects
(i.e., the service returned by calling getCallbackService() on the
reference) rather than model objects.
Simon
Simon Laws wrote:
In Axis2ReferenceBindingProvider constructor there is some code that looks
for the callback associated with the reference, if there is one, to get the
binding. From this it ultimately determines the from address for outgoing
messages.
// look for a matching callback binding
WebServiceBinding callbackBinding = null;
if (reference.getCallback() != null) {
for (Binding binding : reference.getCallback().getBindings()) {
if (binding instanceof WebServiceBinding) {
// set the first compatible callback binding
callbackBinding = (WebServiceBinding)binding;
continue;
}
}
}
In the case where the callback information is inferred from the
implementation rather than explicitly included in the SCDL the callback
model object on the reference is incomplete, i.e. there is no binding
information, but the callback service runtime object appears to be complete.
So we either need to ensure that the model is up to date in these situations
or that we go get the required information from the callback service. If it
is generally the case that the model is an accurate reflection of the
current runtime objects then we should make sure the model is updated.
Thoughts?
Regards
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1500) Many callback tests don't run
[ https://issues.apache.org/jira/browse/TUSCANY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1500: Attachment: patch1 Here is patch1 for this JIRA. It enables the callback-api test in the build and gets it working. Here's a summary of the changes in this patch. 1. Rename CallBackApiTestCaseFIXME.java to CallBackApiTestCase.java. (NOTE: This must be done manually before applying the patch, which contains an update to CallBackApiTestCase.java.) 2. Change the class name for the test from CallBackApiTestCaseFIXME to CallBackApiTestCase. 3. Change the test code that gets the callable reference to use the correct spec APIs. 4. Move the code in JDKCallbackInvocationHandler that clones and binds the selected dynamic wire into CallbackWireObjectFactory so that it can be executed when callable references are created as when as when callback invocations are made. 5. Restore the factory.resolveTarget() call in RequestContextImpl.getCallbackReference() that was commented out. This selects a wire and endpoint for the callback so that this becomes part of the callable reference. 6. Make RequestContextImpl.getCallbackReference() return a CallableReferenceImpl object instead of a service reference. (This was being done previously but was inadvertently changed by an overlapping update.) 7. Restrict the constructors in CallableReferenceImpl to protected as we don't want to open up direct instantiation of these objects to application code. I am looking at the other failing callback tests and I will post further patches to get them working. Many callback tests don't run - Key: TUSCANY-1500 URL: https://issues.apache.org/jira/browse/TUSCANY-1500 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: patch1 The following itests are currently disabled in the build. If they are enabled by changing the name of the test class from xxxTest to xxxTestCase, they fail with various errors. callback-api callback-complex-type callback-id callback-set-callback callback-set-conversation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1500) Many callback tests don't run
[ https://issues.apache.org/jira/browse/TUSCANY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1500: Patch Info: [Patch Available] Many callback tests don't run - Key: TUSCANY-1500 URL: https://issues.apache.org/jira/browse/TUSCANY-1500 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: patch1 The following itests are currently disabled in the build. If they are enabled by changing the name of the test class from xxxTest to xxxTestCase, they fail with various errors. callback-api callback-complex-type callback-id callback-set-callback callback-set-conversation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release management for next release, was: SCA 0.92 release?
Running calculator-script using the distribution, I see the following message. Result is OK, but this seems to be complaining about some package. I also saw this when I tried to run the same sample from within eclipse : sys-package-mgr*: can't create package cache dir, 'C:\tuscany-new\s ca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\lib\jython-2.2-beta2.jar\cachedir\pa ckages' === Result I see running ant run: Buildfile: build.xml run: [java] 3 + 2=5.0 [java] 3 - 2=1.0 [java] *sys-package-mgr*: can't create package cache dir, 'C:\tuscany-new\s ca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\lib\jython-2.2-beta2.jar\cachedir\pa ckages' [java] 3 * 2=6.0 [java] 3 / 2=1.5 BUILD SUCCESSFUL Total time: 7 seconds C:\tuscany-new\sca-dist\tuscany- sca-1.0-incubating-SNAPSHOT\samples\calculator-s On 8/22/07, ant elder [EMAIL PROTECTED] wrote: Please review the current distributions so we've a good shot and getting an RC1 on friday that passes. You can build the absolute latest distro's yourself from sca/distribution or I'm right now uploading pre-built ones to http://people.apache.org/~antelder/tuscany/SNAPSHOT/. This isn't complete and there's still a lot to fix up so don't expect perfection yet but if you see major issues please point them out. ...ant On 8/21/07, ant elder [EMAIL PROTECTED] wrote: On 8/19/07, ant elder [EMAIL PROTECTED] wrote: On 8/13/07, ant elder [EMAIL PROTECTED] wrote: On 8/13/07, Luciano Resende [EMAIL PROTECTED] wrote: Simon Laws wrote: +1 for 21st as the target. Can I suggest we take some time (assuming there is some) on the 20th to test the samples and check through the readmes etc before taking the branch. We could probably get a stable distribution available on the 20th, and we would check that. That sounds like a good plan, i'll continue with some tidy up this week aiming to get distribution out for the 20th. ...ant Just a reminder that this plan is still on target, i'll get an example stable distribution out tomorrow for review then cut a branch on the 21st, and an RC out for voting on by the 23rd. If you've changes planned you want included please get them committed ASAP, if the change is more than trivial raising a JIRA now for the release would be a help so we all know whats coming. ...ant A bunch off us had an off-list discussion about this and as we're not quite ready i'll hold off cutting the branch till Thursday and get an RC1 out by Friday the 24th. ...ant
Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope
Hi, Sebastien. You're right on what I meant used to be. IMO, these are in the grey areas as we're not very sure if we should extend the scoping support for other component implementation types. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 22, 2007 9:24 AM Subject: Re: Difference between o.a.t.sca.scope and o.a.t.sca.core.scope Raymond Feng wrote: Hi, The o.a.t.sca.scope contains the interfaces/classes which used to be SPIs while the o.a.t.sca.core.scope contains implementation classes. Thanks, Raymond What you said here quickly started a whole new discussion about SPIs :) but I'd like to make I understand exactly what you meant, since the packages I'm talking about are not in the list of SPIs in our CHANGES file... By which used to be SPIs, did you mean which used to be SPIs before we modularized the whole kernel 5 months ago, but are not SPIs now I guess, since they are in the core module and are not listed in the SPI section of our CHANGES file? Is that what you meant? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1569) Minor fixes for implementation.osgi
[ https://issues.apache.org/jira/browse/TUSCANY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1569: - Assignee: ant elder (was: Raymond Feng) Assigned it back to Ant as he has already applied the patch. Minor fixes for implementation.osgi Key: TUSCANY-1569 URL: https://issues.apache.org/jira/browse/TUSCANY-1569 Project: Tuscany Issue Type: Bug Components: Java SCA OSGi Integration Reporter: Rajini Sivaram Assignee: ant elder Priority: Minor Attachments: itest-osgi-implementation-patch.txt, modules-implementation-osgi-patch.txt Update pom.xml and felix.config.properties in itest/osgi-implementation to use the latest bundles. Add OSGiImplementation.equals method to check bundle location and properties. There is an exception thrown during Felix shutdown by one of the tests in itest. This exception does not cause a test failure, and has been raised as a Felix bug (https://issues.apache.org/jira/browse/FELIX-341). --- Exception with component : Unexpected problem executing task --- java.lang.IllegalStateException: Service already unregistered. at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:105) at org.apache.felix.scr.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:503) at org.apache.felix.scr.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:369) at org.apache.felix.scr.AbstractComponentManager.access$200(AbstractComponentManager.java:55) at org.apache.felix.scr.AbstractComponentManager$3.run(AbstractComponentManager.java:176) at org.apache.felix.scr.ComponentActorThread.run(ComponentActorThread.java:81) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1500) Many callback tests don't run
[ https://issues.apache.org/jira/browse/TUSCANY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1500: - Assignee: Raymond Feng (was: Simon Nash) Many callback tests don't run - Key: TUSCANY-1500 URL: https://issues.apache.org/jira/browse/TUSCANY-1500 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: patch1 The following itests are currently disabled in the build. If they are enabled by changing the name of the test class from xxxTest to xxxTestCase, they fail with various errors. callback-api callback-complex-type callback-id callback-set-callback callback-set-conversation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1500) Many callback tests don't run
[ https://issues.apache.org/jira/browse/TUSCANY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng resolved TUSCANY-1500. --- Resolution: Fixed Patch applied. Thanks. Many callback tests don't run - Key: TUSCANY-1500 URL: https://issues.apache.org/jira/browse/TUSCANY-1500 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: patch1 The following itests are currently disabled in the build. If they are enabled by changing the name of the test class from xxxTest to xxxTestCase, they fail with various errors. callback-api callback-complex-type callback-id callback-set-callback callback-set-conversation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1500) Many callback tests don't run
[ https://issues.apache.org/jira/browse/TUSCANY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash reopened TUSCANY-1500: - Assignee: Simon Nash (was: Raymond Feng) Thanks for applying patch1. I'm reopening this JIRA because there is further work needed to get the remaining callback tests to run. Many callback tests don't run - Key: TUSCANY-1500 URL: https://issues.apache.org/jira/browse/TUSCANY-1500 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: patch1 The following itests are currently disabled in the build. If they are enabled by changing the name of the test class from xxxTest to xxxTestCase, they fail with various errors. callback-api callback-complex-type callback-id callback-set-callback callback-set-conversation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1570) ANT build of calcualator-webapp sample fails.. either remove it or fix it
ANT build of calcualator-webapp sample fails.. either remove it or fix it - Key: TUSCANY-1570 URL: https://issues.apache.org/jira/browse/TUSCANY-1570 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Environment: tomcat version 6.0.14, using distribution that Ant published on 8/22, running on windows Reporter: haleh mahbod Priority: Critical followed readme instruction for ant issued ant package command copied war file to tomcat webapp directory (Note war file looks very small compared to what mvn would produce. it is about 270K) start tomcat start browser and give it the link It says HTTP Status 404 - /sample-calculator-webapp/calc.jsp Now, try the same excercise.. first compile with mvn and then do the same thing. it works. Suggest that we either remove the ant aspect from the sample or fix it. Don't leave it in the distro as is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question on extension-helper and how to register extensions with specific QNames
I'm updating all Tuscany extensions that are non-spec'd to use a Tuscany namespace, and with this, some bindings or component types will be registered with the SCA 1.0 namespace (e.g binding-ejb) but others will use the Tuscany extension namespace (e.g binding-dwr). In this case, and mainly when they are both implemented using Tuscany extension-helper, how I can use a specific QName for a tuscany binding or component type, and avoid using the default one ? Do we have any support for this today ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1571) componentType files not supported for implementation.java
componentType files not supported for implementation.java - Key: TUSCANY-1571 URL: https://issues.apache.org/jira/browse/TUSCANY-1571 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: Simon Nash Priority: Critical Fix For: Java-SCA-Next The implementation-java extension ignores services and references defined in a componentType file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1572) mvn on helloworld-ws-reference gets exception - used binary snapshot for .99
mvn on helloworld-ws-reference gets exception - used binary snapshot for .99 - Key: TUSCANY-1572 URL: https://issues.apache.org/jira/browse/TUSCANY-1572 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Environment: windows Reporter: haleh mahbod Following read me instructions 1) Ant run works fine 2) Building and running the sample using ant - works 3) Building And Running The Sample Using Maven --- Fails cd helloworld-ws-reference mvn [INFO] Scanning for projects... [INFO] [INFO] Building Apache Tuscany HelloWorld Web Service Client Sample [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://people.apache.org/repo/m2-incubating-repository/wsdl4j/wsdl4j/1.6.2/wsdl4j-1.6.2.pom [WARNING] Unable to get resource from repository apache.incubator (http://people.apache.org/repo/m2-incubating-repository) Downloading: http://www.ibiblio.net/pub/packages/maven2/wsdl4j/wsdl4j/1.6.2/wsdl4j-1.6.2.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/neethi/neethi/2.0.1/neethi-2.0.1.pom [WARNING] Unable to get resource from repository apache.incubator (http://people.apache.org/repo/m2-incubating-repository) Downloading: http://www.ibiblio.net/pub/packages/maven2/org/apache/neethi/neethi/2.0.1/neethi-2.0.1.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://people.apache.org/repo/m2-incubating-repository/jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom [WARNING] Unable to get resource from repository apache.incubator (http://people.apache.org/repo/m2-incubating-repository) Downloading: http://www.ibiblio.net/pub/packages/maven2/jaxen/jaxen/1.1-beta-10/jaxen-1.1-beta-10.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://people.apache.org/repo/m2-incubating-repository/org/apache/woden/woden/1.0-incubating-M7a/woden-1.0-incubating-M7a.pom [WARNING] Unable to get resource from repository apache.incubator (http://people.apache.org/repo/m2-incubating-repository) Downloading: http://www.ibiblio.net/pub/packages/maven2/org/apache/woden/woden/1.0-incubating-M7a/woden-1.0-incubating-M7a.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [WARNING] Artifact junit:junit:jar:4.2:test retains local scope 'test' overriding broader scope 'runtime' given by a dependency. If this is not intended, modify or remove the local scope. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: C:\tuscany-new\sca-dist\tuscany-sca-1.0-incubating-SNAPSHOT\samples\helloworld-ws-reference\target\surefire-reports --- T E S T S --- Running helloworld.HelloWorldClientTestCase log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Aug 22, 2007 2:05:34 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.10 Aug 22, 2007 2:05:34 PM org.apache.catalina.startup.ContextConfig defaultWebConfig INFO: No default web.xml Aug 22, 2007 2:05:34 PM org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/jsp_2_0.xsd Aug 22, 2007 2:05:34 PM org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_1_1.dtd Aug 22, 2007 2:05:34 PM org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd Aug 22, 2007 2:05:34 PM org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd Aug 22, 2007 2:05:34 PM org.apache.catalina.startup.DigesterFactory register WARNING: Could not get url for /javax/servlet/resources/j2ee_web_services_1_1.xsd Aug 22, 2007 2:05:34 PM
[jira] Updated: (TUSCANY-1571) componentType files not supported for implementation.java
[ https://issues.apache.org/jira/browse/TUSCANY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1571: Attachment: test1571.zip The test case is a modified version of the calculator sample from which all annotations have been removed. In this version, componentType files are used to define all the services and references, using interface-style service definitions instead of implementation classes. componentType files not supported for implementation.java - Key: TUSCANY-1571 URL: https://issues.apache.org/jira/browse/TUSCANY-1571 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: Simon Nash Priority: Critical Fix For: Java-SCA-Next Attachments: test1571.zip The implementation-java extension ignores services and references defined in a componentType file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1371) C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop)
[ https://issues.apache.org/jira/browse/TUSCANY-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1371: --- Attachment: TUSCANY-1371.txt This patch updates the DataObject::getProperty methods to the 2.1 spec API. C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop) - Key: TUSCANY-1371 URL: https://issues.apache.org/jira/browse/TUSCANY-1371 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1371.txt The Tuscany C++ SDO specification interface introduces off-spec member function overloads for getProperty. The SDO 2.1 spec introduces the member function: DataObject::getInstanceProperty(const std::string prop), whicfh should replace these functions. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 6:35 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop) Hi, In the DataObject interface, these member functions are present which are not in the C++ 2.1 specification: virtual const Property getProperty(unsigned int index) = 0; virtual const Property getProperty(const char* prop) = 0; virtual const Property getProperty(const SDOString prop) = 0; Since the 2.1 spec now has getInstanceProperty(const std::string prop), would it be a good idea to file a Jira/patch to replace these member functions with it in the specification interface? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1571) componentType files not supported for implementation.java
[ https://issues.apache.org/jira/browse/TUSCANY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng reassigned TUSCANY-1571: - Assignee: Raymond Feng componentType files not supported for implementation.java - Key: TUSCANY-1571 URL: https://issues.apache.org/jira/browse/TUSCANY-1571 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: Simon Nash Assignee: Raymond Feng Priority: Critical Fix For: Java-SCA-Next Attachments: test1571.zip The implementation-java extension ignores services and references defined in a componentType file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1571) componentType files not supported for implementation.java
[ https://issues.apache.org/jira/browse/TUSCANY-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521938 ] Raymond Feng commented on TUSCANY-1571: --- I'll add it to svn and exclude it from the itest/pom.xml as it is not working yet. componentType files not supported for implementation.java - Key: TUSCANY-1571 URL: https://issues.apache.org/jira/browse/TUSCANY-1571 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: Simon Nash Assignee: Raymond Feng Priority: Critical Fix For: Java-SCA-Next Attachments: test1571.zip The implementation-java extension ignores services and references defined in a componentType file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: [jira] Updated: (TUSCANY-1371) C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop)
Hi, I uploaded a patch for TUSCANY-1371. If someone could review and apply it that would be great. Thanks, Michael -Original Message- From: Michael Yoder (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 22, 2007 2:47 PM To: Michael Yoder Subject: [jira] Updated: (TUSCANY-1371) C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop) [ https://issues.apache.org/jira/browse/TUSCANY-1371?page=com.atlassian.ji ra.plugin.system.issuetabpanels:all-tabpanel ] Michael Yoder updated TUSCANY-1371: --- Attachment: TUSCANY-1371.txt This patch updates the DataObject::getProperty methods to the 2.1 spec API. C++ SDO spec compliance/portability: C++ DataObject::getInstanceProperty(const std::string prop) -- --- Key: TUSCANY-1371 URL: https://issues.apache.org/jira/browse/TUSCANY-1371 Project: Tuscany Issue Type: Bug Components: C++ SDO, C++ Specification Affects Versions: Cpp-M3 Environment: API issue - all platforms Reporter: Michael Yoder Fix For: Cpp-Next Attachments: TUSCANY-1371.txt The Tuscany C++ SDO specification interface introduces off-spec member function overloads for getProperty. The SDO 2.1 spec introduces the member function: DataObject::getInstanceProperty(const std::string prop), whicfh should replace these functions. -Original Message- From: Michael Yoder Sent: Thursday, June 21, 2007 6:35 PM To: 'tuscany-dev@ws.apache.org' Subject: C++ SDO spec compliance/portability: DataObject::getInstanceProperty(const std::string prop) Hi, In the DataObject interface, these member functions are present which are not in the C++ 2.1 specification: virtual const Property getProperty(unsigned int index) = 0; virtual const Property getProperty(const char* prop) = 0; virtual const Property getProperty(const SDOString prop) = 0; Since the 2.1 spec now has getInstanceProperty(const std::string prop), would it be a good idea to file a Jira/patch to replace these member functions with it in the specification interface? Thanks, Michael Yoder Rogue Wave Software - [EMAIL PROTECTED] Software Developer - HydraSDO -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1573) helloworld-jsronrpc sample does not run using .99 snapshot
helloworld-jsronrpc sample does not run using .99 snapshot -- Key: TUSCANY-1573 URL: https://issues.apache.org/jira/browse/TUSCANY-1573 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99 Environment: I tried both firefox and ie. and checked to make sure scripting is enabled. -- Windows Reporter: haleh mahbod Fix For: Java-SCA-0.99 Following readme instruction, a) copied war file to tomcat webapp directory b) started tomcat ( I see init message for hellow json-rpc) c) started browser and gave it url: http://localhost:8080/sample-helloworld-jsonrpc Screen pops up that shows Helloworld Json/rpc sample screen. Type something in the box and submit... Nothing happens At the bottome part of the browser I see a brief message in the explorer tool bar (bottom) saying 'error on page'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
I'll start a different thread to discuss the more long term support for implementation.web. For now, comments inline to cover the immediate WAR size issue for the 0.99 release. Simon Laws wrote: [snip] 1 - what is in the war that is build from these samples - currently all of the tuscany jars required [snip] Doing 1 is a relatively straightforward exercise of refactoring the current war into a slimmed down version. I'm still not convinced that it's a good idea to remove the webapp samples and compress everything into a small number of samples I think we should just document how to copy the required JARs to the Tomcat lib folder and run the stripped down WARs this way, assuming that it works. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
Jean-Sebastien Delfino wrote: I'll start a different thread to discuss the more long term support for implementation.web. For now, comments inline to cover the immediate WAR size issue for the 0.99 release. Simon Laws wrote: [snip] 1 - what is in the war that is build from these samples - currently all of the tuscany jars required [snip] Doing 1 is a relatively straightforward exercise of refactoring the current war into a slimmed down version. I'm still not convinced that it's a good idea to remove the webapp samples and compress everything into a small number of samples I think we should just document how to copy the required JARs to the Tomcat lib folder and run the stripped down WARs this way, assuming that it works. And to be clearer, I'm with you, -1 on removing the webapp samples and compressing everything into a small number of samples. Additionally we should document that people can also copy all the JARs to their webapp if they wish. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Connect errors in samples/*webapp Web Services samples
The calculator and helloworld Web Service WAR samples contain test cases that attempt to talk to the sample Webapp that they are contained in. I am not sure how they're supposed to work without taking the WAR and deploying it to a separate Tomcat instance by hand. Maybe I missed a step or my environment is not right... I have temporarily renamed the two test cases to *FIXME for now as they're breaking the build for me (and Raymond just confirmed in a chat that calculator-webapp-ws is breaking for him as well). Should these two test cases work? or are they not supposed to be included in these samples? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XQuery implementation scenarios
Hi, interesting topic :) so I've copied the tuscany-user list as well in case some of our users are interested too. Vasil Vasilev wrote: Hi all, I would like to start a discussion about how we see the usage and the future of XQuery within the boundaries of SCA. What inspired me when I started my work on the XQuery implementation type for SCA was the capabilities it provides in the area of data integration. You can take a look for example on the BEA AquaLogic platform. You can see how they create the data integration layer of a SOA application on the basis of XQuery. Currently the SCA specification supports integration with EJB and Spring, but I think XQuery provides many capabilities for working directly with XML data sources - like Web Services and DataBases. It should be noted that the main database vendors support XQuery. Yes, I agree with you that it's missing from SCA right now, and people who use XML based programming models, XML schema for their data, WSDL for their interfaces, or BPEL for their processes, and want to work directly with the XML data will want to use XQuery to transform, filter, mediate their XML messages, and query data from all kinds of XML-enabled backends. I think that with your code contribution we have a good starting point that we can now further develop and refine, use to develop scenarios, samples, demos that illustrate its usage. I'm hoping that this work and the discussions here will help put together a proposal to bring to the spec group. With respect to database access, a number of folks in Tuscany are working on DAS (Data Access Service) and I believe they have started to look at XQuery as well, so I'm not sure if or how these two subjects are related, but I'd be curious to hear from the DAS people on the XQuery subject as well. Another interesting question may be: If the XQuery program talks to a database, will we want to configure the database information on the XQuery component itself? or is the XQuery component going to be more independent of the database itself and we'll represent the accessed database as a separate service? So having in mind what was said above one step for enhancing the XQuery implementation type is to decouple it from Saxon. The user should be able to plug-in his preferred XQuery processor. For example if he uses Oracle, he could delegate the execution of the XQuery script to the Oracle parser. Or he could prefer to use DataDirect's implementation, which is very optimized for accessing databases. In order to do it we could think of some kind of extension points, which define what is needed by the implementation, i.e. to introspect the XQuery file, to call a single function in it, to set external parameters and functions and etc. That sounds good to me. Is there a standard XQuery processor API that we could use here? or should we define that extensibility mechanism ourselves as a specific Tuscany API? How about using SCA policy intents to configure which XQuery processor is going to be used. Have you looked at SCA policies at all? I'm just brainstorming here, but maybe we could define a few policy intents that the application developer could put on a component to say I want an XQuery processor that works well with this XML databinding or I want the XQuery processor that works well with my database... Another direction where the XQuery implementation type seems useful is in the area of mapping one service interface to another and in this way adapt both interfaces. He could even do it with a mapping tool, which generates XQuery code out of it. This could be very useful for BPEL implementation type services for example. Of course here also XSLT could be used, but I selected XQuery, because it is more similar to a programming language and it could easier fit in the concept of interfaces and operations of the services. In this area JBI inherently provide a solution (you can see Open ESB for example), while in SCA this concept is somehow missing. That's why I thing an XQuery implementation type would be a good step forward. Right! XQuery can definitely be very useful to implement mediation components. I can see two different patterns here: - Data mediation - I have data type X and need to transform it to Y, I could write a XQuery component named TransformX2Y for example and then reuse it in various places in my SCA composite application, from Java components that don't want to write this transformation in Java, from BPEL components between BPEL assigns, etc. This kind of component could have a fixed operation like any transform(any) for example, or a more specific operation signature indicating its input/output types. We could have one transform per component or choose to bundle a bunch of related transforms in the same component... There's a lot to explore here I think :) - Interface mediation - I have two WSDL interfaces that don't exactly match, the operation
[jira] Updated: (TUSCANY-1500) Many callback tests don't run
[ https://issues.apache.org/jira/browse/TUSCANY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1500: Attachment: patch2 Here is patch2 for this JIRA. It enables the callback-id test in the build and gets it working. Here's a very brief summary of the changes in this patch. 1. Rename CallBackIdTestCaseFIXME.java to CallBackIdTestCase.java. (NOTE: This must be done manually before applying the patch, which contains an update to CallBackIdTestCase.java.) 2. Change the class name for the test from CallBackIdTestCaseFIXME to CallBackIdTestCase. 3. Change the test code where it was not using the correct spec APIs. 4. Various runtime changes to enable the correct passing of the callback ID on requests I am looking at the other failing callback tests and I will post further patches to get them working. Many callback tests don't run - Key: TUSCANY-1500 URL: https://issues.apache.org/jira/browse/TUSCANY-1500 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: patch1, patch2 The following itests are currently disabled in the build. If they are enabled by changing the name of the test class from xxxTest to xxxTestCase, they fail with various errors. callback-api callback-complex-type callback-id callback-set-callback callback-set-conversation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
Simon Nash wrote: Sorry for the delay in replying. I was away with no access to email. Comments inline. Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: See inline. Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: Sorry that I missed this the first time round. See inline. Simon Jean-Sebastien Delfino wrote: [snip] The important part in what I was proposing was: and will save the application developer to have to understand it. ... I don't want the application developer to have to understand a Tuscany specific naming convention like $callback.Abc for endpoint URIs used by callbacks. Where is this exposed to the application developer? The developer does not wire callbacks or specify an explicit URI for them. The creation and usage of the special name should be entirely confined to the runtime. This is the URI where the service is available, where as an application developer, I'm going to point my TCP/IP monitor, my Web Browser, or my Web Services explorer to test the service... so I better know where it is. We've seen recurring questions and discussions on this list where it was not clear to people which URI was actually used to expose a service (as it was not explicit in the SCA assembly XML), same here for callbacks, those special names will come back hunt app developers every day. Thanks, this helps me to understand the scenarios. I was thinking in terms of service and reference names, which would not be exposed (like the current $self$. and $promoted$. names that the runtime uses). The issue is when the service or reference name is used to form the externally visible URI for the callback endpoint. If we want to do something in the spec group to address this, I think the best thing to do would be to add a rule to the spec for how a URI should be constructed for the endpoint that represents a callback reference. This needs to be done in a way that won't collide with URIs for SCDL services on the same component. One way to ensure that the endpoint names don't collide is to say (as you have proposed): 1. The name of the callback endpoint is derived from the SCDL reference name using the same algorithm that is currently used for services. 2. Reference and service names must never be the same. Another way to ensure that the endpoint names don't collide is to say: 1. The name of the callback endpoint is derived from the SCDL reference name using a different algorithm than the one that is currently used for services. For example, it could be something like componentname/referencename-callback My preference would be for something like this because it makes it very easy to see which URIs are for callbacks and which are for real services. Simon Will that work? component name=foo service name=bar/ -- this one has a callback reference name=bar-callback /component On the service side there is no problem, as no external endpoint URI is created for the pseudo-reference, and I am not proposing that we change the internal Tuscany model names from the $callback$. scheme. The case that would have a problem is on the reference side: component name=foo service name=bar-callback/ reference name=bar -- this one has a callback /component I was only using the -callback suffix is as an example to get the discussion started. If we are trying to ensure guaranteed uniqueness in all cases, then we need a different separator from - that isn't legal for service names but is legal for URIs. What about using /? The above example would then translate to: base-uri/foo/bar-callback -- the real SCDL service base-uri/foo/bar/callback -- the callback pseudo-service As long as there is no possibility of having a SCDL service named bar/callback then this will not break. Sure it was an example, and I just gave an example of why it wouldn't work :) But remember, the main reason why I don't like that approach is that I think that make it work we'll need to come up with an ugly naming convention, and place that ugly naming convention in the face of all application developers. foo/bar/callback doesn't work either, if you have a component bar inside a (composite) component foo (as with nested composition you can't really use the component name, you have to use the component URI instead). Please can you explain this in a little more detail, preferably with an example. I believe you're talking about SCDL like the following: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://sample; xmlns:sample=http://sample; name=OuterComposite component name=SourceComponent implementation.composite name=sample:InnerComposite/ reference name=targetComponentRef2 target=TargetComponent2/InnerTargetService/ /component component name=TargetComponent2 implementation.composite
Re: Question on extension-helper and how to register extensions with specific QNames
Well, i gave it a try, and I was able to get further by creating and registering a new module activator that extended BindingsActivator and overriding the getBindingQName method. On 8/22/07, Luciano Resende [EMAIL PROTECTED] wrote: I'm updating all Tuscany extensions that are non-spec'd to use a Tuscany namespace, and with this, some bindings or component types will be registered with the SCA 1.0 namespace (e.g binding-ejb) but others will use the Tuscany extension namespace (e.g binding-dwr). In this case, and mainly when they are both implemented using Tuscany extension-helper, how I can use a specific QName for a tuscany binding or component type, and avoid using the default one ? Do we have any support for this today ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA distribution is really big now
+1 for I think we should just document how to copy the required JARs to the Tomcat lib folder and run the stripped down WARs this way, assuming that it works. We anyways have the READMEs where we put in documentation on how to run the samples. Adding this step for webapps seems fine to me -Venkat On 8/23/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'll start a different thread to discuss the more long term support for implementation.web. For now, comments inline to cover the immediate WAR size issue for the 0.99 release. Simon Laws wrote: [snip] 1 - what is in the war that is build from these samples - currently all of the tuscany jars required [snip] Doing 1 is a relatively straightforward exercise of refactoring the current war into a slimmed down version. I'm still not convinced that it's a good idea to remove the webapp samples and compress everything into a small number of samples I think we should just document how to copy the required JARs to the Tomcat lib folder and run the stripped down WARs this way, assuming that it works. And to be clearer, I'm with you, -1 on removing the webapp samples and compressing everything into a small number of samples. Additionally we should document that people can also copy all the JARs to their webapp if they wish. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Renaming binding-ajax to binding-dwr?
Simon Nash wrote: How about binding-ajax-dwr? This seems to go well with binding-ws-axis2. That seems to contradict what we said before as: - DWR is a transport protocol (like JSON, another protocol) - but Axis2 is an implementation. Simon Mike Edwards wrote: +1 to the rename. Best to name the binding by the transport mechanism involved, not the implementation used to drive it. Yours, Mike. Jean-Sebastien Delfino wrote: ant elder wrote: On 8/19/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'd like to rename binding-ajax to binding-dwr, as Ajax is a really generic term, and it will make clear that this binding is actually using the DWR (Direct Web Remoting) protocol. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Closed: (TUSCANY-1053) Use a Tuscany namespace for all non-spec'd Tuscany extensions
Done under revision #568830 On 8/22/07, Mike Edwards [EMAIL PROTECTED] wrote: Jean-Sebastien, Jean-Sebastien Delfino wrote: snip Looks like option (B) is the most preferred option with: - one -1 - five +1 - one more spec compliant Do we need more technical discussion? or a new [VOTE] thread to close this issue? Thanks for a great summary. I'm happy with the conclusion. Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
