Re: [jira] Commented: (TUSCANY-1389) published DTD for composite XML Schema needed/useful - SUGGESTION
James, I'm not sure which XML tools that you are using, but I'll give you my experiences and make a suggestion. I use Eclipse and for XML and XSD editing I've installed the Eclipse Web Tools Project, which you can find here: http://www.eclipse.org/webtools/main.php The XML editor in WTP supports creation and editing of XML files with assist and validation based either on the use of DTD or on the use of XSD files to define the structure of the XML documents. Here is a quick and incomplete sample of an SCA composite file which I built using the editor: http://tempuri.org"; xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0 ../xsds/sca-core.xsd "> This had validation and assist working for me. Note the schemaLocation attribute in the composite element - this points at the xsds for SCA. In my case I had a local copy in my project, hence the "../xsds/..." location value. The XSDs are actually also available online in the place implied by their namespace: http://www.osoa.org/xmlns/sca/1.0/... So, I hope that by providing a correct schemaLocation attribute in your composite files you should be able to get the behaviour you're after. Now, I suppose the next thought is to ensure a valid schemaLocation attribute in our sample files xsi:schemaLocation="http://www.osoa.org/xmlns/sca/1.0 http://www.osoa.org/xmlns/sca/1.0/sca-core.xsd"; will do the trick I think. What do other folks think? Yours, Mike. James wrote: thanks for your reply. i adding information about Eclipse use of DTD. if similar for XSD then that's fine (i'm not an expert on this). see screenshots added to this issue. At 09:26 AM 6/27/2007, you wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508537 ] Mike Edwards commented on TUSCANY-1389: --- James, Does it have to be a DTD - or will an XSD be sufficient to meet your requirements? I have a particular dislike of DTDs born of having to deal with them in relation to SGML documents "back in the old days". There are plenty of tools that can work with XSDs and use them for validation. > published DTD for composite XML Schema needed/useful > > > Key: TUSCANY-1389 > URL: https://issues.apache.org/jira/browse/TUSCANY-1389 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA BigBank Sample, Java SCA Core Runtime, Java SCA Samples >Affects Versions: Java-SCA-0.90 > Environment: java >Reporter: James Tomkinson >Priority: Minor > > Samples should supply a DOCTYPE in *.composite xml files, that points to a stored DTD, so that XML editing tools can be used to create/edit/validate XML schema. This will enhance productivity/accuracy. > Example for Hibernate: >"-//Hibernate/Hibernate Configuration DTD 3.0//EN" > "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TuscanySCA C++ : The WSDLOperation instance returned by WSDLDefinition::findOperation( portTypeName, operationName ) does not have the endpoint set.
I have a patch implemented for this but have a few questions/issues before finalizing it. When testing the patch, I ran into a problem with the CppBigBank/bigbank.account/StockQuoteWebService.wsdl WSDL bindings. The WSDL has 3 bindings, only one of which is a SOAP binding, the other two are HTTP bindings. I considered discarding these non-SOAP bindings. Is that the correct thing to do? I'm inclined to think not. This leads into my second question: If we don't discard these non-SOAP bindings, a WSDLOperation should be created for the relavent operations. If we create a WSDLOperation for these bindings, how cohesive would that be, considering that the WSDLOperation seems rather SOAP-centric? The attributes documentStyle, wrappedStyle, encoded, and soapVer don't really apply to a WSDLOperation for an HTTP binding. Then there's the issue of having no attributes for http. A quick solution would be to have a string attribute called binding, and possibly some HTTP binding attributes. A better solution would be to use a Strategy design pattern, creating a Binding class hierarchy and having a Binding base class pointer in WSDLOperation. Do we really need to go that far, though? Thoughts anyone? Brady Johnson Lead Software Developer - HydraSCA Rogue Wave Software - [EMAIL PROTECTED] -Original Message- From: Pete Robbins [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 27, 2007 2:33 PM To: tuscany-dev@ws.apache.org Subject: Re: TuscanySCA C++ : The WSDLOperation instance returned by WSDLDefinition::findOperation( portTypeName, operationName ) does not have the endpoint set. On 27/06/07, Brady Johnson <[EMAIL PROTECTED]> wrote: > > I submit a TuscanySCA C++ JIRA for this. > > https://issues.apache.org/jira/browse/TUSCANY-1392 > > The problem is that the WSDLOperation instance returned by > WSDLDefinition::findOperation( portTypeName, operationName ) does not > have the endpoint set. I can see that its not set in > WSDLDefinition::findOperation() because that particular signature of > the method does not have access to the WSDL service, which is where > the endpoint is contained. The other signature of that method: > findOperation( serviceName, PortName, operationName ) does set the > endpoint in the WSDLOperation since it does have access to the WSDL > service. > > The fix for this problem is not trivial, and leads into another issue > with the findOperation() methods. Every time either method is called, > they walk the SDO, which could be an acceptable performance hit during > load time, but is not an efficient runtime search. There is an > operationMap available, but it is never populated. > > I think the best solution would be to traverse the wsdlModel SDO upon > instantiation, and when addWSDLModel() is called, and populate the > operationMap. This would solve the above problem of not having access > to the WSDL service endpoint, and also address the runtime performance > issues associated with walking the SDO. I would certainly vote for this option. > > Another less optimal solution would be to at least add the operation > to the operationMap each time findOperation() is called, effectively > caching the operations. But this still doesnt address the problem of > the WSDL service endpoint. > > When a solution is decided, I can implement the patch and submit it > for a contributor to put into the code base. > Please submit a patch when ready. I'm rebuilding my dev environment after a disk crash but should be able to apply/test patches soon. > Thanks > > > Brady Johnson > Lead Software Developer - HydraSCA > Rogue Wave Software - [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Tuscany Java SCA 0.91-incubating
On 6/28/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: Hi, Please review and vote on the 0.91 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~svkrish/tuscany/0.91-rc1/ The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/ Seems ok to me, so here is my +1. Thanks. - Venkat +1 This looks pretty good to me. There's a few things that could be improved - missing readme's for demos and some samples, some missing license headers have crept in, the rmi calculator client fails for me - none of those are blocking problems though. The biggest is for 0.90 we were asked to list all the jars under the Apache license just to make the licensing clear but thats missing, again not a blocker but it would be good to show we listen. I'll try to fix most of these in the brn in case we do cut another rc, but unless many more problems are discovered this rc gets my vote. ...ant
[jira] Commented: (TUSCANY-1377) Conversational PM- HTTP Session persistence
[ https://issues.apache.org/jira/browse/TUSCANY-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508925 ] Jean-Sebastien Delfino commented on TUSCANY-1377: - Additional comments from Lou Amodeo on the tuscany-dev. I was hoping from the title of this JIRA that the proposal was to persist the implementation instances in the Http Session object not just the conversationId. The ConversationScopeContainer would know how to store/retrieve from an HttpSession object associated with the conversationId. This would allow for exploiting existing infrastructure for failover and session affinity. > Conversational PM- HTTP Session persistence > --- > > Key: TUSCANY-1377 > URL: https://issues.apache.org/jira/browse/TUSCANY-1377 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-Next >Reporter: ant elder > Fix For: Java-SCA-Next > > > Implement conversational PM- HTTP Session persistence -- 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-1395) XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or xsd:boolean types
XSD2JavaGenerator -noUnsettable option is broken for models with xsd:int or
xsd:boolean types
-
Key: TUSCANY-1395
URL: https://issues.apache.org/jira/browse/TUSCANY-1395
Project: Tuscany
Issue Type: Bug
Components: Java SDO Tools
Affects Versions: Java-SDO-Next
Reporter: Ron Gavlin
Priority: Critical
Classes generated by XSD2JavaGenerator with the -noUnsettable option do not
compile if the associated schema has elements/attributes of type xsd:int or
xsd:boolean.
In order to reproduce the problem, invoke XSD2JavaGenerator with the
-noUnsettable flag and the customerAccount.xsd test schema. The following
method in the generated com.example.customer.impl.AccountImpl class has a
compiler error in its last line [notify(int, int, int, int) is invalid].
public void setAccountNum(int newAccountNum)
{
int oldAccountNum = accountNum;
accountNum = newAccountNum;
if (isNotifying())
notify(ChangeKind.SET, ACCOUNT_NUM, oldAccountNum, accountNum); //
COMPILER ERROR
}
- 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: Supporting callbacks across Web Services
Comment inline. Simon Simon Nash wrote: There are a few more changes that did not make it into the original list. In ImplementationProvider I have added a new method createCallbackInvoker. This needs to be implemented by all the implementation providers: JavaImplementationProvider ScriptImplementationProvider CRUDImplementationProvider My apologies. This method was previously there in the code. The createCallbackInvoker method that I added was for ServiceBindingProvider and is listed under item 7 in the original list. In ReferenceBindingProvider, createInvoker() no longer needs an isCallback parameter, so I have added a new createInvoker() method without this parameter and I have retained the existing method signature as @Deprecated. This raises the question of how we deprecate and replace SPIs now that we are trying to keep the SPIs stable. I'd suggest the following steps: 1. Deprecate existing method M1 and add new replacement method M2. The new core framework should first attempt to call method M2 and catch an error if it does not exist. If M2 does not exist because this is an old extension binary that doesn't implement M2, the core framework should fall back to calling M1 (which will exist in an old extension). Extensions that are compiled against the new SPI need to implement both M1 and M2. 2. Deliver step 1 in some release R1. When extension developers move up to compiling against release R1, they must change their code to implement both M1 and M2. 3. In the next release after R1 (call it R2), change the SPI again to remove M1 and change the core framework to only call M2. 4. When extension developers are comfortable with moving up their extensions to depend on release R2, they can remove the M1 implementation from their code (leaving M2 there) and recompile and run against R2. Any comments on this? Do we all think this is the right way to handle SPI deprecation? Simon Simon Nash wrote: I have this working now and I'd like to summarize the changes I have made. I am now working on gathering all my changes together and creating a patch. I'll put more detailed information about the changes and the patch in TUSCANY-1341. Changes 1 through 13 below provide the necessary core enablement for bindings to support callbacks in any manner they choose. Changes 14 through 20 restore the previous limited support for callbacks across Web services. This code is useful for testing some end-to-end scenarios but it needs to be replaced by a full implementation based on WS-Addressing. I'm planning to start work on this after creating patches for my changes so far. My goal has been to make it possible to add support for this in the Web Service binding without needing to change the core enablement provided by changes 1 through 13. The highlights of the core enablement changes from a design/architecture perspective are as follows: * Bindings are marked as either forward bindings or callback bindings. * A service or reference with a callback interface will have both a forward binding and a callback binding, with separate binding providers for the forward and callback paths. * Runtime wires for forward bindings have an interface contract with a forward interface only and no callback interface. Runtime wires for callback bindings have an interface contract with a callback interface only and no forward interface. This means that for interfaces with callbacks, there are now two unidrectional runtime wires where there used to be a single bidirectional runtime wire. Here is the detailed list of changes: 1. InterfaceContractMapperImpl.checkCompatibility - copy existing FIXME code from forward interface path to callback interface path. 2. WebServiceBindingProcessor.resolve - set callback interface in interface contract for callback bindings. 3. CompositeActivatorImpl - fix createWires to handle callback interfaces and callback bindings correctly, and to avoid adding nonblocking interceptors for bindings that respect nonblocking semantics. 4. DataBindingRuntimeWireProcessor - don't transform void return type. 5. JDKCallbackInvocationHandler - handle callback wires with null "from" endpoints, and avoid the need to create and populate a new Map object on every callback invocation. 6. ReferenceBindingProvider - add supportsAsyncOneWayInvocation method (see 3 above). 7. ServiceBindingProvider - add supportsAsyncOneWayInvocation method (see 3 above) and createCallbackInvoker method. 8. RuntimeSCABindingProvider - add supportsAsyncOneWayInvocation method (see 3 above). 9. Binding - add indication of whether this is a forward binding or a callback bindings 10. CompositeProcessor - set bindings as either forward or callback. 11. InterfaceContract - make cloneable, add makeUnidirectional method 12. InterfaceContractImpl - add makeUnidirectional method 13. RuntimeWire and Runt
[VOTE] Release Tuscany Java SCA 0.91-incubating
Hi, Please review and vote on the 0.91 release artifacts of Tuscany SCA for Java. The artifacts are available for review at: http://people.apache.org/~svkrish/tuscany/0.91-rc1/ The SVN tag for the release is: https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/0.91-rc1-incubating/ Seems ok to me, so here is my +1. Thanks. - Venkat
[jira] Commented: (TUSCANY-1237) DAS should support JDK 1.4
[ https://issues.apache.org/jira/browse/TUSCANY-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508907 ] Ron Gavlin commented on TUSCANY-1237: - My proposal is to modify the DAS pom maven-compiler-plugin configuration to specify 1.4 for both the source and target. This is similar to the approach taken by the SDO sub-project. A few of the sample modules (companyweb & ajax)currently use meaningful JDK 5 features. Should I leave these as JDK 5 samples or downgrade them also to use only 1.4 features. Let me know. - Ron > DAS should support JDK 1.4 > -- > > 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 > Fix For: Java-DAS-Next > > > 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: [jira] Commented: (TUSCANY-1377) Conversational PM- HTTP Session persistence
I was hoping from the title of this JIRA that the proposal was to persist the implementation instances in the Http Session object not just the conversationId. The ConversationScopeContainer would know how to store/retrieve from an HttpSession object associated with the conversationId. This would allow for exploiting existing infrastructure for failover and session affinity. On 6/27/07, Mike Edwards (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508486] Mike Edwards commented on TUSCANY-1377: --- There is a mixture of 2 things here, as described in Sebastien's last comment: 1) Handling of Scope for components (he mentions implementation.java, which is fine) 2) Dealing with conversational sessions on the HTTP binding These two are NOT directly related. You can do one without the other. I'd suggest sorting out the HTTP binding first - only once there is a conversation going on between 2 components over the wire does it become useful to implement the Scope attribute on a component. > Conversational PM- HTTP Session persistence > --- > > Key: TUSCANY-1377 > URL: https://issues.apache.org/jira/browse/TUSCANY-1377 > Project: Tuscany > Issue Type: Improvement > Components: Java SCA Core Runtime >Affects Versions: Java-SCA-Next >Reporter: ant elder > Fix For: Java-SCA-Next > > > Implement conversational PM- HTTP Session persistence -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DAS Support for JDK 1.4 was, Re: [jira] Commented: (TUSCANY-1237) DAS should support JDK 1.4
Hi Ron It would be great to have these on DAS beta1 if you are not going to take much longer to have the patch available. What's the timeframe for having the patch ? What's the solution you are proposing ? Are you just adding the ability to compile DAS with a JDK1.4 or your proposal is to have a set of 1.4 binaries available as well ? Thanks On 6/28/07, Ron Gavlin (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508866 ] Ron Gavlin commented on TUSCANY-1237: - I am preparing a patch for this issue. The changes are fairly benign. Is it too late for the patch to be included in the next release? If not, when would you need the patch submitted in order to include it? Thanks, - Ron > DAS should support JDK 1.4 > -- > > 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 > Fix For: Java-DAS-Next > > > 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] -- 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: SDO C++ compliance with 2.1 spec - help needed
Pete Robbins wrote: On 25/06/07, Caroline Maynard <[EMAIL PROTECTED]> wrote: A fair amount actually, but I am making an assumption that once the changes are in place, the migration effort will be largely refactoring. That is, that the non-spec function will resurface in Tuscany implementation classes (if not adopted by the spec). If this is not the case, then the response from the php implementation could be different. Do you have a list of the non-spec interfaces PHP is using? I believe the getUserData interfaces were added for PHP use?? Yes, the UserData stuff was added as somewhere for consumers (like PHP) to be able to augment the DataObject with their own data, and it's crucial to our implementation. I've given some thought as to how we could easily create a definitive list of the Tuscany APIs employed. But since the PHP implementation includes the Tuscany code, we don't have the ability to simply list the external references as we would for a dynamic library, unless you can suggest another way. However we don't have a huge amount of code, and it is very simple to download it from cvs using pserver:[EMAIL PROTECTED]:/repository checkout pecl/sdo and load it into cscope or similar, so you could easily check for references that way. Or you could just mail us :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r551409 - in /incubator/tuscany/java/sca/modules/implementation-bpel: lib/ lib/maven-artifact-ant-2.0.4-dep.jar pom.xml src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/Emb
I have changed this to use the maven plugin for unpack the ODE DB and
removed the lib directory. This was done under revision #551630.
On 6/28/07, ant elder <[EMAIL PROTECTED]> wrote:
How come this ant jar needs to be checked into our svn and can't be got like
usual maven dependencies? (just trying to understand whats going on)
...ant
On 6/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Author: lresende
> Date: Wed Jun 27 17:03:00 2007
> New Revision: 551409
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=551409
> Log:
> TTUSCANY-1394 - Applying patch from Mathieu Riou
>
> Added:
> incubator/tuscany/java/sca/modules/implementation-bpel/lib/
> incubator/tuscany/java/sca/modules/implementation-bpel/lib/maven-
> artifact-ant-2.0.4-dep.jar (with props)
> Modified:
> incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml
>
incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java
>
>
> Added: incubator/tuscany/java/sca/modules/implementation-bpel/lib/maven-
> artifact-ant-2.0.4-dep.jar
> URL:
>
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/implementation-bpel/lib/maven-artifact-ant-2.0.4-dep.jar?view=auto&rev=551409
> ==
>
> Binary file - no diff available.
>
> Propchange:
> incubator/tuscany/java/sca/modules/implementation-bpel/lib/maven-
> artifact-ant-2.0.4-dep.jar
> --
>
> svn:mime-type = application/octet-stream
>
> Modified: incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml
> URL:
>
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml?view=diff&rev=551409&r1=551408&r2=551409
> ==
>
> --- incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml
> (original)
> +++ incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml Wed Jun
> 27 17:03:00 2007
> @@ -102,42 +102,42 @@
>
> org.apache.ode
> ode-bpel-epr
> -1.1-SNAPSHOT
> +1.0-incubating
>
>
> org.apache.ode
> ode-bpel-dao
> - 1.1-SNAPSHOT
> +1.0-incubating
>
>
> org.apache.ode
> ode-bpel-dao
> -1.1-SNAPSHOT
> +1.0-incubating
>
>
> org.apache.ode
> ode-dao-jpa
> -1.1-SNAPSHOT
> +1.0-incubating
>
>
> org.apache.ode
> ode-bpel-runtime
> -1.1-SNAPSHOT
> +1.0-incubating
>
>
> org.apache.ode
> ode-bpel-api
> -1.1-SNAPSHOT
> +1.0-incubating
>
>
> org.apache.ode
> ode-bpel-scheduler-quartz
> -1.1-SNAPSHOT
> +1.0-incubating
>
>
> org.apache.ode
> ode-utils
> -1.1-SNAPSHOT
> +1.0-incubating
>
>
>
> @@ -213,4 +213,26 @@
>
>
>
> +
> +
> +
> +
> +maven-antrun-plugin
> + org.apache.maven.plugins
> +
> +
> +
> +test-compile
> +run
> +
> +
> + inheritRefs="true"/>
> +
> +
> +
> +
> +
> +
> +
> +
>
>
> Modified:
>
incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java
> URL:
>
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java?view=diff&rev=551409&r1=551408&r2=551409
>
> ==
> ---
>
incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java
> (original)
> +++
>
incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java
> Wed Jun 27 17:03:00 2007
> @@ -32,6 +32,7 @@
> import java.util.concurrent.Executors ;
> import java.util.concurrent.ExecutorService;
> import java.io.File;
> +import java.net.URL;
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> @@ -56,7 +57,12 @@
>
> public void init() throws ODEInitializationException {
> _config = new Ode
Re: Supporting callbacks across Web Services
There are a few more changes that did not make it into the original list. In ImplementationProvider I have added a new method createCallbackInvoker. This needs to be implemented by all the implementation providers: JavaImplementationProvider ScriptImplementationProvider CRUDImplementationProvider In ReferenceBindingProvider, createInvoker() no longer needs an isCallback parameter, so I have added a new createInvoker() method without this parameter and I have retained the existing method signature as @Deprecated. This raises the question of how we deprecate and replace SPIs now that we are trying to keep the SPIs stable. I'd suggest the following steps: 1. Deprecate existing method M1 and add new replacement method M2. The new core framework should first attempt to call method M2 and catch an error if it does not exist. If M2 does not exist because this is an old extension binary that doesn't implement M2, the core framework should fall back to calling M1 (which will exist in an old extension). Extensions that are compiled against the new SPI need to implement both M1 and M2. 2. Deliver step 1 in some release R1. When extension developers move up to compiling against release R1, they must change their code to implement both M1 and M2. 3. In the next release after R1 (call it R2), change the SPI again to remove M1 and change the core framework to only call M2. 4. When extension developers are comfortable with moving up their extensions to depend on release R2, they can remove the M1 implementation from their code (leaving M2 there) and recompile and run against R2. Any comments on this? Do we all think this is the right way to handle SPI deprecation? Simon Simon Nash wrote: I have this working now and I'd like to summarize the changes I have made. I am now working on gathering all my changes together and creating a patch. I'll put more detailed information about the changes and the patch in TUSCANY-1341. Changes 1 through 13 below provide the necessary core enablement for bindings to support callbacks in any manner they choose. Changes 14 through 20 restore the previous limited support for callbacks across Web services. This code is useful for testing some end-to-end scenarios but it needs to be replaced by a full implementation based on WS-Addressing. I'm planning to start work on this after creating patches for my changes so far. My goal has been to make it possible to add support for this in the Web Service binding without needing to change the core enablement provided by changes 1 through 13. The highlights of the core enablement changes from a design/architecture perspective are as follows: * Bindings are marked as either forward bindings or callback bindings. * A service or reference with a callback interface will have both a forward binding and a callback binding, with separate binding providers for the forward and callback paths. * Runtime wires for forward bindings have an interface contract with a forward interface only and no callback interface. Runtime wires for callback bindings have an interface contract with a callback interface only and no forward interface. This means that for interfaces with callbacks, there are now two unidrectional runtime wires where there used to be a single bidirectional runtime wire. Here is the detailed list of changes: 1. InterfaceContractMapperImpl.checkCompatibility - copy existing FIXME code from forward interface path to callback interface path. 2. WebServiceBindingProcessor.resolve - set callback interface in interface contract for callback bindings. 3. CompositeActivatorImpl - fix createWires to handle callback interfaces and callback bindings correctly, and to avoid adding nonblocking interceptors for bindings that respect nonblocking semantics. 4. DataBindingRuntimeWireProcessor - don't transform void return type. 5. JDKCallbackInvocationHandler - handle callback wires with null "from" endpoints, and avoid the need to create and populate a new Map object on every callback invocation. 6. ReferenceBindingProvider - add supportsAsyncOneWayInvocation method (see 3 above). 7. ServiceBindingProvider - add supportsAsyncOneWayInvocation method (see 3 above) and createCallbackInvoker method. 8. RuntimeSCABindingProvider - add supportsAsyncOneWayInvocation method (see 3 above). 9. Binding - add indication of whether this is a forward binding or a callback bindings 10. CompositeProcessor - set bindings as either forward or callback. 11. InterfaceContract - make cloneable, add makeUnidirectional method 12. InterfaceContractImpl - add makeUnidirectional method 13. RuntimeWire and RuntimeWireImpl - addCallbackInvocationChain and getCallbackInvocationMap methods to avoid the need to create and populate two Map objects on the callback invocation path (see 5 above). 14. Axis2ReferenceBindingProvider - support callback
Tuscany Release Guide
I just noticed Ant started building a release guide in [1], there is also a guide available in [2]. I'd like to propose merging both, and making a "Tuscany Release Guide" that would be used for all Tuscany sub-projects. Thoughts ? [1] http://cwiki.apache.org/confluence/display/TUSCANY/Making+releases [2] http://cwiki.apache.org/confluence/display/TUSCANY/DAS+Release+Process -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1237) DAS should support JDK 1.4
[ https://issues.apache.org/jira/browse/TUSCANY-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508866 ] Ron Gavlin commented on TUSCANY-1237: - I am preparing a patch for this issue. The changes are fairly benign. Is it too late for the patch to be included in the next release? If not, when would you need the patch submitted in order to include it? Thanks, - Ron > DAS should support JDK 1.4 > -- > > 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 > Fix For: Java-DAS-Next > > > 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]
[jira] Resolved: (TUSCANY-1369) EMF 2.2.2 Dependencies from ISU are Stale
[ https://issues.apache.org/jira/browse/TUSCANY-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin Goodson resolved TUSCANY-1369. - Resolution: Fixed > EMF 2.2.2 Dependencies from ISU are Stale > - > > Key: TUSCANY-1369 > URL: https://issues.apache.org/jira/browse/TUSCANY-1369 > Project: Tuscany > Issue Type: Bug > Components: Java SDO Implementation > Environment: All. >Reporter: Brian ONeill >Priority: Minor > Attachments: emf_dependency_fix.txt > > > There is a reference to the following repository in a few pom.xml's > > > > > indiana > http://ftp.ussg.iu.edu/eclipse/modeling/emf/emf/maven2/ > > true > > > That repository no longer contains the 2.2.2 artifacts. I updated the > version to 2.2.3, which is contained in that repository; and all compiled > just fine. -- 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: Sample with SDO Databinding over web service
I will check out that test case and try to build a sample to contribute. My problems have not been very consistent, depending on which combination of SCA and SDO I use. I've been trying with SCA 0.90 with SDO beta 1, SCA trunk with whatever version of SDO maven retrieves, SCA trunk with SDO trunk, and SCA 0.90 and SCA trunk with SDO revision that has this fix: https://issues.apache.org/jira/browse/TUSCANY-1250 . Also looked quickly at the SCA 0.91 branch, but building with mvn did not complete. What is a good version of SCA/SDO I should use to build the sample with? - Original Message From: Jean-Sebastien Delfino <[EMAIL PROTECTED]> To: tuscany-dev@ws.apache.org Sent: Wednesday, June 27, 2007 8:31:29 PM Subject: Re: Sample with SDO Databinding over web service [EMAIL PROTECTED] wrote: > I've been running into all kinds of problems trying to get a simple example > going using a webapp, SDO objects generated from a wsdl and webservice > binding. Is there a sample (or anyone have existing working code) in this > kind of format? I thought it would be a common basic scenario, but I didn't > see any SDO databinding samples around. Would appreciate any sort of > guidance. > Hi, There's no sample yet, but a pretty comprehensive test case there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/ In that test suite, take a look at: SDOWSDLTest.java - calls Web Service operations that flow various combinations of simple and complex types, represented as SDO DataObjects AccountService.wsdl - the test Web service description SDOWSDLTest.composite - the test composite, declares an SDO DataFactory using an extension element Hope this helps. Would you mind reporting the problems you've run in a JIRA issue? this way people can start looking at them and help fix them :) Thanks. Also, if anybody on the mailing list is interested in contributing a new useful sample, I think it would be great to add a new sample showing how to provide and consume a Web Service taking an XSD complex type bound to an SDO DataObject, similar to the above test case, but a real sample, simpler and with a nice README... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Fuhwei Lwo for Tuscany Committer
+1 from me, welcome Fuhwei. On 6/26/07, kelvin goodson <[EMAIL PROTECTED]> wrote: I'd like to propose Fuhwei Lwo as a Tuscany Committer. According to my gmail archive he has, since mid of 2006, posted 114 times to tusany-dev, 79 of those times resulting from interactions with JIRA issue management. He has raised 34 JIRAs (see [1]) The gmail search -- "from:fuhwei [jira] Attachment:" shows that Fuhwei has attached around 27 patches to JIRAs. The JIRAs he raises, the comments he makes and the solutions he provides demonstrate in depth knowledge of SDO and clearly he will be a strong asset for the community. Please vote to give Fuhwei this well deserved status Regards, Kelvin. [1] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&reporterSelect=specificuser&reporter=fuhwei&sorter/field=issuekey&sorter/order=DESC&sorter/field=components&sorter/order=ASC&sorter/field=updated&sorter/order=DESC
Re: svn commit: r551409 - in /incubator/tuscany/java/sca/modules/implementation-bpel: lib/ lib/maven-artifact-ant-2.0.4-dep.jar pom.xml src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/Emb
How come this ant jar needs to be checked into our svn and can't be got like
usual maven dependencies? (just trying to understand whats going on)
...ant
On 6/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: lresende
Date: Wed Jun 27 17:03:00 2007
New Revision: 551409
URL: http://svn.apache.org/viewvc?view=rev&rev=551409
Log:
TTUSCANY-1394 - Applying patch from Mathieu Riou
Added:
incubator/tuscany/java/sca/modules/implementation-bpel/lib/
incubator/tuscany/java/sca/modules/implementation-bpel/lib/maven-
artifact-ant-2.0.4-dep.jar (with props)
Modified:
incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml
incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java
Added: incubator/tuscany/java/sca/modules/implementation-bpel/lib/maven-
artifact-ant-2.0.4-dep.jar
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/implementation-bpel/lib/maven-artifact-ant-2.0.4-dep.jar?view=auto&rev=551409
==
Binary file - no diff available.
Propchange:
incubator/tuscany/java/sca/modules/implementation-bpel/lib/maven-
artifact-ant-2.0.4-dep.jar
--
svn:mime-type = application/octet-stream
Modified: incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml?view=diff&rev=551409&r1=551408&r2=551409
==
--- incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml
(original)
+++ incubator/tuscany/java/sca/modules/implementation-bpel/pom.xml Wed Jun
27 17:03:00 2007
@@ -102,42 +102,42 @@
org.apache.ode
ode-bpel-epr
-1.1-SNAPSHOT
+1.0-incubating
org.apache.ode
ode-bpel-dao
- 1.1-SNAPSHOT
+1.0-incubating
org.apache.ode
ode-bpel-dao
-1.1-SNAPSHOT
+1.0-incubating
org.apache.ode
ode-dao-jpa
-1.1-SNAPSHOT
+1.0-incubating
org.apache.ode
ode-bpel-runtime
-1.1-SNAPSHOT
+1.0-incubating
org.apache.ode
ode-bpel-api
-1.1-SNAPSHOT
+1.0-incubating
org.apache.ode
ode-bpel-scheduler-quartz
-1.1-SNAPSHOT
+1.0-incubating
org.apache.ode
ode-utils
-1.1-SNAPSHOT
+1.0-incubating
@@ -213,4 +213,26 @@
+
+
+
+
+maven-antrun-plugin
+ org.apache.maven.plugins
+
+
+
+test-compile
+run
+
+
+
+
+
+
+
+
+
+
+
Modified:
incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java?view=diff&rev=551409&r1=551408&r2=551409
==
---
incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java
(original)
+++
incubator/tuscany/java/sca/modules/implementation-bpel/src/main/java/org/apache/tuscany/sca/implementation/bpel/ode/EmbeddedODEServer.java
Wed Jun 27 17:03:00 2007
@@ -32,6 +32,7 @@
import java.util.concurrent.Executors ;
import java.util.concurrent.ExecutorService;
import java.io.File;
+import java.net.URL;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
@@ -56,7 +57,12 @@
public void init() throws ODEInitializationException {
_config = new OdeConfigProperties(new Properties(), "ode-sca");
-_workRoot = new File("ode-work");
+
+// Setting work root as the directory containing our database
(wherever in the classpath)
+URL dbLocation =
getClass().getClassLoader().getResource("jpadb");
+if (dbLocation == null)
+throw new ODEInitializationException("Couldn't find database
in the classpath");
+_workRoot = new File(dbLocation.getFile()).getParentFile();
initTxMgr();
Re: Supporting callbacks across Web Services
I have this working now and I'd like to summarize the changes I have made. I am now working on gathering all my changes together and creating a patch. I'll put more detailed information about the changes and the patch in TUSCANY-1341. Changes 1 through 13 below provide the necessary core enablement for bindings to support callbacks in any manner they choose. Changes 14 through 20 restore the previous limited support for callbacks across Web services. This code is useful for testing some end-to-end scenarios but it needs to be replaced by a full implementation based on WS-Addressing. I'm planning to start work on this after creating patches for my changes so far. My goal has been to make it possible to add support for this in the Web Service binding without needing to change the core enablement provided by changes 1 through 13. The highlights of the core enablement changes from a design/architecture perspective are as follows: * Bindings are marked as either forward bindings or callback bindings. * A service or reference with a callback interface will have both a forward binding and a callback binding, with separate binding providers for the forward and callback paths. * Runtime wires for forward bindings have an interface contract with a forward interface only and no callback interface. Runtime wires for callback bindings have an interface contract with a callback interface only and no forward interface. This means that for interfaces with callbacks, there are now two unidrectional runtime wires where there used to be a single bidirectional runtime wire. Here is the detailed list of changes: 1. InterfaceContractMapperImpl.checkCompatibility - copy existing FIXME code from forward interface path to callback interface path. 2. WebServiceBindingProcessor.resolve - set callback interface in interface contract for callback bindings. 3. CompositeActivatorImpl - fix createWires to handle callback interfaces and callback bindings correctly, and to avoid adding nonblocking interceptors for bindings that respect nonblocking semantics. 4. DataBindingRuntimeWireProcessor - don't transform void return type. 5. JDKCallbackInvocationHandler - handle callback wires with null "from" endpoints, and avoid the need to create and populate a new Map object on every callback invocation. 6. ReferenceBindingProvider - add supportsAsyncOneWayInvocation method (see 3 above). 7. ServiceBindingProvider - add supportsAsyncOneWayInvocation method (see 3 above) and createCallbackInvoker method. 8. RuntimeSCABindingProvider - add supportsAsyncOneWayInvocation method (see 3 above). 9. Binding - add indication of whether this is a forward binding or a callback bindings 10. CompositeProcessor - set bindings as either forward or callback. 11. InterfaceContract - make cloneable, add makeUnidirectional method 12. InterfaceContractImpl - add makeUnidirectional method 13. RuntimeWire and RuntimeWireImpl - addCallbackInvocationChain and getCallbackInvocationMap methods to avoid the need to create and populate two Map objects on the callback invocation path (see 5 above). 14. Axis2ReferenceBindingProvider - support callbacks (many changes). 15. Axis2ReferenceCallbackTargetInvoker - restore commented out line. 16. Axis2CallbackInvocationHandler - rewrite invoke method to avoid the need to create and populate a new Map object. 17. Axis2ServiceBindingProvider - support callbacks (many changes). 18. Axis2ServiceInOutAsyncMessageReceiver - uncomment code. 19. Axis2ServiceInMessageReceiver - uncomment code. 20. Axis2InOutAsyncMessageReceiver - pass callback provider. Simon Simon Nash wrote: I thought of a slightly different approach that would be closer to the current code. reference myService interface contract forward binding interface callback binding interface forward binding.ws binding interface contract forward binding interface null callback binding interface (other forward bindings) callback binding.ws binding interface contract null forward binding interface callback binding interface (other callback bindings) I'll see how I get on with this. Simon Simon Nash wrote: I am making good progress with getting callbacks working across the Web Service binding. In the process of doing this I have learned a lot about SCA callbacks and the Tuscany runtime. So far the code changes I have made are all fairly minor, and working out what is needed has been a good learning experience. My changes are divided into two categories: 1. fixing some bugs in the core runtime framework for supporting callbacks when bindings are involved 2. reinstating the code in the Web Service binding that handles callbacks. I see the latter as a temporary solution only and I intend to look into how to make callbacks using WS-Addressin
Re: [VOTE] Fuhwei Lwo for Tuscany Committer
+1 (non-binding) for Fuhwei. Excellent work! Simon Simon Laws wrote: On 6/27/07, Luciano Resende <[EMAIL PROTECTED]> wrote: +1 Welcome Fuhwei On 6/27/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > +1 from me. > > Thanks, > Raymond > > - Original Message - > From: "Frank Budinsky" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, June 26, 2007 5:47 AM > Subject: Re: [VOTE] Fuhwei Lwo for Tuscany Committer > > > > Absolutely +1 from me! > > > > Frank. > > > > "kelvin goodson" <[EMAIL PROTECTED]> wrote on 06/26/2007 07:10:23 > > AM: > > > >> I'd like to propose Fuhwei Lwo as a Tuscany Committer. > >> > >> According to my gmail archive he has, since mid of 2006, posted 114 > > times to > >> tusany-dev, 79 of those times resulting from interactions with JIRA > > issue > >> management. > >> > >> He has raised 34 JIRAs (see [1]) > >> > >> The gmail search -- "from:fuhwei [jira] Attachment:" shows > > that > >> Fuhwei has attached around 27 patches to JIRAs. > >> > >> The JIRAs he raises, the comments he makes and the solutions he provides > >> demonstrate in depth knowledge of SDO and clearly he will be a strong > > asset > >> for the community. > >> > >> Please vote to give Fuhwei this well deserved status > >> > >> Regards, Kelvin. > >> > >> [1] > >> http://issues.apache.org/jira/secure/IssueNavigator.jspa? > >> > > reset=true&&pid=12310210&reporterSelect=specificuser&reporter=fuhwei&sorter/field=issuekey&sorter/order=DESC&sorter/field=components&sorter/order=ASC&sorter/field=updated&sorter/order=DESC > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 from me. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can an implementation provider detect changes to its SCA domain?
Simon, Thank you, this was exactly what I was looking for (obviously didn't try hard enough to find it). Thank you... Regards, Rajini On 6/27/07, Simon Laws <[EMAIL PROTECTED]> wrote: On 6/27/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > Hello, > > Is there any way for an implementation provider to detect when a > contribution is updated/removed from an SCA domain or when a domain is > closed? > > The OSGi implementation provider for SCA allows an OSGi bundle to be > shared > across multiple SCA components. The bundles need to be uninstalled at some > point, and since only the implementation provider knows about its > installed > bundles, it needs to uninstall them when the contribution is removed from > the SCA domain and also before any updates to the contribution. The bundle > cannot be uninstalled when the component is deactivated since there could > be > other components which are using the bundle. Unfortunately OSGi does not > provide reference counting for its bundles, so the implementation provider > for SCA has to figure out when it is safe to uninstall the bundles that it > installed. Any suggestions on how this could be done are appreciated. > > Thank you... > > Regards, Rajini Hi Rajini Ignacio started a thread generally about notification [1] and Huag Kai started another about system events [2]. It sounds like you would like to subscribe to events to do with contrigutions being removed. It would be good to have you input on this so this can work for you too. Regards Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19181.html [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg19365.html
