[jira] Updated: (TUSCANY-243) Adding doc-lit support for Axis2 integration
[ http://issues.apache.org/jira/browse/TUSCANY-243?page=all ] Raymond Feng updated TUSCANY-243: - Attachment: doc-lit-0502.patch Hi, Ant. Here's the 3rd version of the patch tested on the latest code. Thanks, Raymond > Adding doc-lit support for Axis2 integration > > > Key: TUSCANY-243 > URL: http://issues.apache.org/jira/browse/TUSCANY-243 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Binding > Reporter: Raymond Feng > Assignee: ant elder > Attachments: client-service.zip, doc-lit-0430-fixed.patch, > doc-lit-0430.patch, doc-lit-0502.patch, doc-lit.patch > > Adding doc-lit support in addtional to doc-lit-wrapped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RESULT]Re: Karma for Dan
Dan, What would you like your Apache id to be. Please send me some alternate choices (in order or priority). thanks, dims On 5/2/06, Daniel Kulp <[EMAIL PROTECTED]> wrote: I just want to say a quick thanks to everyone for the vote of confidence. Thanks! Dan On Tuesday 02 May 2006 19:12, Jim Marino wrote: > Result of the vote for Dan Kulp as committer on Apache Tuscany: > > +1 jmarino,jboynes,antelder,dims,jsdelfino,rineholt > > No -1s > > Dan welcome to the Apache Tuscany community! We'll start the process > of getting you karma. > > Jim > > On Apr 29, 2006, at 10:28 AM, Jim Marino wrote: > > I'd like to propose was make Dan a commiter since he's done a lot > > including: > > > > - Creating a binding that supports web services and will support > > JMS over the next couple of days > > - Fixed a host of compiler warnings in a number of projects > > - Has served as an excellent "bridge" to the Celtix community > > - Has demonstrated that he shares a philosophy towards design and > > coding that is consistent with the Tuscany group > > > > Also, more practically, there is outstanding work to move the > > Celtix binding to main and he has a fairly large commit coming. I > > for one would like to have Dan do it directly :-) > > > > So, could we vote on this proposal? > > > > +1 (obviously) from me. > > > > Jim -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/
[jira] Assigned: (TUSCANY-259) Core tests fail if assertions are turned on
[ http://issues.apache.org/jira/browse/TUSCANY-259?page=all ]
Jim Marino reassigned TUSCANY-259:
--
Assign To: Jim Marino
> Core tests fail if assertions are turned on
> ---
>
> Key: TUSCANY-259
> URL: http://issues.apache.org/jira/browse/TUSCANY-259
> Project: Tuscany
> Type: Bug
> Components: Java SCA Core
> Reporter: Daniel Kulp
> Assignee: Jim Marino
>
> Several tests (40 to be exact) fail if assertions are turned on in the VM
> that maven is running in. (add -ea to your MAVEN_OPTS)
> The cause is:
> public AutowireExtensibilityElement(Method m) {
> assert(method.getParameterTypes().length == 1): "Illegal number of
> parameters";
> method = m;
> }
> The method is allowed to be null, but if it is, evaluating the assertion
> causes a NullPointerException. It should be:
> assert(method == null || method.getParameterTypes().length == 1)..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-243) Adding doc-lit support for Axis2 integration
[ http://issues.apache.org/jira/browse/TUSCANY-243?page=comments#action_12377512 ] Raymond Feng commented on TUSCANY-243: -- Hi, Ant. I have an updated patch based on the latest code for 3rd time. I hope it will be the last time I have to update the patch. :-) Thanks, Raymond > Adding doc-lit support for Axis2 integration > > > Key: TUSCANY-243 > URL: http://issues.apache.org/jira/browse/TUSCANY-243 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Binding > Reporter: Raymond Feng > Assignee: ant elder > Attachments: client-service.zip, doc-lit-0430-fixed.patch, > doc-lit-0430.patch, doc-lit.patch > > Adding doc-lit support in addtional to doc-lit-wrapped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-259) Core tests fail if assertions are turned on
Core tests fail if assertions are turned on
---
Key: TUSCANY-259
URL: http://issues.apache.org/jira/browse/TUSCANY-259
Project: Tuscany
Type: Bug
Components: Java SCA Core
Reporter: Daniel Kulp
Several tests (40 to be exact) fail if assertions are turned on in the VM that
maven is running in. (add -ea to your MAVEN_OPTS)
The cause is:
public AutowireExtensibilityElement(Method m) {
assert(method.getParameterTypes().length == 1): "Illegal number of
parameters";
method = m;
}
The method is allowed to be null, but if it is, evaluating the assertion causes
a NullPointerException. It should be:
assert(method == null || method.getParameterTypes().length == 1)..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [RESULT]Re: Karma for Dan
I just want to say a quick thanks to everyone for the vote of confidence. Thanks! Dan On Tuesday 02 May 2006 19:12, Jim Marino wrote: > Result of the vote for Dan Kulp as committer on Apache Tuscany: > > +1 jmarino,jboynes,antelder,dims,jsdelfino,rineholt > > No -1s > > Dan welcome to the Apache Tuscany community! We'll start the process > of getting you karma. > > Jim > > On Apr 29, 2006, at 10:28 AM, Jim Marino wrote: > > I'd like to propose was make Dan a commiter since he's done a lot > > including: > > > > - Creating a binding that supports web services and will support > > JMS over the next couple of days > > - Fixed a host of compiler warnings in a number of projects > > - Has served as an excellent "bridge" to the Celtix community > > - Has demonstrated that he shares a philosophy towards design and > > coding that is consistent with the Tuscany group > > > > Also, more practically, there is outstanding work to move the > > Celtix binding to main and he has a fairly large commit coming. I > > for one would like to have Dan do it directly :-) > > > > So, could we vote on this proposal? > > > > +1 (obviously) from me. > > > > Jim -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED]
[RESULT]Re: Karma for Dan
Result of the vote for Dan Kulp as committer on Apache Tuscany: +1 jmarino,jboynes,antelder,dims,jsdelfino,rineholt No -1s Dan welcome to the Apache Tuscany community! We'll start the process of getting you karma. Jim On Apr 29, 2006, at 10:28 AM, Jim Marino wrote: I'd like to propose was make Dan a commiter since he's done a lot including: - Creating a binding that supports web services and will support JMS over the next couple of days - Fixed a host of compiler warnings in a number of projects - Has served as an excellent "bridge" to the Celtix community - Has demonstrated that he shares a philosophy towards design and coding that is consistent with the Tuscany group Also, more practically, there is outstanding work to move the Celtix binding to main and he has a fairly large commit coming. I for one would like to have Dan do it directly :-) So, could we vote on this proposal? +1 (obviously) from me. Jim
Cross language interop
I spent a little time getting familiar with PHP/SDO and had some more thoughts about cross language interop testing. For SDO the most basic test is to read and write an XML file from PHP/JAVA/C++ and compare the results. We could develop this to test other functions such as creating, updating and deleting content and again comparing the content from the different implementations. Assuming we start with the same input we would expect the outputs to be compatible. Is there an XML file somewhere that contains the full set of supported types and type constructs? Where relational DASs are implemented Similar tests could be carried out with relational data ensuring that type conversions are performed accurately and consistently across implementations by reading out of a database and printing out the data for comparison or by inserting back into a database for comparison. We could also look at how consistently the implementations convert from one DAS type to another but I guess this is not strictly an interoperability issue. Is there an intention that SDO change histories will be shared? If so this is something else that you could expect to be transferred across language boundaries and hence we should think about how to test this. Once the work is done to have C++ support Axis2 we should do some SCA interop testing also. In the near term we could do some basic testing based on SDO/axiom conversions if it's thought that to be worth it. I'm happy to spend time setting up tests if we can agree which ones are required. Thoughts Regards Simon
[jira] Created: (TUSCANY-258) Static DataObjects are not correctly deserialized from WS request messages
Static DataObjects are not correctly deserialized from WS request messages -- Key: TUSCANY-258 URL: http://issues.apache.org/jira/browse/TUSCANY-258 Project: Tuscany Type: Bug Components: Java SCA Axis Binding, Java SDO Implementation Reporter: ant elder Priority: Blocker All WS entryPoints that used static DataObjects fail as the incoming SOAP message doesn't get correctly deserialized. Instead of getting a single DataObject back from dataBinding.fromOMElement(requestOM) it returns an array of 5 other objects, all SDO type things. To reproduce run BB URL to start http://localhost:8080/webclient-SNAPSHOT/login.html logon with test/password -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-253) SDO types not being registered in webapp (BigBank)
[ http://issues.apache.org/jira/browse/TUSCANY-253?page=comments#action_12377468 ] ant elder commented on TUSCANY-253: --- I've committed a change in r399025 which fixes this particular problem. BB still doesn't work as now the AccountService WS fails as the request isn't deserialized into an SDO correctly. I'll raise a seperate JIRA for that. > SDO types not being registered in webapp (BigBank) > -- > > Key: TUSCANY-253 > URL: http://issues.apache.org/jira/browse/TUSCANY-253 > Project: Tuscany > Type: Bug > Components: Java SCA Core, Java SCA Axis Binding > Reporter: Rick Rineholt > Assignee: ant elder > Priority: Blocker > > It doesn't appear that SDO types are being registered in a webapp environment > where SCA components have externalServices. > apache.tuscany.binding.axis2.util.AxiomHelper.toDataObject(commonj.sdo.helper.TypeHelper, > java.lang.Object[], javax.xml.namespace.QName) returns null for > xsdHelper.getGlobalProperty(typeQN.getNamespaceURI(), typeQN.getLocalPart(), > true); > To reproduce run BB > URL to start http://localhost:8080/webclient-SNAPSHOT/login.html > logon with test/password -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TUSCANY-256) loadClass in SDOUtil receiving exception because different class loaders are used
[ http://issues.apache.org/jira/browse/TUSCANY-256?page=all ] Frank Budinsky resolved TUSCANY-256: Resolution: Fixed Fixed in revision 399033. > loadClass in SDOUtil receiving exception because different class loaders are > used > - > > Key: TUSCANY-256 > URL: http://issues.apache.org/jira/browse/TUSCANY-256 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Environment: all > Reporter: Paul Golick > Attachments: patchSDOUtil.txt > > In SDOUtil.java it is necessary that the loadClass method be wrapped and done > by invoking AccessController.doPriveleged on a PrivelegedExceptionAction > object because the current class loader can be different than the one > previously used to load the class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Big Bank status?
Rick
Thanks for looking, sorry to distrct you. Must be something wrong with my
check out. I'll start again.
Regards
Simon
On 5/2/06, Rick Rineholt <[EMAIL PROTECTED]> wrote:
Fresh build compiles for me
AccountService.java: snippet is below matches WSDL and AccountServiceImpl
/**
* Auto generated method signatures
* @param param6* @param param7
*/
public float deposit(
java.lang.String param6,float param7) throws
java.rmi.RemoteException;
Simon Laws wrote:
> Hi
>
> I just tried running the maven build (I checked out from svn a couple of
> hours ago) for the big bank sample and the AccountService.java interface
> that is generated from the AccountService.wsdl matches neither the
> wsdl nor
> the checked in AccountServiceImpl.java and hence the build fails. The
> signatures are all represented but they are incorrect, e.g.
>
> WSDL
>
>
>
>type="xsd:string" />
>
>
>
>
>
> AccountServiceImpl.java
>
>public float deposit(String account, float ammount) throws
> RemoteException {
>try{
>
> Generated AccountService.java
>
>public float deposit(
> java.lang.String param0) throws java.rmi.RemoteException;
>
> I had assumed this would work as Rick has been posting fixes to big
> bank. If
> this is being caused by work in progress then not to worry I will
> wait. If
> not I will raise JIRAs
>
> Regards
>
> Simon
>
[jira] Updated: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
[ http://issues.apache.org/jira/browse/TUSCANY-257?page=all ] Paul Golick updated TUSCANY-257: Attachment: patchInterface2JavaGenerator.txt The attached patch makes the file compatible with Java 1.4 by removing the code that handled methods with parameterized return types, a new feature of Java 1.5. > recently added file Interface2JavaGenerator.java is not compatible with JDK > 1.4 > --- > > Key: TUSCANY-257 > URL: http://issues.apache.org/jira/browse/TUSCANY-257 > Project: Tuscany > Type: Bug > Components: Java SDO Tools > Environment: all > Reporter: Paul Golick > Attachments: patchInterface2JavaGenerator.txt > > Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and > java.lang.reflect.Type that were added in Java 5 for generics. It appears > that the portion of Interface2JavaGenerator that uses ParameterizedType and > Type is not needed for Java 1.4 classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-253) SDO types not being registered in webapp (BigBank)
[ http://issues.apache.org/jira/browse/TUSCANY-253?page=all ] ant elder reassigned TUSCANY-253: - Assign To: ant elder > SDO types not being registered in webapp (BigBank) > -- > > Key: TUSCANY-253 > URL: http://issues.apache.org/jira/browse/TUSCANY-253 > Project: Tuscany > Type: Bug > Components: Java SCA Core, Java SCA Axis Binding > Reporter: Rick Rineholt > Assignee: ant elder > Priority: Blocker > > It doesn't appear that SDO types are being registered in a webapp environment > where SCA components have externalServices. > apache.tuscany.binding.axis2.util.AxiomHelper.toDataObject(commonj.sdo.helper.TypeHelper, > java.lang.Object[], javax.xml.namespace.QName) returns null for > xsdHelper.getGlobalProperty(typeQN.getNamespaceURI(), typeQN.getLocalPart(), > true); > To reproduce run BB > URL to start http://localhost:8080/webclient-SNAPSHOT/login.html > logon with test/password -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-257) recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4
recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 --- Key: TUSCANY-257 URL: http://issues.apache.org/jira/browse/TUSCANY-257 Project: Tuscany Type: Bug Components: Java SDO Tools Environment: all Reporter: Paul Golick Interface2JavaGenerator.java uses java.lang.reflect.ParameterizedType and java.lang.reflect.Type that were added in Java 5 for generics. It appears that the portion of Interface2JavaGenerator that uses ParameterizedType and Type is not needed for Java 1.4 classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-256) loadClass in SDOUtil receiving exception because different class loaders are used
[ http://issues.apache.org/jira/browse/TUSCANY-256?page=all ] Paul Golick updated TUSCANY-256: Attachment: patchSDOUtil.txt The attached patch file moves the loadClass method into a PrivelegedExceptionAction object and invokes it with a doPriveleged method. > loadClass in SDOUtil receiving exception because different class loaders are > used > - > > Key: TUSCANY-256 > URL: http://issues.apache.org/jira/browse/TUSCANY-256 > Project: Tuscany > Type: Bug > Components: Java SDO Implementation > Environment: all > Reporter: Paul Golick > Attachments: patchSDOUtil.txt > > In SDOUtil.java it is necessary that the loadClass method be wrapped and done > by invoking AccessController.doPriveleged on a PrivelegedExceptionAction > object because the current class loader can be different than the one > previously used to load the class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-256) loadClass in SDOUtil receiving exception because different class loaders are used
loadClass in SDOUtil receiving exception because different class loaders are used - Key: TUSCANY-256 URL: http://issues.apache.org/jira/browse/TUSCANY-256 Project: Tuscany Type: Bug Components: Java SDO Implementation Environment: all Reporter: Paul Golick In SDOUtil.java it is necessary that the loadClass method be wrapped and done by invoking AccessController.doPriveleged on a PrivelegedExceptionAction object because the current class loader can be different than the one previously used to load the class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Big Bank status?
Fresh build compiles for me
AccountService.java: snippet is below matches WSDL and AccountServiceImpl
/**
* Auto generated method signatures
* @param param6* @param param7
*/
public float deposit(
java.lang.String param6,float param7) throws
java.rmi.RemoteException;
Simon Laws wrote:
Hi
I just tried running the maven build (I checked out from svn a couple of
hours ago) for the big bank sample and the AccountService.java interface
that is generated from the AccountService.wsdl matches neither the
wsdl nor
the checked in AccountServiceImpl.java and hence the build fails. The
signatures are all represented but they are incorrect, e.g.
WSDL
AccountServiceImpl.java
public float deposit(String account, float ammount) throws
RemoteException {
try{
Generated AccountService.java
public float deposit(
java.lang.String param0) throws java.rmi.RemoteException;
I had assumed this would work as Rick has been posting fixes to big
bank. If
this is being caused by work in progress then not to worry I will
wait. If
not I will raise JIRAs
Regards
Simon
Re: Big Bank status?
Bigbank won't work for other reasons
http://issues.apache.org/jira/browse/TUSCANY-253
But I'm not aware of this issue. I'm going to try to get a clean svn
check out of java. I'm having some issues with svn right now however.
As soon as I know something I'll respond. What I have locally did
compile, but I'll try fresh.
Simon Laws wrote:
Hi
I just tried running the maven build (I checked out from svn a couple of
hours ago) for the big bank sample and the AccountService.java interface
that is generated from the AccountService.wsdl matches neither the
wsdl nor
the checked in AccountServiceImpl.java and hence the build fails. The
signatures are all represented but they are incorrect, e.g.
WSDL
AccountServiceImpl.java
public float deposit(String account, float ammount) throws
RemoteException {
try{
Generated AccountService.java
public float deposit(
java.lang.String param0) throws java.rmi.RemoteException;
I had assumed this would work as Rick has been posting fixes to big
bank. If
this is being caused by work in progress then not to worry I will
wait. If
not I will raise JIRAs
Regards
Simon
Big Bank status?
Hi
I just tried running the maven build (I checked out from svn a couple of
hours ago) for the big bank sample and the AccountService.java interface
that is generated from the AccountService.wsdl matches neither the wsdl nor
the checked in AccountServiceImpl.java and hence the build fails. The
signatures are all represented but they are incorrect, e.g.
WSDL
AccountServiceImpl.java
public float deposit(String account, float ammount) throws
RemoteException {
try{
Generated AccountService.java
public float deposit(
java.lang.String param0) throws java.rmi.RemoteException;
I had assumed this would work as Rick has been posting fixes to big bank. If
this is being caused by work in progress then not to worry I will wait. If
not I will raise JIRAs
Regards
Simon
Re: Karma for Dan
+1 Jean-Sebastien Delfino wrote: Jim Marino wrote: I'd like to propose was make Dan a commiter since he's done a lot including: - Creating a binding that supports web services and will support JMS over the next couple of days - Fixed a host of compiler warnings in a number of projects - Has served as an excellent "bridge" to the Celtix community - Has demonstrated that he shares a philosophy towards design and coding that is consistent with the Tuscany group Also, more practically, there is outstanding work to move the Celtix binding to main and he has a fairly large commit coming. I for one would like to have Dan do it directly :-) So, could we vote on this proposal? +1 (obviously) from me. Jim Dan, a BIG +1 from me, welcome to Tuscany!
[jira] Updated: (TUSCANY-254) Add -interfaceDataObject codegen option to generate interfaces that extend SDO DataObject interface
[ http://issues.apache.org/jira/browse/TUSCANY-254?page=all ] ant elder updated TUSCANY-254: -- Component: Java SDO Tools Priority: Minor (was: Major) > Add -interfaceDataObject codegen option to generate interfaces that extend > SDO DataObject interface > --- > > Key: TUSCANY-254 > URL: http://issues.apache.org/jira/browse/TUSCANY-254 > Project: Tuscany > Type: Improvement > Components: Java SDO Tools > Environment: All > Reporter: Dan Murphy > Priority: Minor > > The current Java generator generates POJO style java interfaces, if a > developer need to use SDO methods then they need to explicitly cast to a > DataObject. This wouold be unnecessary and result in "better" code if the > generated classed extended DataObject. > This could be acheived by adding a -interfaceDataObject flag to the > generator... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Problems retrieving source for SDO for C++
Heres another 'gotcha' that I got caught by. If you check out using http:// instead of https://, then you get a very similar error to the one you are getting, but can check out using update. However, you are never allowed to check anything back in, and get (alternately) error 403, error 200, and just a silent hang when trying to check in your code. On 02/05/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: On 27/04/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > Geoff, I've seen this behaviour too using both TortoiseSVN and subclipse > from eclipse. It's not just on the cpp tree of Tuscany. It seems to happen > fairly randomly. > > On 26/04/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > > > I've tried to retrieve the source for SDO for C++ from the repository > > using > > the following command. > > > > E:> svn checkout http://svn.apache.org/repos/asf/incubator/tuscany/cpp > > > > When I do this fo rthe first time, I get what looks like a failure > > > > svn: REPORT request failed on '/repos/asf/!svn/vcc/default' > > svn: REPORT of '/repos/asf/!svn/vcc/default': 200 OK ( > > http://svn.apache.org) > > > > However, if I then issue the same command again, the extract works > without > > a > > problem (ie lots of files get fetched). > > > > I'm using svn V1.3.0 and I've also tried TortoiseSVN 1.3.3 - which gives > > essentially the same behaviour, failing on this first attempt but then > > succeeding. Is this normal? It feels to me that I'm failing to do some > > setup > > step before attempting the checkout but I can't see what that is. > > > > Thanks and regards, > > > > Geoff. > > > > > > > -- > Pete > While fixing a completely different problem, I discovered that svn checkout works fine when I have my Zone Labs firewall switched off. I'll investigate this a bit further and see if I can find a way to make the two co-exist. Geoff.
[jira] Created: (TUSCANY-255) Test data files not found by sdo_test program
Test data files not found by sdo_test program - Key: TUSCANY-255 URL: http://issues.apache.org/jira/browse/TUSCANY-255 Project: Tuscany Type: Improvement Components: C++ SDO Environment: Microsoft Visual C++ V7.1 running on Windows XP Reporter: Geoff Winn Priority: Minor When I attempt to run the sdo_test.exe program from with Visual Studio, the attempt fails with numerous file not found errors. The "missing" files are .xsd files such as company.xsd, simple.xsd and so on. These files are available in the distribution, in directories sdo\runtime\core\test and sdo\runtime\core\test\Debug however the test runs with its working directory set to sdo\projects\tuscany_sdo\sd_runtime and therefore doesn't find them. Copying the files into the required directory resolves the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-254) Add -interfaceDataObject codegen option to generate interfaces that extend SDO DataObject interface
[ http://issues.apache.org/jira/browse/TUSCANY-254?page=comments#action_12377404 ] Dan Murphy commented on TUSCANY-254: Sorry, should have set this to minor & assgined it to SDO Java... can't see how to do this now :( > Add -interfaceDataObject codegen option to generate interfaces that extend > SDO DataObject interface > --- > > Key: TUSCANY-254 > URL: http://issues.apache.org/jira/browse/TUSCANY-254 > Project: Tuscany > Type: Improvement > Environment: All > Reporter: Dan Murphy > > The current Java generator generates POJO style java interfaces, if a > developer need to use SDO methods then they need to explicitly cast to a > DataObject. This wouold be unnecessary and result in "better" code if the > generated classed extended DataObject. > This could be acheived by adding a -interfaceDataObject flag to the > generator... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-254) Add -interfaceDataObject codegen option to generate interfaces that extend SDO DataObject interface
Add -interfaceDataObject codegen option to generate interfaces that extend SDO DataObject interface --- Key: TUSCANY-254 URL: http://issues.apache.org/jira/browse/TUSCANY-254 Project: Tuscany Type: Improvement Environment: All Reporter: Dan Murphy The current Java generator generates POJO style java interfaces, if a developer need to use SDO methods then they need to explicitly cast to a DataObject. This wouold be unnecessary and result in "better" code if the generated classed extended DataObject. This could be acheived by adding a -interfaceDataObject flag to the generator... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [C++] QName and Uri
Great. I'll take a look at it and see if I can use it to achieve what I need. Cheers, On 02/05/06, Edward Slattery <[EMAIL PROTECTED]> wrote: A while ago, Pete raised a requirement to create Types in a DataFactory which are of type URI, but know that they came from a QName originally. We store this information in a TypeDefinition class when loading from XSD, so the easy way to allow Types to be created on the fly with this feature would be to expose TypeDefinition as a class, and let the user crate a list of TypeDefinitions, which can be passed back to the DataFactory DefineTypes method. I have therefore exposed TypeDefinition, TypeDefiniitons and PropertyDefinition classes. I hope this helps. -- Pete
Re: Problems retrieving source for SDO for C++
On 27/04/06, Pete Robbins <[EMAIL PROTECTED]> wrote: Geoff, I've seen this behaviour too using both TortoiseSVN and subclipse from eclipse. It's not just on the cpp tree of Tuscany. It seems to happen fairly randomly. On 26/04/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote: > > I've tried to retrieve the source for SDO for C++ from the repository > using > the following command. > > E:> svn checkout http://svn.apache.org/repos/asf/incubator/tuscany/cpp > > When I do this fo rthe first time, I get what looks like a failure > > svn: REPORT request failed on '/repos/asf/!svn/vcc/default' > svn: REPORT of '/repos/asf/!svn/vcc/default': 200 OK ( > http://svn.apache.org) > > However, if I then issue the same command again, the extract works without > a > problem (ie lots of files get fetched). > > I'm using svn V1.3.0 and I've also tried TortoiseSVN 1.3.3 - which gives > essentially the same behaviour, failing on this first attempt but then > succeeding. Is this normal? It feels to me that I'm failing to do some > setup > step before attempting the checkout but I can't see what that is. > > Thanks and regards, > > Geoff. > > -- Pete While fixing a completely different problem, I discovered that svn checkout works fine when I have my Zone Labs firewall switched off. I'll investigate this a bit further and see if I can find a way to make the two co-exist. Geoff.
[C++] QName and Uri
A while ago, Pete raised a requirement to create Types in a DataFactory which are of type URI, but know that they came from a QName originally. We store this information in a TypeDefinition class when loading from XSD, so the easy way to allow Types to be created on the fly with this feature would be to expose TypeDefinition as a class, and let the user crate a list of TypeDefinitions, which can be passed back to the DataFactory DefineTypes method. I have therefore exposed TypeDefinition, TypeDefiniitons and PropertyDefinition classes. I hope this helps.
Re: C++ release before ApacheCon Europe
A separate thread to discuss SCA/SDO interop testing sounds like a good idea. I'd like to focus here on what we need to complete to have a viable binary release: code(functional content), documentation, testing, samples... etc. and then come up with a timetable/ordering of the tasks. Cheers, -- Pete
[jira] Created: (TUSCANY-253) SDO types not being registered in webapp (BigBank)
SDO types not being registered in webapp (BigBank) -- Key: TUSCANY-253 URL: http://issues.apache.org/jira/browse/TUSCANY-253 Project: Tuscany Type: Bug Components: Java SCA Core, Java SCA Axis Binding Reporter: Rick Rineholt Priority: Blocker It doesn't appear that SDO types are being registered in a webapp environment where SCA components have externalServices. apache.tuscany.binding.axis2.util.AxiomHelper.toDataObject(commonj.sdo.helper.TypeHelper, java.lang.Object[], javax.xml.namespace.QName) returns null for xsdHelper.getGlobalProperty(typeQN.getNamespaceURI(), typeQN.getLocalPart(), true); To reproduce run BB URL to start http://localhost:8080/webclient-SNAPSHOT/login.html logon with test/password -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-243) Adding doc-lit support for Axis2 integration
[ http://issues.apache.org/jira/browse/TUSCANY-243?page=comments#action_12377384 ] ant elder commented on TUSCANY-243: --- There's been so many changes this patch isn't even close anymore. I'll have a go at adding wrapped/unwrapped support based on the code in the patch > Adding doc-lit support for Axis2 integration > > > Key: TUSCANY-243 > URL: http://issues.apache.org/jira/browse/TUSCANY-243 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Binding > Reporter: Raymond Feng > Assignee: ant elder > Attachments: client-service.zip, doc-lit-0430-fixed.patch, > doc-lit-0430.patch, doc-lit.patch > > Adding doc-lit support in addtional to doc-lit-wrapped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TUSCANY-243) Adding doc-lit support for Axis2 integration
[ http://issues.apache.org/jira/browse/TUSCANY-243?page=all ] ant elder reassigned TUSCANY-243: - Assign To: ant elder > Adding doc-lit support for Axis2 integration > > > Key: TUSCANY-243 > URL: http://issues.apache.org/jira/browse/TUSCANY-243 > Project: Tuscany > Type: Improvement > Components: Java SCA Axis Binding > Reporter: Raymond Feng > Assignee: ant elder > Attachments: client-service.zip, doc-lit-0430-fixed.patch, > doc-lit-0430.patch, doc-lit.patch > > Adding doc-lit support in addtional to doc-lit-wrapped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TUSCANY-185) samples/bigbank folder mistakenly contains the initial DAS/SCA "customers" sample
[ http://issues.apache.org/jira/browse/TUSCANY-185?page=all ] Rick Rineholt closed TUSCANY-185: - Resolution: Fixed removed. > samples/bigbank folder mistakenly contains the initial DAS/SCA "customers" > sample > - > > Key: TUSCANY-185 > URL: http://issues.apache.org/jira/browse/TUSCANY-185 > Project: Tuscany > Type: Task > Components: Java Samples BigBank > Reporter: Kevin Williams > Assignee: Rick Rineholt > > The "Customers" sample folder is currenlty misplaced under samples/bigbank. > This should be moved to /samples/das -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Location of sca.module
>> Does the first way of packaging outlined above meet your needs? I think it is a sensible way of packaging in the interim. However, as you mentioned there should be a more robust deployment model in the long term and it should be driven from a specification perspective rather than treated as an implementation issue. We also need to look into how SCA deployment model can work together with J2EE packaging and deployment model. >> if you would like to help for Tuscany, just jump in by proposing some ideas to the list Thanks, I would definitely like to. I am familiarising myself with the codebase and running the sample apps. Once I am familiar with the stuff, I wouldn't mind helping out with docs, clearing compiler warnings etc, if you don't mind. We use Mule quite a bit at work and one of the things I find quite good with Mule is the ease of switching between different transports. Though, Mule's way of doing things in a loosely coupled manner on a SEDA-based model is quite elegant, in scenarios where you need strong typing we end up building custom stuff on top of Mule using dynamic proxies that expose strong interfaces and abstracts the interactions with the Mule event bus. This is one thing I quite like in SCA, the way it supports interface-based interactions. Ta Meeraj -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 01 May 2006 22:51 To: tuscany-dev@ws.apache.org Subject: Re: Location of sca.module J2EE deployment integration was one of the to-do items for the spec group (it hasn't been done yet). In terms of the scenario you outlined, I think it would be cleaner to package fragments in the jar files and the sca.module file in the war. This means there is one module per war but I think that is the cleanest approach (and it's what we support with Tomcat) since modules are generally things that are evolved and deployed together, it avoids having to deal with child classloaders, and it makes mapping module components to URIs much easier. Longer term I don't think this will provide a very robust deployment model for the scenarios SCA is designed for and we have been looking at OSGi as a more flexible mechanism. I'm planning to do an OSGi integration when we finish up with the JavaOne release if you are interested. I believe others are interested in deploying to Geronimo so we will need to figure out a broader J2EE deployment story sometime soon (if you would like to help for Tuscany, just jump in by proposing some ideas to the list). Does the first way of packaging outlined above meet your needs? Jim On May 1, 2006, at 1:46 PM, meeraj kunnumpurath wrote: > Thanks Jim. > > I was also thinking about how an SCA deployment unit would be loaded > within the context of a J2EE container. For example, if two module JAR > files are included in the WEB-INF\lib directory of a WAR file, then > would we need to child classloaders to the WAR classloader responsible > for loading each of the SCA modules. Or is there a different behaviour > expected in terms of classloader hierarchy as part of the SCA runtime? > Also, does SCA assembly model define how SCA modules are expected to > be deployed in a J2EE environment? > > Ta > Meeraj > > >> - Original Message - >> From: "Jim Marino" <[EMAIL PROTECTED]> >> To: tuscany-dev@ws.apache.org >> Subject: Re: Location of sca.module >> Date: Mon, 1 May 2006 13:14:55 -0700 >> >> >> There should be one module file per deployment unit. To get the >> intended behavior I believe you want (i.e. a module definition >> composed of a number of fragments), use sca.fragment files and places >> them in the classpath as they will be merged during load. >> On a file system, the directories would just need to be on the >> classpath. >> >> That said, the SCA deployment story needs a lot of work (some of >> which is currently underway). Having only one "top-level" >> sca.module file per deployment unit is a good thing since the URI is >> defined there. I'm not too keen on the classpath merge with multiple >> fragments and we've discussed a plan to move to more of an "include" >> style (i.e. sca.module can include a bunch of fragments or fragments >> can "include themselves" into a module). >> >> Let me know if you run into issues with the existing approach or have >> ideas on making things better. >> >> Jim >> >> >> >> On May 1, 2006, at 7:44 AM, meeraj kunnumpurath wrote: >> >> >>> Hi, >>> >>> Could someone please shed some light on the expected behaviour when >>> more than one sca.module file is found within the scope of the >>> thread context classloader? The spec requires a packaged module JAR >>> file to have exactly one sca.module file at the root. >>> Would this require each module JAR to be loaded by its own >>> classloader. Also, how would this work if the deployemnt unit is a >>> folder in the file- system? >>> >>> Thanks in advance >>> Meeraj >>> >>> -- ___ >>> >>> Search for
Re: C++ release before ApacheCon Europe
+1 Following on from Ed's point. I'm working my way through doing some simple read/write interop test for PHP/C++/Java XML at the moment initially based on the company data example. However to make this a useful test it would seem sensible to make a schema that contains all of the simple and complex types and sequences that we expect to come across in SDO/XML. Has one been made already? On the SCA testing front. Can we use and modify an existing sample like Big Bank to pull in implementations other than Java? I will take a look at it and maybe we can start a separate thread on SCA/SDO interop testing. Regards Simon On 5/2/06, Edward Slattery <[EMAIL PROTECTED]> wrote: +1. From the SDO C++ point of view, the interop that could be done by then would be at the serialized level - I.E being able to load/save the same XML in both systems. In terms of Axis2C support, I am looking into providing a utility to write AXIOM from SDOs and SDO types. Ideally I would do that by creating AXIOM objects directly from SDO properties, but the quick solution would be to stream the SDO to XML, and then use axis2 to read the XML. cheers, Ed. On 01/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: > > I think it would be a good idea to have a release of the C++ subproject > before ApacheCon Europe (Last week in June). > I'll set up a wiki page along the lines of the Java "Tasks" page to set > out > what we need to do to get to a release. > > I'd like to have an IRC chat (Wednesday?) to discuss the functional > content > of this proposed release and how we get there. > > Current thoughts are to have webservice support using Axis2C and a sample > to > demonstrate interoperability with the Java release and ... > > Cheers, > > -- > Pete > >
Re: C++ release before ApacheCon Europe
+1. From the SDO C++ point of view, the interop that could be done by then would be at the serialized level - I.E being able to load/save the same XML in both systems. In terms of Axis2C support, I am looking into providing a utility to write AXIOM from SDOs and SDO types. Ideally I would do that by creating AXIOM objects directly from SDO properties, but the quick solution would be to stream the SDO to XML, and then use axis2 to read the XML. cheers, Ed. On 01/05/06, Pete Robbins <[EMAIL PROTECTED]> wrote: I think it would be a good idea to have a release of the C++ subproject before ApacheCon Europe (Last week in June). I'll set up a wiki page along the lines of the Java "Tasks" page to set out what we need to do to get to a release. I'd like to have an IRC chat (Wednesday?) to discuss the functional content of this proposed release and how we get there. Current thoughts are to have webservice support using Axis2C and a sample to demonstrate interoperability with the Java release and ... Cheers, -- Pete
