Re: svn commit: r556249 - /incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
For a similar reason as line 84/85 says ...the wsdlElement attribute must
refer to a binding element in the WSDL and not an endpoint or service? I
agree the spec isn't 100% clear but it seems a mistake to me that line 85
doesn't continue on saying a similar thing for the uri attribute. If you do
specify both the wsdl port and a uri then the uri is completely and silently
ignored which i've found quite confusing in the past and likely other users
may too.
How about keeping the exception for now until we have our logging strategy
in place and then changing it so a warning msg is produced instead of
throwing the exception?
...ant
On 7/14/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Ant.
It was me who commented out the code when I debugged a test case and ran
into this exception. The WS binding spec says the following:
The rules for resolving the URI at which an SCA service is hosted, or SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the
wsa:EndpointReference,
76 2. The explicitly stated URI in the uri attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification
Why is it an error if both uri and WSDL endpoint are present? The spec
seems
to say we should use the WSDL endpoint over the binding uri in this case
and
they are not exclusive. Maybe I miss some points. Please clarify.
Thanks,
Raymond
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, July 14, 2007 2:19 AM
Subject: svn commit: r556249 -
/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
Author: antelder
Date: Sat Jul 14 02:18:59 2007
New Revision: 556249
URL: http://svn.apache.org/viewvc?view=revrev=556249
Log:
Remove unused import,
add back in throwing exception when using wsdl port endpoint but a uri
is
specified on the scdl binding
(not sure why that got commented out, all the tests pass with it in and
it
makes it much easier to debug so adding it back and see if anyone
complains)
Modified:
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
Modified:
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java?view=diffrev=556249r1=556248r2=556249
==
---
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
(original)
+++
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
Sat Jul 14 02:18:59 2007
@@ -65,7 +65,6 @@
private ConfigurationContext configContext;
private MessageFactory messageFactory;
private Axis2ServiceBindingProvider callbackProvider;
-private InterfaceContract bindingInterfaceContract;
// TODO: what to do about the base URI?
private static final String BASE_URI = http://localhost:8080/;;
@@ -193,9 +192,9 @@
wsdlURI = getEndpoint(wsBinding.getPort());
}
if (wsdlURI != null wsdlURI.isAbsolute()) {
-//if (wsBinding.getURI() != null
(wsBinding.getServiceName() != null wsBinding.getBindingName() ==
null)) {
-//throw new IllegalArgumentException(binding URI
cannot
be used with absolute WSDL endpoint URI);
-//}
+if (wsBinding.getURI() != null (wsBinding.getServiceName
()
!= null wsBinding.getBindingName() == null)) {
+throw new IllegalArgumentException(binding URI cannot
be
used with absolute WSDL endpoint URI);
+}
return URI.create(wsdlURI.toString());
}
-
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: Getting developer jira access to Amita Vadhavkar
+1 from me Yours, Mike. Luciano Resende wrote: Amita Vadhavkar has been helping DAS for couple months and recently also started to help on SDO and had contributed many patches. I'd like to give her developer access to JIRA so she can manage JIRAs with more flexibility, etc. Thoughts ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1391) Provide capability to load and save XML with unknown features
[ https://issues.apache.org/jira/browse/TUSCANY-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512793 ] Amita Vadhavkar commented on TUSCANY-1391: -- Hi Fuhwei, I compared the patch I sumbitted on July 10 with the latest one (13th July ) and there is no difference anywhere, so will you please check if you have not attached the cleaned patch here? For future improvement, we can definitely consider making content in SDO terms for unknown properties as well as possibility of SAVE option support. Regards, Amita Provide capability to load and save XML with unknown features - Key: TUSCANY-1391 URL: https://issues.apache.org/jira/browse/TUSCANY-1391 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-1.0 Reporter: Amita Vadhavkar Attachments: 1391.patch, 1391.patch, 1391.patch, 1391.patch, JIRA1391Design.txt, JIRA1391Design.txt expose XMLResource.OPTION_RECORD_UNKNOWN_FEATURE through tuscany-sdo-impl -- 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: Website ACL
Folks, I think that we should consider the idea of Website Wiki committership separately from Code committership. I don't think that it should be necessary for someone to have Code committership in order to be granted update access to the Website/Wiki. I do agree that it needs to be controlled, but that we should draw up a wider list of folk who are allowed to edit material on the Website. As has been pointed out, updates to the website have slowed down since we restricted write access. This is not good. Our website needs plenty of work. Yours, Mike. Luciano Resende wrote: My only concern is that, after we restricted access to our wiki, and started using the process of JIRA or updates on the other wiki space, the website contributions basically stopped. I think we had only one JIRA created on this space. On 7/13/07, ant elder [EMAIL PROTECTED] wrote: On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote: I was referring to the following paragraph... a CLA is required for cover substantial contributions for source. therefore wiki karma must only be granted those with a CLA. Yes but that doesn't mean that the converse is also true, ie just having a CLA doesn't give the right to be granted wiki karma. +1 Robert also says later on : a committer is essentially a developer with a CLA and also that provenance needs to be established and oversight maintained If we have control to who gets access, and we are covered, on the legal aspects, by having the CLA in place, we should be Ok. What are your concerns here ? As with the code, it requires more than just having a CLA to be granted commit access to our SVN. The other two alternatives I see are : - Make wiki patches, or copies from ocpy of the website wiki - Make all website contributors a Tuscany committer +1, both of these seem appropriate to me. People can raise JIRAs and do proposed updates on the TUSCANYWIKI space, once they've proven themselves we can vote them in as a website committer just like from code contributions. ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support
[ https://issues.apache.org/jira/browse/TUSCANY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1431: - Attachment: 1431_xquery.patch 1431_api.patch this is just a work in progress, where config (xquery specific) is created and some basic classes are in progress. trying and checking different XQuery implementations available - like Saxon, DB2 Express etc. Next patch will have some work on that. Please give suggestions based on patch and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19983.html Thanks, Amita 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 Attachments: 1431_api.patch, 1431_xquery.patch 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: svn commit: r556249 - /incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
Hi,
My understanding is that the spec treats the uri of endpoint from the
referenced WSDL and uri of wsa:Address from the wsa:EndpointReference at the
same level (Line 73, Item 1 of the WS binding spec uses or). Therefore,
these two are exclusive.
Anyway, I agree with you the spec is not clear. Let's bring it up to spec
guys to clarify before we change the code.
Thanks,
Raymond
- Original Message -
From: ant elder [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Sunday, July 15, 2007 2:23 AM
Subject: Re: svn commit: r556249 -
/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
For a similar reason as line 84/85 says ...the wsdlElement attribute must
refer to a binding element in the WSDL and not an endpoint or service? I
agree the spec isn't 100% clear but it seems a mistake to me that line 85
doesn't continue on saying a similar thing for the uri attribute. If you
do
specify both the wsdl port and a uri then the uri is completely and
silently
ignored which i've found quite confusing in the past and likely other
users
may too.
How about keeping the exception for now until we have our logging strategy
in place and then changing it so a warning msg is produced instead of
throwing the exception?
...ant
On 7/14/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi, Ant.
It was me who commented out the code when I debugged a test case and ran
into this exception. The WS binding spec says the following:
The rules for resolving the URI at which an SCA service is hosted, or
SCA
reference targets,
72 when used with binding.ws (in precedence order) are:
73 1. The URIs in the endpoint(s) of the referenced WSDL
74 or
75 The URI specified by the wsa:Address element of the
wsa:EndpointReference,
76 2. The explicitly stated URI in the uri attribute of the binding.ws
element, which may be
77 relative,
78 3. The implicit URI as defined by the Assembly specification
Why is it an error if both uri and WSDL endpoint are present? The spec
seems
to say we should use the WSDL endpoint over the binding uri in this case
and
they are not exclusive. Maybe I miss some points. Please clarify.
Thanks,
Raymond
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, July 14, 2007 2:19 AM
Subject: svn commit: r556249 -
/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
Author: antelder
Date: Sat Jul 14 02:18:59 2007
New Revision: 556249
URL: http://svn.apache.org/viewvc?view=revrev=556249
Log:
Remove unused import,
add back in throwing exception when using wsdl port endpoint but a uri
is
specified on the scdl binding
(not sure why that got commented out, all the tests pass with it in and
it
makes it much easier to debug so adding it back and see if anyone
complains)
Modified:
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
Modified:
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java?view=diffrev=556249r1=556248r2=556249
==
---
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
(original)
+++
incubator/tuscany/java/sca/modules/binding-ws-axis2/src/main/java/org/apache/tuscany/sca/binding/axis2/Axis2ServiceBindingProvider.java
Sat Jul 14 02:18:59 2007
@@ -65,7 +65,6 @@
private ConfigurationContext configContext;
private MessageFactory messageFactory;
private Axis2ServiceBindingProvider callbackProvider;
-private InterfaceContract bindingInterfaceContract;
// TODO: what to do about the base URI?
private static final String BASE_URI = http://localhost:8080/;;
@@ -193,9 +192,9 @@
wsdlURI = getEndpoint(wsBinding.getPort());
}
if (wsdlURI != null wsdlURI.isAbsolute()) {
-//if (wsBinding.getURI() != null
(wsBinding.getServiceName() != null wsBinding.getBindingName() ==
null)) {
-//throw new IllegalArgumentException(binding URI
cannot
be used with absolute WSDL endpoint URI);
-//}
+if (wsBinding.getURI() != null
(wsBinding.getServiceName
()
!= null wsBinding.getBindingName() == null)) {
+throw new IllegalArgumentException(binding URI cannot
be
used with absolute WSDL endpoint URI);
+}
return URI.create(wsdlURI.toString());
}
-
Re: Website ACL
I think this is exactly what I'm proposing. The only requirement is that, someone that we would consider for Website wiki committership MUST have a CLA in place. We could even promote voting for this karma, although I don't think this is widely recognized in ASF. On 7/15/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I think that we should consider the idea of Website Wiki committership separately from Code committership. +1 I don't think that it should be necessary for someone to have Code committership in order to be granted update access to the Website/Wiki. +1 I do agree that it needs to be controlled, but that we should draw up a wider list of folk who are allowed to edit material on the Website. As has been pointed out, updates to the website have slowed down since we restricted write access. This is not good. Our website needs plenty of work. Yours, Mike. Luciano Resende wrote: My only concern is that, after we restricted access to our wiki, and started using the process of JIRA or updates on the other wiki space, the website contributions basically stopped. I think we had only one JIRA created on this space. On 7/13/07, ant elder [EMAIL PROTECTED] wrote: On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote: I was referring to the following paragraph... a CLA is required for cover substantial contributions for source. therefore wiki karma must only be granted those with a CLA. Yes but that doesn't mean that the converse is also true, ie just having a CLA doesn't give the right to be granted wiki karma. +1 Robert also says later on : a committer is essentially a developer with a CLA and also that provenance needs to be established and oversight maintained If we have control to who gets access, and we are covered, on the legal aspects, by having the CLA in place, we should be Ok. What are your concerns here ? As with the code, it requires more than just having a CLA to be granted commit access to our SVN. The other two alternatives I see are : - Make wiki patches, or copies from ocpy of the website wiki - Make all website contributors a Tuscany committer +1, both of these seem appropriate to me. People can raise JIRAs and do proposed updates on the TUSCANYWIKI space, once they've proven themselves we can vote them in as a website committer just like from code contributions. ...ant - 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]
[jira] Created: (TUSCANY-1435) CastCastException is thrown when both JSONRPC and EJBBinding are on the classpath
CastCastException is thrown when both JSONRPC and EJBBinding are on the
classpath
-
Key: TUSCANY-1435
URL: https://issues.apache.org/jira/browse/TUSCANY-1435
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-0.91, Java-SCA-Next
Reporter: Raymond Feng
Priority: Critical
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:s=http://store;
name=store
component name=Catalog
implementation.java class=services.CatalogImpl/
service name=Catalog
binding.jsonrpc /
/service
/component
/composite
launch code lools like follows
package launch;
import org.apache.tuscany.sca.host.embedded.SCADomain;
public class Launch {
public static void main(String[] args) throws Exception {
System.out.println(Starting ...);
SCADomain scaDomain = SCADomain.newInstance(store.composite);
System.out.println(store.composite ready for big business !!!);
System.out.println();
}
}
seeing the following in the console
Starting ...
Exception in thread main org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:263)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68)
at launch.Launch.main(Launch.java:9)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:148)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:229)
... 2 more
Caused by: org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:602)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:145)
... 3 more
Caused by: java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.binding.ejb.EJBBindingActivator.createService(EJBBindingActivator.java:34)
at
org.apache.tuscany.sca.spi.impl.BindingsActivator$1$2.init(BindingsActivator.java:120)
at
org.apache.tuscany.sca.spi.impl.BindingsActivator$1.createServiceBindingProvider(BindingsActivator.java:119)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.configureComposite(CompositeActivatorImpl.java:111)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:599)
... 4 more
--
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-1435) CastCastException is thrown when both JSONRPC and EJBBinding are on the classpath
[
https://issues.apache.org/jira/browse/TUSCANY-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng updated TUSCANY-1435:
--
Attachment: store.zip
Here is the test case
CastCastException is thrown when both JSONRPC and EJBBinding are on the
classpath
-
Key: TUSCANY-1435
URL: https://issues.apache.org/jira/browse/TUSCANY-1435
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-0.91, Java-SCA-Next
Reporter: Raymond Feng
Priority: Critical
Attachments: store.zip
compositexmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:s=http://store;
name=store
component name=Catalog
implementation.java class=services.CatalogImpl/
service name=Catalog
binding.jsonrpc /
/service
/component
/composite
launch code lools like follows
package launch;
import org.apache.tuscany.sca.host.embedded.SCADomain;
public class Launch {
public static void main(String[] args) throws Exception {
System.out.println(Starting ...);
SCADomain scaDomain = SCADomain.newInstance(store.composite);
System.out.println(store.composite ready for big business !!!);
System.out.println();
}
}
seeing the following in the console
Starting ...
Exception in thread main org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:263)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68)
at launch.Launch.main(Launch.java:9)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:148)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:229)
... 2 more
Caused by: org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:602)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:145)
... 3 more
Caused by: java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.binding.ejb.EJBBindingActivator.createService(EJBBindingActivator.java:34)
at
org.apache.tuscany.sca.spi.impl.BindingsActivator$1$2.init(BindingsActivator.java:120)
at
org.apache.tuscany.sca.spi.impl.BindingsActivator$1.createServiceBindingProvider(BindingsActivator.java:119)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.configureComposite(CompositeActivatorImpl.java:111)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:599)
... 4 more
--
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-1435) CastCastException is thrown when both JSONRPC and EJBBinding are on the classpath
[
https://issues.apache.org/jira/browse/TUSCANY-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512825
]
Raymond Feng commented on TUSCANY-1435:
---
After debugging, I found the problem in
org.apache.tuscany.sca.spi.impl.BindingsActivator.java which registers multiple
provider factories under the same key: PojoBinding.class.
I have a fix and will check it in soon.
Thanks,
Raymond
CastCastException is thrown when both JSONRPC and EJBBinding are on the
classpath
-
Key: TUSCANY-1435
URL: https://issues.apache.org/jira/browse/TUSCANY-1435
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-0.91, Java-SCA-Next
Reporter: Raymond Feng
Priority: Critical
Attachments: store.zip
compositexmlns=http://www.osoa.org/xmlns/sca/1.0;
xmlns:s=http://store;
name=store
component name=Catalog
implementation.java class=services.CatalogImpl/
service name=Catalog
binding.jsonrpc /
/service
/component
/composite
launch code lools like follows
package launch;
import org.apache.tuscany.sca.host.embedded.SCADomain;
public class Launch {
public static void main(String[] args) throws Exception {
System.out.println(Starting ...);
SCADomain scaDomain = SCADomain.newInstance(store.composite);
System.out.println(store.composite ready for big business !!!);
System.out.println();
}
}
seeing the following in the console
Starting ...
Exception in thread main org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:263)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:68)
at launch.Launch.main(Launch.java:9)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:148)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:229)
... 2 more
Caused by: org.apache.tuscany.sca.core.runtime.ActivationException:
java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:602)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:145)
... 3 more
Caused by: java.lang.ClassCastException:
org.apache.tuscany.sca.binding.jsonrpc.JSONRPCBinding incompatible with
org.apache.tuscany.sca.binding.ejb.EJBBinding
at
org.apache.tuscany.sca.binding.ejb.EJBBindingActivator.createService(EJBBindingActivator.java:34)
at
org.apache.tuscany.sca.spi.impl.BindingsActivator$1$2.init(BindingsActivator.java:120)
at
org.apache.tuscany.sca.spi.impl.BindingsActivator$1.createServiceBindingProvider(BindingsActivator.java:119)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.configureComposite(CompositeActivatorImpl.java:111)
at
org.apache.tuscany.sca.core.runtime.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:599)
... 4 more
--
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 Programming model for multiple implementations Fwd: [jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support
Hi Amita I was taking a quick look in your proposed changes in the DAS API that is in my sandbox, could you please elaborate your thoughts around the programming model proposed here [1] ? Have you looked at the implications of these changes on other DAS implementations, such as LDAP DAS ? [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html -- Forwarded message -- From: Amita Vadhavkar (JIRA) tuscany-dev@ws.apache.org Date: Jul 15, 2007 10:56 AM Subject: [jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support To: tuscany-dev@ws.apache.org [ https://issues.apache.org/jira/browse/TUSCANY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1431: - Attachment: 1431_xquery.patch 1431_api.patch this is just a work in progress, where config (xquery specific) is created and some basic classes are in progress. trying and checking different XQuery implementations available - like Saxon, DB2 Express etc. Next patch will have some work on that. Please give suggestions based on patch and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19983.html Thanks, Amita 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 Attachments: 1431_api.patch, 1431_xquery.patch 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] -- 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: DAS Programming model for multiple implementations Fwd: [jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support
Hi, I reviewed Luciano's sandbox code a while back, and will integrate it once I have tested all the CRUD operations / the classes that are the workhorses..., so any changes will have minimal impact on the LDAP DAS at them moment. Cheers, - Ole Luciano Resende wrote: Hi Amita I was taking a quick look in your proposed changes in the DAS API that is in my sandbox, could you please elaborate your thoughts around the programming model proposed here [1] ? Have you looked at the implications of these changes on other DAS implementations, such as LDAP DAS ? [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg14428.html -- Forwarded message -- From: Amita Vadhavkar (JIRA) tuscany-dev@ws.apache.org Date: Jul 15, 2007 10:56 AM Subject: [jira] Updated: (TUSCANY-1431) DAS with XQuery based data access support To: tuscany-dev@ws.apache.org [ https://issues.apache.org/jira/browse/TUSCANY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amita Vadhavkar updated TUSCANY-1431: - Attachment: 1431_xquery.patch 1431_api.patch this is just a work in progress, where config (xquery specific) is created and some basic classes are in progress. trying and checking different XQuery implementations available - like Saxon, DB2 Express etc. Next patch will have some work on that. Please give suggestions based on patch and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg19983.html Thanks, Amita 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 Attachments: 1431_api.patch, 1431_xquery.patch 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Website ACL
Ant wrote: So no problem, when someone comes along we want to grant access just discuss and vote on the private list and we can just give them access. +1 On 7/15/07, ant elder [EMAIL PROTECTED] wrote: The Apache CWIKI page is now quite clear about this (not sure what changed, i thought some cwiki page used to say the opposite?) - An individual person contributing documentation in this way is not required to be a committer, but he or she does need to file a CLA, so that there is no doubt that the individual intends to contribute the copyright on the documentation to the ASF. Of course, whenever anyone makes welcome and sustained contributions to the documentation, it is appropriate to invite that person to become a committer and PMC Member, and share in the decision making. - see http://cwiki.apache.org/CWIKI/. So no problem, when someone comes along we want to grant access just discuss and vote on the private list and we can just give them access. If we could get cwiki change emails sent to the tuscany-commit mailing list so its easy to give some oversight then I'd be in favour of a very low bar of entry. ...ant On 7/15/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, I think that we should consider the idea of Website Wiki committership separately from Code committership. I don't think that it should be necessary for someone to have Code committership in order to be granted update access to the Website/Wiki. I do agree that it needs to be controlled, but that we should draw up a wider list of folk who are allowed to edit material on the Website. As has been pointed out, updates to the website have slowed down since we restricted write access. This is not good. Our website needs plenty of work. Yours, Mike. Luciano Resende wrote: My only concern is that, after we restricted access to our wiki, and started using the process of JIRA or updates on the other wiki space, the website contributions basically stopped. I think we had only one JIRA created on this space. On 7/13/07, ant elder [EMAIL PROTECTED] wrote: On 7/13/07, Luciano Resende [EMAIL PROTECTED] wrote: I was referring to the following paragraph... a CLA is required for cover substantial contributions for source. therefore wiki karma must only be granted those with a CLA. Yes but that doesn't mean that the converse is also true, ie just having a CLA doesn't give the right to be granted wiki karma. +1 Robert also says later on : a committer is essentially a developer with a CLA and also that provenance needs to be established and oversight maintained If we have control to who gets access, and we are covered, on the legal aspects, by having the CLA in place, we should be Ok. What are your concerns here ? As with the code, it requires more than just having a CLA to be granted commit access to our SVN. The other two alternatives I see are : - Make wiki patches, or copies from ocpy of the website wiki - Make all website contributors a Tuscany committer +1, both of these seem appropriate to me. People can raise JIRAs and do proposed updates on the TUSCANYWIKI space, once they've proven themselves we can vote them in as a website committer just like from code contributions. ...ant - 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]
[jira] Assigned: (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 reassigned TUSCANY-1237: Assignee: Luciano Resende 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]
[jira] Created: (TUSCANY-1436) TypeHelper.getType(java.util.List.class) throws ClassCastException
TypeHelper.getType(java.util.List.class) throws ClassCastException
--
Key: TUSCANY-1436
URL: https://issues.apache.org/jira/browse/TUSCANY-1436
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Java-SDO-beta1, Java-SDO-1.0
Reporter: Raymond Feng
Priority: Critical
The following simple test case fails:
package org.apache.tuscany.sdo.test;
import java.util.List;
import junit.framework.TestCase;
import commonj.sdo.helper.TypeHelper;
/**
* @version $Rev$ $Date$
*/
public class TypeHelperTestCase extends TestCase {
public void testGetType() {
assertTrue(TypeHelper.INSTANCE.getType(List.class) instanceof
commonj.sdo.Type);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-684) Generated SDO classes should be able to register the static types to a given TypeHelper
[ https://issues.apache.org/jira/browse/TUSCANY-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-684. Generated SDO classes should be able to register the static types to a given TypeHelper --- Key: TUSCANY-684 URL: https://issues.apache.org/jira/browse/TUSCANY-684 Project: Tuscany Issue Type: New Feature Components: Java SDO Implementation Affects Versions: Java-SCA-M2 Reporter: Raymond Feng Assignee: Frank Budinsky Fix For: Java-SDO-beta1 In the generated SDO classes, static types are automatically registered into the EMF global registry. This behavior prevent us from keeping SDO types into different scopes defined by external schemes. It would be nice that we can do somthing like: SDOUtil.registerStaticTypes(TypeHelper scope, Class factoryClass); Thanks, Raymond -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-358) TypeHelper.getType(Class ...) either returns unexpected Type or throws ClassCastException for java .lang.String or other simple java types
[ https://issues.apache.org/jira/browse/TUSCANY-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-358. TypeHelper.getType(Class ...) either returns unexpected Type or throws ClassCastException for java .lang.String or other simple java types -- Key: TUSCANY-358 URL: https://issues.apache.org/jira/browse/TUSCANY-358 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-M1-tentative Reporter: Raymond Feng Assignee: Frank Budinsky Priority: Critical Fix For: Java-M1-tentative I ran into two problems: 1) If I happens to initialize EMF XMLTypePackage, TypeHelper.getType(String.class) throws a ClassCastException java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EDataTypeImpl incompatible with commonj.sdo.Type at org.apache.tuscany.sdo.helper.TypeHelperImpl.getType(TypeHelperImpl.java:92) 2) Otherwise I received [EMAIL PROTECTED] (name: LangType) (instanceClassName: java.lang.String) (serializable: true) and the EPackage is: [EMAIL PROTECTED] (name: namespace) (nsURI: http://www.w3.org/XML/1998/namespace, nsPrefix: xml) It seems that the SDO spec doesn't well define the behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-112) Generated SDO2 DataObject class throws ClassCastException when DataObject.getType() is called
[ https://issues.apache.org/jira/browse/TUSCANY-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-112. Generated SDO2 DataObject class throws ClassCastException when DataObject.getType() is called - Key: TUSCANY-112 URL: https://issues.apache.org/jira/browse/TUSCANY-112 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Reporter: Raymond Feng Priority: Critical These 4 lines of code will fail: import org.apache.tuscany.model.scdl.Module; import org.apache.tuscany.model.scdl.ScdlFactory; Module module = ScdlFactory.INSTANCE.createModule(); Type type = ((DataObject) module).getType(); Exception in thread main java.lang.ClassCastException: org.eclipse.emf.ecore.impl.EClassImpl incompatible with commonj.sdo.Type at org.apache.tuscany.sdo.impl.DataObjectImpl.getType(DataObjectImpl.java:319) at org.apache.tuscany.axis2.stax.AxiomHelper.main(AxiomHelper.java:135) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-969) Add pass-by-value support for remotable interfaces
[ https://issues.apache.org/jira/browse/TUSCANY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-969. Add pass-by-value support for remotable interfaces Key: TUSCANY-969 URL: https://issues.apache.org/jira/browse/TUSCANY-969 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Raymond Feng Assignee: Venkatakrishnan Fix For: Java-SCA-Next Attachments: PassByValueInterceptor.java, PassByValueInterceptorTestCase.java, Tuscany-JIRA-969-Dec07-06.diff I open this JIRa to track the efforts to add pass-by-value support for remotable interfaces as required by the SCA spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-387) mvn eclipse:eclipse is broken due to resource./resource section in the top-level pom.xml
[ https://issues.apache.org/jira/browse/TUSCANY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Feng closed TUSCANY-387. mvn eclipse:eclipse is broken due to resource./resource section in the top-level pom.xml Key: TUSCANY-387 URL: https://issues.apache.org/jira/browse/TUSCANY-387 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-M1 Reporter: Raymond Feng Assignee: Jean-Sebastien Delfino Priority: Blocker Fix For: Java-M1 The current maven eclipse plugin doesn't support src folder exclusion pattern. Adding resource.resource to the pom.xml triggers the maven eclipse plugin add the root folder of the project as a source folder and it leads to build path overlapping problem for Eclipse. -- 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-1110) Improve the performance of TypeHelperImpl.getType(Class)
[ https://issues.apache.org/jira/browse/TUSCANY-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512856 ] Raymond Feng commented on TUSCANY-1110: --- Is there any plan to fix this before the SDO 1.0 release? It will have a big impact on the SDO Databinding for SCA. Please see more discussions on http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200702.mbox/[EMAIL PROTECTED] Thanks, Raymond Improve the performance of TypeHelperImpl.getType(Class) Key: TUSCANY-1110 URL: https://issues.apache.org/jira/browse/TUSCANY-1110 Project: Tuscany Issue Type: Improvement Components: Java SDO Implementation Affects Versions: Java-SDO-Next Reporter: Raymond Feng Fix For: Java-SDO-Next In the SDO databinding for SCA, we need to introspect a java class/interface to figure out the corresponding SDO type. Looking into the code, there is a TODO comment: //TODO more efficient implementation ... this is a really bad one! Do you plan to provide a more efficient impl :-)? Thanks, Raymond -- 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 1.0-incubating release candidate 1
Hi I'd like to see the stax dependency issue resolved, otherwise we are going to have issues with DAS and possibly CTS releases that are based on SDO 1.0 release. On 7/15/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I would like to see the following JIRAs fixed before the 1.0 release. https://issues.apache.org/jira/browse/TUSCANY-1110 https://issues.apache.org/jira/browse/TUSCANY-1436 Thanks, Raymond - Original Message - From: kelvin goodson [EMAIL PROTECTED] To: Tuscany Users [EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 2:38 PM Subject: SDO Java 1.0-incubating release candidate 1 I've posted an RC1 of SDO Java 1.0-incubating at [1] Maven artifacts for the release candidate are available at [2] I cut a branch for this release at [3] Please take a look at this release candidate. There are a few more fixes due to go into the release, which should be ready by the end of this week, so there will be a respin of this candidate, but I'd particularly like to get feedback on the structure of the distribution, as a lot has changed in this respect since the beta1. Also please feed back on the install, build and run samples instructions since these have all changed too. Best Regards, Kelvin. [1] http://people.apache.org/~kelvingoodson/sdo_java/1.0-incubating/RC1/ [2] http://people.apache.org/~kelvingoodson/repo/ [3] http://svn.apache.org/repos/asf/incubator/tuscany/branches/sdo-1.0-incubating/ - 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]
