Re: Tuscany DAS M2 Exception with default useGetGeneratedKeys = true
some more thoughts on https://issues.apache.org/jira/browse/TUSCANY-1353
and https://issues.apache.org/jira/browse/TUSCANY-1417, as both JIRAs
are effectively for solving the same problem.
Another ML thread on the same issue is -
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19752.html
1)one suggestion from Ron (based on 1353 JIRA comments) is to pass list of
vendors using system properties
2)Another approach can be add in config at Config level a new attribute
like
boolean - databaseGeneratedKeys - default TRUE
With this, setting of ConnectionImpl.useGetGeneratedKeys can be based on
this new attribute from Config.
3)And to further make the solution bullet proof,
ConnectionImpl.prepareStatement(queryString, returnKeys[])
can be changed as follows:-
public PreparedStatement prepareStatement(String queryString, String[]
returnKeys) throws SQLException {
try{
if (this.logger.isDebugEnabled()) {
this.logger.debug(Preparing Statement: + queryString);
}
if (useGetGeneratedKeys) {
System.out.println(if true for gen keys);
return connection.prepareStatement(queryString,
Statement.RETURN_GENERATED_KEYS);
} else if (returnKeys.length 0) {
System.out.println(if false for gen keys and ret keys 0);
return connection.prepareStatement(queryString, returnKeys);
}
return connection.prepareStatement(queryString);
}catch(Exception e){
//try with different setting of useGetGeneratedKeys, if required
if(this.useGetGeneratedKeys){
System.out.println(if true for gen keys - exception - set to
false and try);
this.useGetGeneratedKeys = false;
return prepareStatement(queryString, returnKeys);
}
else{
//this mean, we tried to manipulate this.useGetGeneratedKeys to
false,
//but was of no use, so reset it back as per user Config
if(DAS.databaseGeneratedKeys) {
this.useGetGeneratedKeys = true;
}
System.out.println(if false for gen keys - exception - work
further);
if(e instanceof SQLException){
throw (SQLException)e;
}
else{
throw new RuntimeException(e);
}
}
}
}
With this change, irrespective of what is the Class of Exception occuring,
at maximum one attempt will be made to try with useGetGeneratedKeys false.
4)Also, I could see one design change - as -
In DASImpl, we contain java.sql.Connection and then in 2 different places in
BaseCommandImpl, we create new instances of ConnectionImpl. Will it be a
good idea, if DASImpl itself can contain ConnectionImpl (instead of
java.sql.Connection) and pass it to the Commands? This way, we will be
reducing references to java.sql.Connection and number of ConnectionImpl
instances in the DAS Runtime. This can have some benefit in the context of
memory utilization
Thoughts?
Regards,
Amita
On 6/27/07, Luciano Resende [EMAIL PROTECTED] wrote:
Hi Ron
Could you please provide the das configuration file being used for this
app.
Thanks
On 6/26/07, Ron Gavlin [EMAIL PROTECTED] wrote:
Hi Amita,
Yes, the driver supports this statement. However, is it legal to use
this type of PreparedStatement if the corresponding table has no generated
keys?
- Ron
- Original Message
From: Amita Vadhavkar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, June 26, 2007 7:51:12 AM
Subject: Re: Tuscany DA S M2 Exception with default useGetGeneratedKeys
= true
Please check if the driver you are using is supporting
connection.prepareStatement(queryString,
Statement.*RETURN_GENERATED_KEYS*);
Regards,
Amita
On 6/18/07, Ron Gavlin [EMAIL PROTECTED] wrote:
Greetings,
I am having problems inserting rows with Tuscany DAS M2 using the BEA
WebLogic Sybase JDBC driver (BEA WebLogic 8.1). The code below
generates
the following stacktrace:
...
Command insert = das.createCommand(insert into Test (testCol1,
testCol2)
values (?, ?));
insert.setParameter(1, str1);
insert.setParameter(2, str2);
insert.execute();
Stacktrace:
Caused by: java.sql.SQLException: [BEA][Sybase JDBC Driver]No rows
affected.
at weblogic.jdbc.base.BaseExceptions.createException(Unknown
Source)
at weblogic.jdbc.base.BaseException.getException(Unknown Source)
at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown
Source)
at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown
Source)
at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(
PreparedStatement.java:159)
at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(
Statement.java:173)
at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(
Statement.java:133)
at org.apache.tusany.das.rdb.impl.InsertCommandImpl.execute(
InsertCommandImpl.java:44)
While interactively debugging
Re: [SCA Native] preliminary ant build
Automake generates a config file with lots of standard stuff but the
only one we need is the IS_DARWIN, which is used in 2 places. I'll
remove the 2 references to this header and change automale to set the
IS_DARWIN compile flag.
Cheers,
On 18/07/07, Brady Johnson [EMAIL PROTECTED] wrote:
I did the following diff command and got quite a lot of changes (listed
below):
# diff tuscany_sca_config.h.in tuscany_sca_config.h
Are these not needed?
If not, I can get to work on removing all references to the
file.
If so, then we still need to figure out how to create the file.
I just realized, its 23:30, there... Go to bed! ;)
Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]
0a1
/* tuscany_sca_config.h. Generated by configure. */
4c5
#undef CLOSEDIR_VOID
---
/* #undef CLOSEDIR_VOID */
8c9
#undef HAVE_DIRENT_H
---
#define HAVE_DIRENT_H 1
11c12
#undef HAVE_DLFCN_H
---
#define HAVE_DLFCN_H 1
14c15
#undef HAVE_DOPRNT
---
/* #undef HAVE_DOPRNT */
17c18
#undef HAVE_GETCWD
---
#define HAVE_GETCWD 1
20c21
#undef HAVE_INTTYPES_H
---
#define HAVE_INTTYPES_H 1
23c24
#undef HAVE_MEMORY_H
---
#define HAVE_MEMORY_H 1
26c27
#undef HAVE_NDIR_H
---
/* #undef HAVE_NDIR_H */
29c30
#undef HAVE_PUTENV
---
#define HAVE_PUTENV 1
33c34
#undef HAVE_STAT_EMPTY_STRING_BUG
---
/* #undef HAVE_STAT_EMPTY_STRING_BUG */
36c37
#undef HAVE_STDBOOL_H
---
#define HAVE_STDBOOL_H 1
39c40
#undef HAVE_STDINT_H
---
#define HAVE_STDINT_H 1
42c43
#undef HAVE_STDLIB_H
---
#define HAVE_STDLIB_H 1
45c46
#undef HAVE_STRDUP
---
#define HAVE_STRDUP 1
48c49
#undef HAVE_STRINGS_H
---
#define HAVE_STRINGS_H 1
51c52
#undef HAVE_STRING_H
---
#define HAVE_STRING_H 1
55c56
#undef HAVE_SYS_DIR_H
---
/* #undef HAVE_SYS_DIR_H */
59c60
#undef HAVE_SYS_NDIR_H
---
/* #undef HAVE_SYS_NDIR_H */
62c63
#undef HAVE_SYS_STAT_H
---
#define HAVE_SYS_STAT_H 1
65c66
#undef HAVE_SYS_TIME_H
---
#define HAVE_SYS_TIME_H 1
68c69
#undef HAVE_SYS_TYPES_H
---
#define HAVE_SYS_TYPES_H 1
71c72
#undef HAVE_UNISTD_H
---
#define HAVE_UNISTD_H 1
74c75
#undef HAVE_VPRINTF
---
#define HAVE_VPRINTF 1
77c78
#undef HAVE__BOOL
---
#define HAVE__BOOL 1
80c81
#undef IS_DARWIN
---
/* #undef IS_DARWIN */
84c85
#undef LSTAT_FOLLOWS_SLASHED_SYMLINK
---
#define LSTAT_FOLLOWS_SLASHED_SYMLINK 1
87c88
#undef PACKAGE
---
#define PACKAGE tuscany_sca_native
90c91
#undef PACKAGE_BUGREPORT
---
#define PACKAGE_BUGREPORT
93c94
#undef PACKAGE_NAME
---
#define PACKAGE_NAME tuscany_sca_native
96c97
#undef PACKAGE_STRING
---
#define PACKAGE_STRING tuscany_sca_native 1.0-incubator-M3
99c100
#undef PACKAGE_TARNAME
---
#define PACKAGE_TARNAME tuscany_sca_native
102c103
#undef PACKAGE_VERSION
---
#define PACKAGE_VERSION 1.0-incubator-M3
105c106
#undef STDC_HEADERS
---
#define STDC_HEADERS 1
108c109
#undef VERSION
---
#define VERSION 1.0-incubator-M3
111c112
#undef const
---
/* #undef const */
116c117
#undef inline
---
/* #undef inline */
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 4:22 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build
yeah I figured that... I did exactly the same when committing changes
earlier! I dodn't commit the changes inthe tools folder.
Cheers,
On 18/07/07, Brady Johnson [EMAIL PROTECTED] wrote:
Ok, I wasn't aware that I had changed the tools.
I simply did a svn diff . patch_file from the tuscany root dir.
You can disregard the tools changes. I'll look into it.
Thanks
Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]
-Original Message-
From: Pete Robbins [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 18, 2007 4:16 PM
To: tuscany-dev@ws.apache.org
Subject: Re: [SCA Native] preliminary ant build
Cool! I've applied this change as well. The update2 patch contained
changes to the tools/TuscanyDriver/build.xml. This doesn't work so you
may want to look at it.
Cheers,
On 18/07/07, Brady Johnson [EMAIL PROTECTED] wrote:
If that's all we need the tuscany_sca_config.h file for then, yes
this
just got a whole lot easier. We can do the following on the
Tuscany-BaseCompiler
condition property=mac value=true
os family=mac/
/condition
compiler id=Tuscany-BaseCompiler multithreaded=true
exceptions=true rtti=true
defineset if=windows
define=WIN32,_CRT_SECURE_NO_DEPRECATE,SCA_EXPORTS/
defineset if=mac define=IS_DARWIN/
includepath path=${sdo.include.dir}/
includepath path=${tuscanySCA.root.dir}/ !--
tuscany_sca_config.h --
includepath path=${tuscanySCA.root.src.dir}/
includepath path=${tuscanySCA.root.src.dir}/core/src/
/compiler
Brady Johnson
Lead Software Developer - HydraSCA
Rogue Wave Software - [EMAIL PROTECTED]
-Original Message-
From: Pete Robbins
Re: svn commit: r557494 - in /incubator/tuscany/java/sca/samples: calculator-rmi-reference/src/main/resources/ calculator-rmi-service/src/main/resources/ calculator-script/src/main/resources/ calculat
Do we really need these, line 1033 of the assembly spec says the targetNamespace is optional, and the samples don't use the sample namespace? As they're samples isn't it good to keep the XML as bare and simple as possible? ...ant On 7/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: lresende Date: Wed Jul 18 22:33:05 2007 New Revision: 557494 URL: http://svn.apache.org/viewvc?view=revrev=557494 Log: TUSCANY-1330 - Adding targetNameSpace to sample composites Modified: incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/calculator-webapp/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/calculator/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/chat-webapp/src/main/resources/chat.composite incubator/tuscany/java/sca/samples/das-service-web/src/main/resources/dasservice.composite incubator/tuscany/java/sca/samples/das-service/src/main/resources/dasservice.composite incubator/tuscany/java/sca/samples/helloworld-dojo/src/main/resources/jsonrpc.composite incubator/tuscany/java/sca/samples/helloworld-jsonrpc/src/main/resources/jsonrpc.composite incubator/tuscany/java/sca/samples/implementation-notification/src/test/resources/TrafficAdvisoryNotification.composite incubator/tuscany/java/sca/samples/simple-bigbank-spring/src/main/resources/StockQuote.composite incubator/tuscany/java/sca/samples/simple-bigbank/src/main/resources/StockQuote.composite incubator/tuscany/java/sca/samples/web-resource/src/main/resources/WebResource.composite Modified: incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent Modified: incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent Modified: incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent Modified: incubator/tuscany/java/sca/samples/calculator-webapp/src/main/resources/Calculator.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-webapp/src/main/resources/Calculator.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-webapp/src/main/resources/Calculator.composite (original) +++
Re: [jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support
The one's in the maven repository do seem old, you could try emailing the Saxon mailing list and asking if they'd upload the latest version? ...ant On 7/18/07, Amita Vadhavkar (JIRA) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Amita Vadhavkar updated TUSCANY-1431: - Attachment: net.sf.saxon.8.9.zip as long as maven repos does not contain required version of saxon, this zip file can be extracted in M2_REPO DAS with XQuery based data access support - Key: TUSCANY-1431 URL: https://issues.apache.org/jira/browse/TUSCANY-1431 Project: Tuscany Issue Type: New Feature Components: Java DAS XQuery Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1431.patch, 1431.patch, 1431_api.patch, 1431_xquery.patch, net.sf.saxon.8.9.zip place for submitting incremental patches for the ground work of XQuery DAS -- 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: [Java SDO, SCA and DAS] change of group id and artifact name for sdo api maven artifact
On 7/19/07, kelvin goodson [EMAIL PROTECTED] wrote: I opened https://issues.apache.org/jira/browse/TUSCANY-1437 a few days back with multiple components, touching DAS and SCA as well as SDO in order that it was understood that there were impacts on all these components. The groupId for the API artifact needs to change to org.apache.tuscany.sdoand the artifact-id to tuscany-sdo-api-r2.1. This change arose from feedback on the release candidate. The branch for the SDO 1.0 release already has this renaming in place, but we need a coordinated effort in making this change in the trunk. A knock on effect of the change is that the api jar name has an additional tuscany- prefix on it, so scripts that set up classpaths might need to be changed. The components on this JIRA have just been reset to SDO-Implem, so it's clear that I didn't communicate the cross component nature of the issue very well through that JIRA. In the body of the JIRA I asked people working in the affected component areas to identify the places where this change occurs. Please feed back either in the JIRA or on this thread, the places which are likely to break if we don't coordinate this change, and better still provide a patch for that area so that i can apply all the changes synchronously. It may not be so bad - if the artifacts with the old name remain in the maven repository then while that old api is compatible with the impl then things should still keep on working, shouldn't they? So that would give us a bit of leeway. Searching the SCA code base there's quite a lot of places needing change, I can help do that but would be good if it could be left till at least next week. ...ant
Fwd: [SDO Java] things to be done for SDO release - please help
I posted the attached note yesterday in response to Fuhwei's comments, but unfortunately fell foul of the unexpected missing reply-to issue (eee my P.S.). Regard, Kelvin. P.S. I'm not sure if it's my configuration or that of some people who respond to the list, but I seem to get a small proportion of responses to my posts on the lists that come back to me on my personal email address and secondly to tuscany-dev. When this happens I do not see a reply-to field set to tuscany-dev AT ws.apache.org and so if I only hit reply then the posting goes to the sender alone. Unfortunately the gmail Reply to All button is a bit hidden, so sometimes my responses to these messages go to the sender alone. Does anyone have any suggestions. Is this my problem alone or is there any way that could people look at the way that they respond to the list to make sure that they are sending to the list first, and optionally the poster second. -- Forwarded message -- From: kelvin goodson [EMAIL PROTECTED] Date: 18-Jul-2007 09:35 Subject: Re: [SDO Java] things to be done for SDO release - please help To: Fuhwei Lwo [EMAIL PROTECTED] I believe we have to address this. Do we have a feel for how long it might take to fix? So, just to make sure I have this right, we return to a design where no metadata gets put into EPackage.Registry.INSTANCE. All HelperContexts, whether default or not, have one level of delegation to the builtInModelRegistry. I'll make some headway on the other stuff and work with you on getting this sorted as soon as we can. Regards, Kelvin. On 18/07/07, Fuhwei Lwo [EMAIL PROTECTED] wrote: Kelvin, I hate to slow you down but we may need to change our scoping design and implementation so we have clean codegen fixes from 1143 and are not depending on EMF's EPackage.Registry.INSTANCE. The problem from current 1143 patch is that SDO runtime model are no longer registered with the EPackage.Registry.INSTANCE because we are trying not to use the EPackage.Registry.INSTANCE so 1143 patch took out the registration code in the FactoryBase.java. If we didn't go with the new design, we need to find a way to pre-register SDO runtime models with the EPackage.Registry.INSTANCE in addition to the builtInModelRegistry. Let me try to describe the new design here and see whether it makes sense. Current: The default helper context is associated with the EPackage.Registry.INSTANCE so all the model packages get/put operations will be based on the registry from the TCCL. The local helper context (from SDOUtil.createHelperContext()) is associated with the local package registry. If the model packages get/put operations failed, the delegation chain is builtInModelRegistry then EPackage.Registry.INSTANCE * default HelperContext (EPackage.Registry.INSTANCE/TCCL based) * local HelperContext (local package registry) --delegate-- builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE EMF and SDO runtime models resided in EPackage.Registry.INSTANCE SDO type models ( sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) resided in both builtInModelRegistry and EPackage.Registry.INSTANCE (registered in the FactoryBase.java) User models will reside either in the EPackage.Registry or local package registry New: default HelperContext (SDOPackageRegistryImpl/TCCL based) --delegate-- builtInModelRegistry local HelperContext (local package registry) --delegate-- builtInModelRegistry EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry User models will reside either in the SDOPackageRegistryImpl(TCCL based) or local package registry This new scoping design needs to closely work with TUSCANY-1143 because the new codegen pattern needs to be used to generate the SDO runtime models to support this new design. Let me know whether we should pursue this. Thanks. Fuhwei *kelvin goodson [EMAIL PROTECTED]* wrote: This release is running later than I had hoped due to extra jiras being added to the plan, and a few issues that have come up after recent fixe, so we are a bit behind where I'd proposed we should be in terms of getting this release out. Please help with some of these TODOs if you can. If you plan to tackle anything please post here so that we don't overlap; I'll do the same. these are the things that I think are must-fix 1143 -- the issues re test failures are being resolved -- david's working on this 1429 -- i've looked at this and it is fine apart from the casting to HelperContextImpls -- i put a note on the jira, 1428 -- note appended to jira asking for code to exercise/demonstrate the fix other issues raised on the list the pom has a provided scope dependency on stax -- I will fix this as per my note to tuscany-dev use rat results to fix license header issues and post rat results check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch the following have been raised by comments on RC1 NOTICE files (create
Re: [SCA Native] preliminary ant build
I've taken out the references to tuscany_sca_config.h and patched the automake for now with setting -DIS_DARWIN on mac. Yet to test it on Mac as I need to kick the kids off my machine! On 19/07/07, Pete Robbins [EMAIL PROTECTED] wrote: Automake generates a config file with lots of standard stuff but the only one we need is the IS_DARWIN, which is used in 2 places. I'll remove the 2 references to this header and change automale to set the IS_DARWIN compile flag. Cheers, On 18/07/07, Brady Johnson [EMAIL PROTECTED] wrote: I did the following diff command and got quite a lot of changes (listed below): # diff tuscany_sca_config.h.in tuscany_sca_config.h Are these not needed? If not, I can get to work on removing all references to the file. If so, then we still need to figure out how to create the file. I just realized, its 23:30, there... Go to bed! ;) Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] 0a1 /* tuscany_sca_config.h. Generated by configure. */ 4c5 #undef CLOSEDIR_VOID --- /* #undef CLOSEDIR_VOID */ 8c9 #undef HAVE_DIRENT_H --- #define HAVE_DIRENT_H 1 11c12 #undef HAVE_DLFCN_H --- #define HAVE_DLFCN_H 1 14c15 #undef HAVE_DOPRNT --- /* #undef HAVE_DOPRNT */ 17c18 #undef HAVE_GETCWD --- #define HAVE_GETCWD 1 20c21 #undef HAVE_INTTYPES_H --- #define HAVE_INTTYPES_H 1 23c24 #undef HAVE_MEMORY_H --- #define HAVE_MEMORY_H 1 26c27 #undef HAVE_NDIR_H --- /* #undef HAVE_NDIR_H */ 29c30 #undef HAVE_PUTENV --- #define HAVE_PUTENV 1 33c34 #undef HAVE_STAT_EMPTY_STRING_BUG --- /* #undef HAVE_STAT_EMPTY_STRING_BUG */ 36c37 #undef HAVE_STDBOOL_H --- #define HAVE_STDBOOL_H 1 39c40 #undef HAVE_STDINT_H --- #define HAVE_STDINT_H 1 42c43 #undef HAVE_STDLIB_H --- #define HAVE_STDLIB_H 1 45c46 #undef HAVE_STRDUP --- #define HAVE_STRDUP 1 48c49 #undef HAVE_STRINGS_H --- #define HAVE_STRINGS_H 1 51c52 #undef HAVE_STRING_H --- #define HAVE_STRING_H 1 55c56 #undef HAVE_SYS_DIR_H --- /* #undef HAVE_SYS_DIR_H */ 59c60 #undef HAVE_SYS_NDIR_H --- /* #undef HAVE_SYS_NDIR_H */ 62c63 #undef HAVE_SYS_STAT_H --- #define HAVE_SYS_STAT_H 1 65c66 #undef HAVE_SYS_TIME_H --- #define HAVE_SYS_TIME_H 1 68c69 #undef HAVE_SYS_TYPES_H --- #define HAVE_SYS_TYPES_H 1 71c72 #undef HAVE_UNISTD_H --- #define HAVE_UNISTD_H 1 74c75 #undef HAVE_VPRINTF --- #define HAVE_VPRINTF 1 77c78 #undef HAVE__BOOL --- #define HAVE__BOOL 1 80c81 #undef IS_DARWIN --- /* #undef IS_DARWIN */ 84c85 #undef LSTAT_FOLLOWS_SLASHED_SYMLINK --- #define LSTAT_FOLLOWS_SLASHED_SYMLINK 1 87c88 #undef PACKAGE --- #define PACKAGE tuscany_sca_native 90c91 #undef PACKAGE_BUGREPORT --- #define PACKAGE_BUGREPORT 93c94 #undef PACKAGE_NAME --- #define PACKAGE_NAME tuscany_sca_native 96c97 #undef PACKAGE_STRING --- #define PACKAGE_STRING tuscany_sca_native 1.0-incubator-M3 99c100 #undef PACKAGE_TARNAME --- #define PACKAGE_TARNAME tuscany_sca_native 102c103 #undef PACKAGE_VERSION --- #define PACKAGE_VERSION 1.0-incubator-M3 105c106 #undef STDC_HEADERS --- #define STDC_HEADERS 1 108c109 #undef VERSION --- #define VERSION 1.0-incubator-M3 111c112 #undef const --- /* #undef const */ 116c117 #undef inline --- /* #undef inline */ -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 4:22 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build yeah I figured that... I did exactly the same when committing changes earlier! I dodn't commit the changes inthe tools folder. Cheers, On 18/07/07, Brady Johnson [EMAIL PROTECTED] wrote: Ok, I wasn't aware that I had changed the tools. I simply did a svn diff . patch_file from the tuscany root dir. You can disregard the tools changes. I'll look into it. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 4:16 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build Cool! I've applied this change as well. The update2 patch contained changes to the tools/TuscanyDriver/build.xml. This doesn't work so you may want to look at it. Cheers, On 18/07/07, Brady Johnson [EMAIL PROTECTED] wrote: If that's all we need the tuscany_sca_config.h file for then, yes this just got a whole lot easier. We can do the following on the Tuscany-BaseCompiler condition property=mac value=true os family=mac/ /condition compiler id=Tuscany-BaseCompiler multithreaded=true exceptions=true rtti=true defineset if=windows define=WIN32,_CRT_SECURE_NO_DEPRECATE,SCA_EXPORTS/ defineset
[jira] Created: (TUSCANY-1454) binding.ws malfunction with customer data types
binding.ws malfunction with customer data types --- Key: TUSCANY-1454 URL: https://issues.apache.org/jira/browse/TUSCANY-1454 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: winXP, java5, sca java svn Reporter: 耿韶光 I was working with Tuscany's binding.ws these two days, I established a service provider. I found that if the element type is base types(xsd type such as int, string), it worked find. Since I remember a mail in the list has metiond complexTypes doesn't work some what. So I tried this out, and, it was . The service just worked the first time it was accessed, then I refused to work any more. I traced the code for some depth, I found the error came from a dom instance was always held, and the same dom serves all the following request, then a error checking method produces a Exception. I will look into these code next monday, for the time being, I cry this out, wish some one could devote. -- 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] Created: (TUSCANY-1454) binding.ws malfunction with customer data types
This sounds like an interesting problem. If you could attach any of the code you used to show this it would be really helpful to recreate and debug, doesn't have to be testcase or patch or anything complicated, just a zip of any files you have would help. ...ant On 7/19/07, 耿韶光 (JIRA) tuscany-dev@ws.apache.org wrote: binding.ws malfunction with customer data types --- Key: TUSCANY-1454 URL: https://issues.apache.org/jira/browse/TUSCANY-1454 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: winXP, java5, sca java svn Reporter: 耿韶光 I was working with Tuscany's binding.ws these two days, I established a service provider. I found that if the element type is base types(xsd type such as int, string), it worked find. Since I remember a mail in the list has metiond complexTypes doesn't work some what. So I tried this out, and, it was . The service just worked the first time it was accessed, then I refused to work any more. I traced the code for some depth, I found the error came from a dom instance was always held, and the same dom serves all the following request, then a error checking method produces a Exception. I will look into these code next monday, for the time being, I cry this out, wish some one could devote. -- 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: [SDO Java] things to be done for SDO release - please help
16 is done, will now do ... 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples that leaves ... 2 use rat results to fix license header issues and post rat results 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 17 add the change summary aspects of the medical scenario sample I think perhaps also we should make a quick fox for tuscany-1146 (samples don't compile with java 1.4.2) Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: 12 is done On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: Oops, I copied 3 across unnecessarily-- it's done. I'm back looking at 12 now. Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: 11 seemed to be a no-op 13 is done 14 is done leaving ... 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 12 exclude samples infrastructure classes from samples javadoc 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples 16 put an overview doc into the sdo lib project's javadoc 17 add the change summary aspects of the medical scenario sample On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: I have now ported 4 or 5 fixes that had been made to the trunk but not to the branch (task 3). While we are in this pre-release phase if you could create a patch of your local workspace when working in the trunk before committing and attach it to the JIRA, then that eases the task of porting to the branch. Better still would be to apply the patch to the branch too. Now I'm going to look at the samples javadoc issues, phase 1 = tasks 11, 12, 13, 14 Regards, Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: just did 4,5,7,8,9,10(a) -- still not run the linux script so that leaves 2,3,6,11,12,13,14, and 15,16,17 (which were badly numbered as 12,13,14 -- doh!) 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 11 fix up bad javadoc links in samples index.html 12 exclude samples infrastructure classes from samples javadoc 13 fix link back to tuscany site from overview.html to point to the get involved page 14 incorporate Haleh's suggested paragraph [1] into overview.html 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples 16 put an overview doc into the sdo lib project's javadoc 17 add the change summary aspects of the medical scenario sample I'm going to tackle 3 now Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: I'm going to number off the non jira related tasks so that its easy to reference them I just did 1 and now plan to do 4,5,7,8,9 1 the pom has a provided scope dependency on stax -- I will fix this as per my note to tuscany-dev 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch the following have been raised by comments on RC1 4 NOTICE files (create separate ones for impl and bin and ensure no disclaimer contained) 5 need to update release notes with descriptive para and fixed jiras 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 7 should remove EPL license from src distro 8 add stax reference in bin distro license 9 add readme to bin distro samples folder 10 fix up runsamples scripts to be more robust/helpful and ensure that the runsamples.sh script runs ok in a linux env 11 fix up bad javadoc links in samples index.html 12 exclude samples infrastructure classes from samples javadoc 13 fix link back to tuscany site from overview.html to point to the get involved page 14 incorporate Haleh's suggested paragraph [1] into overview.html and some of my own todos that I hope to get to 12 ensure consistency of each sample program's javadoc to point back to central instructions for running samples 13 put an overview doc into the sdo lib project's javadoc 14 add the change summary aspects of the medical scenario sample Regards, Kelvin On 17/07/07, kelvin goodson [EMAIL
Re: [SDO Java] things to be done for SDO release - please help
Of course I meant fix, not fox, and more importantly TUSCANY-1446, not 1146 Kelvin. On 19/07/07, kelvin goodson [EMAIL PROTECTED] wrote: 16 is done, will now do ... 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples that leaves ... 2 use rat results to fix license header issues and post rat results 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 17 add the change summary aspects of the medical scenario sample I think perhaps also we should make a quick fox for tuscany-1146 (samples don't compile with java 1.4.2) Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: 12 is done On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: Oops, I copied 3 across unnecessarily-- it's done. I'm back looking at 12 now. Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: 11 seemed to be a no-op 13 is done 14 is done leaving ... 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 12 exclude samples infrastructure classes from samples javadoc 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples 16 put an overview doc into the sdo lib project's javadoc 17 add the change summary aspects of the medical scenario sample On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: I have now ported 4 or 5 fixes that had been made to the trunk but not to the branch (task 3). While we are in this pre-release phase if you could create a patch of your local workspace when working in the trunk before committing and attach it to the JIRA, then that eases the task of porting to the branch. Better still would be to apply the patch to the branch too. Now I'm going to look at the samples javadoc issues, phase 1 = tasks 11, 12, 13, 14 Regards, Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: just did 4,5,7,8,9,10(a) -- still not run the linux script so that leaves 2,3,6,11,12,13,14, and 15,16,17 (which were badly numbered as 12,13,14 -- doh!) 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 11 fix up bad javadoc links in samples index.html 12 exclude samples infrastructure classes from samples javadoc 13 fix link back to tuscany site from overview.html to point to the get involved page 14 incorporate Haleh's suggested paragraph [1] into overview.html 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples 16 put an overview doc into the sdo lib project's javadoc 17 add the change summary aspects of the medical scenario sample I'm going to tackle 3 now Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: I'm going to number off the non jira related tasks so that its easy to reference them I just did 1 and now plan to do 4,5,7,8,9 1 the pom has a provided scope dependency on stax -- I will fix this as per my note to tuscany-dev 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch the following have been raised by comments on RC1 4 NOTICE files (create separate ones for impl and bin and ensure no disclaimer contained) 5 need to update release notes with descriptive para and fixed jiras 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 7 should remove EPL license from src distro 8 add stax reference in bin distro license 9 add readme to bin distro samples folder 10 fix up runsamples scripts to be more robust/helpful and ensure that the runsamples.sh script runs ok in a linux env 11 fix up bad javadoc links in samples index.html 12 exclude samples infrastructure classes from samples javadoc 13 fix link back to tuscany site from overview.html to point to the get involved page 14 incorporate Haleh's suggested paragraph [1] into overview.html and some of my own todos that I hope to get to 12 ensure consistency of each sample program's javadoc to
Re: Question on callback bindings
I am implementing approach 1). The code is turning out to be straightforward and this approach fully supports the SCA callback spec AIUI. The Axis2 callback MEP isn't the same as an SCA callback, and it's confusing that these have the same name. With the Axis2 callback MEP, the forward call is sent asynchronously, and the callback message carries the result from the forward call. In SCA, the callback is a normal call made in the reverse direction, and the signature of the callback is unrelated to the signature of the forward call. Simon Simon Laws wrote: On 7/18/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Assuming we have the following declaration: reference r1 is wired to service s1. reference name=r1 interface.wsdl interface=http://ns1#wsdl.interface(Service1) callbackInterface=http://ns1#wsdl.interface(Service1Callback)/ binding.ws .../ callback binding.ws .../ /callback /reference service name=s1 interface.wsdl interface=http://ns1#wsdl.interface(Service1) callbackInterface=http://ns1#wsdl.interface(Service1Callback)/ binding.ws .../ callback binding.ws .../ /callback /reference Then the callback path seems to be following: s1 (binding.ws) --- r1 (binding.ws). Is this like another web service call? or is it really that the s1 provides asynchronous response to the web service layer and the web service client is making a callback? For the forward call, r1 -- ws client ..(soap/http) .ws service --s1. Which path should be used for the callback? 1) s1-- ws client ..(soap/http) .ws service --r1 (another regular ws call) or 2) s1--(ws-callback)-- ws server ...(soap/http) ... ws client --(ws-callback)--r1 (over ws callback MEP) Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Well 1) would be useful if the callback occurs outside of the context of the original call or if the callback doesn't happen for a really long time, i.e. long enough for connection timeouts. Downside, I guess, is to do the plumbing to host the callback. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WireableBinding questions
I have some questions about the new interface WireableBinding that was checked in as part of revision r557195. 1. Is it intended that all bindings should (eventually) implement this interface, or only some of them? If only some of them, what's the guideline for which bindings should implement it and which should not? 2. For bindings that don't (yet) implement it (i.e., all the current extension bindings), what are the limitations on what can be done with these bindings? 3. This interface introduces three new getter/setter properties: TargetComponent TargetComponentService TargetBinding How are these set/used for reference bindings by the core wiring framework? And how are they set/used for service bindings? 4. The core wiring framework is now calling getURI() as part of its determination of whether or not a binding has an endpoint. Does this put new obligations on extension bindings to call their setURI() method even if no uri attribute was specified in the SCDL? 5. Are there any other changes that extension binding writers need to make (or are recommended to make) to fully support the new multiple bindings support for references with multiplicity and promotion? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1353) Exception attempting to insert rows using DAS w/DataDirect JDBC driver
[ https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513873 ] Ron Gavlin commented on TUSCANY-1353: - The problem appears to be a DataDirect JDBC bug that is triggered when STATEMENT.RETURN_GENERATED_KEYS is true and setAutoCommit is false. In many DAS deployments, this will be a common situation. Obviously, providing a convenient, externalized mechanism for controlling the useGetGeneratedKeys flag is desired. Hibernate allows this setting to be controlled via a property named hibernate.jdbc.use_get_generated_keys which can be set as a system property or in the hibernate configuration file. In the absence of this property, hibernate uses the database metadata supportsGetGeneratedKeys. This seems like the right approach to me. As Amita suggested on the mailing list, how about adding an optional Config attribute named databaseGeneratedKeys (or useGetGeneratedKeys). If absent, the value is derived from the database metadata supportsGetGeneratedKeys. If present, the supplied value is used. I personally don't think add'l bulletproofing is required. For folks with multiple DAS config files, a JVM property which overrides the Config databaseGeneratedKeys attribute might be convenient. However, since DAS doesn't currently support configuration by JVM properties, I don't think it makes sense to introduce this configurable as a JVM property. Thoughts? - Ron Exception attempting to insert rows using DAS w/DataDirect JDBC driver -- Key: TUSCANY-1353 URL: https://issues.apache.org/jira/browse/TUSCANY-1353 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-M2 Environment: Windows XP, WebLogic 8.1SP6, Sybase 12.5, DataDirect Sybase JDBC driver (embedded within BEA WebLogic) Reporter: Ron Gavlin Priority: Critical Greetings, I am having problems inserting rows with Tuscany DAS M2 using the BEA WebLogic Sybase JDBC driver (DataDirect Connect for JDBC 3.6 June 2007)) which is an embedded version of the popular DataDirect JDBC driver. Although I have not tested it, I suspect this problem appears in non-Sybase versions of the driver as well. The code below generates the listed stacktrace. Note: BEA apparently renames the DataDirect Connect for JDBC classes as part of its embedding process. ... Command insert = das.createCommand(insert into Test (testCol1, testCol2) values (?, ?)); insert.setParameter(1, str1); insert.setParameter(2, str2); insert.execute(); Stacktrace: Caused by: java.sql.SQLException: [BEA][Sybase JDBC Driver]No rows affected. at weblogic.jdbc.base.BaseExceptions.createException(Unknown Source) at weblogic.jdbc.base.BaseException.getException(Unknown Source) at weblogic.jdbc.base.BaseStatement.executeUpdateInternal(Unknown Source) at weblogic.jdbc.base.BasePreparedStatement.executeUpdate(Unknown Source) at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:159) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:173) at org.apache.tusany.das.rdb.impl.Statement.executeUpdate(Statement.java:133) at org.apache.tusany.das.rdb.impl.InsertCommandImpl.execute(InsertCommandImpl.java:44) While interactively debugging org.apache.tuscany.das.rdb.impl.ConnectionImpl.prepareStatement(String queryString, String[] returnKeys), I noticed if I manually change the boolean member variable useGetGeneratedKeys to false, no exception is generated and the insert works as designed. The DataDirect Connect for JDBC drivers are either supported or embedded into numerous commercial application servers, including IBM WebSphere 6.1, jBoss 4.x, and BEA WebSphere. Folks using these platforms are likely to quickly hit this problem if they attempt to use the DAS. - Ron -- 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: svn commit: r557494 - in /incubator/tuscany/java/sca/samples: calculator-rmi-reference/src/main/resources/ calculator-rmi-service/src/main/resources/ calculator-script/src/main/resources/ calculat
Folks, I tend to agree with Ant. The namespace gets necessary once we get into inter-contribution sharing of artifacts and then the namespace is essential, but I dont think it is necessary or useful in the simpler examples. I DO think we need to add the XSD location for the SCA namespace, however - this is useful for tooling using the composite files, for example. This is covered by JIRA 1443. Yours, Mike. ant elder wrote: Do we really need these, line 1033 of the assembly spec says the targetNamespace is optional, and the samples don't use the sample namespace? As they're samples isn't it good to keep the XML as bare and simple as possible? ...ant On 7/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: lresende Date: Wed Jul 18 22:33:05 2007 New Revision: 557494 URL: http://svn.apache.org/viewvc?view=revrev=557494 Log: TUSCANY-1330 - Adding targetNameSpace to sample composites Modified: incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/calculator-webapp/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/calculator/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/chat-webapp/src/main/resources/chat.composite incubator/tuscany/java/sca/samples/das-service-web/src/main/resources/dasservice.composite incubator/tuscany/java/sca/samples/das-service/src/main/resources/dasservice.composite incubator/tuscany/java/sca/samples/helloworld-dojo/src/main/resources/jsonrpc.composite incubator/tuscany/java/sca/samples/helloworld-jsonrpc/src/main/resources/jsonrpc.composite incubator/tuscany/java/sca/samples/implementation-notification/src/test/resources/TrafficAdvisoryNotification.composite incubator/tuscany/java/sca/samples/simple-bigbank-spring/src/main/resources/StockQuote.composite incubator/tuscany/java/sca/samples/simple-bigbank/src/main/resources/StockQuote.composite incubator/tuscany/java/sca/samples/web-resource/src/main/resources/WebResource.composite Modified: incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent Modified: incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent Modified: incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample;
[jira] Assigned: (TUSCANY-1443) sample composite files are invalid instance documents against SCA schema types
[ https://issues.apache.org/jira/browse/TUSCANY-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Edwards reassigned TUSCANY-1443: - Assignee: Mike Edwards sample composite files are invalid instance documents against SCA schema types -- Key: TUSCANY-1443 URL: https://issues.apache.org/jira/browse/TUSCANY-1443 Project: Tuscany Issue Type: Bug Components: C++ SCA Environment: all Reporter: Michael Yoder Assignee: Mike Edwards The SCA samples composite files are invalid against the SCA schemas. In a component element, the property element has content. e.g. (from CppBigBank) component name=AccountServiceComponent . property name=currencyEURO/property /component When the XML Schema type does not allow mixed or simple content: complexType name=PropertyType complexContent extension base=anyType attribute name=name type=NCName use=required / attribute name=type type=QName use=required / attribute name=many type=boolean default=false use=optional / attribute name=override type=sca:OverrideOptions default=may use=optional / anyAttribute namespace=##any processContents=lax / /extension /complexContent /complexType The type is open to additional attributes, so the instance documents can be made valid with simple changes like this: component name=AccountServiceComponent . property name=currency value=EURO/ /component -- 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: [SDO Java] things to be done for SDO release - please help
I did 15 and am now looking at applying T-1429 Kelvin. On 19/07/07, kelvin goodson [EMAIL PROTECTED] wrote: Of course I meant fix, not fox, and more importantly TUSCANY-1446, not 1146 Kelvin. On 19/07/07, kelvin goodson [EMAIL PROTECTED] wrote: 16 is done, will now do ... 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples that leaves ... 2 use rat results to fix license header issues and post rat results 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 17 add the change summary aspects of the medical scenario sample I think perhaps also we should make a quick fox for tuscany-1146 (samples don't compile with java 1.4.2) Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: 12 is done On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: Oops, I copied 3 across unnecessarily-- it's done. I'm back looking at 12 now. Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: 11 seemed to be a no-op 13 is done 14 is done leaving ... 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 12 exclude samples infrastructure classes from samples javadoc 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples 16 put an overview doc into the sdo lib project's javadoc 17 add the change summary aspects of the medical scenario sample On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: I have now ported 4 or 5 fixes that had been made to the trunk but not to the branch (task 3). While we are in this pre-release phase if you could create a patch of your local workspace when working in the trunk before committing and attach it to the JIRA, then that eases the task of porting to the branch. Better still would be to apply the patch to the branch too. Now I'm going to look at the samples javadoc issues, phase 1 = tasks 11, 12, 13, 14 Regards, Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: just did 4,5,7,8,9,10(a) -- still not run the linux script so that leaves 2,3,6,11,12,13,14, and 15,16,17 (which were badly numbered as 12,13,14 -- doh!) 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 10b ensure that the runsamples.sh script runs ok in a linux env 11 fix up bad javadoc links in samples index.html 12 exclude samples infrastructure classes from samples javadoc 13 fix link back to tuscany site from overview.html to point to the get involved page 14 incorporate Haleh's suggested paragraph [1] into overview.html 15 ensure consistency of each sample program's javadoc to point back to central instructions for running samples 16 put an overview doc into the sdo lib project's javadoc 17 add the change summary aspects of the medical scenario sample I'm going to tackle 3 now Kelvin. On 18/07/07, kelvin goodson [EMAIL PROTECTED] wrote: I'm going to number off the non jira related tasks so that its easy to reference them I just did 1 and now plan to do 4,5,7,8,9 1 the pom has a provided scope dependency on stax -- I will fix this as per my note to tuscany-dev 2 use rat results to fix license header issues and post rat results 3 check that all recent fixes in the trunk since the branch was made have equivalent fixes in the branch the following have been raised by comments on RC1 4 NOTICE files (create separate ones for impl and bin and ensure no disclaimer contained) 5 need to update release notes with descriptive para and fixed jiras 6 need to remove dependencies on snapshot plugins (rfeng 13/7) 7 should remove EPL license from src distro 8 add stax reference in bin distro license 9 add readme to bin distro samples folder 10 fix up runsamples scripts to be more robust/helpful and ensure that the runsamples.sh script runs ok in a linux env 11 fix up bad javadoc links in samples index.html 12 exclude samples infrastructure classes from samples javadoc 13 fix link back to tuscany site from
Re: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field
Hi Folks, JIRA-1453 opened for this issue is perfectly fixing Blob and ByteArray. Clob and Array, seem to be the only remaining types where TypeHelper.getType(commonj.sdo,...) returns null. Same approach as JIRA-1453 can work the Clob , but for Array? Any hints? Can the same JIRA be used or new JIRA be opened, so this issue does not remain half complete? Regards, Amita On 7/19/07, Kevin Williams [EMAIL PROTECTED] wrote: -- Forwarded message -- From: Kevin Williams [EMAIL PROTECTED] Date: Jul 18, 2007 1:33 PM Subject: Re: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hello Li Taojian, You have uncovered a bug and also found a good fix. It would be very helpful if you could open a JIRA for this bug and also submit your fix as a patch. You can find instruction for doing this here: http://incubator.apache.org/tuscany/issue-tracking.html It would be even better if you could submit an addition to the DAS testuite to verify your fix. Thanks for your interest in the DAS. --Kevin On 7/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All , I modified the ByteArry and BLOB to Bytes in the ResultSetTypeMap.java , and then I could run a sample of reading the BLOB field , I test the sample on Mysql 5.0 , It could run correctly . Maybe this is a bug . ResultSetTypeMap.java case Types.BINARY: case Types.VARBINARY: case Types.LONGVARBINARY: return helper.getType(commonj.sdo, Bytes); // before is return helper.getType(commonj.sdo, ByteArray); case Types.BLOB: return helper.getType(commonj.sdo, Bytes); // before is return helper.getType(commonj.sdo, Blob); -邮件原件- 发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 发送时间: 2007年7月18日 16:54 收件人: [EMAIL PROTECTED] 主题: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field Hi All , I need the DAS to support reading and write the BLOB field , but TypeHelper.getType(commonj.sdo, Blob) is return null , Could you give me some tips to implement the function or fix out the bugs ? Or How could I implement the function immediately ? Li Taojian . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RDB DAS] Solution:sample-ajax-das failing due to SDO-XMLHelpe.save() changes
There is some change in SDO around XMLHelper.save(DO, uri, elementname) - I could not locate which SDO JIRA it is, but due to this, when the query result from DAS are saved into String using XMLHelper.save() - all ones that used to be attributes are now elements. e.g. OLD: ?xml version='1.0' encoding='ISO-8859-1' ? root xmlns:das='http://org.apache.tuscany.das.rdb/config.xsd' xmlns:xsi=' http://www.w3.org/2001/XMLSchema-instance' das:DataGraphRoot COMPANY ID='10' NAME='ACME10 Publishing' /COMPANY /das:DataGraphRoot /root NEW: ?xml version='1.0' encoding='ISO-8859-1' ? root xmlns:das='http://org.apache.tuscany.das.rdb/config.xsd' xmlns:xsi=' http://www.w3.org/2001/XMLSchema-instance' das:DataGraphRoot COMPANY ID10/ID NAMEACME10 Publishing/NAME /COMPANY /das:DataGraphRoot /root In sample-ajax-das:- to take into account this change in xml serialization, 1)all the XSLs used had to change and 2) also the htmlunit test case code where attributes where referred in asserts had to change to referring to corresponding elements. With 1) and 2) , now sample-ajax-das is working as web sample as well as all htmlunit test cases are succeeding In companyweb sample:- There are no changes required, and it is working as web sample and in htmlunit cases. I have created a patch for this and will attach to JIRA when I can access the site. Regards, Amita
Re: An idea for WS Reference
Shaoguang, The SCA specifications allow for the WSDL file to be referenced from a single location, which can include a remote location, via mechanisms such as wsdl:location or via the SCA artifact resolution mechanism (see SCA Assembly spec at www.osoa.org). So copying the WSDL file is not necessary. However, for a Java developer, there is usually the need to derive a Java interface from the WSDL in order to write the Java code for that interface. It is always possible then, that the Java interface gets out of sync with the WSDL file. There is no easy way around this, but the SCA runtime can at least check for compatibility and raise a fault if they do not match. Yours, Mike. shaoguang geng wrote: WS consumer will have to put a wsdl file in it class root, the SCADomain load it automaticly. But this brings a problem if the provider's wsdl changed. So first I think if the consumer could load the wsdl from http://[host]:[port]/[servicename]?wsdl,. There by, when debug the wsdl, the developer will have to edit on the two side. Would anyone think this a better idea? - Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Java SDO, DAS and SCA] alteration to unreleased API
Headline message for SCA (and perhaps DAS) -- this is notice of a change that will require minor updates in order not to break the build We have 2 new things in SDO that are of significance to this message that have come about since the beta1 release. 1) An improved notion of what embodies a scope for types -- the HelperContext (previously the story was confused because the TypeHelper was used for this purpose at times) 2) Restructuring of the code so that it is clear what it Tuscany SDO API ( i.e. Tuscany extensions as opposed to the SDO API itself) However, the API in the trunk still uses a TypeHelper to be passed into half a dozen methods to represent the scope. It would be an awful shame not to fix this, and it would also look odd to go out with a brand new API that already has deprecations. I have altered the API in the SDO release branch [1]. As far as I can tell from poking around in eclipse, SCA makes about half a dozen calls into the API, so it's a small job to fix this up. Can someone is SCA please liaise with me to get this done at our mutual convenience, thanks. Kelvin. [1] http://svn.apache.org/viewvc/incubator/tuscany/branches/sdo-1.0-incubating/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java?view=diffrev=557615r1=557614r2=557615http://svn.apache.org/viewvc/incubator/tuscany/branches/sdo-1.0-incubating/impl/src/main/java/org/apache/tuscany/sdo/helper/SDOHelperImpl.java?view=diffrev=557615r1=557614r2=557615
RE: [SCA Native] preliminary ant build
I can look into testing it on Mac here. I believe we have several mac machines for the purpose. I'll get back to you soon. Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 2:44 AM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build I've taken out the references to tuscany_sca_config.h and patched the automake for now with setting -DIS_DARWIN on mac. Yet to test it on Mac as I need to kick the kids off my machine! On 19/07/07, Pete Robbins [EMAIL PROTECTED] wrote: Automake generates a config file with lots of standard stuff but the only one we need is the IS_DARWIN, which is used in 2 places. I'll remove the 2 references to this header and change automale to set the IS_DARWIN compile flag. Cheers, On 18/07/07, Brady Johnson [EMAIL PROTECTED] wrote: I did the following diff command and got quite a lot of changes (listed below): # diff tuscany_sca_config.h.in tuscany_sca_config.h Are these not needed? If not, I can get to work on removing all references to the file. If so, then we still need to figure out how to create the file. I just realized, its 23:30, there... Go to bed! ;) Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] 0a1 /* tuscany_sca_config.h. Generated by configure. */ 4c5 #undef CLOSEDIR_VOID --- /* #undef CLOSEDIR_VOID */ 8c9 #undef HAVE_DIRENT_H --- #define HAVE_DIRENT_H 1 11c12 #undef HAVE_DLFCN_H --- #define HAVE_DLFCN_H 1 14c15 #undef HAVE_DOPRNT --- /* #undef HAVE_DOPRNT */ 17c18 #undef HAVE_GETCWD --- #define HAVE_GETCWD 1 20c21 #undef HAVE_INTTYPES_H --- #define HAVE_INTTYPES_H 1 23c24 #undef HAVE_MEMORY_H --- #define HAVE_MEMORY_H 1 26c27 #undef HAVE_NDIR_H --- /* #undef HAVE_NDIR_H */ 29c30 #undef HAVE_PUTENV --- #define HAVE_PUTENV 1 33c34 #undef HAVE_STAT_EMPTY_STRING_BUG --- /* #undef HAVE_STAT_EMPTY_STRING_BUG */ 36c37 #undef HAVE_STDBOOL_H --- #define HAVE_STDBOOL_H 1 39c40 #undef HAVE_STDINT_H --- #define HAVE_STDINT_H 1 42c43 #undef HAVE_STDLIB_H --- #define HAVE_STDLIB_H 1 45c46 #undef HAVE_STRDUP --- #define HAVE_STRDUP 1 48c49 #undef HAVE_STRINGS_H --- #define HAVE_STRINGS_H 1 51c52 #undef HAVE_STRING_H --- #define HAVE_STRING_H 1 55c56 #undef HAVE_SYS_DIR_H --- /* #undef HAVE_SYS_DIR_H */ 59c60 #undef HAVE_SYS_NDIR_H --- /* #undef HAVE_SYS_NDIR_H */ 62c63 #undef HAVE_SYS_STAT_H --- #define HAVE_SYS_STAT_H 1 65c66 #undef HAVE_SYS_TIME_H --- #define HAVE_SYS_TIME_H 1 68c69 #undef HAVE_SYS_TYPES_H --- #define HAVE_SYS_TYPES_H 1 71c72 #undef HAVE_UNISTD_H --- #define HAVE_UNISTD_H 1 74c75 #undef HAVE_VPRINTF --- #define HAVE_VPRINTF 1 77c78 #undef HAVE__BOOL --- #define HAVE__BOOL 1 80c81 #undef IS_DARWIN --- /* #undef IS_DARWIN */ 84c85 #undef LSTAT_FOLLOWS_SLASHED_SYMLINK --- #define LSTAT_FOLLOWS_SLASHED_SYMLINK 1 87c88 #undef PACKAGE --- #define PACKAGE tuscany_sca_native 90c91 #undef PACKAGE_BUGREPORT --- #define PACKAGE_BUGREPORT 93c94 #undef PACKAGE_NAME --- #define PACKAGE_NAME tuscany_sca_native 96c97 #undef PACKAGE_STRING --- #define PACKAGE_STRING tuscany_sca_native 1.0-incubator-M3 99c100 #undef PACKAGE_TARNAME --- #define PACKAGE_TARNAME tuscany_sca_native 102c103 #undef PACKAGE_VERSION --- #define PACKAGE_VERSION 1.0-incubator-M3 105c106 #undef STDC_HEADERS --- #define STDC_HEADERS 1 108c109 #undef VERSION --- #define VERSION 1.0-incubator-M3 111c112 #undef const --- /* #undef const */ 116c117 #undef inline --- /* #undef inline */ -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 4:22 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build yeah I figured that... I did exactly the same when committing changes earlier! I dodn't commit the changes inthe tools folder. Cheers, On 18/07/07, Brady Johnson [EMAIL PROTECTED] wrote: Ok, I wasn't aware that I had changed the tools. I simply did a svn diff . patch_file from the tuscany root dir. You can disregard the tools changes. I'll look into it. Thanks Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 4:16 PM To: tuscany-dev@ws.apache.org Subject: Re: [SCA Native] preliminary ant build Cool! I've applied this
Demo for Tuscany BOF at OSCON 2007
A number of us will be at OSCON 2007 attending a Tuscany BOF on Wed. July 25, 7:30. More details here: http://conferences.oreillynet.com/cs/os2007/view/e_sess/14724 I was thinking that we could do a demo and take this opportunity to show integration of the Tuscany Java and Native/C++ runtimes. For example, it should be relatively easy to connect the Java based Bigbank demo to the C++ based Bigbank AccountData service, using a Web Service binding. I can help and come up with a refactored version of the Java Bigbank demo that calls the AccountData service remotely if people think it makes sense, and if the C++ folks can provide the C++ based service. As a starting point we should come up with a WSDL for the AccountData service. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-1199) ClassCastException when getting back a type extended from anything besides a string
[ https://issues.apache.org/jira/browse/TUSCANY-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Ip closed TUSCANY-1199. - Resolution: Invalid Didn't realize this was still open. We found that the generated factory was not referenced in the composite file using dbsdo:import.sdo. I believe this should no longer be an issue. ClassCastException when getting back a type extended from anything besides a string --- Key: TUSCANY-1199 URL: https://issues.apache.org/jira/browse/TUSCANY-1199 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Integration Affects Versions: Java-SCA-M2 Environment: Apache Tomcat 5.5.17 Reporter: Sunny Ip Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: AccountHistoryService.wsdl, default.scdl Originally posted under SDO Implementation, but it was suggested it may be an SCA proxy problem: In my client code (originating from a JSP), whenever I am expecting a return type that extends anything but a string (tried so far with boolean, int, double, decimal, long), I get the following when I call my service: java.lang.ClassCastException: java.lang.String $Proxy34.getAccountBalance(Unknown Source) com.bns.references.account.client.AccountClientImpl.getAccountBalance(AccountClientImpl.java:14) org.apache.jsp.AccountClientTest_jsp._jspService(AccountClientTest_jsp.java:81) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.tuscany.runtime.webapp.TuscanyFilter.doFilter(TuscanyFilter.java:58) Here is a snippet from a WSDL file that is being used: xs:schema xmlns:sample=http://sample; targetNamespace=http://sample; xsd:element name=getAccountBalance xsd:complexType xsd:sequence xsd:element name=accountNumber type=sample:AccountNumber / /xs:sequence /xsd:complexType /xsd:element xsd:element name=getAccountBalanceResponse xsd:complexType xsd:sequence xsd:element name=return type=sample:Dollars / /xsd:sequence /xsd:complexType /xsd:element xsd:simpleType name=Dollars xsd:restriction base=xsd:double xsd:minInclusive value=0 / /xsd:restriction /xsd:simpleType /xsd:schema with everything else exactly the same, changing the return type for getAccountBalanceResponse from sample:Dollars to xsd:double makes everything work fine. I have attached the wsdl and scdl (client side) files for reference. To reproduce: 1) create/generate classes to implement and consume the service described by the wsdl 2) expose the service in your scdl 3) call the getAccountBalance operation The crash will occur after the method on the service side is complete, but before the client gets a response. -- 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-1455) OSCON 2007 BigBank Demo artifacts
OSCON 2007 BigBank Demo artifacts - Key: TUSCANY-1455 URL: https://issues.apache.org/jira/browse/TUSCANY-1455 Project: Tuscany Issue Type: Task Components: Interop Reporter: David Haney This is intended to be a staging area for artifacts related to the OSCON 2007 BigBank demo that was proposed on the tuscany-dev 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] Updated: (TUSCANY-1455) OSCON 2007 BigBank Demo artifacts
[ https://issues.apache.org/jira/browse/TUSCANY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Haney updated TUSCANY-1455: - Attachment: accountdata.zip Attached is an initial take at exposing the AccountDataService from the C++ BigBank example as a web service. This was tested with Windows/VC8, so it may need some tweaking in order to get it running on Linux. Here's the rough instructions: 1. Extract the zip file to the %TUSCANY_SCACPP%\samples directory. Make sure to maintain paths of files that are in the .zip 2. Open up a Command Prompt window 3. Configure the environment for building and using tuscany. I've included a batch file that I use for configuring these variables for my own reference. You probably already know what you need to do. 4. Change directories to the service directory $ cd %TUSCANY_SCACPP%\samples\cpp-bigbank-ws-service 5. Run build.bat to build the service and local client $ build.bat 6. Run runwsserver.bat in the background $ pushd deploy\bigbank.account $ start runwsserver.bat $ popd 7. Change directories to the client directory $ cd %TUSCANY_SCACPP%\samples\cpp-bigbank-ws-client 8. Run build.bat to build the web service client $ build.bat 9. Run runclient.bat $ pushd deploy\bigbank.client $ runclient.bat $ popd OSCON 2007 BigBank Demo artifacts - Key: TUSCANY-1455 URL: https://issues.apache.org/jira/browse/TUSCANY-1455 Project: Tuscany Issue Type: Task Components: Interop Reporter: David Haney Attachments: accountdata.zip This is intended to be a staging area for artifacts related to the OSCON 2007 BigBank demo that was proposed on the tuscany-dev 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]
RE: Demo for Tuscany BOF at OSCON 2007
I filed TUSCANY-1455 was created to track artifacts related to the OSCON 2007 demo, and I attached a zip for the AccountDataService web service. It has an associated WSDL, so we could use it as a start, and refactor as necessary in order to get it to work with the Java side. Thanks. David. -Original Message- From: David Haney Sent: Thursday, July 19, 2007 8:08 AM To: tuscany-dev@ws.apache.org Subject: RE: Demo for Tuscany BOF at OSCON 2007 This sounds good to me. We (Rogue Wave) have done some experiments around exposing parts of the BigBank tutorial as a web service from the C++ side, so that could be a start for that half. I'll create a Jira incident for tracking uploads concerning this and submit what we have so far. (I've had trouble attaching zips to messages sent to this list.) TUSCANY-1432 might come up as a part of implementing the Java-side. I ran into problems exposing/calling a webservice from Java that contains complex-types, and I'm pretty sure we'll need to that for the AccountDataService (unless we reduce it to returning simple-types). Thanks. David. -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 7:38 AM To: tuscany-dev@ws.apache.org Subject: Demo for Tuscany BOF at OSCON 2007 A number of us will be at OSCON 2007 attending a Tuscany BOF on Wed. July 25, 7:30. More details here: http://conferences.oreillynet.com/cs/os2007/view/e_sess/14724 I was thinking that we could do a demo and take this opportunity to show integration of the Tuscany Java and Native/C++ runtimes. For example, it should be relatively easy to connect the Java based Bigbank demo to the C++ based Bigbank AccountData service, using a Web Service binding. I can help and come up with a refactored version of the Java Bigbank demo that calls the AccountData service remotely if people think it makes sense, and if the C++ folks can provide the C++ based service. As a starting point we should come up with a WSDL for the AccountData service. Thoughts? -- 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]
RE: Demo for Tuscany BOF at OSCON 2007
This sounds good to me. We (Rogue Wave) have done some experiments around exposing parts of the BigBank tutorial as a web service from the C++ side, so that could be a start for that half. I'll create a Jira incident for tracking uploads concerning this and submit what we have so far. (I've had trouble attaching zips to messages sent to this list.) TUSCANY-1432 might come up as a part of implementing the Java-side. I ran into problems exposing/calling a webservice from Java that contains complex-types, and I'm pretty sure we'll need to that for the AccountDataService (unless we reduce it to returning simple-types). Thanks. David. -Original Message- From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] Sent: Thursday, July 19, 2007 7:38 AM To: tuscany-dev@ws.apache.org Subject: Demo for Tuscany BOF at OSCON 2007 A number of us will be at OSCON 2007 attending a Tuscany BOF on Wed. July 25, 7:30. More details here: http://conferences.oreillynet.com/cs/os2007/view/e_sess/14724 I was thinking that we could do a demo and take this opportunity to show integration of the Tuscany Java and Native/C++ runtimes. For example, it should be relatively easy to connect the Java based Bigbank demo to the C++ based Bigbank AccountData service, using a Web Service binding. I can help and come up with a refactored version of the Java Bigbank demo that calls the AccountData service remotely if people think it makes sense, and if the C++ folks can provide the C++ based service. As a starting point we should come up with a WSDL for the AccountData service. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1456) Conversational Scope Container not Implemented
Conversational Scope Container not Implemented --- Key: TUSCANY-1456 URL: https://issues.apache.org/jira/browse/TUSCANY-1456 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: Lou Amodeo I was trying to use conversation support and noticed there is not CSC available. I took a crack at creating one and attached it. -- 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-1456) Conversational Scope Container not Implemented
[ https://issues.apache.org/jira/browse/TUSCANY-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lou Amodeo updated TUSCANY-1456: Attachment: ConversationalScopeContainer.java Conversational Scope Container not Implemented --- Key: TUSCANY-1456 URL: https://issues.apache.org/jira/browse/TUSCANY-1456 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: Lou Amodeo I was trying to use conversation support and noticed there is not CSC available. I took a crack at creating one and attached it. -- 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-1456) Conversational Scope Container not Implemented
[ https://issues.apache.org/jira/browse/TUSCANY-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lou Amodeo updated TUSCANY-1456: Attachment: (was: ConversationalScopeContainer.java) Conversational Scope Container not Implemented --- Key: TUSCANY-1456 URL: https://issues.apache.org/jira/browse/TUSCANY-1456 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: Lou Amodeo I was trying to use conversation support and noticed there is not CSC available. I took a crack at creating one and attached it. -- 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-1456) Conversational Scope Container not Implemented
[ https://issues.apache.org/jira/browse/TUSCANY-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lou Amodeo updated TUSCANY-1456: Attachment: ConversationalScopeContainer.java Conversational Scope Container not Implemented --- Key: TUSCANY-1456 URL: https://issues.apache.org/jira/browse/TUSCANY-1456 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: Lou Amodeo Attachments: ConversationalScopeContainer.java I was trying to use conversation support and noticed there is not CSC available. I took a crack at creating one and attached it. -- 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: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field
Let's just create a new one. It would be great to have some test cases provided as well, as suggested by Kevin. On 7/19/07, Amita Vadhavkar [EMAIL PROTECTED] wrote: Hi Folks, JIRA-1453 opened for this issue is perfectly fixing Blob and ByteArray. Clob and Array, seem to be the only remaining types where TypeHelper.getType(commonj.sdo,...) returns null. Same approach as JIRA-1453 can work the Clob , but for Array? Any hints? Can the same JIRA be used or new JIRA be opened, so this issue does not remain half complete? Regards, Amita On 7/19/07, Kevin Williams [EMAIL PROTECTED] wrote: -- Forwarded message -- From: Kevin Williams [EMAIL PROTECTED] Date: Jul 18, 2007 1:33 PM Subject: Re: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hello Li Taojian, You have uncovered a bug and also found a good fix. It would be very helpful if you could open a JIRA for this bug and also submit your fix as a patch. You can find instruction for doing this here: http://incubator.apache.org/tuscany/issue-tracking.html It would be even better if you could submit an addition to the DAS testuite to verify your fix. Thanks for your interest in the DAS. --Kevin On 7/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All , I modified the ByteArry and BLOB to Bytes in the ResultSetTypeMap.java , and then I could run a sample of reading the BLOB field , I test the sample on Mysql 5.0 , It could run correctly . Maybe this is a bug . ResultSetTypeMap.java case Types.BINARY: case Types.VARBINARY: case Types.LONGVARBINARY: return helper.getType(commonj.sdo, Bytes); // before is return helper.getType(commonj.sdo, ByteArray); case Types.BLOB: return helper.getType(commonj.sdo, Bytes); // before is return helper.getType(commonj.sdo, Blob); -邮件原件- 发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 发送时间: 2007年7月18日 16:54 收件人: [EMAIL PROTECTED] 主题: How to do if I need the DAS and SDO to support reading and writing the BLOB or CLOB field Hi All , I need the DAS to support reading and write the BLOB field , but TypeHelper.getType(commonj.sdo, Blob) is return null , Could you give me some tips to implement the function or fix out the bugs ? Or How could I implement the function immediately ? Li Taojian . - 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/
Re: WireableBinding questions
Hi, Simon. Nice summary:-). I was about to drop a note but you are ahead of me. The code is still evolving and the WireableWiring is gone (with some methods merged into SCABinding). Please see my comments inline. Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, July 19, 2007 3:35 AM Subject: WireableBinding questions I have some questions about the new interface WireableBinding that was checked in as part of revision r557195. 1. Is it intended that all bindings should (eventually) implement this interface, or only some of them? If only some of them, what's the guideline for which bindings should implement it and which should not? 2. For bindings that don't (yet) implement it (i.e., all the current extension bindings), what are the limitations on what can be done with these bindings? The WireableBinding interface is now gone. 3. This interface introduces three new getter/setter properties: TargetComponent TargetComponentService TargetBinding How are these set/used for reference bindings by the core wiring framework? And how are they set/used for service bindings? These methods are now in SCABinding. They are used to create local wires for SCA bindings. The target is set when a reference SCABinding is resolved to be wired to a target component service. This is a staged approach. Ideally, we should be able to use the URI (componentName/serviceName) to represent the endpoint reference which can materialized locally if the target exists. 4. The core wiring framework is now calling getURI() as part of its determination of whether or not a binding has an endpoint. Does this put new obligations on extension bindings to call their setURI() method even if no uri attribute was specified in the SCDL? No, for other bindings than SCABinding, the current code assumes it always has a URI. SCABinding is the only binding that supports target attribute at this moment. If a binding starts to support componentName/serviceName addressing, then uri attribute should be correctly configured. 5. Are there any other changes that extension binding writers need to make (or are recommended to make) to fully support the new multiple bindings support for references with multiplicity and promotion? No. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r557494 - in /incubator/tuscany/java/sca/samples: calculator-rmi-reference/src/main/resources/ calculator-rmi-service/src/main/resources/ calculator-script/src/main/resources/ calculat
The targetNameSpace were only added on the Calculator and Chat samples, as suggested on the JIRA 1330. The other changes were merely cosmetic (such as alignments) or adding missing headers on some composite files. What's the suggestion here ? To remove the targetNamespace from the Calculator samples ? On 7/19/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I tend to agree with Ant. The namespace gets necessary once we get into inter-contribution sharing of artifacts and then the namespace is essential, but I dont think it is necessary or useful in the simpler examples. I DO think we need to add the XSD location for the SCA namespace, however - this is useful for tooling using the composite files, for example. This is covered by JIRA 1443. Yours, Mike. ant elder wrote: Do we really need these, line 1033 of the assembly spec says the targetNamespace is optional, and the samples don't use the sample namespace? As they're samples isn't it good to keep the XML as bare and simple as possible? ...ant On 7/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: lresende Date: Wed Jul 18 22:33:05 2007 New Revision: 557494 URL: http://svn.apache.org/viewvc?view=revrev=557494 Log: TUSCANY-1330 - Adding targetNameSpace to sample composites Modified: incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/calculator-webapp/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/calculator/src/main/resources/Calculator.composite incubator/tuscany/java/sca/samples/chat-webapp/src/main/resources/chat.composite incubator/tuscany/java/sca/samples/das-service-web/src/main/resources/dasservice.composite incubator/tuscany/java/sca/samples/das-service/src/main/resources/dasservice.composite incubator/tuscany/java/sca/samples/helloworld-dojo/src/main/resources/jsonrpc.composite incubator/tuscany/java/sca/samples/helloworld-jsonrpc/src/main/resources/jsonrpc.composite incubator/tuscany/java/sca/samples/implementation-notification/src/test/resources/TrafficAdvisoryNotification.composite incubator/tuscany/java/sca/samples/simple-bigbank-spring/src/main/resources/StockQuote.composite incubator/tuscany/java/sca/samples/simple-bigbank/src/main/resources/StockQuote.composite incubator/tuscany/java/sca/samples/web-resource/src/main/resources/WebResource.composite Modified: incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-rmi-reference/src/main/resources/CalculatorRMIReference.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent Modified: incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite?view=diffrev=557494r1=557493r2=557494 == --- incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite (original) +++ incubator/tuscany/java/sca/samples/calculator-rmi-service/src/main/resources/CalculatorRMIServer.composite Wed Jul 18 22:33:05 2007 @@ -18,6 +18,8 @@ * under the License. -- composite xmlns=http://www.osoa.org/xmlns/sca/1.0; + targetNamespace=http://sample; + xmlns:sample=http://sample; name=Calculator component name=CalculatorServiceComponent Modified: incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/samples/calculator-script/src/main/resources/Calculator.composite?view=diffrev=557494r1=557493r2=557494 == ---
Qurey related to wsdl imports
Hi, I am taking a look at https://issues.apache.org/jira/browse/TUSCANY-1426 and to get to the crux of that problem I am first trying to see if wsdl imports work. Here is what I am attempting. There is B.wsdl that imports A.wsdl, where B.wsdl has the bindings and services defined and A.wsdl has the types, messages and porttypes defined. But this does not seem to work. It ends up that while Tuscany WSDL Interface processor is dealing with B.wsdl it does not seem to find the elements (remember they are defined inside inline xsd in A.wsdl). Has this been tried out before? Could somebody please point me to samples or itests that have this working in the trunk? Related to this, but slightly different question is... - Do we expect WSDL4J to be resolving the imports and handing us over an aggregated wsdl definition or are we going to use the model and artifact resolution mechanisms within Tuscany to do this ? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1237) DAS should support JDK 1.4 runtime
[ https://issues.apache.org/jira/browse/TUSCANY-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1237. -- Resolution: Fixed Patch applied under revision #557695. Thanks Ron. DAS should support JDK 1.4 runtime -- Key: TUSCANY-1237 URL: https://issues.apache.org/jira/browse/TUSCANY-1237 Project: Tuscany Issue Type: Improvement Components: Java DAS RDB Environment: Windows, Sun JDK 1.4.2_11 Reporter: Ron Gavlin Assignee: Luciano Resende Fix For: Java-DAS-Next Attachments: das-TUSCANY-1237.2.patch, das-TUSCANY-1237.patch Tuscany DAS should support JDK 1.4. Since Tuscany DAS leverages SDO, it would seem to make sense for the DAS JDK requirements to be sync'd with the Tuscany SDO JDK requirements. Tuscany SDO currently supports JDK 1.4+. After browsing the DAS source code, there appear to be only a few places that leverage JDK 1.5 features. These could easily be replaced with JDK 1.4 functions. Please consider supporting JDK 1.4 until SDO 3 is released at which time I presume SDO will require JDK 1.5. -- 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: WireableBinding questions
Thoughts and comments inline. Raymond Feng wrote: Hi, Simon. Nice summary:-). I was about to drop a note but you are ahead of me. The code is still evolving and the WireableWiring is gone (with some methods merged into SCABinding). Please see my comments inline. Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, July 19, 2007 3:35 AM Subject: WireableBinding questions I have some questions about the new interface WireableBinding that was checked in as part of revision r557195. 1. Is it intended that all bindings should (eventually) implement this interface, or only some of them? If only some of them, what's the guideline for which bindings should implement it and which should not? If bindings want to be provided with pointers to a target component/service/binding, they implement WireableBinding. 2. For bindings that don't (yet) implement it (i.e., all the current extension bindings), what are the limitations on what can be done with these bindings? The WireableBinding interface is now gone. Sorry, I think we should keep it :) the limitation for bindings that do not implement WireableBinding is that they are not provided with pointers to the target component/service/binding. Most bindings don't care about these as they are simply using the endpoint information that they are configured with. 3. This interface introduces three new getter/setter properties: TargetComponent TargetComponentService TargetBinding How are these set/used for reference bindings by the core wiring framework? And how are they set/used for service bindings? These methods are now in SCABinding. They are used to create local wires for SCA bindings. The target is set when a reference SCABinding is resolved to be wired to a target component service. This is a staged approach. Ideally, we should be able to use the URI (componentName/serviceName) to represent the endpoint reference which can materialized locally if the target exists. I think it's better to keep WireableBinding like you had yesterday, and not tie it to SCABinding. This way: - whatever binding needs pointers to the target can implement it - implementations of the SCABinding interface do not have to if they don't need that info. In other words, support WireableBinding in the core runtime, but SCABinding does not extend it. A particular SCABindingImpl can decide to implement WireableBinding or not (e.g a remote-only distributed SCABinding may not need to, on the other hand an SCABinding that wants to optimize local calls may want to implement WireableBinding). 4. The core wiring framework is now calling getURI() as part of its determination of whether or not a binding has an endpoint. Does this put new obligations on extension bindings to call their setURI() method even if no uri attribute was specified in the SCDL? No, for other bindings than SCABinding, the current code assumes it always has a URI. SCABinding is the only binding that supports target attribute at this moment. If a binding starts to support componentName/serviceName addressing, then uri attribute should be correctly configured. 5. Are there any other changes that extension binding writers need to make (or are recommended to make) to fully support the new multiple bindings support for references with multiplicity and promotion? No. Simon - 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] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1457) Unable to code gen SDOModel.xsd
Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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: Qurey related to wsdl imports
Hi, I tried this further by adding a little bit of code in the WSDLDocumentProcessor.read method. Over there there is a fragment that scans the schema elements in the read wsdl definition and adds them to XMLSchemaCollection. To this loop I added code to peek into the imported definitions as well and add the schema elements in there to this XMLSchemaCollection. Doing this seems to get the imports going for now. Not sure if this is the right thing to do. - Venkat On 7/19/07, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I am taking a look at https://issues.apache.org/jira/browse/TUSCANY-1426 and to get to the crux of that problem I am first trying to see if wsdl imports work. Here is what I am attempting. There is B.wsdl that imports A.wsdl, where B.wsdl has the bindings and services defined and A.wsdl has the types, messages and porttypes defined. But this does not seem to work. It ends up that while Tuscany WSDL Interface processor is dealing with B.wsdl it does not seem to find the elements (remember they are defined inside inline xsd in A.wsdl). Has this been tried out before? Could somebody please point me to samples or itests that have this working in the trunk? Related to this, but slightly different question is... - Do we expect WSDL4J to be resolving the imports and handing us over an aggregated wsdl definition or are we going to use the model and artifact resolution mechanisms within Tuscany to do this ? Thanks - Venkat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1458) sample-ajax-das failing due to SDO-XMLHelpe.save() changes
sample-ajax-das failing due to SDO-XMLHelpe.save() changes -- Key: TUSCANY-1458 URL: https://issues.apache.org/jira/browse/TUSCANY-1458 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Amita Vadhavkar in serialized DO using XMLHelper - attributes changed to elements, so needed to tweak htmlunit cases and xsl s where those were refed. -- 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-1458) sample-ajax-das failing due to SDO-XMLHelpe.save() changes
[ https://issues.apache.org/jira/browse/TUSCANY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1458: - Attachment: 1458.patch sample-ajax-das failing due to SDO-XMLHelpe.save() changes -- Key: TUSCANY-1458 URL: https://issues.apache.org/jira/browse/TUSCANY-1458 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-beta1 Reporter: Amita Vadhavkar Attachments: 1458.patch in serialized DO using XMLHelper - attributes changed to elements, so needed to tweak htmlunit cases and xsl s where those were refed. -- 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-1458) sample-ajax-das failing due to SDO-XMLHelpe.save() changes
[ https://issues.apache.org/jira/browse/TUSCANY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1458: - Fix Version/s: Java-DAS-Next Affects Version/s: (was: Java-DAS-beta1) Java-DAS-Next sample-ajax-das failing due to SDO-XMLHelpe.save() changes -- Key: TUSCANY-1458 URL: https://issues.apache.org/jira/browse/TUSCANY-1458 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1458.patch in serialized DO using XMLHelper - attributes changed to elements, so needed to tweak htmlunit cases and xsl s where those were refed. -- 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-1458) sample-ajax-das failing due to SDO-XMLHelpe.save() changes
[ https://issues.apache.org/jira/browse/TUSCANY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende updated TUSCANY-1458: - Patch Info: [Patch Available] sample-ajax-das failing due to SDO-XMLHelpe.save() changes -- Key: TUSCANY-1458 URL: https://issues.apache.org/jira/browse/TUSCANY-1458 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1458.patch in serialized DO using XMLHelper - attributes changed to elements, so needed to tweak htmlunit cases and xsl s where those were refed. -- 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-1458) sample-ajax-das failing due to SDO-XMLHelpe.save() changes
[ https://issues.apache.org/jira/browse/TUSCANY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1458. -- Resolution: Fixed Amita's patch applied under revision #557718. This fixes the issues during Tomcat integration tests. sample-ajax-das failing due to SDO-XMLHelpe.save() changes -- Key: TUSCANY-1458 URL: https://issues.apache.org/jira/browse/TUSCANY-1458 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Affects Versions: Java-DAS-Next Reporter: Amita Vadhavkar Fix For: Java-DAS-Next Attachments: 1458.patch in serialized DO using XMLHelper - attributes changed to elements, so needed to tweak htmlunit cases and xsl s where those were refed. -- 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-1452) InterfaceContract and its associated objects should be Cloneable
[ https://issues.apache.org/jira/browse/TUSCANY-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sykes updated TUSCANY-1452: --- Attachment: (was: clone.diff) InterfaceContract and its associated objects should be Cloneable Key: TUSCANY-1452 URL: https://issues.apache.org/jira/browse/TUSCANY-1452 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model, Java SCA Core Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Reporter: Matthew Sykes Fix For: Java-SCA-Next Given the current infrastructure in 0.90, it is difficult for a binding provider to setup a binding-specific databinding on the binding InterfaceContract because the InterfaceContract, Interface, and Operation model objects can't be easily cloned. While the binding providers are allowed to give the runtime an InterfaceContract for the binding, if the data describing the interface comes from something other than the binding configuration the binding will typically use the InterfaceContract from the componentType. Without a way to copy the InterfaceContract, the binding provider will need to create an interface from scratch by using one of the interface processors or the assembly model factories and custom logic. For example, the axis2 binding will use the portType from wsdl document associated with the binding.ws ... element in scdl to create an InterfaceContract or the binding. This approach requires the WebServiceBindngProcessor to access the interface introspector and introspect an interface contract. I've discussed this a bit with Raymond who has agreed that making the InterfaceContract, Interface, Operation, and associated objects cloneable would allow a binding provider implementation to get an instance of the interface contract that could be updated with a binding-specific databinding. This is similar to what existed in the M2 branches of days gone by. -- 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-1452) InterfaceContract and its associated objects should be Cloneable
[ https://issues.apache.org/jira/browse/TUSCANY-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sykes updated TUSCANY-1452: --- Attachment: clone-2.diff Patch to make InterfaceContract, Interface, and Operation Cloneable. The previous attachment did not make a deep copy of the inputType associated with the operation and that caused the reference interface contract that was cloned to be effected by updates to the binding interface contract. InterfaceContract and its associated objects should be Cloneable Key: TUSCANY-1452 URL: https://issues.apache.org/jira/browse/TUSCANY-1452 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model, Java SCA Core Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Reporter: Matthew Sykes Fix For: Java-SCA-Next Attachments: clone-2.diff Given the current infrastructure in 0.90, it is difficult for a binding provider to setup a binding-specific databinding on the binding InterfaceContract because the InterfaceContract, Interface, and Operation model objects can't be easily cloned. While the binding providers are allowed to give the runtime an InterfaceContract for the binding, if the data describing the interface comes from something other than the binding configuration the binding will typically use the InterfaceContract from the componentType. Without a way to copy the InterfaceContract, the binding provider will need to create an interface from scratch by using one of the interface processors or the assembly model factories and custom logic. For example, the axis2 binding will use the portType from wsdl document associated with the binding.ws ... element in scdl to create an InterfaceContract or the binding. This approach requires the WebServiceBindngProcessor to access the interface introspector and introspect an interface contract. I've discussed this a bit with Raymond who has agreed that making the InterfaceContract, Interface, Operation, and associated objects cloneable would allow a binding provider implementation to get an instance of the interface contract that could be updated with a binding-specific databinding. This is similar to what existed in the M2 branches of days gone by. -- 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: [Java SDO, DAS and SCA] alteration to unreleased API
Hi, Kelvin. When do you plan to make the changes? I can help on the SCA side. Thanks, Raymond - Original Message - From: kelvin goodson [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Thursday, July 19, 2007 6:48 AM Subject: [Java SDO, DAS and SCA] alteration to unreleased API Headline message for SCA (and perhaps DAS) -- this is notice of a change that will require minor updates in order not to break the build We have 2 new things in SDO that are of significance to this message that have come about since the beta1 release. 1) An improved notion of what embodies a scope for types -- the HelperContext (previously the story was confused because the TypeHelper was used for this purpose at times) 2) Restructuring of the code so that it is clear what it Tuscany SDO API ( i.e. Tuscany extensions as opposed to the SDO API itself) However, the API in the trunk still uses a TypeHelper to be passed into half a dozen methods to represent the scope. It would be an awful shame not to fix this, and it would also look odd to go out with a brand new API that already has deprecations. I have altered the API in the SDO release branch [1]. As far as I can tell from poking around in eclipse, SCA makes about half a dozen calls into the API, so it's a small job to fix this up. Can someone is SCA please liaise with me to get this done at our mutual convenience, thanks. Kelvin. [1] http://svn.apache.org/viewvc/incubator/tuscany/branches/sdo-1.0-incubating/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java?view=diffrev=557615r1=557614r2=557615http://svn.apache.org/viewvc/incubator/tuscany/branches/sdo-1.0-incubating/impl/src/main/java/org/apache/tuscany/sdo/helper/SDOHelperImpl.java?view=diffrev=557615r1=557614r2=557615 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Java SDO, DAS and SCA] alteration to unreleased API
Thanks, I'd be happiest to leave it until the middle of next week if that fits with you. Kelvin. On 19/07/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Kelvin. When do you plan to make the changes? I can help on the SCA side. Thanks, Raymond - Original Message - From: kelvin goodson [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Thursday, July 19, 2007 6:48 AM Subject: [Java SDO, DAS and SCA] alteration to unreleased API Headline message for SCA (and perhaps DAS) -- this is notice of a change that will require minor updates in order not to break the build We have 2 new things in SDO that are of significance to this message that have come about since the beta1 release. 1) An improved notion of what embodies a scope for types -- the HelperContext (previously the story was confused because the TypeHelper was used for this purpose at times) 2) Restructuring of the code so that it is clear what it Tuscany SDO API ( i.e. Tuscany extensions as opposed to the SDO API itself) However, the API in the trunk still uses a TypeHelper to be passed into half a dozen methods to represent the scope. It would be an awful shame not to fix this, and it would also look odd to go out with a brand new API that already has deprecations. I have altered the API in the SDO release branch [1]. As far as I can tell from poking around in eclipse, SCA makes about half a dozen calls into the API, so it's a small job to fix this up. Can someone is SCA please liaise with me to get this done at our mutual convenience, thanks. Kelvin. [1] http://svn.apache.org/viewvc/incubator/tuscany/branches/sdo-1.0-incubating/lib/src/main/java/org/apache/tuscany/sdo/api/SDOHelper.java?view=diffrev=557615r1=557614r2=557615 http://svn.apache.org/viewvc/incubator/tuscany/branches/sdo-1.0-incubating/impl/src/main/java/org/apache/tuscany/sdo/helper/SDOHelperImpl.java?view=diffrev=557615r1=557614r2=557615
[DAS] DAS SDO
Hey Kelvin gave as some head's up of upcoming changes that might affect DAS [1] and [2] (Thanks Kelvin). I think there is also a JIRA regarding integration with latest SDO 2.1 APIs [2] and the usage of deprecated SDO APIs [4]. It would be great if someone could help on getting these issues and JIRAs reviewed, and submit patches as needed. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20388.html [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20369.html [3] http://issues.apache.org/jira/browse/TUSCANY-986 [4] http://issues.apache.org/jira/browse/TUSCANY-961 -- 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: WireableBinding questions
OK. Let's bring the WireableBinding back. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, July 19, 2007 10:28 AM Subject: Re: WireableBinding questions Thoughts and comments inline. Raymond Feng wrote: Hi, Simon. Nice summary:-). I was about to drop a note but you are ahead of me. The code is still evolving and the WireableWiring is gone (with some methods merged into SCABinding). Please see my comments inline. Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, July 19, 2007 3:35 AM Subject: WireableBinding questions I have some questions about the new interface WireableBinding that was checked in as part of revision r557195. 1. Is it intended that all bindings should (eventually) implement this interface, or only some of them? If only some of them, what's the guideline for which bindings should implement it and which should not? If bindings want to be provided with pointers to a target component/service/binding, they implement WireableBinding. 2. For bindings that don't (yet) implement it (i.e., all the current extension bindings), what are the limitations on what can be done with these bindings? The WireableBinding interface is now gone. Sorry, I think we should keep it :) the limitation for bindings that do not implement WireableBinding is that they are not provided with pointers to the target component/service/binding. Most bindings don't care about these as they are simply using the endpoint information that they are configured with. 3. This interface introduces three new getter/setter properties: TargetComponent TargetComponentService TargetBinding How are these set/used for reference bindings by the core wiring framework? And how are they set/used for service bindings? These methods are now in SCABinding. They are used to create local wires for SCA bindings. The target is set when a reference SCABinding is resolved to be wired to a target component service. This is a staged approach. Ideally, we should be able to use the URI (componentName/serviceName) to represent the endpoint reference which can materialized locally if the target exists. I think it's better to keep WireableBinding like you had yesterday, and not tie it to SCABinding. This way: - whatever binding needs pointers to the target can implement it - implementations of the SCABinding interface do not have to if they don't need that info. In other words, support WireableBinding in the core runtime, but SCABinding does not extend it. A particular SCABindingImpl can decide to implement WireableBinding or not (e.g a remote-only distributed SCABinding may not need to, on the other hand an SCABinding that wants to optimize local calls may want to implement WireableBinding). 4. The core wiring framework is now calling getURI() as part of its determination of whether or not a binding has an endpoint. Does this put new obligations on extension bindings to call their setURI() method even if no uri attribute was specified in the SCDL? No, for other bindings than SCABinding, the current code assumes it always has a URI. SCABinding is the only binding that supports target attribute at this moment. If a binding starts to support componentName/serviceName addressing, then uri attribute should be correctly configured. 5. Are there any other changes that extension binding writers need to make (or are recommended to make) to fully support the new multiple bindings support for references with multiplicity and promotion? No. Simon - 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] -- 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] Commented: (TUSCANY-961) DAS: Using deprected SDO method causes Type lookup failure
[ https://issues.apache.org/jira/browse/TUSCANY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513987 ] Kelvin Goodson commented on TUSCANY-961: Best practise now is, if possible to manage your scopes for types by using client created instances of HelperContext. These can be created using the static method in org.apache.tuscany.sdo.api.SDOUtil.createHelperContext(). The TypeHelper is accessible via the HelperContext.getTypeHelper() method. If you must use the global scope for types then the default TypeHelper is accessible from the default HelperContext via HelperProvider.getDefaultContext() DAS: Using deprected SDO method causes Type lookup failure -- Key: TUSCANY-961 URL: https://issues.apache.org/jira/browse/TUSCANY-961 Project: Tuscany Issue Type: Bug Components: Java DAS RDB Reporter: Brent Daniel Assignee: Brent Daniel Fix For: Java-DAS-Next The DAS is still using SDOUtil.createTypeHelper() rather than TypeHelper.INSTANCE. This causes the DAS to not have visibility of types defined by TypeHelper or XSDHelper. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513988 ] Ron Gavlin commented on TUSCANY-1457: - David, What command-line options are you using to invoke the XSD2JavaGenerator in this context? Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513989 ] Kelvin Goodson commented on TUSCANY-1457: - My guess is that david will be using the ones from the javadoc ... XSD2JavaGenerator -generateBuiltIn commonj.sdo -targetDirectory temp-dir -javaPackage org.apache.tuscany.sdo.model sdo-api-dir/src/main/resources/xml/sdoModel.xsd Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513990 ] David T. Adcox commented on TUSCANY-1457: - Kelvin, that is correct. Per the directions in the java doc at the top of ModelFactoryImpl. Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513997 ] Frank Budinsky commented on TUSCANY-1457: - The problem is that sdoModel.xsd includes datagraph.xsd. The SchemaLocator class in SDOXSDEcoreBuilder needs to avoid looking up the model in the package registry if locateSchema is being called for an include. I'll attach a patch. Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky updated TUSCANY-1457: Attachment: 1457.patch Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1457.patch When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1459) Remove package registry delegation to EPackage.Registry.INSTANCE
Remove package registry delegation to EPackage.Registry.INSTANCE Key: TUSCANY-1459 URL: https://issues.apache.org/jira/browse/TUSCANY-1459 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Priority: Critical Fix For: Java-SDO-1.0 This improvement is to reduce today's 3 tier registry delegation mechanism to 2 tier's so we won't rely on EPackage.Registry.INSTANCE. Current design: The default HelperContext created by using HelperProvider.getDefaultContext() is using the EPackage.Registry.INSTANCE as its package registry that can be delegated to the TCCL's registry. The local HelperContext created by using api.SDOUtil.createHelperContext() is creating a local package registry that can delegate to the builtInModelRegistry that potentially delegates to the EPackage.Registry.INSTANCE. default HelperContext (EPackage.Registry.INSTANCE/TCCL based) local HelperContext (local package registry) --delegate-- builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE EMF, SDO runtime models, SDO type models are resided in the EPackage.Registry.INSTANCE SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) are resided in both builtInModelRegistry and EPackage.Registry.INSTANCE (registered in the FactoryBase.java) User models will reside either in the EPackage.Registry.INSTANCE or local package registry New design: The builtInModelRegistry will become the end of registry delegation chain that would contain all required EMF and SDO runtime models and type models. The user models will reside at the local registry created for the helper context. If it's the default helper context, the special registry will be the SDOPackageRegistryDelegator that is similar to EPackage.Registry.INSTANCE$Delegator that would look up TCCL's registry and at the end of chain delegates to the builtInModelRegistry. If it's the local HelperContext, a regular Hashmap registry will be used then delegates to the builtInModelRegistry. default HelperContext (SDOPackageRegistryDelegator/TCCL based) --delegate-- builtInModelRegistry local HelperContext (local package registry) --delegate-- builtInModelRegistry EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry User models will reside either in the SDOPackageRegistryDelegator(TCCL based) or local package registry -- 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-1459) Remove package registry delegation to EPackage.Registry.INSTANCE
[ https://issues.apache.org/jira/browse/TUSCANY-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fuhwei Lwo updated TUSCANY-1459: Attachment: 1459.patch Here is the patch to implement the new design. Please review and provide comments. Thanks. Remove package registry delegation to EPackage.Registry.INSTANCE Key: TUSCANY-1459 URL: https://issues.apache.org/jira/browse/TUSCANY-1459 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Priority: Critical Fix For: Java-SDO-1.0 Attachments: 1459.patch This improvement is to reduce today's 3 tier registry delegation mechanism to 2 tier's so we won't rely on EPackage.Registry.INSTANCE. Current design: The default HelperContext created by using HelperProvider.getDefaultContext() is using the EPackage.Registry.INSTANCE as its package registry that can be delegated to the TCCL's registry. The local HelperContext created by using api.SDOUtil.createHelperContext() is creating a local package registry that can delegate to the builtInModelRegistry that potentially delegates to the EPackage.Registry.INSTANCE. default HelperContext (EPackage.Registry.INSTANCE/TCCL based) local HelperContext (local package registry) --delegate-- builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE EMF, SDO runtime models, SDO type models are resided in the EPackage.Registry.INSTANCE SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) are resided in both builtInModelRegistry and EPackage.Registry.INSTANCE (registered in the FactoryBase.java) User models will reside either in the EPackage.Registry.INSTANCE or local package registry New design: The builtInModelRegistry will become the end of registry delegation chain that would contain all required EMF and SDO runtime models and type models. The user models will reside at the local registry created for the helper context. If it's the default helper context, the special registry will be the SDOPackageRegistryDelegator that is similar to EPackage.Registry.INSTANCE$Delegator that would look up TCCL's registry and at the end of chain delegates to the builtInModelRegistry. If it's the local HelperContext, a regular Hashmap registry will be used then delegates to the builtInModelRegistry. default HelperContext (SDOPackageRegistryDelegator/TCCL based) --delegate-- builtInModelRegistry local HelperContext (local package registry) --delegate-- builtInModelRegistry EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry User models will reside either in the SDOPackageRegistryDelegator(TCCL based) or local package registry -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky updated TUSCANY-1457: Attachment: 1457.patch Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1457.patch When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky updated TUSCANY-1457: Attachment: (was: 1457.patch) Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1457.patch When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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: svn commit: r557770 - in /incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model: SDOClass.java SDOFactoryClass.java
Having recently installed europa and the latest javajet stuff, I believe this making of the NL variable public is the default behaviour of the emitter. Kelvin. On 19/07/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: frankb Date: Thu Jul 19 14:00:46 2007 New Revision: 557770 URL: http://svn.apache.org/viewvc?view=revrev=557770 Log: generated files Modified: incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOClass.java incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOFactoryClass.java Modified: incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOClass.java URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOClass.java?view=diffrev=557770r1=557769r2=557770 == --- incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOClass.java (original) +++ incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOClass.java Thu Jul 19 14:00:46 2007 @@ -17,7 +17,7 @@ return result; } - public final String NL = nl == null ? (System.getProperties ().getProperty(line.separator)) : nl; + protected final String NL = nl == null ? (System.getProperties ().getProperty(line.separator)) : nl; protected final String TEXT_1 = ; protected final String TEXT_2 = /** + NL + * copyright + NL + * /copyright + NL + * + NL + * ; protected final String TEXT_3 = Id; Modified: incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOFactoryClass.java URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOFactoryClass.java?view=diffrev=557770r1=557769r2=557770 == --- incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOFactoryClass.java (original) +++ incubator/tuscany/java/sdo/tools/src/main/java/org/apache/tuscany/sdo/generate/templates/model/SDOFactoryClass.java Thu Jul 19 14:00:46 2007 @@ -37,7 +37,7 @@ return result; } - public final String NL = nl == null ? (System.getProperties ().getProperty(line.separator)) : nl; + protected final String NL = nl == null ? (System.getProperties ().getProperty(line.separator)) : nl; protected final String TEXT_1 = ; protected final String TEXT_2 = /** + NL + * copyright + NL + * /copyright + NL + * + NL + * ; protected final String TEXT_3 = Id; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1457) Unable to code gen SDOModel.xsd
[ https://issues.apache.org/jira/browse/TUSCANY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1457. - Resolution: Fixed Fixed in revision 557781. Unable to code gen SDOModel.xsd --- Key: TUSCANY-1457 URL: https://issues.apache.org/jira/browse/TUSCANY-1457 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1457.patch When I attempt to generate the java source files representing the SDOModel, I am seeing a NPE thrown in SDOXSDEcoreBuilder.java. Here is the stack trace: java.lang.NullPointerException at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.lookupPrefix(SDOXSDEcoreBuilder.java:104) at org.apache.tuscany.sdo.helper.SDOXSDEcoreBuilder.getEPackage(SDOXSDEcoreBuilder.java:129) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.getEStructuralFeature(BaseSDOXSDEcoreBuilder.java:1413) at org.apache.tuscany.sdo.helper.BaseSDOXSDEcoreBuilder.generate(BaseSDOXSDEcoreBuilder.java:1512) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:247) at org.apache.tuscany.sdo.helper.XSDHelperImpl.define(XSDHelperImpl.java:224) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.generateFromXMLSchema(XSD2JavaGenerator.java:179) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.run(XSD2JavaGenerator.java:146) at org.apache.tuscany.sdo.generate.XSD2JavaGenerator.main(XSD2JavaGenerator.java:96) I've tracked the issue down to some code changes made for T-513. A change was made in XSDHelperImpl in the define method to change how the ResourceSet is constructed prior to loading the schema. Additional changes were made in SDOXSDEcoreBuilder to set up some options when constructing a ResourceSet. These combined changes seem to be precipitating the issue. The XSDSchemaAdapterFactoryImpl inner class contains a method isFactoryForType(Object) that appears to be setting up conditions such that more elementDeclarations than should be expected is being created, later leading to the NPE. -- 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-1459) Remove package registry delegation to EPackage.Registry.INSTANCE
[ https://issues.apache.org/jira/browse/TUSCANY-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514015 ] Frank Budinsky commented on TUSCANY-1459: - Patch looks perfect! Can we apply it or does it cause breakage if not syncronized with TUSCANY-1143? Remove package registry delegation to EPackage.Registry.INSTANCE Key: TUSCANY-1459 URL: https://issues.apache.org/jira/browse/TUSCANY-1459 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Priority: Critical Fix For: Java-SDO-1.0 Attachments: 1459.patch This improvement is to reduce today's 3 tier registry delegation mechanism to 2 tier's so we won't rely on EPackage.Registry.INSTANCE. Current design: The default HelperContext created by using HelperProvider.getDefaultContext() is using the EPackage.Registry.INSTANCE as its package registry that can be delegated to the TCCL's registry. The local HelperContext created by using api.SDOUtil.createHelperContext() is creating a local package registry that can delegate to the builtInModelRegistry that potentially delegates to the EPackage.Registry.INSTANCE. default HelperContext (EPackage.Registry.INSTANCE/TCCL based) local HelperContext (local package registry) --delegate-- builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE EMF, SDO runtime models, SDO type models are resided in the EPackage.Registry.INSTANCE SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) are resided in both builtInModelRegistry and EPackage.Registry.INSTANCE (registered in the FactoryBase.java) User models will reside either in the EPackage.Registry.INSTANCE or local package registry New design: The builtInModelRegistry will become the end of registry delegation chain that would contain all required EMF and SDO runtime models and type models. The user models will reside at the local registry created for the helper context. If it's the default helper context, the special registry will be the SDOPackageRegistryDelegator that is similar to EPackage.Registry.INSTANCE$Delegator that would look up TCCL's registry and at the end of chain delegates to the builtInModelRegistry. If it's the local HelperContext, a regular Hashmap registry will be used then delegates to the builtInModelRegistry. default HelperContext (SDOPackageRegistryDelegator/TCCL based) --delegate-- builtInModelRegistry local HelperContext (local package registry) --delegate-- builtInModelRegistry EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry User models will reside either in the SDOPackageRegistryDelegator(TCCL based) or local package registry -- 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]
Relating ServiceReference/CallableReference to the reference proxy?
CallableReference presents an interface for setting and getting conversation information. When it comes time to dispatch a message the information is required in the invoker handler. There is not direct relationship between these two structures. The current mechanism of using the ThreadMessageContext to transfer bits of this information is suspect in my opinion because the conversation information in question is related to the message to be sent and not to the context of the message that was received. I could bend the (non spi) interfaces to pass the originating service reference into the WireObjectFactor, ProxyService and hence on into the proxy/invoker handler. Looks a bit tricky due to the way it's structured atm. Without changing interfaces I could invent a hidden method on the proxy to accept a reference to the ServiceReference which can be used to get conversation information as required. Is there an obvious (easy) way that these are/can be associated? Simon
Re: Relating ServiceReference/CallableReference to the reference proxy?
Hi, Please see my comments inline. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Thursday, July 19, 2007 3:31 PM Subject: Relating ServiceReference/CallableReference to the reference proxy? CallableReference presents an interface for setting and getting conversation information. I think CallableReference is not only for conversation. It's more like an endpoint reference which contains the address (uri and properties) and state (parameter). When it comes time to dispatch a message the information is required in the invoker handler. There is not direct relationship between these two structures. The current mechanism of using the ThreadMessageContext to transfer bits of this information is suspect in my opinion because the conversation information in question is related to the message to be sent and not to the context of the message that was received. I think we should move into more message-oriented than invocation-oriented. The Message should carry more metadata (message headers). When the message reaches an implemention/binding provider, the provider will create context out of the message and present them to the impl/binding (on the thread, or in binding-specific way). I could bend the (non spi) interfaces to pass the originating service reference into the WireObjectFactor, ProxyService and hence on into the proxy/invoker handler. Looks a bit tricky due to the way it's structured atm. Without changing interfaces I could invent a hidden method on the proxy to accept a reference to the ServiceReference which can be used to get conversation information as required. Is there an obvious (easy) way that these are/can be associated? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1460) SDO databinding's SDO metadata is scoped in a classloader different from the webapp classloader created by the embedded tomcat (ClassCastException w/ sample-helloworld-s
SDO databinding's SDO metadata is scoped in a classloader different from the webapp classloader created by the embedded tomcat (ClassCastException w/ sample-helloworld-sdo) Key: TUSCANY-1460 URL: https://issues.apache.org/jira/browse/TUSCANY-1460 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng The embedded Tomcat creates web app classloader for the thread handling the incoming HTTP requests. As a result, the scope for SDO HelperContext is different from the classloader when the SDO metadata is introspected during the contribution processing. We probably need a better scoping for SDO metadata than the classloader. Contribution might be used as the key (we can even support import/export). -- 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-1432) Unable to implement helloworld-ws-reference sample with complex types.
[
https://issues.apache.org/jira/browse/TUSCANY-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-1432.
---
Resolution: Won't Fix
The current code works fine for the complex SDO. A related issue is tracked by
TUSCANY-1460.
Unable to implement helloworld-ws-reference sample with complex types.
--
Key: TUSCANY-1432
URL: https://issues.apache.org/jira/browse/TUSCANY-1432
Project: Tuscany
Issue Type: Bug
Components: Java SCA Samples
Affects Versions: Java-SCA-M2
Environment: Windows XP, JDK 1.5.0_11-b03, ant 1.7.0
Reporter: David Haney
Assignee: Raymond Feng
Fix For: Java-SCA-Next
Attachments: helloworld-ws-reference.zip
I'm attempting to modify the helloworld-ws-reference example so that it is
sending a complexType instead of simple types, and am having trouble with an
exception that I can't explain. I wasn't able to find an example of this
sort of thing in one of the other samples, so I've been trying to piece
together the necessary changes, and I'm guessing I've just missed a step
along the way.
Here's what I've done so far (all file references are relative to
installdir/samples/helloworld-ws-reference):
- Modified the src/main/resources/wsdl/helloworld.wsdl So that the
getGreetings operation contains a complexType:
...
element name=getGreetings
complexType
sequence
element name=name type=tns:Name/
/sequence
/complexType
/element
...
complexType name=Name
sequence
element name=first type=xsd:string/
element name=last type=xsd:string/
/sequence
/complexType
...
- Next, I code-generated the static SDO types based on the updated WSDL file.
I added the following to the root build.xml in order to generate the types
(I wasn't able to find the necessary code-generator tools in the SCA
distribution, so the following depends on an external SDO distribution
specified by the environment variable TUSCANY_SDO. I used the
tuscany-sdo-1.0-incubating-beta1 binary distribution for this test):
...
property environment=env/
target name=codegen depends=init
java classname=org.apache.tuscany.sdo.generate.XSD2JavaGenerator
fork=true
classpath
pathelement
path=${env.TUSCANY_SDO}/lib/tuscany-sdo-tools-1.0-incubating-beta1.jar
/
pathelement path=${env.TUSCANY_SDO}/lib/common-2.2.2.jar/
pathelement path=${env.TUSCANY_SDO}/lib/ecore-2.2.2.jar/
pathelement
path=${env.TUSCANY_SDO}/lib/sdo-api-r2.1-1.0-incubating-beta1.jar/
pathelement
path=${env.TUSCANY_SDO}/lib/tuscany-sdo-impl-1.0-incubating-beta1.jar/
pathelement path=${env.TUSCANY_SDO}/lib/ecore-xmi-2.2.2.jar/
pathelement path=${env.TUSCANY_SDO}/lib/xsd-2.2.2.jar/
pathelement
path=${env.TUSCANY_SDO}/lib/ecore-change-2.2.2.jar/
pathelement path=${env.TUSCANY_SDO}/lib/codegen-2.2.2.jar/
pathelement
path=${env.TUSCANY_SDO}/lib/codegen-ecore-2.2.2.jar/
/classpath
arg value=-targetDirectory/
arg value=src/main/java/
arg value=-javapackage/
arg value=helloworld/
arg value=src/main/resources/wsdl/helloworld.wsdl/
/java
/target
...
- This produced the following files in src/main/java/helloworld:
getGreetings.java
getGreetingsResponse.java
HelloworldFactory.java
Name.java
impl/getGreetingsImpl.java
impl/getGreetingsResponseImpl.java
impl/HelloworldFactoryImpl.java
impl/NameImpl.java
- Once these were in place, I modified HelloWorldService::getGreetings() to
take the new Name type:
...
public interface HelloWorldService {
public String getGreetings(Name name); }
- and modified HelloWorldServiceComponent::getGreeting() to match:
...
public String getGreetings(Name name) {
System.out.println(Called getGreetings);
return helloWorldService.getGreetings(name);
}
- Finally, I modified HelloWorldServiceClient::main() to create a Name
instance, and pass it into the getGreetings() call.
...
Name name = HelloworldFactory.INSTANCE.createName();
name.setFirst(David);
name.setLast(Haney);
String value = helloWorldService.getGreetings(name);
...
- Once all of the code changes were in place, I went back to the
src/main/resources/helloworldws.composite file, and attempted to update it so
that it would recognize that it should be using the SDO binding:
dbsdo:import.sdo
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
factory=helloworld.HelloworldFactory/
- That seemed like it should be sufficient based on the
documentation/tests/demos/examples that I was able to find, however when I
attempt to run the application, I'm seeing the following output:
Buildfile: build.xml
run:
[java] log4j:WARN No appenders could be found
[jira] Resolved: (TUSCANY-1459) Remove package registry delegation to EPackage.Registry.INSTANCE
[ https://issues.apache.org/jira/browse/TUSCANY-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Budinsky resolved TUSCANY-1459. - Resolution: Fixed Committed revision 557838. Remove package registry delegation to EPackage.Registry.INSTANCE Key: TUSCANY-1459 URL: https://issues.apache.org/jira/browse/TUSCANY-1459 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Environment: WinXP Reporter: Fuhwei Lwo Priority: Critical Fix For: Java-SDO-1.0 Attachments: 1459.patch This improvement is to reduce today's 3 tier registry delegation mechanism to 2 tier's so we won't rely on EPackage.Registry.INSTANCE. Current design: The default HelperContext created by using HelperProvider.getDefaultContext() is using the EPackage.Registry.INSTANCE as its package registry that can be delegated to the TCCL's registry. The local HelperContext created by using api.SDOUtil.createHelperContext() is creating a local package registry that can delegate to the builtInModelRegistry that potentially delegates to the EPackage.Registry.INSTANCE. default HelperContext (EPackage.Registry.INSTANCE/TCCL based) local HelperContext (local package registry) --delegate-- builtInModelRegistry --delegate-- EPackage.Registry.INSTANCE EMF, SDO runtime models, SDO type models are resided in the EPackage.Registry.INSTANCE SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) are resided in both builtInModelRegistry and EPackage.Registry.INSTANCE (registered in the FactoryBase.java) User models will reside either in the EPackage.Registry.INSTANCE or local package registry New design: The builtInModelRegistry will become the end of registry delegation chain that would contain all required EMF and SDO runtime models and type models. The user models will reside at the local registry created for the helper context. If it's the default helper context, the special registry will be the SDOPackageRegistryDelegator that is similar to EPackage.Registry.INSTANCE$Delegator that would look up TCCL's registry and at the end of chain delegates to the builtInModelRegistry. If it's the local HelperContext, a regular Hashmap registry will be used then delegates to the builtInModelRegistry. default HelperContext (SDOPackageRegistryDelegator/TCCL based) --delegate-- builtInModelRegistry local HelperContext (local package registry) --delegate-- builtInModelRegistry EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry User models will reside either in the SDOPackageRegistryDelegator(TCCL based) or local package registry -- 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-1461) Checkin of T-1459 has created a compilation problem in HelperProviderBase
Checkin of T-1459 has created a compilation problem in HelperProviderBase - Key: TUSCANY-1461 URL: https://issues.apache.org/jira/browse/TUSCANY-1461 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1461.patch The scope of HelperProvider.defaultContext is undeclared so by default it is private. HelperProviderBase extends HelperProvider and references defaultContext. I've attached a patch making HelperProvider.defaultContext protected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1461) Checkin of T-1459 has created a compilation problem in HelperProviderBase
[ https://issues.apache.org/jira/browse/TUSCANY-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1461: Attachment: 1461.patch Checkin of T-1459 has created a compilation problem in HelperProviderBase - Key: TUSCANY-1461 URL: https://issues.apache.org/jira/browse/TUSCANY-1461 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-M2 Environment: n/a Reporter: David T. Adcox Fix For: Java-SDO-1.0 Attachments: 1461.patch The scope of HelperProvider.defaultContext is undeclared so by default it is private. HelperProviderBase extends HelperProvider and references defaultContext. I've attached a patch making HelperProvider.defaultContext protected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1405) when the component is implemented by a composite which has multi service,occur can't find service error.
[
https://issues.apache.org/jira/browse/TUSCANY-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514085
]
wangfeng commented on TUSCANY-1405:
---
I look into the code and found the crux of this problem.
when a component is implemented by a inner composite,the composite service only
generate a promoted service named by the prefix of '$promoted$.' on the
promoted component but not generate the reference such as self reference.
so when we locate a service which really locate the reference on this
component,occur this service not found error .
I think there are two ways to solve this problem.One is generate the self
reference for every promote service on the promoted component,the other way is
when locate a service ,we search the reference name not only loop the
component's reference,but also loop the component's service.
anyone has better ideas for this?
when the component is implemented by a composite which has multi
service,occur can't find service error.
Key: TUSCANY-1405
URL: https://issues.apache.org/jira/browse/TUSCANY-1405
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-0.90
Reporter: wangfeng
Assignee: Raymond Feng
Fix For: Java-SCA-0.91
Attachments: ConmpositeImplementation.jar
I create a simple SCA application,which test composite Implementation.I
defined two composite files,one is OuterComposite.composite,the other is
InnerComposite.composite and the Innercomposite file has defined two
composite services.
when I get a service (offer a service name to the getService method) from the
component which defined in the OuterComposite file ,occur an error as below.
Exception in thread main org.osoa.sca.ServiceRuntimeException: Service not
found: TargetComponent/Service_Two
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getService(DefaultSCADomain.java:278)
at composite.CompositeClient.main(CompositeClient.java:31)
OuterComposite.composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://sample;
xmlns:sample=http://sample;
name=OuterComposite
component name=TargetComponent
implementation.composite name=sample:InnerComposite/
/component
/composite
InnerComposite.composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://sample;
xmlns:sample=http://sample;
name=InnerComposite
service name=Service_One promote=ComponentOne
interface.java interface=composite.Target/
/service
service name=Service_Two promote=ComponentTwo
interface.java interface=composite.Target/
/service
component name=ComponentOne
implementation.java class=composite.TargetOne/
/component
component name=ComponentTwo
implementation.java class=composite.TargetTwo/
/component
/composite
Target.java
package composite;
public interface Target {
String hello(String arg);
}
TargetOne.java
package composite;
import org.osoa.sca.annotations.Service;
@Service(Target.class)
public class TargetOne implements Target {
public String hello(String arg) {
return TargetOne: Hello + arg+ !;
}
}
TargetTwo.java
package composite;
import org.osoa.sca.annotations.Service;
@Service(Target.class)
public class TargetTwo implements Target {
public String hello(String arg) {
return TargetTwo: Hello + arg + !;
}
}
CompositeClient .java
package composite;
import org.apache.tuscany.sca.host.embedded.SCADomain;
public class CompositeClient {
public static void main(String[] args) throws Exception {
SCADomain scaDomain =
SCADomain.newInstance(OuterComposite.composite);
Target target = scaDomain.getService(Target.class,
TargetComponent/Service_Two);
String res = target.hello(Wang Feng);
System.out.println(res);
scaDomain.close();
}
}
--
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-1143) Generated code should separate metadata creation from registration to permit proper scoping
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David T. Adcox updated TUSCANY-1143: Attachment: 1143.patch Ok, so here is my latest attempt for a patch on this issue. During testing of the last 1143 patch, I found some issues (noted by Kelvin) that have been addressed by T-1459. After a T-1459 was posted, I reworked my previous 1143 patch to be compatible. Additionally, I have regenerated the SDO builtin models so they follow the new code gen pattern. So, the good news is that most of the issues have been addressed. Unfortunately, I am still seeing two Errors thrown in org.apache.tuscany.sdo.test.DefineTypeTestCase and org.apache.tuscany.sdo.test.SerializeTypesTestCase (Error stacks will be appended). These errors seem to be the same as what was being seen before T-1459. It seems that there is still some need for the builtin models to register with the EMF global registry, based on my test results. If I restore the EPackage.Registry registration code found in the second FactoryBase constructor (this code is removed with this patch), the problems are resolved. More testing is needed to isolate where the EMF registry is being referenced, as it is my understanding that T-1459 should remove any SDO dependency on that registry. So, this patch may or may not be the final solution pending resolution of this last issue. Generated code should separate metadata creation from registration to permit proper scoping --- Key: TUSCANY-1143 URL: https://issues.apache.org/jira/browse/TUSCANY-1143 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-beta1 Reporter: Kelvin Goodson Fix For: Java-SDO-1.0 Attachments: 1143.patch, 1143.patch, 1143.patch The switch to registration of metadata from the global scope to selected scopes is not complete yet, although for all current test cases there are no failures. Currently the generated init() method for a factory calls the deprecated SDOUtil.registerStaticTypes for its simple dependencies. In the simple case this is just ModelFactory and SDOFactory, but could contain other user generated dependencies if for example there were to be an xsd import of another namespace (exposed a gap in our test case set). This would mean that the user generated model dependency would also be registered against the global registry. It is proposed that all registrations, including the built in models, are made against the helper context provided to the Factory's register method. I.e. a state invariant that no models are ever registered against the global registry. The pattern of looking up models from within packages is not required, since the code can just refer to each model's singleton INSTANCE (see below for the exception SDOFactoryImpl). Creation of the metadata should be done in the init method, and the registration of all metadata (built-in or otherwise) should be done in the register method. It would appear on inspection that no reference to the simple dependencies of a factory need be made in its init method, and simple reference to the dependencies INSTANCE in the register will be enough to ensure that those dependencies are initialised before being registered against the provided scope. SDOFactoryImpl does not have an INSTANCE currently. The current proposed solution is to modify SDOFactory to have an INSTANCE, in order that it can behave like an ordinary generated dependency in this new approach. -- 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-1143) Generated code should separate metadata creation from registration to permit proper scoping
[ https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514088 ] David T. Adcox commented on TUSCANY-1143: - Here are the two error stacks... --- Test set: org.apache.tuscany.sdo.test.DefineTypeTestCase --- Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.171 sec FAILURE! testDefineDataType(org.apache.tuscany.sdo.test.DefineTypeTestCase) Time elapsed: 0 sec ERROR! java.lang.ClassCastException: The value of type 'class java.lang.Integer' must be of type '[EMAIL PROTECTED] (name: MyIntType) (instanceClassName: null) (serializable: true)' at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettableDynamic.validate(EStructuralFeatureImpl.java:2176) at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleDataUnsettable.dynamicSet(EStructuralFeatureImpl.java:2116) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicSet(BasicEObjectImpl.java:709) at org.apache.tuscany.sdo.impl.DynamicDataObjectImpl.eDynamicSet(DynamicDataObjectImpl.java:160) at org.apache.tuscany.sdo.impl.DataObjectImpl.eSet(DataObjectImpl.java:1459) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eSet(BasicEObjectImpl.java:654) at org.apache.tuscany.sdo.impl.DataObjectImpl.set(DataObjectImpl.java:142) at org.apache.tuscany.sdo.util.DataObjectUtil.setInt(DataObjectUtil.java:527) at org.apache.tuscany.sdo.impl.DataObjectImpl.setInt(DataObjectImpl.java:525) at org.apache.tuscany.sdo.test.DefineTypeTestCase.testDefineDataType(DefineTypeTestCase.java:304) at org.apache.tuscany.sdo.test.DefineTypeTestCase.testDefineDataType(DefineTypeTestCase.java:304) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818) --- Test set: org.apache.tuscany.sdo.test.SerializeTypesTestCase --- Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.453 sec FAILURE! testSerializeTypesRoundTrip(org.apache.tuscany.sdo.test.SerializeTypesTestCase) Time elapsed: 0.328 sec ERROR! org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value '1' is not legal. (file:///C:/sdosrc/Tuscany/java/sdo/impl/all.datagraph, 115, 25) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83) at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:193) at org.apache.tuscany.sdo.util.DataGraphResourceFactoryImpl$DataGraphResourceImpl$LoadImpl.load(DataGraphResourceFactoryImpl.java:455) at
Re: [CONF] Apache Tuscany: SCA Java binding.jsonrpc (page edited)
Every commit is good to know to keep track of whats going on. But it
would be good if this mail just about provided a link like this
http://cwiki.apache.org/confluence/pages/viewchangessincelastlogin.action?pageId=54462
which is actually the diff between two versions, than churn out all
contents.
- Venkat
On 7/19/07, Simon Laws [EMAIL PROTECTED] wrote:
On 7/18/07, ant elder [EMAIL PROTECTED] wrote:
It will, just like when we commit code to SVN. I think its necessary if
we're to provide proper oversight of whats happening on our website, do
others agree?
...ant
On 7/18/07, haleh mahbod [EMAIL PROTECTED] wrote:
Ant,
will this get generated on each save? I typically do many saves when
working
on a page. I'd like to understand this to avoid flooding the mailing
list.
Haleh
On 7/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Page Edited : TUSCANY
http://cwiki.apache.org/confluence/display/TUSCANY: SCA
Java binding.jsonrpc
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.jsonrpc
SCA Java binding.jsonrpc
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.jsonrpc
has
been edited by
ant http://cwiki.apache.org/confluence/display/%7Eant (Jul 18,
2007).
(View changes)
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=54462originalVersion=17revisedVersion=18
Content:
Unable to render {include} Couldn't find a page to include called:
Repeating
Menu
http://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=TUSCANYtitle=Repeating+MenulinkCreation=truefromPageId=54462
*Documentation*
User Guide
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+User+Guide
Architecture Guide
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Architecture+Guide
Developer Guide
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Development+Guide
Extension Developer Guide
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Extension+Development+Guide
*Resources*
FAQ
http://cwiki.apache.org/confluence/display/TUSCANY/Tuscany+SCA+Java+-+FAQ
Source Code
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca
binding.jsonrpc
Tuscany supports JSON-RPC http://json-rpc.org/ as a protcol for use
with
SCA services by using the binding.jsonrpc SCDL extension. This
enables
remote web browser clients to easily make RPC style calls to
server-side
SCA
components.
This binding has no attributes or elements so to include it on a SCA
service simply requires the following SCDL:
binding.jsonrpc/
Also see binding.ajax
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+binding.ajax
which
provides some similar function.
Any JSON-RPC client may be used to access SCA services which use
binding.jsonrpc, but to simplify the task for web browsers the
binding
can generate a script which may be included within an HTML document to
set
up proxy objects for each SCA service within the HTML page
environment.
This script is used by simply including the following script tag
within
the HTML page:
script type=text/javascript src=SCA/SCADomain/scaDomain.js /
This initializes the proxys for the SCA services which can then be
used
make requests to the server-side components. For example, if there was
a
service named myService which had operations aOnewayRequest and
anRpcRequest the scripts in the HTML page could now invoke these
opperations with the following:
myService.aOnewayRequest(args);
or
myService.anRpcRequest(args, responseFunction);
In that example 'responseFunction' is the name of a function which is
called to process the response and which gets called asynchronously on
another thread when the response is avaialble. RPC requests are done
this
way instead of the simpler answer = myService.anRpcRequest(args) to
avoid hanging the browser while the (potentialy slow) request is being
processed. An example of the responseFunction for the previous example
is:
function responseFunction(answer){
// do something with answer
}
Using SCA JSON-RPC services with Dojo
Apache Tuscany JSON-RPC services provide built-in support for Dojo
RPC
http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book9.
The Dojo http://dojotoolkit.org/ toolkit is a popular framework for
writing Ajax/Web 2.0 style browser client applications. Tuscany SCA
services which use binding.jsonrpc will by default support the
Simple
Method Description (SMD) http://dojo.jot.com/SMD protocol. SMD is
similar to ?wsdl for Web services, entering a service endpoint
appended
with
?smd will return a SMD descriptor for the service.
Using Tuscany SCA services with Dojo can therefore be as simple as the
following:
var myService = new
